msdeploy (Web Deploy) en échec avec 401 problèmes d'authentification
J'essaie d'obtenir msdeploy installé et configuré. J'ai installé le service distant sur le serveur Web, mais tous mes tests me donnent un 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 d'administrateurs locaux sur le serveur.
J'ai vérifié:
- Que le service est correctement installé et que je l'ai démarré
- Diverses combinaisons pour ne pas utiliser la partie domaine du nom d'utilisateur et ajouter authType = Basic
- Étant donné les autorisations complètes sur ce dossier à tout le monde
- Dans IIS autoriser les connexions à distance
- Ajout de règles de délégation de service de gestion pour mon utilisateur "msdeploy" pour contentPath et iisApp (généralement basé sur la lecture this )
- Essayé avec un compte d'administrateur différent que j'utilise pour RDC sur le serveur ...
- Essayé avec différents contentPaths et différentes commandes msdeploy
- Créé un compte spécifique et ajouté ce compte aux utilisateurs IIS. Ajout de cet utilisateur à mon site Web "Autorisations du gestionnaire IIS" et configuration de "Délégation de service de gestion" pour tous les fournisseurs.
Je suppose que vous avez correctement configuré votre serveur pour WebDeploy 2.0 conformément à cet article:
Remarque: MS a publié une actualisation de Web Deploy 2.0 et le lien d'origine n'est plus vraiment valide. Je l'ai mis à jour, mais je pense que ce sera une cible mouvante dans le temps.
Vous devez également installer Web Deploy 2.0 sur votre ordinateur de développement/build/CI.
Si vous utilisez toujours la version 1.0, je vous recommande de mettre à jour, il y a des améliorations énormes dans la version 2.0.
Utilisation de la fonctionnalité de publication de Visual Studio 2010:
Visual Studio peut publier un site en cliquant dessus avec le bouton droit de la souris et en sélectionnant "Publier". Cela amène le dialogue suivant:
Il y a quelques pièges avec Visual Studio 2010 et WebDeploy 2.0. La première est que VS2010 n'est pas conscient de WebDeploy/MSDeploy 2.0. Donc, si vous essayez de publier, vous obtiendrez une erreur comme celle-ci:
Erreur 1 La tâche de déploiement Web A échoué. ((04/02/2011 12:30:40) Une erreur S'est produite lors du traitement de la demande Sur l'ordinateur distant.)
L'erreur suivante apparaît également dans le traçage des demandes ayant échoué pour le service de gestion Web sur le serveur dans C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1, en supposant que cela soit activé:
AspNetModuleDiagErrorEvent
Uri /msdeploy.axd
eventData Tracing exception d'agent de déploiement. ID de la demande ''. Demande d'horodatage: '02/04/2011
System.UnauthorizedAccessException: L'accès au chemin 'D: \' est refusé.
La lettre du lecteur varie en fonction du lecteur sur lequel se trouve votre site IIS.
Par défaut, le mécanisme de publication intégré à l'interface graphique utilise par défaut la version incorrecte de MSDeploy (1.0). Nous voulons dire à VS2010 d'utiliser MSDeploy 2.0. Vous pouvez le faire en modifiant le fichier devenv.exe.config de Visual Studio 2010 qui se trouve dans (en supposant que vous avez installé le lecteur c:\ par défaut):
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é (je viens d'utiliser Visual Studio 2010 lui-même) et copiez le code 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 section /configuration/runtime/assemblyBinding:
Une fois cette opération effectuée, fermez toutes les instances de Visual Studio 2010 pour que cette modification soit prise en compte. Redémarrez VS2010, ouvrez un projet Web, puis essayez à nouveau de publier. Cette fois, ça devrait être réussi.
Publication à l'aide d'un package de construction:
Visual Studio peut générer un package de génération pouvant être exécuté à partir de la ligne de commande. Ceci est généré en utilisant Project -> Build Deployment Package. Pratique pour l'intégration continue et similaire (le paquet peut également être généré en utilisant msbuild avec le commutateur /t:Package).
La valeur par défaut du dossier de sortie du paquet est généralement obj\Package.
Malheureusement, Visual Studio 2010 se trompe un peu et génère un script de traitement par lots pour le wrapper msdeploy visant 1.0 et ciblant le déploiement sur le serveur plutôt que sur le 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. Je l'ai divisé en plusieurs lignes pour le rendre un peu plus lisible.:
"C:\Programmes\IIS\Web Web Deploy v2 \\ msdeploy.exe" -Source: archiveDir = 'd:\sites\DemoApp\obj\Package\Archive' -dest: auto, nom ordinateur = 'https: //votresite.com: 8172/msdeploy.axd? site = nom_site', nomutilisateur = 'demosite' , mot de passe = 'un mot de passe', authtype = 'base', 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 d'accès à msdeploy.exe. Visual Studio génère un chemin d'accès à la version 1.0. J'ai changé cela pour utiliser 2.0.
Paramètres notables: _
-source:archiveDir= indique à msdeploy que nous déployons un package et fournit l'emplacement local
computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename' - cela 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 sont le nom de l'utilisateur du gestionnaire délégué pour le site. Ceci est configuré à l'aide de la fonctionnalité "Autorisations du gestionnaire IIS" au niveau du site. Le compte doit être un compte d'utilisateur Windows local.
-authtype='basic' - ceci force l'authentification de base sinon l'authentification NTLM est tentée.
-allowuntrusted - cela ignore les erreurs de certificat SSL si vous utilisez le certificat SSL auto-signé intégré.
Si vous utilisez cette ligne de commande, vous devriez pouvoir déployer avec succès sur un serveur IIS7 distant.
Publication du contenu brut:
Parfois, nous souhaitons simplement publier du contenu statique (ou peut-être même un site Classic ASP ou PHP) directement à partir d'un dossier local. Nous pouvons le faire en utilisant la ligne de commande msdeploy.exe suivante:
"C:\Programmes\IIS\Web Web Deploy v2 \\ msdeploy.exe" -Source: contentPath = 'd:\websites\mysite' -Dest: contentPath = 'votre nom de site', nom_ordinateur = 'https: //votresite.com: 8172/msdeploy.axd? site = votre nom de site', nomutilisateur = 'demosite', mot de passe = 'un mot de passe', authtype = 'base', includeAcls = 'False' - verbe: sync - allowuntrusted
Encore une fois, les mêmes règles s'appliquent que précédemment pour -dest:contentPath et computerName.
Je pense que les problèmes liés à la version de MSDeploy seront résolus dans le SP1 (que je n'ai pas encore eu la chance d'examiner).
Un Final VS2010 obtenu:
Lors de la publication à l'aide de Visual Studio 2010, le package de génération "Publier" entraîne la modification de la liste de contrôle d'accès du compte anonyme du site sur Lecture seule pour tous les fichiers et dossiers, à l'exception du dossier App_Data qui a été remplacé par Lecture et écriture.
Cela peut être contourné en ajoutant le paramètre suivant au fichier .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 d'ici:
Saut de la définition d'une liste de contrôle d'accès dans un package de déploiement de Visual Studio 2010 (lien WayBackMachine car le contenu d'origine n'est plus disponible)
Pour moi, la publication fonctionnait dans Visual Studio, mais cela n’a pas fonctionné lorsque j’ai exécuté le script .deploy.cmd.
En définissant <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 (Outils> Options> Projets et solutions> Construire et exécuter> Verbosité de la sortie du projet MSBuild), vous pouvez voir la ligne de commande utilisée par le VS.
Les problèmes avec mon .deploy.cmd étaient:
- Mon utilisateur IIS ne disposait que d'autorisations sur ce site. J'avais donc besoin de
?site=<SITENAME>danscomputerName. - J'avais besoin de
AuthType='Basic'dans le paramètre-dest:.
Nous étions confrontés à un problème similaire au vôtre.
Pour cela, vous devez démarrer le service d'agent distant dans les services. Nous avons utilisé le nom du PC car l'adresse IP générait une erreur. Donc, essayez d'utiliser le nom de l'ordinateur, nom d'utilisateur et mot de passe.
En fin de compte, je n'ai jamais demandé quelles autorisations me manquaient avec mon compte d'utilisateur de déploiement - mais j'ai constaté que si j'utilisais le compte d'administrateur de la machine, le déploiement aboutirait. Pour l'instant, j'utilise le compte administrateur pour effectuer le déploiement.
Félicitations à Kev pour le résumé fantastique et informatif de la configuration de ms deploy 2 :)
Pour ce que ça vaut. La publication fonctionnait pour moi et un jour, j'ai eu le même problème (erreur 401 non autorisée). Le redémarrage de VS2012 a résolu le problème. J'aurais aimé essayer avant d'essayer toute autre solution.