Bonjour,

Ce guide fait suite à mon post sur la création d’une collection RDS avec équilibrage de charge sous Windows serveur 2012 R2.

Nous allons voir comment installer le rôle licensing RDS et mettre une GPO basique pour configurer le(s) serveurs(s) host RDS avec ces informations.

Installation du rôle licensing

 Sur la page Overview des services RDS, cliquez sur le plus au dessus de RD Licensing

L’assistant vous demande quel(s) serveur(s) hébergera le rôle. Nous allons ici choisir le serveur qui héberge déjà les rôles Broker et Web (voir post précédent) car aucun des trois n’est très consommateurs de ressources machine et on peut donc les regrouper sur une architecture de petite taille.

Il faudra ensuite ajouter vos licences TS dans la console (Ici mon poste à une CAL temporaire)

Création d’une GPO pour configurer les serveurs host RDS

Afin de ne pas avoir à passer sur chaque serveur nous allons mettre une GPO sur les serveurs avec le rôle host.

J’ai créé une GPO nommée GPO_WRK_RDS_CONFIG et je l’ai placée dans l’OU AD réservée à mes serveurs RDS (tout rôles).

Le filtre de sécurité limite l’application à mes serveurs host RDS.

Nous allons maintenant voir les paramètres obligatoires et intéressants à mettre en place (tout ce qui suit est à adapter à vos besoins car nous).

Tout les paramètres sont dans la partie ordinateur de la stratégie.

Il faut en premier ce rendre dans : “Policies/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host”

Dans la partie “Licensing” :

Les paramètres suivants sont nécessaire pour la bonne configuration de l’infrastructure RDS.

Nous allons renseigner dans la 1ère ligne le nom complet du serveur hébergeant le rôle licensing (dans notre cas LAB-BRDS-02T.labo-pis.dom).

Dans le 3ème, nous spécifions le type de licence utiliser (soit par device, soit par user).

 

Dans la partie “redirection d’imprimante” :

Nous pouvons gérer la redirection des imprimantes clients dans les sessions remote desktop.

Dans le cas de ma dernière expérience il était nécessaire de la bloquer car nous avions des imprimantes installés sur les serveurs et les redirections prêtaient à confusion.

 

Dans le partie “Device and Resource Redirection” :

Nous allons ici bloquer la redirection audio et vidéo, la redirection de l’enregistrement audio, nous autorisons la redirection du port COM (car elle nous est nécessaire pour notre client dans mon cas).

Nous pouvons aussi gérer le presse-papier et d’autres options.

 

 Dans la partie “Session Time Limit” :

Nous allons mettre une durée de vie maximale aux sessions déconnectées.

Nous avons maintenant une collection de serveurs RDS Windows Server 2012 R2 fonctionnelle.

 

Bonjour à tous,

Nous allons voir comment mettre en place une collection de serveurs Hôte RDS.

Nous allons mettre en place l’infrastructure suivante :

• 2 serveurs avec le rôle hôte de sessions (LAB-HRDS-03T et LAB-HRDS-04T)

• 1 serveur avec les rôles “connection Broker” et “Web access” RDS (LAB-BRDS-02T) (vous pouvez bien sûr rajouter plusieurs broker si vous voulez de la redondance)

Nous allons voir ici la version graphique la plus simple à mettre en œuvre.

CREATION D’UN GROUPE DE SERVEUR

Il faut en premier créer un groupe de serveurs (via le gestionnaire de serveur) sur le serveur servant à l’installation de l’architecture RDS.

INSTALLATION DES ROLES RDS SUR LES DIFFERENTS SERVEURS

Nous allons faire un ajout de rôle sur le serveur LAB-BRDS-02T.

Nous allons faire une installation de type Remote Desktop Service

Nous allons choisir ensuite un déploiement standard qui permet de configurer une solution RDS avec plusieurs serveurs.

Nous avons ici deux options :

• déploiement de bureau basé sur des VM
• déploiement de bureau basé sur des sessions

Ici nous allons choisir la seconde option.

Nous avons ensuite une présentation des 3 rôles de bases d’une architecture RDS (Le licencing sera abordé dans un autre post ultérieurement)

Le service Broker gère la reconnexion des sessions. Cela permet à un utilisateur de retrouvé le bureau du même serveur à chaque reconnexion.

