PI Services

Le blog des collaborateurs de PI Services

Windows Serveur : Extraction des configurations DHCP

Attention ne s'applique qu'à partir de  Windows Server 2012 et Windows 8.

Comment connaitre rapidement les configurations DHCP du domaine? Eh bien, avec Powershell.

 

Lister les serveurs DHCP du domaine:

Pour lister les serveurs DHCP du domaine vous pouvez utiliser la commande:

Get-DhcpServerInDC

Cette commande vous retournera par défaut :

  1. l'adresse IP du ou des serveurs
  2. Le nom Dns du ou des serveurs

Lister les scopes DHCP:

Pour lister les scopes DHCP et leurs configurations vous pouvez utiliser la commande suivante:

Get-DhcpServerv4Scope

Par défaut cette commande vous retournera les éléments suivants:

  1. L'étendue
  2. Le masque sous réseau
  3. Le Nom du scope
  4. L'état (Actif ou Inactif)
  5. L'adresse IP de début
  6. L'adresse IP de fin
  7. La durée des baux

Bien sur il est possible de récupérer d'autres informations si vous le souhaitez.

Obtenir des informations sur les scopes:

Pour obtenir des informations sur l'utilisation des scopes vous pouvez utiliser la commande suivante:

 

Get-DhcpServerv4ScopeStatistics

 

Cette commande retourne :

  1. L'étendue
  2. Le nombre d'adresses libres
  3. Le nombre d'adresses utilisées
  4. Le pourcentage d'utilisation
  5. Le nombre d'adresses réservées
  6. Le nombre d'adresses en attente de distribution (normalement 0)
  7. Le nom de l'étendue globale

Peut on scripter tout ça?

Il vous est possible d'exécuter toutes ces commandes à distance via "invoke-command" ou "Enter-PSSession" sauf la commande "Get-DhcpServerInDC".

Donc il est possible de scripter toutes ces commandes et avoir une belle extraction sans se connecter au serveur à condition de déjà posséder la résultante de  "Get-DhcpServerInDC".

Sinon vous pouvez aussi exécuter un script depuis le serveur, mais bon ça, c'est quand même moins "Secure".

Plus d'informations sur : 

https://technet.microsoft.com/library/jj590751(v=wps.620).aspx

 

 

Desired State Configuration (Partie 5) : Création d’une ressource personnalisée

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

Une ressource est constituée de plusieurs fichiers :

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

DSC xDscResourceDesigner

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.

Dans l'exemple ci-dessous, on définit 3 propriétés :

  • le nom du partage
  • le chemin vers lequel le partage pointe
  • la présence ou l'abscence du partage
Ensuite, il est nécessaire de créer la ressource via la cmdlet “New-xDscResource”. Il faut spécifier toutes les propriétés utilisées dans cette ressource, le nom de la ressource et éventuellement le chemin où l'on va la stocker (sinon il sera placé dans un répertoire “DSCResources” à l’intérieur du répertoire dans lequel on se trouve).
Nous nous retrouvons avec le fichier .MOF ci-dessous :

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

Le code intégré à la fonction “Get-TargetResource” récupère le partage NFS s'il existe et retourne le chemin vers lequel il pointe. S'il n'y a pas de partage NFS avec ce nom, alors un message est écrit dans l'invite de commande Powershell.

Set-TargetRessource

Dans le code ci-dessous, on récupère un éventuel partage avec le nom défini en paramètre. Si ce dernier existe, alors on le met à jour avec le bon chemin (obligation de supprimer puis de recréer le partage NFS) sinon le partage NFS est créé. Si le partage est présent alors que la propriété “Ensure” a pour valeur “Absent” alors le partage NFS est supprimé. Il est à noter que cette fonction n'est appelée que lors de la modification d'un fichier de configuration d'un serveur ou lorsqu’une configuration est incorrecte.

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

Cette dernière fonction valide qu'une configuration est bien appliquée. Elle vérifie l'existence du partage ainsi que le chemin vers lequel il pointe si le paramètre “Ensure” a pour valeur “Present”. Si “Ensure” vaut “Absent” alors il est vérifié que le partage NFS n'existe pas. Les différents tests retournent la valeur “$true” si la configuration est bonne et “$false” dans le cas contraire. 

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

