msdeploy (Web Deploy) échoue avec des problèmes d'authentification 401

Question

J'essaie d'obtenir msdeploy installé et configuré. J'ai installé le service à distance sur le serveur web, mais tous mes tests me donnent un message d'erreur. 401 unauthorised error . Le serveur est Windows 2008 R2.

Je teste une commande msdeploy très simple :

msdeploy -verb:dump -source:contentPath=c:\inetpub\wwwroot\MyApp,computerName=<IP HERE>,userName=Domain\msdeploy,password=MyPassword

Et l'erreur :

Error: Object of type 'contentPath' and path 'c:\inetpub\wwwroot\MonApp' cannot be created.
Error: Remote agent (URL http://<IP HERE>/MSDEPLOYAGENTSERVICE) could not be contacted.  Make sure the remote agent service is installed and started on the target computer.
Error: An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected.
Error: The remote server returned an error: (401) Unauthorized.
Error count: 1.

J'ai créé un utilisateur appelé msdeploy et je l'ai ajouté au groupe des administrateurs locaux sur le serveur.

J'ai vérifié :

• Que le service s'est installé correctement et que je l'ai démarré
• Diverses combinaisons pour ne pas utiliser la partie domaine du nom d'utilisateur et ajouter authType=Basic.
• Donner les droits complets à ce dossier à tout le monde
• Dans IIS, autorisez les connexions à distance
• Ajout de règles de délégation de service de gestion pour mon utilisateur "msdeploy" pour contentPath et iisApp (vaguement basé sur la lecture de ce )
• J'ai essayé avec un autre compte d'administrateur que j'utilise pour le RDC sur le serveur...
• J'ai essayé avec différents contentPaths et différentes commandes msdeploy.
• J'ai créé un compte spécifique, et je l'ai ajouté à IIS_Users. J'ai ajouté cet utilisateur à mon site web "IIS Manager Permissions", et configuré "Management Service Delegation" pour tous les fournisseurs.

Answer 1

Je suppose que vous avez configuré votre serveur correctement pour WebDeploy 2.0 selon cet article :

Configurer Web Deploy (IIS.NET)

Note : MS a publié une mise à jour de Web Deploy 2.0 et le lien original n'est plus vraiment valide. J'ai mis à jour ce lien mais je pense que ce sera une cible mouvante au fil du temps.

Vous devez également installer Web Deploy 2.0 sur votre machine de développement/construction/CI.

Si vous utilisez encore la version 1.0, je vous recommande de la mettre à jour, car la version 2.0 comporte d'énormes améliorations.

Utilisation de la fonction de publication de Visual Studio 2010 :

Visual Studio peut publier un site en faisant un clic droit sur le site et en sélectionnant "Publish". La boîte de dialogue suivante apparaît alors :

Il y a quelques problèmes avec Visual Studio 2010 et WebDeploy 2.0. La première est que VS2010 n'est pas compatible avec WebDeploy/MSDeploy 2.0. Ainsi, si vous essayez de publier, vous obtiendrez une erreur telle que la suivante :

Erreur 1 Tâche de déploiement Web a échoué.((04/02/2011 12:30:40) Une erreur s'est produite lorsque la demande a été traitée sur l'ordinateur distant).

Vous verrez également l'erreur suivante dans le traçage des requêtes échouées pour le service de gestion Web sur le serveur en C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1 en supposant que vous l'ayez activé :

AspNetModuleDiagErrorEvent
Uri /msdeploy.axd
eventData Traçage exception de l'agent de déploiement. ID de la demande ''. Horodatage de la demande : '02/04/2011
System.UnauthorizedAccessException : L'accès au chemin 'D:\' est refusé.

La lettre de lecteur varie en fonction du lecteur sur lequel se trouve votre site IIS.

Le mécanisme de publication de l'interface utilisateur utilise par défaut la mauvaise version de MSDeploy (1.0). Nous voulons dire à VS2010 d'utiliser MSDeploy 2.0. Vous pouvez le faire en modifiant le fichier de Visual Studio 2010 devenv.exe.config qui est situé dans (en supposant que vous avez fait un défaut c:\ installation du lecteur) :

Pour les systèmes 64 bits : c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE Pour les systèmes 32 bits : c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

Ouvrez devenv.exe.config dans votre éditeur XML préféré (j'ai simplement utilisé Visual Studio 2010 lui-même) et copiez le xml suivant :

<dependentAssembly>
  <assemblyIdentity 
    name="Microsoft.Web.Deployment" 
    publicKeyToken="31bf3856ad364e35" culture="neutral"/>
  <bindingRedirect oldVersion="7.1.0.0" newVersion="8.0.0.0"/>
</dependentAssembly>

Ajoutez ceci à la /configuration/runtime/assemblyBinding section :

Une fois que vous avez fait cela, fermez toutes les instances de Visual Studio 2010 pour permettre à ce changement de prendre effet. Redémarrez VS2010, ouvrez un projet Web et essayez à nouveau de publier. Cette fois, la publication devrait réussir.

Publication à l'aide d'un paquet de construction :

Visual Studio peut produire un paquet de construction qui peut être exécuté à partir de la ligne de commande. Celui-ci est généré en utilisant Project -> Build Deployment Package . Pratique pour l'intégration continue et autres (le paquet peut aussi être généré en utilisant msbuild avec l'option /t:Package interrupteur).

Le dossier de sortie du paquet est généralement défini par défaut comme suit obj\Package .

Malheureusement, Visual Studio 2010 s'y prend un peu mal et génère un lot msdeploy wrapper script ciblant 1.0 et ciblant le déploiement au niveau du serveur plutôt que du site.

Il n'y a pas de solution rapide pour cela, si ce n'est de créer votre propre ligne de commande msdeploy.exe. J'ai divisé ceci en plusieurs lignes pour rendre cela un peu plus lisible.. :

"C:\\Program Files\\IIS\\Microsoft Web Deploy v2\\\\msdeploy.exe"
  -source:archiveDir='d:\\sites\\DemoApp\\obj\\Package\\Archive' 
  -dest:
       auto,
       computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename',
       userName='demosite',
       password='somepassword',
       authtype='basic',
       includeAcls='False' 
  -verb:sync 
  -disableLink:AppPoolExtension 
  -disableLink:ContentExtension 
  -disableLink:CertificateExtension 
  -setParamFile:"d:\\sites\\DemoApp\\obj\\Package\\Archive.SetParameters.xml"   
  -allowuntrusted

La première chose à noter est le chemin vers msdeploy.exe . Visual Studio génère un chemin vers la version 1.0. Je l'ai modifié pour utiliser la version 2.0.

Paramètres notables :

-source:archiveDir= indique à msdeploy que nous déployons un paquet et fournit l'emplacement local

computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename' - ceci indique à MSDEPLOY de se déployer sur un site spécifique sur IIS7. yoursitename doit correspondre exactement au nom du site dans IIS.

userName et password est le nom de l'utilisateur gestionnaire délégué pour le site. Il est configuré à l'aide de la fonction "IIS Manager Permissions" au niveau du site. Le compte doit être un compte d'utilisateur Windows local.

-authtype='basic' - cela force l'authentification de base, sinon l'authentification NTLM est tentée.

-allowuntrusted - ceci ignore toute erreur de certificat SSL si vous utilisez le certificat SSL auto-signé intégré.

Si vous utilisez cette ligne de commande, vous devriez être en mesure de déployer avec succès sur un serveur IIS7 distant.

Publication de contenu brut :

Parfois, nous voulons simplement publier un contenu statique (ou peut-être même un site ASP ou PHP classique) directement à partir d'un dossier local. Nous pouvons le faire en utilisant la méthode suivante msdeploy.exe ligne de commande :

"C:\\Program Files\\IIS\\Microsoft Web Deploy v2\\\\msdeploy.exe" 
  -source:contentPath='d:\\websites\\mysite' 
  -dest:
     contentPath='yoursitename',
     computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename',
     userName='demosite',
     password='somepassword',
     authtype='basic',
     includeAcls='False' 
-verb:sync 
-allowuntrusted 

Là encore, les mêmes règles s'appliquent que précédemment pour -dest:contentPath et computerName .

Je pense que les problèmes de version de MSDeploy seront résolus dans le SP1 (que je n'ai pas encore eu l'occasion de regarder).

Une dernière erreur de VS2010 :

Lors de la publication à l'aide de Visual Studio 2010, le paquet de construction "Publish" fait passer les listes de contrôle d'accès du compte anonyme du site en lecture seule pour tous les fichiers et dossiers, à l'exception de l'élément de menu "Publish". App_Data qui est changé en lecture et écriture.

Il est possible de contourner ce problème en ajoutant le paramètre suivant à la section .csproj sous chaque <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> :

<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>

Ou si vous utilisez msbuild :

msbuild.exe myproject.csproj /t:Package /p:IncludeSetAclProviderOnDestination=False

J'ai trouvé cette pépite utile ici :

Sauter la définition d'une ACL dans un paquet de déploiement Visual Studio 2010 (Lien WayBackMachine car le contenu original n'est plus disponible)