Le service Web Access fournit une page web de connexion qui permet de gérer les éléments disponible pour les utilisateurs.

Le service Host correspond au(x) serveur(s) qui hébergeront les applications et les sessions bureau à distance.

Il faut ensuite spécifier le serveur qui hébergera le rôle connection broker

Ensuite nous pouvons spécifier le serveur qui hébergera le rôle Web access.

Nous avons le choix du serveur et une case à cocher pour choisir automatiquement le serveur qui hébergera le rôle connection broker

Enfin il faut spécifier le(s) serveur(s) qui hébergeront le rôle session host.

Nous avons ensuite un récapitulatif de nos choix.

Le(s) serveur(s) hébergeant le rôle session host nécessiteront un redémarrage.

Dans le gestionnaire de serveur du serveur hébergeant le rôle connection broker nous allons créer notre collection de session qui permettra au utilisateurs de se connecter à une adresse unique puis d’être dirigé vers le serveur ayant le moins de sessions.

Ensuite nous avons la page récapitulatif de la collection.

Nous retrouvons 4 sections:

1. Propriétés : listes des informations de base sur la collection.
2. Programme RemoteApp : liste des applications publiés dans la collection (ces dernières peuvents être lancé directement depuis l’interface RD Web)
3. Serveur Host: liste des serveurs host de la collection. Il est possible de refuser les nouvelles connexions (pour une maintenance par exemple) sur un serveur en faisant un clique droit sur son nom.

1. Connexions : liste les connexions actuelles et leur état. ATTENTION : il n’y a pas de rafraichissement automatique de la fenêtre il faut choisir tache => rafraichir ou changer de page dans le gestionnaire de serveur

Nous pouvons désormais accéder au serveur RDweb et nous authentifier avec notre compte AD.

ATTENTION : il faut mettre le nom de domaine même si vous n’en avez qu’un. 

Nous voyons notre collection il suffit de cliquer dessus pour se connecter.

Je suis en nom de RDP sur mon broker mais la session est bien ouverte sur un serveur host (LAB-HRDS-03T)

Contexte

Dans Hyper-V sous Windows Server 2012 R2 vous obtenez l’erreur “Logon failure : the user has not been granted the requested logon type at this computer” lorsque vous tentez d’éteindre ou allumer une VM.

Problématique

Cette erreur intervient même lorsque l’utilisateur fait partie du groupe “Hyper-V Administrators”.

L’erreur dans le journal d’évènements Windows (Applications and Services Logs / Microsoft / Windows / Hyper-V-VMMS / Admin) est la suivante :

Error 15500 : “VM” failed to start worker process: Logon failure:the user has not been granted the requested logon type at this computer. (0x80070569). (Virtual machine ID <GUID>)

Cette erreur est due à une GPO qui ôte un droit au compte d’Hyper-V.

Solution

Pour résoudre ce problème, il faut donc identifier et modifier la GPO qui change les droits en lui ajoutant NT Virtual Machine\Virtual Machines au droit Log on as a service ou exclure le serveur Hyper-V de la GPO.

Il existe également une solution à court terme qui permet de contourner le problème. Pour cela il faut redémarrer le service Hyper-V Virtual Machine Management depuis la console Services. Le redémarrage de ce service n’a pas d’impact sur les machines virtuelles (qu’elles soient allumées ou éteintes).

Introduction

• Partie 1 : introduction et syntaxe
• Partie 2 : configuration du mode push
• Partie 3 : configuration du mode pull (via smb)
• Partie 4 : configuration du mode pull (via web service)
• Partie 5 : création d’une ressource personnalisée

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 l'implémentation du mode Pull via un web service.

Desired State Configuration est fourni avec un certain nombre de ressources. Malgré qu'il y en ai peu, et comme évoqué dans le précédent article, Microsoft et la communauté se sont employés à créer des nouvelles ressources. Dans cette cinquième et dernière partie, nous évoquerons la création d’une ressource personnalisée. Cette dernière permettra de prendre en charge un scénario non présent dans les ressources existantes : la présence d'un partage NFS.

Fonctionnement

• Un fichier .SCHEMA.MOF contenant sa définition et plus particulièrement toutes les propriétés que l'on pourra renseigner.
• Un module Powershell contenant quelques fonctions obligatoires (.PSM1)
• Un fichier .PSD1 représentant le manifest du module Powershell. Ce dernier contiendra les fonctions a exporter de notre module. Ce dernier est principalement utilisé pour versionner le module et avoir quelques informations dessus.