Enfin, il faut générer le fichier de manifest du module. Afin de réaliser cette opération, il faut utiliser la commance New-ModuleManifest en spécifiant les paramètres “FunctionsToExport”, “RequiredModules” et “Path”. Attention, le chemin indiqué doit être la racine de la ressource créée (Au même niveau que le dossier DSCResources), sinon il vous sera impossible d'importer la ressource. De même, le nom du manifest doit être le même que le nom du module.

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\

En utilisant la commande “Get-DSCResource”, on remarque que notre ressource NFSShare est disponible. On s'aperçoit aussi que la propriété DependsOn est automatiquement rajouté sur cette ressource. Il s'agit d'une propriété par défaut disponible sur toutes les ressources DSC. Pour rappel elle permet de lier des configurations entre elles en spécifiant qu’une configuration dépend de la réussite d’une autre.
 DSC List Resources
Il est ensuite possible de générer un fichier de configuration pour un serveur. Il est nécessaire d'ajouter la commande “Import-DscResource” en renseignant le paramètre “ModuleName” dans le bloc de configuration lorsque l'on utilise des ressources personnalisées.
Enfin, on applique la configuration via la ligne de commande ci-dessous et on obtient bien la création du partage NFS :

DSC Result

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. 

Windows 2012 Server Manager: Ajout “basique” d’un serveur a gérer.

 

Windows 2012 est clairement orienté Gestion a distance.

Voici comment ajouter rapidement un serveur dans la liste des serveurs gérés

image

Cliquez en haut a droite de la console sur Manage – Add Servers

image

Assurez vous que le nom du serveur a ajouter est bien résolu, ou bien renseignez son IP

image

Une fois découvert, ajoutez le a la sélection de droite, puis OK.

image

Aïe! un message ‘'”Refresh Failed” vous indique que le client WinRm n’a pas pu exécuter la requête.

image

Ouvrez un fenêtre de commande et exécutez la commande:

winrm set winrm/config/client @{TrustedHosts="mcsaw2k12srv1"}

Ceci pour ajouter la machine cible a la liste des serveurs autorisés dans la configuration du client WinRM.

image

Fermez les notification précédentes et réitérer l’ajout du serveur.

Il apparait a présent dans la liste

image

Faites un clic-droit sur le nom et sélectionnez Manage As… si le serveur distant doit être géré avec un compte diffèrent.

image

image

Desired State Configuration (Partie 3) : Configuration du mode pull (via smb)

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

image 

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/

1 2 3 4 5 6 7 8 9 10 11 12 13 14
# 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é :
        image 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).

Desired State Configuration (Partie 2) : LocalConfigurationManager et Mode Push

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, Winsows 2012/8 et Windows 2008 R2/7.

Il s’agit de la seconde partie qui traite de la configuration du mode Push. Pour rappel, il existe deux modes d’application d’une configuration avec la technologie DSC :

  • Push
  • Pull

Ainsi, nous verrons comment le mode Push fonctionne. Nous nous attarderons ensuite sur la configuration du mode push via une ressource. Enfin, j’expliquerai comment appliquer une configuration en mode Push à distance.

Fonctionnement

Le mode Push est le mode par défaut dans Desired State Configuration. Chaque configuration est poussé par l’utilisateur via ligne de commande ou script directement depuis le serveur concerné ou à distance depuis un autre serveur. L’intérêt de la deuxième option est de centraliser les fichiers “.mof” sur un seul serveur. Pour appliquer la configuration il faut utiliser la commande Start-DscConfiguration (comme vu dans la partie 1).

Ressource LocalConfigurationManager

L’une des nombreuses ressources disponibles lors d’une configuration est nommée : LocalConfigurationManager. Cette dernière permet de définir quand et comment seront appliquées les configurations. Elle est décrite dans le lien ci-dessous :

http://technet.microsoft.com/en-us/library/dn249922.aspx

NB : Au 16/12/2013, le lien comporte des erreurs. Nous allons donc voir ici les différents attributs qui peuvent nous intéresser pour le mode Push.

La ressource LocalConfigurationManager s’utilise comme toutes les autres ressources de DSC. Il va donc être nécessaire de générer un “.mof” contenant cette ressource, puis l’appliquer. Pour récupérer la configuration actuelle  du LocalConfigurationManager  du serveur, il faut utiliser la commande :

