Le problème n'est pas avec le fichier hôte ou l'agent de build, mais plutôt le certificat de serveur sur le cible de la machine. Pour moi, J'utilisais VSTS pour me déployer dans un Azure VM quand j'ai rencontré le problème, mais la solution reste la même pour sur place machines.

pour un déploiement de VM Azure, le problème se pose lorsque vous créez une VM sans nom DNS étiquette pour votre IP publique, puis ajouter plus tard un (quelque chose comme example.centralus.cloudapp.azure.com). Il peut également se produire si vous changez l'étiquette de nom DNS.

Problème

vous voudrez vérifier comment vous vous connectez à la machine. Avant, ça marchait très bien avec L'adresse IP VM Azure. Maintenant, VSTS a commencé à essayer d'utiliser example.centralus.cloudapp.azure.com:5986 depuis que j'ai récemment ajouté une étiquette de nom DNS. Nous allons appeler cette adresse de la machine cible.

Sur le cible machine, ouvrez PowerShell ou L'invite de commande en tant qu'administrateur et entrez la commande 'winrm e winrm/config/listener'. Il devrait rendre deux auditeurs, un pour HTTP et un autre pour HTTPS (si l'un n'est pas listé pour HTTPS, ne vous inquiétez pas, nous en ajouterons un plus tard). Faites particulièrement attention à la nom d'hôte pour L'auditeur HTTPS. Si cela ne correspond pas à l' adresse de la machine cible nous avons trouvé plus tôt, c'est ce qui cause l'erreur. CertificateThumbprint correspond à un serveur certificat sur la machine.

pour voir ces certificats, tapez mmc et appuyez sur entrée. Aller à' File ' > ' Ajouter/Supprimer Snap-in...'. Sélectionnez "Certificats", et cliquez sur Ajouter. Dans la boîte de dialogue, sélectionnez "Compte d'Ordinateur" et cliquez sur Terminer. Sous "certificats" > "personnels" > "certificats", vous verrez le certificat utilisé par la configuration WinRM. Certificats ici qui sont les autographes sont considérés Certificats D'Essai parce qu'ils ne sont pas appuyés par une autorité de certification officielle. Nous devrons en créer un qui représente le adresse de la machine cible vous souhaitez utiliser.

vous pouvez également afficher les certificats dans IIS sous 'Certificats De Serveur'.

Solution

assurez-vous de savoir quelle adresse vous voulez utiliser pour vous connecter à la machine. C'est le adresse de la machine cible.

Sur le cible machine, ouvrez PowerShell comme administrateur. Entrez la commande suivante.

New-SelfSignedCertificate -DnsName WhateverTargetMachineAddressYouNeed -CertStoreLocation Cert:\LocalMachine\My

Cela crée un nouveau certificat de serveur pour votre adresse cible avec une période de validité d'un an.

ensuite, nous voulons recréer L'écouteur WinRM pour les types de transport HTTPS pour utiliser le nouveau certificat. Ouvrez IIS et regardez Certificats De Serveur pour votre serveur web. Vous devrait voir celui que vous venez de créer. Un clic-droit dessus et sélectionnez " Afficher les...'. Dans le Détails onglet, copiez le empreinte du pouce pour le certificat. Vous pouvez également le faire à partir du mmc si vous préférez.

entrez les commandes suivantes une à la fois dans PowerShell.

winrm delete winrm/config/listener?Address=*+Transport=HTTPS

Puis:

winrm create winrm/config/listener?Address=*+Transport=HTTPS '@{Hostname="WhateverTargetMachineAddressYouNeed";CertificateThumbprint="TheThumbprintYouCopied";port="5986"}'

Fait! Si vous entrez winrm e winrm/config/listener dans PowerShell, vous devriez maintenant Voir le transport HTTPS en utilisant votre nouveau certificat.

si quelque chose dans votre définition de version ou vos scripts de déploiement utilise l'ancienne adresse (pour moi, l'adresse IP VM Azure), assurez-vous de les mettre à jour pour utiliser la nouvelle adresse de la machine cible (pour moi, l'étiquette de nom Azure VM DNS) avec le numéro de port. Dans VSTS, assurez-vous de cocher la case pour utiliser un ' Certificat D'Essai'. Bonne chance!

Pour plus d'informations, vous pouvez aller ici:

http://www.dotnetcurry.com/windows-azure/1289/configure-winrm-execute-powershell-remote-azure-with-arm