Answer 2

Pour moi, l'édition a fonctionné dans Visual Studio, mais pas lorsque j'ai exécuté l'application .deploy.cmd script.

En fixant <UseMsdeployExe>true</UseMsdeployExe> dans votre .csproj vous pouvez forcer VS à utiliser msdeploy.exe au lieu d'une tâche MSBuild. Ensuite, en augmentant le niveau de journalisation (Tools > Options > Projects and Solutions > Build and Run > MSBuild project build output verbosity), vous pouvez voir la ligne de commande que VS utilise.

Les problèmes avec mon .deploy.cmd étaient :

• Mon utilisateur IIS n'avait les droits que sur ce site, j'avais donc besoin de ?site=<SITENAME> dans le computerName .
• J'avais besoin AuthType='Basic' dans le -dest: paramètre.

Answer 3

Nous étions confrontés à un problème similaire au vôtre.

Pour cela, vous devez lancer le service d'agent distant dans les services. Nous avons utilisé le nom du PC car l'adresse IP donnait une erreur. Essayez donc d'utiliser le nom du PC, le nom d'utilisateur et le mot de passe.

Answer 4

En fin de compte, je n'ai jamais pu déterminer quelles étaient les permissions manquantes avec mon compte utilisateur de déploiement, mais j'ai constaté que si j'utilisais le compte administrateur de la machine, le déploiement réussissait. Pour l'instant, j'utilise le compte administrateur pour effectuer le déploiement.

Bravo à Kev pour ce résumé fantastique et informatif de la mise en place de ms deploy 2 :)

Answer 5

Pour ce que ça vaut. La publication fonctionnait pour moi et puis un jour j'ai eu ce même problème (erreur 401 non autorisée) Le redémarrage de VS2012 a résolu le problème. J'aurais aimé essayer cela avant d'essayer toutes les autres solutions.