001
Get-DscLocalConfigurationManager

 

Le résultat par défaut est le suivant :image Les attributs intéressants pour le mode Push sont :

  • RefreshMode : La valeur doit être à PUSH.
  • ConfigurationMode : Apply, ApplyAndMonitor, ApplyAndAutoCorrect sont les valeurs possibles. Apply définit qu’il faut simplement appliquer la configuration. ApplyAndMonitor ajoute une phase de contrôle et loguera les éventuelles dérives de configuration (dans l’observateur d’événements). ApplyAndAutoCorrect réapplique la configuration après chaque nouveau test, s’il y a une dérive.
  • RefreshFrequencyMins : Il s’agit de l’intervalle de temps pour l’actualisation du fichier de configuration. La valeur minimal est 15 minutes.
  • ConfigurationModeFrequencyMins : C'est le temps entre chaque vérification de conformité.
  • RebootNodeIfNeeded : C’est un booléen autorisant ou non le redémarrage automatique de la machine si celui-ci est nécessaire.

    Voici un exemple de script configurant la ressource LocalConfigurationManager :

    001
    002
    003
    004
    005
    006
    007
    008
    009
    010
    011
    Configuration SetPushMode
    {
        Node WEBSRV01 {
           
            LocalConfigurationManager {
                ConfigurationMode = "ApplyandMonitor" 
                RefreshMode = "Push"
                RefreshFrequencyMins = 30
            }
        }
    }

    On invoque ensuite le bloc Configuration (ligne 1) et on l’applique (ligne 2) afin que la configuration soit prise en compte.

    001
    002
    SetPushMode -OutputPath C:\DSCConfig
    Set-DscLocalConfigurationManager -Path C:\dscconfig\ -ComputerName WEBSRV01 -Credential "WEBSRV01\Administrator" -Verbose

    Ici, les paramètres Credendial et ComputerName sont renseignés permettant d’appliquer la configuration de la ressource à distance.

    Pour que la connexion à distance fonctionne, il est nécessaire de pouvoir se connecter en WMI à distance à “root/Microsoft/Windows/DesiredStateConfiguration”. Pour configurer ce pré-requis, il faut se référer à l’article suivant : http://blog.piservices.fr/post/Powershell-Gestion-a-distance.aspx.

Application d’une configuration à distance

Nous avons vu l’application d’une configuration en mode Push lors de la partie 1. Nous verrons donc ici simplement un complément permettant d’appliquer une configuration à distance. On peut ainsi imaginer un script s’exécutant sur un serveur central possédant tout les fichiers “.mof”. Ce script bouclera sur l’ensemble des serveurs d’une liste et lance les commandes de configuration. Dans cet exemple, on considère qu’un fichier “.mof” a été généré dans “C:\DSCConfig”.

001
Start-DscConfiguration -ComputerName WEBSRV01 -Path C:\dscconfig -Verbose -Wait

Les paramètres utilisés ainsi que les pré requis sont les mêmes que précédemment, seul la cmdlet utilisée change.

Desired State Configuration (Partie 1) : Introduction et syntaxe

Introduction

Powershell 4.0 (introduit avec Windows 2012 R2) apporte son lot de nouveautés. La plus importante est : Desired State Configuration.

En entreprise, il existe deux problématiques récurrentes au sein d’un système d’informations :

  • L’augmentation du nombre de serveurs
  • Le changement

Desired State Configuration apporte une solution à ces questions en proposant une solution pour l’automatisation des déploiements et la maintenance des serveurs (contrôle et retour en conformité).

Avec cette fonctionnalité, il sera possible de déployer rapidement et à grande échelle des améliorations à une infrastructure, tout en s’assurant que les systèmes ne varient pas au cours du temps.

Par exemple, on peut vouloir s’assurer qu’un groupe de serveurs web possède :

  • le rôle adéquat correctement configuré,
  • les services nécessaires démarrés
  • les sources valides d’un site web copiées dans le bon répertoire
  • la bonne adresse IP pour chaque serveur.

