Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

Desired State Configuration (Partie 4) : Configuration du mode pull (via web service)

par | 10 Mai 2014 |

Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Windows 2012/8 et Windows 2008 R2/7.

Lors du précédent article nous avons vu le fonctionnement du mode Pull puis son implémentation. Cette dernière se base sur un partage SMB permettant à tous les clients d’aller récupérer leur configuration par ce biais.

Dans cette quatrième partie, nous aborderons l’implémentation du mode Pull via un web service.

Fonctionnement

Le fonctionnement du mode Pull est expliqué dans la Partie 2 de ce guide sur DSC. Dans le mode Pull via web services, seul la façon de publier les fichiers de configurations et l’implémentation changent. Au lieu d’utiliser un partage, les clients DSC interrogerons à intervalle régulier une URL pour récupérer leur configuration :
“http://PullServerName:8080/PSDSCPullServer/PSDSCPullServer.svc" où PullServerName représente le nom du serveur Pull.

Contrairement au mode Pull via partage SMB, il n’est possible de déployer le Web Services que sur une version Serveur de Windows. Celui-ci se base sur la fonctionnalité Windows Powershell Desired State Configuration Service. Cependant, via le web service, il est possible de sécuriser la connexion avec l’usage de certificat.

Nous retrouvons les mêmes étapes que pour un serveur Pull via partage. Les clients ont un GUID unique de configuration. Ils récupèrent le fichier .mof portant ce GUID. Une vérification d’intégrité du fichier est effectuée grâce à un fichier portant le même GUID avec l’extension .mof.checksum.

Implémentation du web service

Dans cette section, j’explique comment mettre en place un serveur Pull avec Web Service de façon manuelle afin de comprendre les différentes briques de cette fonctionnalité. Dans le dernier paragraphe, vous trouverez des liens vers des ressources Desired State Configuration permettant de réaliser toute cette configuration beaucoup plus rapidement.

Tout d’abord, on installe le service DSC en graphique ou via la commande :

Install DSC Service

Toute une série de dépendance est ainsi installée dont notamment IIS et le Windows Process Activation Service.

Capture d_écran 2014-04-20 à 11.52.16

Puis dans IIS, on crée un nouveau pool d’application (DSCApplicationPool) qui sera lancé avec le compte Local System (Sur le pool d’application choisir “Advanced Settings” puis “Identity”).

Add PoolConfigure Pool

On crée un nouveau site (Exemple : DSCPullSite) utilisant notre pool d’application nouvellement créé et on le fait pointer vers un dossier de son choix. Ce dernier contiendra les sources du web service.

Add Site

Dans le dossier du site web IIS, on crée un répertoire bin dans lequel on copie le fichier Microsoft.Powershell.DesiredStateConfiguration.Service.dll contenu dans $pshome/modules/psdesiredstateconfiguration/pullserver ($pshome correpond à C:\Windows\System32\WindowsPowerShell\v1.0 si vous avez une installation classique de Windows). 

Il faut ensuite copier les fichiers suivants contenu dans le dossier  $pshome/modules/psdesiredstateconfiguration/pullserver à la racine du site web :

  • Global.asax 
  • PSDSCPullServer.mof 
  • PSDSCPullServer.svc 
  • PSDSCPullServer.xml 
  • PSDSCPullServer.config : il doit être renommé en web.config

L’arborescence doit être identique à celle ci-dessous :

Arborscence

Il faut ensuite autoriser les différentes méthodes d’authentification en réalisant un "unlock" sur les sections adéquate du fichier web.config que nous avons copié (anciennement PSDSCPullServer.config).

Voici un script permettant de réaliser cette opération :

Le résultat peut être vérifié dans le fichier C:\Windows\System32\inetsrv\config\applicationHost.config 

web.config

Enfin, dans ce même fichier web.config il faut ajouter les lignes suivantes dans le noeud appsettings :

Lors de l’installation du service DSC, une hiérarchie de dossier a été créée dans C:\Program Files\WindowsPowerShell\DscService :

  • Configuration : dans ce dossier, il faut placer les fichiers .mof et .mof.checksum (renommé avec un GUID, voir Partie 2).
  • Modules : Contient les éventuels modules dont on pourrait avoir besoin.

Pour terminer la configuration du serveur Pull, il faut copier le fichier $pshome/modules/psdesiredstateconfiguration/pullserver/Devices.mdb vers le dossier C:\Program Files\WindowsPowerShell\DscService

