msdeploy (Web Deploy) en panne avec 401 problèmes d'auth
je vais essayer d'obtenir msdeploy installé et configuré. J'ai installé le service distant sur le serveur web, mais tous mes essais 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:inetpubwwwrootMyApp,computerName=<IP HERE>,userName=Domainmsdeploy,password=MyPassword
Et le message d'erreur:
Error: Object of type 'contentPath' and path 'c:inetpubwwwrootMonApp' 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 local sur le serveur.
j'ai vérifié:
- que le service a installé correctement et j'ai commencé il
- diverses combinaisons de ne pas utiliser la partie domaine du nom d'utilisateur, et ajouter authType=Basic
- donné les permissions complètes à ce dossier à tout le monde
- Dans IIS autoriser les connexions à distance
- ajout des règles de délégation des services de gestion pour mon utilisateur" msdeploy " pour contentPath et iisApp (vaguement basé sur la lecture )
- essayé avec un compte administrateur différent que j'utilise pour la RDC à la serveur...
- essayé avec différents contentPaths et différentes commandes msdeploy
- créé un compte spécifique, et ajouté ce compte à IIS_Users. J'ai ajouté cet utilisateur à mon site web "IIS Manager Permissions", et j'ai configuré "Management Service Delegation" pour tous les fournisseurs.
5 réponses
je suppose que vous avez configuré votre serveur correctement pour WebDeploy 2.0 comme dans cet article:
Remarque: MS ont publié une mise à jour de Web Deploy 2.0 et le lien original n'est plus vraiment valide. Je l'ai mis à jour, 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 1.0 alors je recommande la mise à jour, il y a d'énormes améliorations dans 2.0.
utilisation de la fonctionnalité publier de Visual Studio 2010:
Visual Studio peut publier un site en cliquant avec le bouton droit de la souris sur le site et en sélectionnant "publier". Ceci fait apparaître le dialogue suivant:
il y a un couple de gotcha 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 un message d'erreur tel que le suivant:
erreur 1 tâche de déploiement Web échouer.((04/02/2011 12:30: 40) une erreur s'est produite lorsque la demande a été traité sur l'ordinateur distant.)
vous verrez également l'erreur suivante dans le traçage de requête échoué pour le service de gestion web sur le serveur en C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1 en supposant que vous avez cette allumé:
Aspnetmodulediagrorevent
Uri / msdeploy.axd
eventData de Traçage exception de l'agent de déploiement. ID de la demande ". Demande D'Horodatage: '02/04/2011
Système.Nonauthorizedaccessexception: l'accès au chemin 'D:\' est refusé.
la lettre du lecteur variera selon le lecteur de votre site SII est situé sur.
Hors de la boîte, le GUI mécanisme de publication par défaut à l'aide de la version incorrecte de MSDeploy (1.0). Nous voulons dire à VS2010 d'utiliser MSDeploy 2.0. Vous pouvez le faire en modifiant Visual Studio 2010 devenv.exe.config fichier qui se trouve dans (en supposant que vous avez fait un
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
Ouvrir devenv.exe.config dans votre éditeur XML préféré (je viens d'utiliser Visual Studio 2010 lui-même) et copier le suivant xml:
<dependentAssembly>
<assemblyIdentity
name="Microsoft.Web.Deployment"
publicKeyToken="31bf3856ad364e35" culture="neutral"/>
<bindingRedirect oldVersion="7.1.0.0" newVersion="8.0.0.0"/>
</dependentAssembly>
ajouter ceci au /configuration/runtime/assemblyBinding l'article:
une fois que vous avez fait cette fermeture, toutes les instances de Visual Studio 2010 pour permettre à ce changement de prendre effet. Redémarrez VS2010, ouvrez un projet web puis essayez de publier à nouveau. Cette fois, il devrait être couronné de succès.
Publication à l'aide d'une accumulation de Paquet:
Visual Studio peut produire un paquet de construction qui peut être exécuté à partir de la ligne de commande. Il est généré à l'aide de Project -> Build Deployment Package. Pratique pour une intégration continue et similaire (le paquet peut aussi être généré en utilisant msbuild avec le /t:Package commutateur).
le dossier de sortie du paquet est par défaut obj\Package.
malheureusement Visual Studio 2010 se trompe un peu et génère un script batch wrapper msdeploy ciblant 1.0 et ciblant le déploiement au niveau du serveur plutôt qu'au niveau du site.
Il n'y a pas de solution miracle pour cela autre que d'élaborer votre propre msdeploy.ligne de commande de l'exe. Je l'ai divisé en plusieurs lignes pour le rendre 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 d'accès msdeploy.exe. Visual Studio génère un chemin vers la version 1.0. J'ai changé pour utiliser 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' - cela dit MSDEPLOY à déployer sur un site spécifique sur IIS7. yoursitename devrait correspondre exactement au nom du site dans IIS.
userName et password are est le nom de l'utilisateur gestionnaire délégué du site. Ceci est configuré en utilisant la fonctionnalité" 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 - cela ignore toute erreur de certificat SSL si vous utilisez le certificat SSL auto-signé.
si vous utilisez cette ligne de commande, vous devriez être capable de vous déployer sur un serveur distant IIS7 avec succès.
La Publication De Contenu Original:
parfois, nous voulons simplement publier du 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 le 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
Encore une fois la mêmes règles s'appliquent comme avant -dest:contentPath et computerName.
je crois que les problèmes de version de MSDeploy seront résolus dans SP1 (que je n'ai pas encore eu l'occasion d'examiner).
Une dernière VS2010 Gotcha:
lors de la publication en utilisant Visual Studio 2010, le paquet de construction" Publish " fait changer les ACL du compte anonyme du site à lire uniquement pour tous les fichiers et dossiers à l'exception du App_Data dossier qui est changé à Lire et écrire.
Cela peut être contourné en ajoutant le paramètre suivant à la .csproj le fichier 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é utile de pépite à partir d'ici:
sauter la mise en place D'un ACL dans un paquet de déploiement Visual Studio 2010 (WayBackMachine lien parce que le contenu n'est plus disponible)
Pour moi, l'édition travaillé dans Visual Studio, mais cela n'a pas fonctionné quand j'ai couru le .deploy.cmd script.
en mettant <UseMsdeployExe>true</UseMsdeployExe> dans votre .csproj, vous pouvez forcer VS à utiliser msdeploy.exe au lieu d'une tâche MSBuild. Ensuite, en activant le niveau de journalisation (Outils > Options > projets et Solutions > construire et exécuter > MSBuild project build output verbosity), vous pouvez voir la ligne de commande que VS utilise.
problèmes avec mon .deploy.cmd étaient les suivants:
- mon utilisateur IIS j'avais seulement les permissions sur ce site donc j'avais besoin de
?site=<SITENAME>dans lecomputerName. - j'ai besoin d'
AuthType='Basic'dans le-dest:paramètre.
nous étions confrontés à un problème similaire au vôtre.
pour cela, vous devez démarrer le service agent à distance dans les services. Nous avons utilisé le nom du PC parce que l'adresse IP donnait une erreur. Essayez donc d'utiliser le nom du pc, le nom d'utilisateur et le mot de passe.
a la fin je n'ai jamais su quelles permissions je manquais avec mon compte d'utilisateur deploy-mais j'ai découvert que si j'utilisais le compte d'Administrateur machine, le déploiement réussirait. Pour l'instant, j'utilise le compte administrateur pour effectuer le déploiement.
Bravo à Kev pour le résumé fantastique et informatif de la mise en place de MS deploy 2:)
Pour ce que ça vaut. La publication fonctionnait pour moi et puis un jour j'ai eu ce même problème (401 erreurs non autorisées) redémarrant VS2012 résolu le problème. Tiens je l'avais essayé avant d'essayer toutes les autres solutions.