DSC permet de configurer un serveur via un script au travers d’une syntaxe simple (similaire aux fonctions Powershell). Les possibilités de configuration sont infinies (rôles, groupes et utilisateurs locaux, registre…). Cette configuration peut se faire en local ou à distance. De plus, au delà de la première application de la configuration du serveur, il existe des mécanismes de contrôles. Avec Desired State Configuration, Windows peut automatiquement vérifier si sa configuration est correcte et la remettre à niveau s’il y a eu un changement anormal. Ainsi, les dérives de configuration sont évitées !

    Pour appliquer une configuration, il existe deux modes :

  • Push : La configuration est envoyé au serveur
  • Pull : La configuration est demandé par le serveur client vers un serveur centrale qui gère toutes les configurations possibles.

Grâce au scripting il va être possible d’appliquer des configuration à des groupes de serveurs.

DSC est basé sur les fichiers “.mof”. Il est possible de les générer de la façon que l’on souhaite (éditeur de texte par exemple). Powershell 4.0 permet de simplifier la génération de ses fichiers notamment grâce à l’auto complétion mais aussi avec syntaxe accessible. Via le module PSDesiredStateConfiguration, on peut créer ses fichiers et les utiliser pour appliquer une configuration.

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, Winsows 2012/8 et Windows 2008 R2/7.

Les ressources

Les éléments que l’on va pouvoir configurer sont appelés ressources.

Voici quelques exemples de ressources disponibles nativement : l’exécution de services, de clés de registre, de scripts ou de variables d’environnement. Les groupes et utilisateurs locaux ainsi que la copie de fichiers sur un serveur est aussi gérable. Les possibilités sont infinies.

Il est aussi possible de créer ses propres ressources, en définissant la façon de réaliser la configuration sur le serveur et de tester la conformité. Ainsi on peut imaginer une ressource qui s’occupera de la gestion du fichier “hosts”, un autre peut gérer la configuration IP ou même la présence et l’activation de règle firewall.

La liste des ressources disponibles nativement est listé dans le lien suivant : http://technet.microsoft.com/en-us/library/dn249921.aspx

La syntaxe

La syntaxe Powershell implémentée se base sur le mot clé Configuration. Voici un exemple :

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
Configuration TestDSC 
{ 

  Node WEBSRV01 #Nom du serveur
  { 
    WindowsFeature IIS 
    { 
      Ensure = “Present” #Vérifie que le rôle est présent
      Name = “Web-Server” #Nom du rôle ou de la fonctionnalité à vérifier
    } 

    File DirectoryCopy
    {
        Ensure = "Present" #Vérifie que les fichiers/dossiers sont présents
        Type = "Directory" #Type d'objet à vérifier
        Recurse = $true #Inclus les fichiers/dossiers enfants
        SourcePath = "\\FILESRV01\MyWebSite" #Chemin des sources
        DestinationPath = "C:\inetpub\wwwroot\MyWebsite" #Destination où doivent se trouver les données
    }
   
    Group ViewerGroup
    {
        Ensure = "Present" #Vérifie qu'un groupe est présent
        GroupName = "Viewer" #Nom du groupe
    }
  } 
}

La déclaration se fait donc via des blocs entre accolades. Dans un bloc de type Configuration, on a un ou plusieurs blocs Node. Pour chaque bloc Node, un fichier MOF sera généré. A côté de ce mot clé, on inscrit le nom du serveur qui possédera cette configuration. A l’intérieur de chacun de ses blocs se trouvent les ressources que l’on souhaitent configurer. Dans l’exemple précédent, on retrouve dans l’ordre les 3 ressources suivantes :

  • WindowsFeature : S’assure que le rôle IIS est installée.
  • File : Vérifie que les fichiers sont bien présents sur le répertoire de destination.
  • Group : Constate que le groupe local Viewer existe.

Dans le cas où l’une des ressources retournerait un résultat incorrect alors l’opération serait réalisée afin de mettre l’ordinateur en conformité. Par exemple, pour les sources du site web (Ressource WebsiteDirectory), le fichier de configuration possède le chemin source et la destination.

Pour générer le fichier MOF, il faut appeler notre configuration comme une fonction Powershell :

001
TestDSC -OutputPath c:\DSCConfig

Le paramètre OutputPath (facultatif) définie le dossier où vont être stockés les fichiers de configuration. Le fichier créé portera le nom de la machine portant cette configuration (ici WEBSRV01).

