msdeploy (Web Deploy) échoue avec 401 problèmes auth
-
09-10-2019 - |
Question
Je suis en train d'obtenir msdeploy
installé et mis en place. J'ai installé le service à distance 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 Administrateurs locaux sur le serveur.
Je l'ai vérifié:
- Que le service installé correctement et je l'ai commencé
- Diverses combinaisons de ne pas utiliser la partie de domaine du nom d'utilisateur, et en ajoutant authType = Basic
- Étant donné les autorisations à ce dossier à tous
- Dans IIS permettent des connexions à distance
- Ajout délégation service de gestion des règles pour mon utilisateur « msdeploy » pour contentPath et iisapp (vaguement basé sur la lecture cette )
- J'ai essayé avec un autre compte administrateur pour une utilisation I RDC au serveur ...
- essayé avec différents contentPaths et différentes commandes msdeploy
- créé un compte spécifique, et a ajouté que compte aux IIS_Users. A ajouté que l'utilisateur sur mon site Web « Gestionnaire des services Internet Autorisations », et la configuration « Délégation de Service de gestion » pour tous les fournisseurs.
La solution
Je suppose que vous avez configuré correctement votre serveur pour WebDeploy 2.0 selon cet article:
Note: MS ont publié un rafraîchissement de déploiement Web 2.0 et le lien d'origine n'est pas vraiment plus valable. Je l'ai mis à jour, mais je pense que ce sera une cible en mouvement au fil du temps.
Vous devez également installer Web Deploy 2.0 sur votre développement / construction / machine CI.
Si vous utilisez encore 1.0 alors je recommande la mise à niveau, il y a quelques améliorations énormes dans la version 2.0.
Utilisation de Visual Studio 2010 Publier Feature:
Visual Studio peut publier un site en cliquant droit sur le site et en sélectionnant « Publier ». Cela fait apparaître le dialogue suivant:
Il y a quelques erreurs et pièges avec Visual Studio 2010 et WebDeploy 2.0. La première est que VS2010 est pas WebDeploy / MSDeploy 2.0 conscient. Donc, si vous essayez de vous publier obtiendrez une erreur, comme suit:
Erreur 1 tâche de déploiement Web échoué. ((02.04.2011 12:30:40) Une erreur eu lieu lorsque la demande était traité sur l'ordinateur distant.)
Vous verrez également l'erreur suivante dans la requête a échoué du suivi pour le service de gestion Web sur le serveur C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1
en supposant que vous avez ce sous tension:
AspNetModuleDiagErrorEvent
Uri /msdeploy.axd
EventData Tracing exception de l'agent de déploiement. demande ID ''. Demande Timestamp: '02 / 04/2011
System.UnauthorizedAccessException: L'accès au chemin 'D: \'. Est refusé
La lettre de lecteur variera en fonction de votre lecteur qui IIS site est situé sur.
Hors de la boîte, la valeur par défaut de publication du mécanisme en utilisant l'interface graphique pour la version incorrecte de MSDeploy (1.0). Nous voulons dire VS2010 utiliser MSDeploy 2.0. Vous pouvez le faire en éditant le fichier devenv.exe.config
de Visual Studio 2010 qui est situé dans (en supposant que vous avez un c:\
lecteur d'installation 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 que vous avez fait fermer toutes les instances de Visual Studio 2010 pour permettre cette modification prenne effet. Redémarrer VS2010, ouvrez un projet Web et puis essayer de publier à nouveau. Cette fois-ci devrait réussir.
Publication à l'aide d'une construction de paquet:
Visual Studio peut produire une construction de paquet qui peut être exécuté à partir de la ligne de commande. Ceci est généré à l'aide Project -> Build Deployment Package
. Pratique pour l'intégration continue et analogues (l'emballage peut également être généré en utilisant msbuild avec le commutateur /t:Package
).
le dossier de sortie pour le paquet habituellement par défaut obj\Package
.
Malheureusement, Visual Studio 2010 obtient ce un mal de bits et génère un script batch wrapper msdeploy 1.0 et le déploiement ciblant au niveau du serveur ciblant plutôt qu'au niveau du site.
Il n'y a pas de solution miracle pour cet autre que de façonner votre propre ligne de commande msdeploy.exe. J'ai divisé ce sur plusieurs lignes pour faire 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 de msdeploy.exe
. Visual Studio génère un chemin vers versisur 1,0. J'ai changé cela à utiliser 2.0.
Paramètres notables:
-source:archiveDir=
dit msdeploy nous déployons un paquet et fournit l'emplacement local
computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename'
- cela indique MSDEPLOY déploiement 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 de gestionnaire délégué pour le site. Ceci est configuré à l'aide de la fonction « Gestionnaire des services Internet autorisations » au niveau du site. Le compte doit être un compte d'utilisateur Windows local.
-authtype='basic'
-. Cette authentification de base des forces sinon l'authentification NTLM est tentée
-allowuntrusted
- cela ne tient pas des erreurs de certificats SSL si vous utilisez le intégré auto-signé certificat SSL
Si vous utilisez cette ligne de commande, vous devriez être en mesure de déployer sur un serveur distant IIS7 avec succès.
Publication de contenu brut:
Parfois, nous voulons simplement publier un contenu statique (ou peut-être même un ASP classique ou d'un site PHP) directement à partir d'un dossier local. Nous pouvons le faire en utilisant la ligne de commande msdeploy.exe
suivante:
"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
Encore une fois les mêmes règles que précédemment pour -dest:contentPath
et computerName
.
Je crois que les questions de version MSDeploy seront résolus dans le Service Pack 1 (que je ne l'ai pas eu la chance de regarder encore).
Une finale VS2010 Gotcha:
Lors de la publication en utilisant Visual Studio 2010, le paquet build « Publier » provoque un compte anonyme de de du site l'ACL au changement en lecture seule pour tous les fichiers et dossiers à l'exception du dossier App_Data
qui est changé en lecture et en é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 à la corde dans la fixation d'un ACL un package de déploiement Visual studio 2010 (lien WayBackMachine parce que le contenu original est plus disponible)
Autres conseils
Pour moi, l'édition a travaillé dans Visual Studio, mais cela n'a pas fonctionné quand je courais 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. Puis en tournant le niveau de journalisation (Outils> Options> Projets et Solutions> Construire et exécuter> projet MSBuild sortie de la construction verbosité) vous pouvez voir la ligne de commande qui utilise VS.
Les problèmes avec mon .deploy.cmd
étaient:
- Mon utilisateur IIS n'avait des autorisations sur ce site si je avais besoin
?site=<SITENAME>
dans lecomputerName
. - I nécessaire
AuthType='Basic'
dans le paramètre-dest:
.
Nous avons été confrontés à un problème similaire que le vôtre.
Pour cela, vous devez démarrer le service d'agent à distance dans les services. Nous avons utilisé le nom du PC parce que l'adresse IP a été de donner une erreur. Donc, essayez d'utiliser le nom de PC, nom d'utilisateur et mot de passe.
En fin de compte, je ne l'ai fait sur Suss les permissions que je manquais mon Déployez compte utilisateur - mais a constaté que si je la machine compte admin, que le déploiement réussirait. Pour l'instant j'utilise le compte administrateur pour effectuer le déploiement.
Félicitations à Kev pour le résumé fantastique et instructif de la mise en place ms 2 Déployez:)
Pour ce que ça vaut la peine. Publishing travaillait pour moi et puis un jour j'ai eu ce même problème (401 d'erreur non autorisée) VS2012 a résolu le redémarrage problème. J'avais essayé souhait que avant d'essayer toutes les autres solutions.