Le module Powershell doit obligatoirement comporter trois fonctions. Elles seront appelées lorsqu'un fichier de configuration contiendra une ressource du type que l'on aura créé. “Get-TargetResource” permet de récupérer la configuration telle qu'elle a été définie. “Set-TargetResource” applique une configuration (création, modification et suppression) et “Test-TargetResource” effectue le test de validité (elle retourne un booléen).

Il convient à la personne créant le module de développer le corps de ces fonctions (le squelette étant toujours identique), c'est à dire les paramètres et les process effectués.

Pré-requis

Au lancement de Powershell 4.0, il pouvait être fastidieux de développer ses propres ressources car il fallait respecter une certaine syntaxe. Cependant, Microsoft a développé un module permettant de faciliter la création de ressource à destination de DSC : xDscResourceDesigner. Ce dernier va nous permettre de générer nos fichiers automatiquement. Il est disponible en suivant le lien ci-dessous : http://gallery.technet.microsoft.com/scriptcenter/xDscResourceDesigne-Module-22eddb29

Il suffit ensuite de placer ce module dans le dossier :
“C:\Program Files\WindowsPowerShell\Modules”.

Création de la ressource

Pour créer la ressource, on commence par définir ses propriétés avec la cmdlet “New-xDscResourceProperty”. Celles-ci possèdent à minima un nom, un type et des attributs. Ces derniers permettent de définir l'accessibilité (lecture, écriture,...). Lorsque l'on définit une nouvelle ressource, au moins une de ses propriétés devra posséder l'attribut “Key” et ne pourra être un tableau. Cet attribut permet d'indiquer la propriété utilisée lors de la recherche d'une ressource.

• le nom du partage
• le chemin vers lequel le partage pointe
• la présence ou l'abscence du partage

Un module Powershell qui ne comprend pour l'instant que le fichier .PSM1 a aussi été généré. Il faut maintenant définir la logique de nos 3 fonctions à l'intérieur de ce module.

Get-TargetResource

Set-TargetRessource

NB : Lors de la génération du template de module à remplir, il est indiqué dans le corps de la fonction qu'il faut positionné la variable globale “$global:DSCMachineStatus” avec la valeur 1 si une configuration nécessite un reboot après son application.

Test-TargetResource

A noter, qu'à la fin de notre module, la cmdlet “Export-ModuleMember” est présente et obligatoire afin que Powershell découvre correctement les méthodes de la ressource.

Génération du manifest