A l’instar des fonctions, on peut utiliser des paramètres. Voici, un exemple similaire au précédent où l’on spécifie la source et la destination des fichiers du site web ainsi qu’une liste de nom d’ordinateur auxquels appliquer cette configuration.

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
Configuration TestDSC 
{ 
 
  param(
    [Parameter(Mandatory=$true)]
    [String[]]$Computers,
    [Parameter(Mandatory=$true)]
    [String]$SourceWeb,
    [Parameter(Mandatory=$true)]
    [String]$DestinationWeb 
  )

  Node $Computers 
  { 
    WindowsFeature IIS 
    { 
      Ensure = “Present” 
      Name = “IIS-Server” 
    } 

    File DirectoryCopy
    {
        Ensure = "Present"
        Type = "Directory"
        Recurse = $true 
        SourcePath = $SourceWeb
        DestinationPath = $DestinationWeb 
    }

  } 
}

Il y aura autant de fichiers MOF générés que de noms dans le paramètre Computers. Voici la commande pour créer les fichiers MOF :

001
002
003
TestDSC -Computers @("WEBSRV01","WEBSRV02","WEBSRV03") `
-SourceWeb "\\FILESRV01\MyWebSite" -DestinationWeb "C:\inetpub\wwwroot\MyWebsite"`
-OutputPath c:\DSCConfig

Application d’une configuration

Ici, nous allons aborder brièvement l’application d’une configuration en local via le mode Push. Le détail de ce mode est expliqué dans la partie 2 de l’article sur Desired State Configuration. On utilise la commande Start-DscConfiguration. Voici l’explication des paramètres utilisées dans la commande ci-dessous :

  • Wait : Ne rend pas la main à l’utilisateur tant que la commande est en cours d’exécution (Par défaut l’exécution de DSC se fait en arrière plan).
  • Verbose : Affiche les opérations effectuées.
  • Path : Le dossier où se toruve le fichier MOF (DSC choisi le fichier portant le nom de l’ordinateur).
001
Start-DscConfiguration -Wait -Verbose -Path C:\DSCConfig

Il ne peut y avoir qu’une configuration active par machine. Si une seconde configuration est appliquée, il n’y aura plus de contrôle de conformité sur les ressources non présentes dans la nouvelle configuration.

Powershell : Gestion à distance

Introduction

L’une des forces de Powershell est la gestion à distance de serveurs, de postes clients et d’applications (comme Exchange, Sharepoint,…). Communément appelée Remote Powershell, elle est apparue avec Powershell 2.0 et donc disponible à partir de Windows Server 2003 (R2) SP2. Cette fonctionnalité n’est pas activée par défaut sur les systèmes d’exploitation Windows hors Windows 2012 (R2). Pour réaliser cette opération il faut lancer la commande suivante en mode administrateur :

001
Enable-PSRemoting

Cette commande permet de démarrer le service WinRM et d’ouvrir les règles de firewall adéquates si celui-ci est activé (port 5985).

Dans cet article, nous verrons comment se connecter à une machine (qu’elle soit dans le même domaine ou dans un workgroup) ou à une application comme Exchange, comment donner la possibilité à un utilisateur de se connecter via Remote Powershell et enfin l’accès WMI distant.

Entre deux ordinateurs du domaine

Il s’agit du cas le plus simple. Pour se connecter à une machine du même domaine, il suffit d’utiliser la commande suivante :

001
Enter-PSSession -ComputerName SERVER01

Il est possible de spécifier l’utilisateur avec lequel on souhaite se connecter via le paramètre Credential :

001
Enter-PSSession -ComputerName SERVER01 -Credential SERVER01\Administrator

Ainsi, un prompt demandant le mot de passe apparaîtra.

Depuis un ordinateur d’un workgroup vers un ordinateur en domaine (et vice versa)

Pour se connecter à une machine appartenant à un domaine différent ou à un workgroup, il est nécessaire que le poste source contienne l’ordinateur distant dans sa liste de client de confiance. Pour ajouter une nouvelle machine, il faut utiliser la commande suivante en mode administrateur :

001
002
003
Set-Item WSMan:\localhost\Client\TrustedHosts -Value *
#OU
Set-Item WSMan:\localhost\Client\TrustedHosts -Value SERVER02

