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.
Était-ce utile?

La solution

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

  

Configurer Web Déploiement (IIS.NET)

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:

entrer image description ici

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.)

entrer image description ici

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é

entrer image description ici

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:

entrer image description ici

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 le computerName.
  • 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.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top