Question

J'ai examiné la classe Microsoft.Web.Administant.dll et la classe ServerManager, essayant de contrôler notre instance IIS7 Windows Server 2008.

J'ai activé l'administration à distance et je peux me connecter via l'outil d'administration à distance IIS, mais lorsque j'essaye d'utiliser ce qui suit, je ne peux pas me connecter:

ServerManager.OpenRemote(serverName);

Cette classe ne me permet pas de spécifier un nom d'utilisateur et un mot de passe sur le serveur IIS7 distant, comme le fait l'outil d'administration distant IIS.

Tout cela est appelé via notre processus de construction en utilisant Nant.

Comment les autres contrôlent-ils leur serveur IIS7 distant dans le cadre de leur configuration CI?

Était-ce utile?

La solution 3

J'ai écrit un service WCF à la fin, qui s'exécute sur la machine distante en tant que service. Le service s'exécute sous un compte local avec les droits de l'administrateur afin que l'instance IIS locale sur cette machine puisse être modifiée.

De mon script NANT, j'ai une série de tâches personnalisées qui communiquent au service WCF et modifient les paramètres IIS selon les besoins.

Comme il s'agit d'un environnement de développement interne, je ne suis pas trop préoccupé par la sécurité et les modifications réelles de l'IIS, je suis autorisée, sont très basiques.

Autres conseils

Vous devrez exécuter l'application sous un utilisateur de domaine (utilisateur Active Directory) qui a les bonnes autorisations pour modifier les fichiers de configuration.

L'authentification Windows fera le reste.

Comme le dit Oded, vous avez besoin d'Active Directory pour pouvoir ouvrir une connexion à un serveur distant en utilisant ServerManager.

En supposant que vous avez un serveur d'accès RDP administrateur, il existe une alternative à utiliser WinRM et Remote PowerShell (fonctionne mieux avec PowerShell 2.0 qui est livré avec la dernière version de WinRM) dans vos scripts de construction:

Outil de ligne de commande de gestion à distance Windows (WinRM.CMD)

Pour configurer rapidement WinRM pour deux machines qui ne sont pas dans un domaine:

Client:

winrm quickconfig  (just say yes)
winrm set winrm/config/Client/Auth '@{Basic="true"}'
:: Only do this next line if not using HTTPS
winrm set winrm/config/Client '@{AllowUnencrypted="true"}'
winrm set winrm/config/Client '@{TrustedHosts="hostname_or_ip"}'

Serveur:

winrm quickconfig (just say yes)
winrm set winrm/config/Service/Auth '@{Basic="true"}'

:: See: http://support.microsoft.com/kb/2019527 regarding https
winrm quickconfig -transport:https

:: Only do this if not using HTTPS AND you are happy about sending credentials
:: in clear text.
winrm set winrm/config/Service '@{AllowUnencrypted="true"}'

Maintenant, il y a des mises en garde. WinRM permettra à un trou dans le pare-feu Windows pour les ports 5985 et 5986 pour l'auditeur (s'il exécute Windows 2003, il utilisera les ports 80 et 443). Ce n'est peut-être pas à votre goût et vous parlez probablement du mieux à vos administrateurs de réseau de la façon de sécuriser cela.

Une fois que vous avez configuré WINRM, vous aurez besoin d'un compte utilisateur configuré sur le serveur distant qui est membre du groupe Administrateurs. Une fois terminé, vous pouvez ensuite tester. Sur le serveur de construction:

# the following line will prompt for a username and password, enter the name of the account
# you just configured on the IIS box
$cred = Get-Credential

# next test the connection
Test-WSMan -ComputerName <server_name_or_ip> -Authentication default `
           -Credential $cred

Si tout est bon, vous devriez voir la réponse suivante:

wsmid           : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.x
                  sd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 6.1.7600 SP: 0.0 Stack: 2.0

La prochaine chose est de se connecter à une session PowerShell distante:

Enter-PSSession <server_name_or_ip> -Authentication default -Credential $cred

Si cela réussit, vous devez avoir une invite PowerShell sur la machine distante.

À l'aide de PowerShell distant, vous pouvez ensuite charger le fournisseur WebAdminging pour PowerShell et manipuler de nombreux aspects de IIS à votre cœur:

Fournisseur d'administration Web (IIS) pour Windows PowerShell

Pour vous connecter au serveur distant, vous devez fournir un PSCredential objet. Comme mentionné ci-dessus, vous fournissez cette question en utilisant:

$cred = Get-Credential

Cependant, cela exige toujours une interaction du clavier pour fournir un nom d'utilisateur et un mot de passe. De toute évidence, ce n'est pas bon pour CI automatisé.

Vous pouvez cependant stocker le mot de passe dans un fichier. Pour ce faire, exécutez ce qui suit une seule fois (ou chaque fois que le mot de passe change):

read-host -assecurestring | convertfrom-securestring | out-file C:\securestring.txt

Ensuite, lorsque vous avez besoin de créer votre PSCredential Pour s'authentifier avec le serveur distant:

$username = "deployment_user"
$password = cat C:\securestring.txt | convertto-securestring
$cred = new-object -typename System.Management.Automation.PSCredential `
         -argumentlist $username, $password

$serverNameOrIp = "192.168.1.1"
Enter-PSSession $serverNameOrIp -Authentication default -Credential $cred

Le script ci-dessus provenait de l'entrée de blog suivante, mais j'ai dupliqué pour préserver ici au cas où cet article deviendra sombre:

Utilisation de PSCredentials sans invite - Geekswithblogs

Quoi qu'il en soit, une fois que vous êtes connecté au serveur distant, vous pouvez émettre d'autres commandes telles que:

Import-Module WebAdministration
CD IIS:\Sites

Etc.

La plupart des éléments ci-dessus doivent être approchés avec prudence si cette machine est confrontée à Internet et que la seule façon d'accès est via Internet. Si tel est le cas, pensez à restreindre uniquement les ports WinRM vers VPN.

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