Le paramètre Value peut prendre les valeurs suivantes :

  • un nom explicit d’une machine (SERV01)
  • * : pour accepter toutes les machines (Ceci n’est pas recommandé)
  • *.myenterprise.com : pour accepter toutes les machines possédant le suffixe DNS myenterprise.com

Connexion à distance à une application (Exchange)

Via le couple de commande New-PSSession / Import-PSSession, il est possible de se connecter à une infrastructure Exchange et importer les commandes relatives à la messagerie de Microsoft sur son poste sans avoir à installer le snapin. De plus, seul les commandes accessibles à l’utilisateur seront chargées sur le poste utilisateur (grâce aux mécanismes de RBAC).

001
002
$Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri ` http://MYSERVER/powershell -Credential MYENTERPRISE\User_1
Import-PSSession $Session -AllowClobber | Out-Null

La première ligne de commande crée une session qui se connecte à l’infrastructure Exchange (Attention il faut modifier la valeur MYSERVER et le nom d’utilisateur avec vos valeurs) tandis que la seconde importe les commandes sur l’ordinateur initialisant la connexion.

Sessions distantes et permissions

Afin de se connecter à distance, il est nécessaire de faire partie du groupe Administrators (ou Remote Management Users pour Windows 2012 et supérieur) soit en étant connecté directement avec le bon compte (par exemple via un utilisateur administrateur du domaine) soit en s’authentifiant en tant qu’administrateur via le paramètre Credential vu précédemment. Il est aussi possible de donner l’accès à d’autres utilisateurs via la commande suivante :

001
002
003
Set-PSSessionConfiguration Microsoft.Powershell -ShowSecurityDescriptorUI -Force
#Si l'on est sur un système 64 bits.
Set-PSSessionConfiguration Microsoft.Powershell32 -ShowSecurityDescriptorUI -Force

Une fenêtre s’affiche et il est possible d’ajouter un utilisateur ou un groupe (via le bouton Add) ainsi que des permissions associées. La permission Execute est suffisante  pour se connecter à distance.

image

NB : Sur Windows 2012 et supérieur, il est nécessaire d’ajouter une clé de registre sur l’ordinateur distant pour que les groupes Administrators et Remote Management Users aient le droit de se connecter via Remote Powershell :

Dans le noeud : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system

Il faut ajouter la clé DWord : LocalAccountTokenFilterPolicy avec la valeur 1.

Cette clé de registre s’applique aussi au chapitre suivant.

Gestion WMI à distance

Pour gérer le WMI à distance (via la commande Set-WmiInstance par exemple). Il faut réunir les 3 conditions suivantes sur le serveur auquel on souhaite se connecter :

  • Faire partie du groupe Administrators ou Remote Management Users ou WinRMRemoteWMIUsers__.
  • Avoir les permissions suffisantes sur la classe WMI.
  • Autoriser l’utilisateur dans la configuration DCOM du serveur.

Les deux dernières conditions sont seulement utiles dans le cas d’un utilisateur qui ne fait pas partie du groupe Administrators (ce dernier possède déjà toutes les permissions nécessaires).

    Gestion des permissions via WMI Control :
Pour cette opération il faut lancer une console MMC et ajouter le composant WMI Control. Effectuer un clic droit et choissisez Properties puis naviguer dans l’onglet Security. Dans la MMC, on sélectionne l’espace de noms qui nous intéresse et on clique sur le bouton Security. Cliquez sur Advanced (cette option plus complète, permet éventuellement d’étendre les permissions au classes enfantes).

image image

On ajoute l’utilisateur ou le groupe avec au minimum les permissions Enable Account et Remote Enable. Il sera surement nécessaire d’ajouter d’autres droits suivants l’action que l’on souhaite réaliser.

image

Autorisation de l’utilisateur dans la configuration DCOM :

En lançant la console dcomcnfg, aller dans Component Services, Computers, My Computer et effectuer un clic droit et choisir Properties.

Dans l’onglet COM Security, choisir Edit Limits dans la section Launch and Activation Permissions. Ajoutez l’utilisateur ou le groupe souhaité et activez l’ensemble des permissions pour avoir accès en local et à distance en WMI via Powershell.

image image

Windows Server 2012–Evaluer l’impact de la déduplication

Windows Server 2012 intègre la notion de déduplication des données. Cette nouvelle fonctionnalitée permettrait d’economiser de l’espace disque, mais combien?

Pour cela Microsoft a intégrer un outil d’analyse permettant de prendre une décision sur l’activation ou non de la déduplication sur certains volume. Cet outils se nomme ddpeval.exe.

L’outil est automatiquement installer lors de l’ajout de la fonction déduplication.:

image

Une fois l’outil installer, il se trouve dans le répertoire c:\Windows\system32

L’outils peut etre copier sur d’autre serveur afin de réaliser les test.

L’outils peut etre copier sur d’autre serveur afin de réaliser les test.

Lancer une invite de commande puis lancer l’outils suivi du chemin a analyser:

Attention ddpeval.exe ne peut pas etre éxécuté sur un disque system, de démarrage ou encore un volume surlequel la déduplication est deja activée. L’analyse peux prendre plusieurs heures en fonction de la volumétrie:

image

Une fois l’analyse finie un compte rendu est affiché. Dans cet exemple 25% de l’espace peut etre economisé si la compression est activée.

Pour plus de détail sur la déduplication:

http://technet.microsoft.com/fr-fr/library/hh831700.aspx

Supprimer Windows.old sur Windows Server 2012

Depuis Windows Server 2008 l’assistant d’installation est capable de détecter un ancienne installation de Windows Server et – dans le cas où celle-ci est compatible – l’assistant d’installation proposera un “Upgrade” vers l’OS désiré.

L’avantage de l’Upgrade est de conserver la configuration et les rôles du serveur après l’installation du nouveau système d’exploitation. Néanmoins, Microsoft recommande lors de l’installation (ou de la mise à jour) d’un serveur de passer par une “Clean Install”, soit une installation traditionnelle de Windows Server.

Pour information, il est impossible d’Upgrader d’une version 32 bits vers une version 64 bits, la seule solution est de recourir à une Clean Install.


Après une Upgrade du serveur, le dossier utilisé par l’ancien système d’exploitation est toujours présent et a été renommé Windows.old.

Pour supprimer correctement ce dossier il faut passer par le “Disk Cleanup” et les habitués de Windows Server seront surpris par son absence sur Windows Server 2012 :

image

Pour faire apparaitre le bouton Disk Cleanup, il faut lancer en tant qu’administrateur la commande PowerShell suivante :

Add-WindowsFeature Desktop-Experience

image

Voici de retour le bouton Disk Cleanup :

image

Le Disk Cleanup ne propose pas immédiatement de nettoyer le dossier Windows.old, il faut passer par l’option “Clean up system files” :

 image

L’assistant Disk Cleanup commence alors à vérifier les anciennes installations de Windows encore présentes sur le serveur :

image

Après analyse, l’assistant propose de nettoyer les dossiers correspondants aux anciennes installations de Windows :

image

image

En moyenne le gain d’espace fait est d’une dizaine de GB, bien entendu cela dépend de la taille de la précédente installation.

Windows Server 2012 : Storage Spaces and Pools

 

Introduction

 

Parmi les nouveautés apportées par Windows Server 2012 et aussi Windows 8 concernant le stockage, on trouve la fonctionnalité Espace de Stockage qui consiste à grouper des disques standard (SATA,SAS..) en plusieurs pools de stockage (Storage Pool) et ensuite créer des Espace de Stockage (Storage Space) à partir de la capacité disponible au niveau du pool de stockage.

Usage

Depuis la console Server Manager on peut accéder à l’interface d’administration du stockage en sélectionnant la fonctionnalité File and Storage Services :

image

Une fois la console File and Storage Services ouverte on peut  sélectionner Storage Pools ce qui nous donne accès à la console d’administration des Pools de Stockage

image

Cette interface unique nous permet de gérer :

  • les Pools de stockage,
  • les Disques physiques qu’on peut affecter à un Pool de Stockage,
  • et les Disques virtuels créé.

Remarques

 

L’utilisation des espaces de stockage permet de :

  • Simplifier le Provisionning en matière de stockage,
  • Réduire les charges administrative relatif à la gestion du stockage,
  • Allouer dynamiquement l’espace,
  • Etendre rapidement les capacité de stockage des serveurs sans pour autant causer des arrêts de services,
  • Consolider et optimiser les gestion du stockage pour des serveurs critiques.