L’url du web service (http://PullServerName/PSDSCPullServer.svc) est maintenant opérationnelle !

Ressource LocalConfigurationManager

La ressource LocalConfigurationManager (déjà rencontrée dans les autres articles sur DSC) doit être configurée pour utiliser le web service.

Cette configuration est similaire à celle de la Partie 2 et 3. On retrouve le ConfigurationID permettant de récupérer les bons fichiers .mof. Les paramètres à changer sont :

  • DownloadManagerName : Il prend la valeur WebDownloadManager. 
    DownloadManagerCustomData : Il contient un hashtable avec l’url du web service et un second paramètre AllowUnsecureConnection utile si vous n’utilisez pas de certificat.
Voici une configuration d’exemple :

Annexe

Depuis la sortie de Powershell V4.0, Microsoft s’est employé à fournir de nombreuses nouvelles ressources pour DSC. Celles-ci sont disponibles en suivant le lien ci-dessous :
http://gallery.technet.microsoft.com/scriptcenter/DSC-Resource-Kit-All-c449312d

Ces ressources sont précédées d’un "x" car elles sont encore considérées comme expérimentales. Parmis toutes ces nouvelles ressources (plus d’une cinquantaine !), il y en a une pour déployer un server Pull facilement (xDscWebService). Cette dernière permet d’effectuer toutes les opérations fastidieuses que l’on a mis en place dans la section précédente (création d’un pool d’application, d’un site web, copie des différents fichiers,…).

Voici un exemple d’utilisation de cette ressource :

On retrouve les paramètres tel que le nom du pool d’application (EndpointName), le chemin vers le site web (PhysicalPath),… Cela nous permet aussi de pouvoir customiser simplement les chemins qui vont contenir nos fichiers .mof et .mof.checksum ainsi que les ports utilisés par DSC et l’intégration d’un certificat.

Vérifier l’installation d’un KB sur plusieurs serveurs

par | 18 Avr 2014 |

Contexte

Dans certains cas, il faut déployer un patch Microsoft sur plusieurs serveurs. Mais comment savoir simplement et rapidement si le patch est bien installé, surtout si vous ne disposez pas de la solution System Center ?

Tout simplement avec un script Powershell. Voyons comment faire.

Dans mon exemple ci dessous, je veux savoir si un KB est installé sur tous les contrôleurs de domaine de tous les domaines de toute ma forêt Active Directory.

Compatibilité

Tout d’abord, ce script s’appuie sur des cmdlets (Get-Job et Get-Hotfix notamment) qui ne sont disponibles qu’avec Powershell version 2 minimum. Pensez à vérifier votre version de Powershell.

Fonctionnement

Dans un premier temps, il faut passer le paramètre “hotfix” au script.

Lors du lancement du script, voici les étapes :

  1. 1- Vérification de la syntaxe du paramètre. Il doit être au format “KBxxxxxx”.
  2. 2- Récupération de la liste de tous les domaines de la forêt Active Directory.
  3. 3- Interroge Active Directory pour récupérer la liste des contrôleurs de domaines en demandant les membres du groupe ‘Domain Controllers’ pour chaque domaine.
  4. 4- Récupération des identifiants pour se connecter à tous les DC.
  5. 5- Création des jobs, avec un job par serveur et maximum 15 jobs simultanés (paramètre $MaxThreads ligne 9).
  6. 6- Récupération des résultats des jobs.
  7. 7- Affichage d’un résumé.
  8. 8- Exportation des résultats.

 

Les jobs Powershell sont utilisés ici afin d’augmenter la rapidité d’exécution. Sinon, les serveurs serait interrogés les uns après les autres. Cette solution fonctionne tout aussi bien, mais demande beaucoup de temps. L’intérêt des jobs est de pouvoir lancer plusieurs requêtes en parallèle. Toutefois, attention à la consommation mémoire car il y’a autant de processus Powershell en mémoire, qu’il y’a de jobs.

Script

Utilisation

Il faut sauvegarder le script ci dessus avec le nom “Check_Hotfix_Installation.ps1”. Ensuite il suffit d’appeler le script dans une console Powershell (en Administrateur) comme ceci : “Check_Hotfix_Installation –Hotfix KB2413670”

Conclusion

Avec un simple script Powershell et l’utilisation des jobs, on peut vérifier énormément de serveurs et très rapidement. Rien empêche de modifier le script pour déclencher l’installation du hotfix avant la vérification, ou encore de cibler des serveurs plutôt que des contrôleurs de domaine.

Libre à vous d’adapter ce script selon vos besoins !

Powershell V5 Preview est sorti ! DSC, Switch, OneGet et du chocolat.

par | 17 Avr 2014 | ,

Introduction

Après le Management Framework 4.0 qui apportait Desired State Configuration, la Powershell Team vient de publier Management Framework 5.0 Preview (le 03/04/2014). Cette nouvelle version intervient seulement 6 mois après la sortie de la V4.0. Microsoft accélère son cycle de développement avec des versions contenant moins de nouveautés mais celles-ci restent tout de même importantes.

Le Management Framework 5.0 est pour l’instant compatible uniquement avec Windows Server 2012 R2, Windows 8.1 Pro et Enterprise mais Microsoft parle d’une rétrocompatibilité avec d’autres versions à venir.

Voici le lien vers l’update a installé :
http://www.microsoft.com/en-us/download/details.aspx?id=42316

Il contient Powershell V5.0 et Powershell ISE.

Capture d’écran 2014-04-17 à 19.00.43

Il est temps de faire le tour des nouveautés !

Générales

Comme à chaque nouvelle version de Powershell, on nous annonce moins de bugs, de meilleures performances et des nouvelles Cmdlets.

Desired State Configuration

Des corrections de bug et des améliorations de performances sont au programme. La Team Powershell indique que Desired State Configuration est une technologie importante pour eux. C’est logique quand on voit le nombre de ressources (plus de 50) qui a été développé depuis la sortie de Powershell V4.0 : http://blogs.msdn.com/b/powershell/archive/2014/03/28/dsc-resource-kit-wave-3.aspx . Ils indiquent que la stratégie de Microsoft est de pousser l’intégration de DSC avec les outils de gestion de configuration (SCCM ?) et que lors d’un choix de ce type de solution, il sera important qu’elle soit compatible avec DSC.

Switch

Powershell V5.0 propose un module natif permettant de manipuler ses switchs. Microsoft a travaillé avec les leaders de l’industrie afin d’élaborer un standard. Les équipements compatibles porteront la certification "Certified for Windows". Au delà de Powershell, ce standard est utilisé dans SCVMM 2012. Cette technologie fait partie de la politique "Datacenter Abstraction Layer" de Microsoft. Elle vise à gérer l’intégralité d’un Datacenter via un même outil de management au lieu d’avoir une vision réduite à un équipement. Elle permettra d’éviter la multiplication des outils de gestion.

Le module qui permet de manipuler les switchs est : NetworkSwitch. Pour être compatible avec ce standard, le switch devra supporté les sessions distantes CIM. Pour rappel, c’est un standard ouvert développé par la DMTF (Distributed Management Task Force) qui définit les interractions entre des équipements ainsi que leur gestion, supervision, etc sous la forme d’un schéma. Ce schéma est orienté objet. WMI est notamment compatible avec ce standard (depuis Powershell V3.0 via les Cmdlets comme Get-CIMClass, Set-CIMInstance, …).

Voici la liste des commandes de ce module :

Capture d’écran 2014-04-17 à 19.07.54

Parmi les fonctionnalités, il est ainsi possible de :

  • réaliser la configuration générale du switch : nom d’hôte, bannière, activation/désactivation de fonctionnalités
  • gérer les vlan : création, suppression, activation, désactivation, listing
  • configurer les ports : activation, désactivation, listing, définition des propriétés

OneGet

On termine ce tour des nouveautés, avec la fonctionnalité qui va sans doute faire le plus parlée d’elle : OneGet. C’est tout simplement un gestionnaire de paquet comme on peut en rencontrer sur Unix !

Pour obtenir la liste des commandes disponibles :

Capture d’écran 2014-04-17 à 19.07.16

On peut utiliser la commande Find-Package pour chercher 7zip par exemple :

Capture d’écran 2014-04-17 à 19.14.18

Puis-on l’installe (Install-Package) :

Capture d’écran 2014-04-17 à 19.14.36

Bien entendu, comme tout gestionnaire de paquet, il s’occupe également d’installer automatiquement les dépendances.

La commande Get-Package permet de récupérer les packages déjà installé. Le package apparaît dorénavant dans le Start Screen (ou dans Program Files) comme n’importe quel autre programme :

Capture d’écran 2014-04-17 à 19.16.11

Dans cette version preview, OneGet ne possède qu’une seule source (ou repository) : Chocolatey (https://chocolatey.org/packages) qui contient actuellement plus de 1700 package. Ce dernier est basé sur NuGet (connu des utilisateurs de Visual Studio) qui est justement un gestionnaire de package. Microsoft ajoutera le support d’autres repositories ultérieurement. On peut même imaginer qu’il sera possible de créer sa propre source et de l’ajouter via la commande Add-PackageSource. Certaines personnes ont d’ailleurs déjà commencé à le faire : http://learn-powershell.net/2014/04/11/setting-up-a-nuget-feed-for-use-with-oneget/.

Derniers articles

Aucun résultat

La page demandée est introuvable. Essayez d'affiner votre recherche ou utilisez le panneau de navigation ci-dessus pour localiser l'article.

Catégories

Archives

Auteurs/Autrices