Les autres champs du fichier .PSD1 généré peuvent aussi être spécifiés via la cmdlet précédente ou en remplissant manuellement le fichier (via un éditeur de texte). Certaines propriétés seront même automatiquement remplies (exemple : auteur avec le samaccountname de l'utilisateur ayant lancé la commande).

Voici un lien menant vers le manifest généré pour cette ressource : Manifest

Import de la ressource et utilisation

Il suffit de placer notre ressource (Répertoire C:\NFSShare dans notre exemple) dans “C:\Program Files\WindowsPowerShell\Modules\”

 

Conclusion

Lors de cet article, nous avons vu la création d'une ressource permettant de gérer des partages NFS. Il est possible de l'améliorer en gérant d'autres propriétés de ce type de partage comme les permissions. 

Préambule

L'ensemble des manipulations ont été réalisées sur une infrastructure Windows 2012 R2 / ADFS 3.0.

Problématique

Avec quelques connaissances en développement web (CSS et Javascript), il est possible de customiser les pages de logon ADFS. On peut positionner un logo qui remplacera le nom de la federation ou encore changer l'illustration par défaut. De plus, Microsoft offre aussi la possibilité de changer une partie du code Javascript et CSS. Nous verrons donc comment gérer ses templates ADFS puis je détaillerai un script Javascript permettant d'ajouter automatiquement le suffixe UPN de l'utilisateur. Ainsi toute personne souhaitant se connecter n'aura qu'à entrer son samAccountName. Attention, cette méthode n'est fonctionnelle que dans le cas où tous les utilisateurs possèdent le même suffixe UPN.

Gestion des templates ADFS

Microsoft fourni quelques indications pour customiser les pages ADFS sur le lien suivant :
http://technet.microsoft.com/en-us/library/dn280950.aspx . On retrouve notamment les modifications les plus basiques comme les changements d'images ou de messages (erreur, aide,...).

Aussi, dans ADFS 3.0, il est possible de gérer plusieurs templates via les Cmdlets Powershell adéquates. Le template de base se nomme "default". On peut d'ailleurs récupérer la liste des thèmes avec la Cmdlet Get-ADFSWebTheme. On remarque qu'il s'agit bien du template de base grâce à l'attribut IsBuiltinTheme.

Les étapes de customisation d'un thème sont les suivantes :

• création d'un nouveau thème 
• export des fichiers du thème 
• modification des fichiers 
• import des fichiers modifiés dans le thème créé

Pour ajouter un nouveau thème il suffit d'utiliser la commande New-AdfsWebTheme en spécifiant le nom du thème ainsi que les sources du nouveau thème. En général, on se basera sur le thème par défaut que l'on customisera ultérieurement.

Il nous faut ensuite exporter les fichiers de ce thème (vers le dossier C:\ADFSTheme par exemple) :

Attention le dossier d'export doit exister (il ne sera pas généré automatiquement).

On remarque que l'on a accès à un certain nombre de fichiers mais pas à tous. En général, ceux que l'on voudra customiser sont le fichier onload.js et le fichier style.css.

Une fois modifiée, il ne reste plus qu'à importer le fichier dans le thème nommé custom. Un exemple avec le fichier onload.js :

Enfin pour définir le thème custom comme actif il faut utiliser la Cmdlet ci-dessous :

Ajout automatique du suffixe UPN

Afin de faciliter l'expérience utilisateur lors d'un usage en situation de mobilité ou via un navigateur ne supportant pas ADFS, il peut être utile d"ajouter automatiquement le suffixe UPN lorsque ce dernier a été omis dans le formulaire d'authentification. Pour les utilisateurs ne connaissant pas les notions de nom de domain Netbios ou d'UPN, cette customisation peut être interessante. Celle-ci nécessite du code Javascript.

ADFS se base sur la valeur entrée dans le champ “UserName” avec l’ID “userNameInput” du fomulaire. Il faut donc modifier cette valeur. Une autre solution (utilisée ici), consiste à changer l’ID et le nom du champ original. Puis, on ajoute un nouveau champ, invisible à l’utilisateur et contenant la bonne valeur ainsi que l’ID et le nom mentionné précédemment. Cette seconde solution est esthétiquement plus réussi (l’utilisateur ne voit pas le changement)

Ci-dessous, se trouve le script a ajouté à la fin du fichier onload.js est à intégrer dans le thème ADFS via la méthode vu précédemment :

Voici les opérations réalisées par le script lorsque le formulaire est valider (via la touche “Entrée” ou un clic sur le bouton de connexion) :

• Récupération du champ contenant l’identifiant utilisateur
• Vérification de la présence d’un suffixe UPN

Si le suffixe est manquant :

• On renomme le champ contenant l’identifiant utilisateur (UserName) et on change son ID (userNameInput).
• On ajoute un nouveau champ non visible portant les valeurs initiales (Id et nom). Il contiendra la valeur entrée par l’utilisateur avec le suffixe UPN. Celles-ci seront transmises à ADFS.

Une amélioration pourrait être d'ajouter une balise “select” contenant une liste de tous les suffixes UPN possibles. Cela permettrait de gérer les infrastructures utilisant de multiples suffixes UPN.

La problématique

Lors de l’installation de Windows Azure Active Directory Synchronization (aka “DirSync”) sous Windows Server 2012 R2, l’erreur suivante peut apparaitre :

The minimum version of Windows Powershell required is 2,0.
Please install the minimum version required (or higher) and try again.

Cela peut sembler étrange d’autant plus que Windows Server 2012 R2 intègre nativement la version 4.0 de PowerShell.

Explication

Il semble que ce problème soit dû à la localisation du système d’exploitation. En effet sur un système d’exploitation installé en langue française, le caractère séparateur entre les entiers et les décimales est la virgule et non le point.

Or on peut remarque que le message d’erreur indique un problème pour détecter la version PowerShell 2,0 et non 2.0.

Solution

La solution consiste tout simplement à modifier les formats de date, d’heure et de nombre et à les passer sur le format anglais.

Il suffit ensuite de fermer, puis de relancer l’installeur de DirSync pour que la modification soit prise en compte et que PowerShell soit bien détecté.

N.B. : Ne pas oublier de lancer dirsync.exe avec des droits administrateur (clic droit, puis Run As Administrator), sinon une exception .net apparaît

Introduction

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

• Partie 1 : introduction et syntaxe
• Partie 2 : configuration du mode push
• Partie 3 : configuration du mode pull (via smb)
• Partie 4 : configuration du mode pull (via web service)
• Partie 5 : création d’une ressource personnalisée

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 :

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

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

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.

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 :

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

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

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.

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

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.

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.

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 :

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 :

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

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

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 :

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

Introduction

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

• Partie 1 : introduction et syntaxe
• Partie 2 : configuration du mode push
• Partie 3 : configuration du mode pull (via smb)
• Partie 4 : configuration du mode pull (via web service)
• Partie 5 : création d’une ressource personnalisée

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

Après avoir montré la configuration du mode Push, cette troisième partie est consacrée au mode Pull et plus particulièrement lorsqu'on l'utilise conjointement à un partage de fichier Samba.

Ainsi, j'expliquerai comment fonctionne le mode Pull ainsi que les différentes étapes de configuration.

Fonctionnement

Pour rappel, DSC fonctionne de la manière suivante :

• Récupération de la configuration
• Application de la configuration
  

Ces deux étapes se répètent indéfiniment selon le temps d'actualisation qui a été défini pour chacune d'entre elles.

La principale différence entre les modes Pull et Push concerne la récupération de la configuration. Le mode Pull utilise le principe inverse du mode Push. Au lieu de transmettre les modifications de configurations à nos serveurs, ces derniers vont interroger eux-même un "dépôt" central (appelé serveur Pull) qui contiendra l'ensemble des configurations gérées par DSC. Le serveur appliquant sa configuration et donc aussi à l'origine de la connexion pour vérifier s'il y a une nouvelle version de sa configuration. Lors de la récupération d'une nouvelle version, le fichier MOF récupéré est vérifié via un fichier checksum présent sur serveur Pull. Ci-dessous un schéma récapitulatif des deux modes (Pull et Push) :

En mode Pull, nous n'avons plus à nous préoccuper de savoir si un de nos serveurs possède la bonne configuration (si elle lui a bien été transmise). Concernant le mode Pull, il existe actuellement deux types de dépôts pour centraliser les fichiers de configurations :

• Un partage de fichier (expliqué dans cet article)
• Un web service (son fonctionnement sera détaillé dans la partie 4 de ce guide sur DSC).

Ceux-ci seront interrogés par les serveurs utilisant DSC.

Comme pour le mode Push, il est nécessaire de configurer la ressource LocalConfigurationManager qui définira les différents paramètres de fonctionnement de DSC sur les machines clientes.
L'un des principaux paramètres configuré est le ConfigurationId. Il s'agit d'un GUID utilisé pour reconnaître le bon fichier de configuration à télécharger depuis le serveur Pull. Ce GUID est inscrit dans le nom du fichier de configuration (exemple : 6c7544f9-4fa9-4a62-a715-04aebfd70b85.mof).

La configuration du mode Pull s'effectue en différentes étapes :

• Configuration de la ressource LocalConfigurationManager. Un fichier .meta.mof est créé par serveur pour appliqué la nouvelle configuration de la ressource sur chaque serveur.
• Génération des fichiers de configuration des serveurs : il s'agit des fichiers .MOF contenant les configurations des serveurs utilisant DSC (un fichier par serveur).
• Copie des fichiers sur le partage (serveur Pull).
• Renommage des fichiers MOF avec le GUID de chaque machine concerné.
• Création des fichiers checksums afin de vérifier l'intégrité des fichiers MOF lors de la récupération d'une configuration par un client (fichier .mof.checksum).

Dans la suite de cet article, je fournis des scripts pour automatiser l'ensemble de ces étapes. Certaines fonctions sont inspirés par l'article de Johan Akerström (http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/) sur le sujet. Les scripts présents en fin d’article sont compatibles avec Windows 7/2008R2 car ils n'utilisent pas les nouvelles Cmdlet Powershell 3.0 et 4.0 uniquement disponibles sur Windows 8/2012 et supérieur. Cela permet de mettre en place un environnement DSC sur une infrastructure ne possédant pas les toutes dernières version des systèmes d'exploitation Microsoft. Avec ces scripts, il est possible de déployer un serveur Pull via DSC, d'automatiser la configuration de DSC sur les serveurs à gérer ainsi que la génération des fichiers de configuration.

Ressource LocalConfigurationManager

La ressource LocalConfigurationManager est expliquée dans la Partie 2 ; je vous invite donc à vous y référer en complément des paramètres liés au mode Pull.

• RefreshMode : C’est le mode de fonctionnement du client DSC, la valeur attendue est Pull (pour que cela soit fonctionnel les paramètres DownloadManager et DownloadManagerCustomData sont obligatoire)
• DownloadManager : Les valeurs possibles sont WebDownloadManager ou DSCFileDownloadManager. Lorsque l'on utilise le mode Pull en mode fichiers (et non web service) alors il faut choisir DSCFileDownloadManager.
• DownloadManagerCustomData : Il s'agit ici d'indiquer dans un hashtable (via la clé SourcePath), le chemin d'accès aux fichiers MOF.
• RefreshFrequencyMins : C'est le temps de refresh du fichier de config à partir de la source (ici SMB)).
• ConfigurationModeFrequencyMins : C'est le temps entre chaque vérification de conformité.
• ConfigurationId : Un GUID pour récupérer les bons fichiers de configurations. La machine n'appliquera que le .MOF portant son ConfigurationID.
• RebootNodeIfNeeded : C’est un booléen autorisant ou non le redémarrage automatique de la machine si celui-ci est nécessaire.
• ConfigurationMode : Apply, ApplyAndMonitor, ApplyAndAutoCorrect (voir partie 2 pour l'explication).

Exemple de reconfiguration du LocalConfigurationManager pour le mode Pull via partage SMB :

NB : Pour appliquer cette configuration, le remote Powershell doit être activé sur les machines clientes (actif par défaut sur Windows 2012/R2)

Partage SMB

Le partage SMB est crucial car il contiendra l'intégralité des fichiers MOF et des fichiers checksums. A partir de Windows 8/2012 est supérieur, il existe un module permettant de gérer simplement les partages SMB (création avec New-SMBShare). Voici une méthode en WMI pour les postes n'ayant pas ce module. Cette dernière ajoute aussi les permissions de partage de contrôle total pour le groupe Everyone.

Ensuite, il est nécessaire d'appliquer des permissions NTFS en lecture et exécution pour le groupe Everyone :

ConfigurationID

Le GUID attendu par le paramètre ConfigurationId peut être généré automatiquement :

On peut aussi utiliser le GUID de l'ordinateur dans Active Directory comme l'explique Johan Akerström dans son article sur DSC : http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/

# Define Get Computer GUID Function 
# Credit: Johan Åkerström 
# http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/
 
Function Get-ComputerGuid { 
  param( 
    [Parameter(Mandatory=$true)] 
    [string]$ComputerName 
  ) 
 
  process { 
    ([guid]([adsisearcher]"(samaccountname=$ComputerName`$)").FindOne().Properties["objectguid"][0]).Guid 
  } 
} 

On peut ensuite copier tous nos fichiers MOF de configuration sur le partage en changeant leurs noms avec le GUID.

Checksum des fichiers MOF

Depuis Powershell 4, il existe une cmdlet permettant de généré un hash : "Get-FileHash". L'algorithme à choisir est SHA256 (celui par défaut).Voici le lien vers la documentation :
http://technet.microsoft.com/en-us/library/dn520872.aspx

Il nous suffit ensuite de créer les fichiers checksum contenant ce hash.

Scripts

Deux scripts sont accessibles via les liens ci-dessous.

Configuration du serveur Pull avec DSC : ici

Librairie de fonctions nécessaires au serveur Pull : ici

L'outil permet de déployer un serveur DSC en mode PULL via DSC. Toutes les étapes sont automatisées. Les fichiers de configurations des clients sont automatiquement générés (copy et renommage avec le guid, création des fichiers checksum, création de tous les fichiers .meta.mof contenant la configuration du LocalConfigurationManager avec la commande Set-DSCLocalConfigurationManager). Il n'y a plus qu'à déployer les ressources LocalConfigurationManager sur les clients (avec un compte possédant les droits nécessaires). Voici les différentes étapes réalisées par le script par ordre d’exécution (chacune d’entre elles nécessite la réussite de la précédente via le paramètre de ressource DSC  DependsOn) :

1. Un dossier contenant le partage avec les configurations est créé.
2. La permission NTFS "ReadAndExecute" est ajouté au group everyone ainsi que la permission "FullControl" pour le compte ordinateur du serveur Pull. En effet, il va créer des dossiers et générer des fichiers. C'est ce compte qui exécute les fichiers de configuration dans DSC.
3. Un partage est généré.
4. Sur ce partage, le groupe everyone possède la permission "Change". Le compte ordinateur du serveur Pull a des droits "FullControl".
5. Une arborescence de dossier est généré :
       Il y a un dossier contenant les configurations créées par l'administrateur (OriginalConfiguration). Un second répertoire (Configuration) a les même configurations renommées avec le GUID de l'ordinateur (pré requis du mode Pull pour que le client récupère sa configuration, voir explication sur le ConfigurationId). Ce dernier contient aussi un fichier checksum pour chaque fichier de configuration .MOF. Un script de librairie est présent dans un troisième dossier (Scripts). Enfin, un répertoire nommé LCM possède tous les fichiers ".meta.mof" de configuration de la ressource LocalConfigurationManager des machines clients.
6. Le script Powershell contenant les fonctions suivantes est copié dans le répertoire des scripts du serveur Pull :
   • Récupération d'ordinateurs sans module Active Directory (via adsisearcher)
   • Génération automatique des fichiers checksum à partir d'un fichier .MOF
   • Récupération du GUID d'un ordinateur
   • Configuration de la ressource LocalConfigurationManager
7. Les fichiers de configuration de la ressource LocalConfigurationManager sont générées pour chaque machine client via le filtre qui a été convenu. Il est possible de sélectionner des ordinateurs par unité d'organisation ou par groupe Active Directory suivant les paramètres entrées lors de la génération du fichier de configuration MOF du serveur Pull.
8. Copie des fichiers de configurations créer par l'utilisateur sur le répertoire contenant les .MOF renommés avec un GUID ; ainsi que création des fichiers checksum associés pour que les clients vérifient l'intégrité de la configuration récupérée. Gràce à cette étape dès qu'une nouvelle configuration ou une modification de l'une d'entre elles a lieu, elle est automatiquement mis à jour avec un une regénération du fichier checksum.

Les étapes 1,2,3,4,5,7,8 sont des ressources DSC de types "script" tandis que l'étape 6 est de type "file".

NB : DSC possède son propre journal d'événements pour vérifier son bon fonctionnement : Applications and Services Logs / Microsoft / Windows Desired State Configuration. Ce dernier permet de superviser DSC lorsqu’on ne déploie plus les configurations manuellement (en mode Push).

Contexte

Dans le cadre de projets, il peut arriver que les licences définitives ne soient pas livrées au moment du déploiement des serveurs. Pour ne pas perdre de temps, il est possible d’installer la version d’évaluation de Windows Server 2012 R2 (http://technet.microsoft.com/fr-fr/evalcenter/dn205286.aspx) qui est valable 180 jours et de la mettre à niveau vers une version commerciale une fois la licence acquise.

Solution

La commande-let DISM permet de mettre à niveau notre version d’évaluation vers une version commerciale (avec licence).

Pour se faire, lancez l’invite de commande en tant qu’administrateur et tapez la commande suivante :

DISM /Online /Set-Edition:<type de version> /ProductKey:<licence> /AcceptEula

Une fois la commande terminée, il faut redémarrer le serveur.

Remarque : Afin de savoir vers quelle type de version il est possible de mettre à niveau le serveur utilisez la commande DISM /Online /Get-TargetEditions

Après le redémarrage le serveur n’est plus un serveur d’évaluation et il peut être activé normalement.

Remarques

1 – Cette commande fonctionne également avec une des nouveautés de Windows Server 2012 R2 : l’AVMA (Automatic Virtual Machine Activation).

2 – Attention cette mise à niveau ne fonctionne pas si le serveur est un contrôleur de domaine. Pensez donc bien à faire la manipulation avant l’installation du rôle Active Directory Domain Services !