PI Services

Le blog des collaborateurs de PI Services

MDT 2013 - Exécuter un script PowerShell – Partie 1

Cet article indique les étapes à réaliser pour exécuter un script PowerShell durant vos déploiements.

Ajout des fonctionnalités

La première étape consiste à mettre à jour votre image de boot pour la rendre compatible avec l’exécution des scripts PS. Pour ce faire, il est nécessaire d’ajouter des fonctionnalités à votre environnement Win PE. Rendez-vous donc dans les propriétés de votre « Deployment Share ».

A

Sélectionner l’onglet « Windows PE », puis l’architecture de votre plateforme (x86 ou x64) et enfin cliquer sur « Features »

Cette fenêtre vous permet de visualiser les fonctionnalités disponibles. Dans notre cas, pour permettre l’utilisation des scripts PowerShell, il est nécessaire d'ajouter les composants suivants :

  • Microsoft Data Access Components (MDAC/ADO) support
  • NET Framework
  • Windows PowerShell

B

Mise à jour de l’image Win PE

Maintenant que les composants ont été sélectionnés, il faut mettre à jour votre Deployment Share. Cette opération va régénérer votre image WinPE avec les nouvelles fonctionnalités. Pour ce faire : Clic droit sur « Deployment Share » puis sélectionner « Update Deployment Share »

1

Sur l’assistant de mise à jour, vous pouvez laisser les options proposées par défaut.

2 

Cliquez sur Next. L’assistant affiche un résumé. Cliquez une nouvelle fois sur Next pour démarrer le processus de mises à jour de l’image.

3

La durée de l’opération peut prendre quelques instants. Patienter jusqu’à la fin du processus.

4

Après avoir vérifié que l’opération s’est déroulée correctement, cliquez sur Finish pour fermer la fenêtre.

Je vous invite à vous rendre sur la seconde et dernière partie. Celle-ci traite l’ajout de l’image Wim dans WDS et l’ajout d’un script Powershell dans une séquence de tâches.

MDT 2013 – Exécuter un script PowerShell – Partie 2

Importer la nouvelle image WinPE dans WDS

Grâce à la première partie, votre nouvel environnement est maintenant capable d’exécuter des scripts Powershell. Cependant, la nouvelle image WinPE n’est pas encore disponible sur votre serveur WDS (et donc pas pour vos clients Windows). Pour mettre en ligne votre image, rendez-vous dans la console WDS.

D

Sélectionner votre serveur de déploiement, puis le dossier « Boot Image ». Faite un clic droit sur celui-ci et sélectionner « ADD Boot Image »

E

La première étape de l’ajout d’une nouvelle image consiste à indiquer le chemin de votre image WinPE.

5

Par défaut, les images se trouvent dans le chemin suivant :

« CheminDuDeploymentShare\Boot»

Sélectionner votre image (portant l’extension « .wim » et cliquez sur « Next ».

Sur la page suivante, vous avez la possibilité de saisir un nom et la description. Cliquez sur « Next ».

La dernière page vous résume la configuration avant de lancer l’import de l’image.

À la fin de l’opération, vérifier que tout s’est déroulé correctement puis fermer cette fenêtre. À présent, vous devriez voir votre image de boot dans la console.

Ajouter un script PowerShell à votre séquence de tâche

La dernière étape consiste à ajouter un script PowerShell dans une séquence de tâche.

Pour ce faire : Rendez-vous dans la console « Deployment Workbench », puis déplier l’arborescence de votre « Deployment Share » et enfin « Task Sequences ».

Sélectionner votre séquence de tâches et aller dans les propriétés de celle-ci.

f

Une nouvelle fenêtre s’ouvre, allez dans l’onglet « Task Sequence ». Maintenant, cliquer sur « Add » puis sur « General » et sélectionner « Run Powershell Script ».

7

Une nouvelle étape d’exécution d’un script PowerShell a été ajoutée à votre Task Sequence. Vous devez remplir les champs : Name, description (optionnel), PowerShell script et parameters (optionnel).

8

Tips 1 : Dans mon exemple, %DEPLOYROOT% est une variable qui représente l’emplacement de mon « Deployment Share ».

Tips 2: Durant le déploiement, MDT se charge d’autoriser l’exécution des scripts Powershell sur l’environnement client.

Tips 3 : Notez également qu’un fichier log est généré pour chaque script exécuté dans une TS.

A présent vous êtes maintenant capable de déployer vos propres scripts dans votre environnement.

Changement du nom de machine dans le fichier Unattend depuis WinPE 5 en Powershell

 

Vous avez appliqué une image wim sur votre poste depuis WinPe et vous avez besoin de changer le nom de machine qui sera utilisé par la phase Specialize du Sysprep avant de rebooter la machine (pour sa prise en compte).

Charger le fichier xml situé dans le répertoire Windows\Panther dans une variable. (positionné ici après le travail de généralisation du Sysprep)

$xml="C:\Windows\Panther\unattend.xml"
[xml]$xml=get-content $xml

Ensuite via cette ligne de commande, saisissez le nom de votre Poste:

$xml.unattend.settings[1].component[1].computername="NomDuPoste"

(il se peut que dans votre fichier unattend, le noeud “computername” soit positionné ailleurs. Il vous faudra alors parcourir votre variable $xml et identifier ou se trouvera le nœud.)

Maintenant sauvegarder votre fichier XML avec la modification apportée.

$xml.save("C:\Windows\Panther\unattend.xml")

Maintenant lorsque vous redémarrerez votre poste, après la passe spécialize et oobe, le hostname du poste sera celui qui aura été renseigné dans la modification apporté dans le fichier xml.

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

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 !

Application Compatibility Toolkit 6.1 – Partie 1

Je vous propose de faire un tour d’horizon de l’outil Application Compatibility Toolkit 6.1. Cet article se décompose en trois parties :

Partie 1 : Introduction et installation

Partie 2 : Création et déploiement de l’outil d’inventaire

Partie 3 : Analyse et exploitation des données colletées

Introduction

Application Compatibility Toolkit 6.1 permet d’aider les équipes IT dans le processus de migration vers un nouveau système d’exploitation. L’objectif de l’outil est de fournir des informations sur la compatibilité des applications présentes dans votre parc.

Sur quels systèmes d’exploitation peut-on collecter des informations sur les applications ?

L’inventory Collection Package peut être exécuté pour collecter des informations sur les applications installées sur les systèmes suivants :

  • Windows 8.1, 8, 7, Vista, XP et 2000
  • Windows Server 2012R2, 2012, 2008 R2, 2008, 2003 R2 et 2003

Fonctionnement

Depuis la console Application Compatibility Toolkit, on génère un package qui sera chargé d’inventorier les applications des postes de travail. Après exécution du package, les données collectées seront stockées sur un partage réseau dédié.

ACT s’appuie sur un service nommé « ACT Log Processing Service ». Celui-ci analyse les informations contenues dans les fichiers déposés sur le partage réseau. Puis, les données du poste de travail sont ajoutées dans la base de données.

Enfin depuis la console ACT, vous exploitez les informations sur la compatibilité des applications depuis la base de données.

Mise en place

Dans un premier temps, il faut tout d’abord installer l’outil Application Compatibility Toolkit. Il est disponible dans le Kit de déploiement et d’évaluation Windows 8.1 (ADK 8.1). À télécharger gratuitement ici.

Depuis l’assistant d’installation ADK 8.1, vous devez ajouter les composants suivants :

  • Application Compatibility Toolkit (ACT)
  • Microsoft SQL Server 2012 Express

2014-03-24_175637

Préparation

Système d’exploitation

Application Compatibility Toolkit doit être installé sur l’une des plateformes suivantes :

  • Windows 8, 7, Vista (SP2) et XP(SP3)
  • Windows Server 2012, 2008 R2, 2008 (SP2)

Base de données

Application Compatibility Toolkit a besoin d’une base de données pour fonctionner. Voici la liste des versions SQL Server supportées :

  • Microsoft SQL Server 2012
  • Microsoft SQL Server 2008 R2
  • Microsoft SQL Server 2008
  • Microsoft SQL Server 2005

Quelles sont les versions de SQL Server supportées ?

Si vous disposez déjà d’un serveur SQL, vous pouvez choisir de:

  • Créer une nouvelle base de données sur une nouvelle instance SQL
  • Créer une nouvelle base de données sur une instance SQL déjà existante

Si vous n’avez pas de serveur SQL, installer une version SQL Server Express disponible gratuitement avec ADK.

.Net Framework

ACT 6.1 nécessite le composant .Net Framework 4.

Configuration

Après l’installation d’ACT 6.1 et SQL Express 2012, vous devez configurer l’application.Logo ACT

Lancer Application Compatibility Toolkit

 

 

Configuration ACT (1)

L’assistant vous propose d’installer le service « ACT Log Processing Service ». Ce service permet de traiter les données des postes de travail puis de les intégrer dans la base de données SQL. Sans ce service, votre base de données ne sera pas alimentée. Sélectionnez « Yes » puis cliquez sur « Next »

Configuration ACT (2)

L’étape suivante configure la base de données SQL. Sélectionner votre serveur SQL et la base de données à utiliser.

Configuration ACT (3)

La prochaine étape détermine le répertoire où seront stockées les données collectées sur les postes. Indiquez un chemin local et le nom du partage réseau à créer. Comme l’indique l’assistant, vérifiez que les postes clients disposent des droits en écriture dans ce répertoire.

Configuration ACT (4)

La prochaine étape vous propose de renseigner le compte à utiliser pour exécuter le service « ACT Log Processing Service ». Deux options s’offrent à vous :

  • Utiliser le compte local System (par défaut)
  • Utiliser un compte de service.
    Si vous retenez cette dernière option, vérifier les points ci-dessous. Le compte doit :
  • Être autorisé à ouvrir une session en tant que service.
  • Disposer des droits en écriture sur le répertoire contenant les fichiers collectés
  • Disposer des droits en écriture sur la base de données

Configuration ACT (5)

La configuration de l’outil touche à sa fin. Cliquez sur Finish

Configuration ACT (6)

L’outil Application Compatibility Toolkit est maintenant installé et configuré. Je vous propose maintenant de passer à la partie 2 : Création et déploiement de l’outil d’inventaire

Application Compatibility Toolkit 6.1 – Partie 3

Ce troisième article sur Application Compatibility Toolkit traite la phase d’analyse de données récoltées.

Avec ACT il est possible de faire une synchronisation de la liste de vos applications sur une plateforme Microsoft. Celle-ci permet d’obtenir les informations officielles publiées par les éditeurs de logiciel. L’accès à ces informations permet de gagner du temps pour la validation de vos applications. De plus, la plateforme héberge les résultats de compatibilité d’une communauté d’utilisateur d’ACT. Celle-ci s’avère utile pour faire le point sur une application dont l’éditeur n’a pas communiqué d’information officielle. Dans les options, il est possible de choisir si l'on souhaite ou non envoyer les résultats de compatibilité sur la plateforme Microsoft

Le menu analyse vous permet de visualiser le résultat de la collecte. Les rapports sont regroupés par système d’exploitation : Windows 7, Windows 8 et Windows 8.1.

Information : Vous pouvez choisir d’afficher uniquement les rapports qui correspondent au système d’exploitation cible. Pour ce faire, cliquez sur « Customize this view » et décochez les systèmes inutiles.

Tips - Custom View 2 Tips - Custom View

 

Rapport général

Pour chaque système d’exploitation, ACT fournit un rapport général.

Rapport - General

Informations sur l’inventaire

Les premières informations portent sur le processus d’inventaire lui-même :

  • Le nombre de postes de travail analysé
  • Le nombre d’applications recensé
  • Le nombre de périphériques détecté

Informations sur les applications

Ensuite, vous trouvez un tableau de synthèse concernant la compatibilité des applications. Vous pourrez ainsi identifier le nombre d'applications:

  • Incompatibles
  • Compatibles
  • Compatibles, mais qui risque de présenter quelques problèmes mineurs à l’utilisation
  • Sans informations sur la compatibilité

Dans la page sont ensuite présentées les informations sur la compatibilité des applications par rapport :

  • Aux informations concernant le support officiel de l’éditeur « Vendor Assessment »
  • À votre résultat sur la compatibilité « My Assessment »

Notez que pour chaque application ACT distingue les architectures 32 et 64 bits.

Informations sur les périphériques

Le tableau dédié aux résultats sur la compatibilité des périphériques est similaire à celui des applications. On retrouve le nombre de périphériques :

  • Incompatibles
  • Compatibles
  • Compatibles, mais qui risque de présenter des problèmes mineurs
  • Sans informations sur la compatibilité

Rapport détaillé

Pour chaque système d’exploitation, ACT fournit des rapports détaillés pour:

  • Les applications
  • Les postes de travail
  • Les périphériques
  • Les Add-On Internet Explorer
  • Un Feedback global

Notez que tous les rapports sont exportables dans les formats suivants : Excel, CSV et XLM.

Rapport sur les applications

L’onglet application recense l’ensemble des informations sur la compatibilité des applications.

Rapport - Application

Vous trouverez les trois premières colonnes qui identifient l’application :

  • Le nom de l’application
  • La version
  • L’éditeur

Évaluation de la compatibilité

  • Votre évaluation sur la compatibilité « My Assessment »
  • L’état de la synchronisation avec la communauté « Send and Receive Status »
  • Les informations sur la compatibilité officielle « Vendor Assessment »
  • Les retours sur la compatibilité de la communauté « Community Assessment »

Autres colonnes

  • La colonne « Versions » affiche le nombre de versions mineur de l’application détectée sur les postes.
  • Le nombre de postes sur lesquels l’application a été détectée est inscrit dans la colonne « Computer ».
  • Vous avez la possibilité de choisir une priorité pour chaque application. Celle-ci est affichée dans l’onglet « Priority ». 4 Niveaux de priorité sont disponibles :
    o Priorité 1 – Business Critical
    o Priorité 2 – Important
    o Priorité 3 – Nice to Have
    o Priorité 4 – Unimportant
    o Unspecified
  • La dernière colonne est intitulée « Deployment Status ». Comme pour la colonne précédente, ACT vous propose de choisir le statut du déploiement de l’application :
    o Not Reviewed
    o Testing
    o Mitigating
    o Ready to Deploy
    o Will not Deploy
  • La colonne « Active Issues » est intéressante dans le cas où une application est incompatible.

Via la plateforme Microsoft, l’éditeur du logiciel peut publier des informations pour résoudre les problèmes de compatibilité (MAJ de l’application de la plupart des cas).

Exemple d’une solution proposée pour l’application Adobe Flash Player 10 Plugin :

Issue - Issue DetailIssue - Solutions

De plus, sachez qu’il existe une autre information (non visible dans le tableau) pour vous aider à organiser votre parc applicatif : les catégories.
La liste de catégories est personnalisable et vous permet d'assigner à une application une ou plusieurs catégories. L'utilisation de celle-ci vous sera fort utile si vous souhaitez utiliser des filtres dans vos rapports.

L’interface est personnalisable et vous pouvez choisir les colonnes à afficher et celle à masquer (via un clic droit sur la ligne d’en tête du tableau)

Rapport sur les postes de travail

Dans cet onglet dédié au poste de travail, on retrouve les colonnes suivantes :

  • Le nom du poste
  • Le nombre d’applications ayant un problème de compatibilité
  • Le nombre de périphériques ayant un problème de compatibilité
  • Le système d’exploitation
  • Le domaine Active Directory
  • Le nombre d’applications
  • Le nombre de périphériques

Information : Les postes de travail équipés de Windows XP SP3 sont identifiés en SP2. En réalité, le SP3 est bien détecté, mais ACT le répertorie comme une application nommée « Windows XP Service Pack 3 ».

Rapport - Ordinateur

Rapport personnalisé : Filtrage

ACT intègre une fonction de filtrage sur les différents rapports (applications, poste de travail, etc.). Le filtre est accessible depuis la barre d’outils principale.

Filtre-barre

Via cette fonctionnalité de filtrage, vous pourrez construire un rapport personnalisé basé sur des conditions.

Filtre-UI

Par exemple, vous pourrez générer un rapport contenant :

  • Les applications de priorité 1 Business Critical
  • Les applications détectées sur les postes de travail nommées avec une syntaxe précise (ex. : INFO, ACHAT…)
  • Les applications qui font partie de la catégorie nommée « Drivers »

Vous trouverez ci-dessous une capture d’écran des différents champs disponibles :

Filtre

Sachez qu’il est possible de créer des requêtes avancées en ajoutant plusieurs conditions. Notez également que l’outil permet de sauvegarder vos requêtes personnalisées pour une utilisation ultérieure de celle-ci.

Application Compatibility Toolkit 6.1 – Partie 2

Collecte

La console Application Compatibility Toolkit s’oriente autour de deux axes.

1. La collecte d’informations sur le parc

2. L’analyse et l’exploitation des informations

Ce second article présente le processus de collecte des applications.

Le menu collecte vous permet de gérer vos packages. Il est possible de créer deux types de package.

  • « Inventory Collection Package » Ce package permet de faire un recensement des applications installées sur un poste de travail. Son utilisation est transparente pour l’utilisateur final, car l’outil s’exécute en tâche de fond. Les données issues de la collecte sont traitées et ajoutées dans ACT.
  • « Runtime Collection Package » Propose d’analyser les applications installées sur un poste pour vérifier la compatibilité de celle-ci.

Processus d’inventaire

Les paragraphes suivants montrent la marche à suivre pour collecter les applications installées sur un parc informatique.

Création d’un package d’inventaire

La première étape pour obtenir les applications installées est la création d’un package qui va analyser et exporter les logs sur un partage réseau dédié.

Pour créer un package d’inventaire, placez-vous dans l’onglet « Collect »

Collect - Icon

Puis, cliquez sur « Create new data collection package »

Collect - Add Package

Une première fenêtre s’ouvre, cliquez sur « Inventory Collection Package »

Inventory Collection Package - Creation S1

La seconde fenêtre de l’assistant paramètre votre package d’inventaire. Vous devrez remplir les trois champs suivants :

  • Choisir le nom du package
  • Indiquer le chemin du répertoire partagé sur lequel seront déposés les résultats des collectes.
  • Déterminer un Label. Celui-ci permet d’ajouter une indication sur la cible. En pratique grâce à l’utilisation des labels, l’exploitation des résultats sera simplifiée. Par exemple via l’utilisation des filtres (que nous verrons plus tard) vous pourrez construire des rapports ayant pour cible un service ou département spécifique.

Inventory Collection Package - Creation S2

Lorsque vous cliquez sur « Create », l’assistant vous propose d’exporter le package. Sélectionner un chemin, puis cliquez sur « Save »

Inventory Collection Package - Creation S3

Le package est prêt à être utiliser. Notez que le compte sera utilisé pour exécuter le package doit avoir les droits en écriture sur le partage réseau contenant les logs.

Inventory Collection Package - Creation S4

Déploiement du package

La seconde étape consiste à déployer le package sur les postes cibles. Différentes méthodes de déploiements sont disponibles, à savoir :

  • Stratégies de groupe
  • Script d’ouverture de session
  • Par l’intermédiaire du produit System Center Configuration Manager
    Manuel
  • Exécution d’un script personnalisé
  • Mise à disposition sur un répertoire partagé

Attention : L’outil a besoin des droits administrateurs sur les postes pour s’exécuter correctement.

Exécution du package

L’exécution du package est totalement silencieuse. Les utilisateurs ne seront ni avertis ni gênés par l’exécution du scan. En arrière-plan, le package dépose quelques fichiers dans le répertoire "Program Files (x86)\Inventory Collection Package". Le processus de collecte démarre automatiquement. Vous pourrez vérifier l'exécution de la collecte via le gestionnaire de tâche Windows. Le nom du processus est : bucketizer.exe

bucketizer

À la fin de l’opération de collecte, les résultats sont envoyés sur le chemin réseau (déterminé au cours de la création via l’assistant). De plus, le répertoire temporaire Inventory Collection Package sera supprimé.

Périodiquement, le service « ACT Log Processing Service » vérifie la présence de nouveau fichier de collecte dans le partage réseau. Dès que le service détecte un nouveau fichier, celui-ci est analysé, traité et intégré dans la base de données ACT. Enfin, vous trouverez dans la console ACT les résultats de la collecte.

Le dernier article est dédié à l’analyse des informations : Partie 3 : Analyse et exploitation des données colletées

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

Exchange 2013 SP1 : Retour du rôle Edge

Introduction

Depuis la sortie d’Exchange 2013, le rôle n’avait pas été porté dans cette nouvelle version d’Exchange. Ce qui oblige les entreprises à faire l’upgrade vers Exchange 2013 en conservant les serveurs Exchange Edge en version 2010. Pour rappel, le rôle Edge est apparu avec Exchange 2007.

Depuis février 2014, Microsoft à publier le SP1 d’Exchange 2013 et réintroduit le rôle Edge ! Vous allez maintenant pouvoir mettre à jour vos infrastructures.

Pour rappel, la principale fonctionnalité du rôle Edge est de protéger votre infrastructure de messagerie des spam et virus grâce aux différents agents présent sur le serveur Edge.

Il faut noter qu’avec la version 2013 d’Exchange, la console Exchange de management telle qu’on la connaissait avec Exchange 2010, n’existe plus. La console est remplacée par le portail web ECP. Ce portail n’existe pas sur le serveur Edge. Un serveur Edge 2013 devra donc être administrer uniquement en PowerShell.

Installation

Sur le serveur Edge, quand vous exécutez l’installation, vous pouvez maintenant choisir le rôle Edge. Les outils de gestion s’installent automatiquement ainsi que les prérequis.

image

Installation et configuration

Voici le lien de téléchargement du service pack 1 : http://www.microsoft.com/en-us/download/details.aspx?id=41994.

Une fois que le rôle est installé et le serveur redémarré, vous devez effectuer deux actions : Installer la clé du produit et faire l’abonnement Edge (il est possible de se passer de cette étape)

Installation de la clé produit :

Sur le serveur Edge, dans la console Exchange Management Shell, saisir la cmdlet :

Set-ExchangeServer <NomDuEdge> –ProductKey XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

Pour vérifier l’application de la clé, on peut lancer la cmdlet : Get-ExchangeServer

Créer l’abonnement Edge vers vos serveurs Exchange 2013 :

Sur le serveur Edge, dans la console Exchange Management Shell, saisir la cmdlet :

New-EdgeSubscription -FileName "C:\EdgeSubscriptionInfo.xml"

Sur un serveur Exchange, dans une console Exchange Management Shell, après avoir copié le fichier XML issu du serveur Edge :

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeSubscriptionInfo.xml" -Encoding Byte -ReadCount 0)) -Site "Default-First-Site"

Maintenant que le serveur Edge est en place, il faut le configurer, voici les principales commandes qui vont vous intéresser :

  • Get-IPBlockListProvidersConfig – Pour spécifier un fournisseur de blacklist
  • Get-SenderFilterConfig – Pour bloquer des expéditeurs
  • Get-RecipientFilterConfig – Bloquer des destinataires
  • Get-ContentFilterConfig – Bloquer du contenu dans les mails

Je vous laisse le soin d’aller voir sur Technet (http://technet.microsoft.com/en-us/library/jj218660(v=exchg.150).aspx) pour savoir comment utiliser ces cmdlets et en découvrir bien d’autres.

Conclusion

Grâce à ce service pack 1 d’Exchange 2013, vous pouvez mettre à jour votre serveur Edge vers la dernière version de manière à avoir un niveau de version homogène.

Nous pouvons vous accompagner dans la mise à jour de votre infrastructure de messagerie Exchange, n’hésitez pas à nous consulter pour un éventuel projet.

Config Mgr 2012 R2 - Erreur de connexion au portail d’application

Contexte

Dans le produit System Center Configuration Manager 2012 R2 il est possible de mettre à disposition un catalogue d’applications pour les utilisateurs finaux. L'implémentation de ce portail « Self-Service » repose sur un service web et nécessite la mise en place des rôles Config Mgr suivants :

  • Application Catalog web service point
  • Application Catalog website point

L’ajout des deux rôles ne pose aucun problème, cependant il est possible que vous rencontriez le problème ci-dessous lors de l’accès à votre catalogue d’application.

2013-12-06_155211_3

Explication

Bien que l’assistant d’installation des rôles ne vous ait pas remonté de problème, il est possible que les choses ne se soient pas passées comme prévu. Si vous rencontrer le message d’erreur « Cannot connect to the application server », c’est qu’il manque très certainement un composant pour rentre votre portail d’application disponible.

Résolution

Pour identifier la source du problème je vous invite à vous rendre dans le répertoire contenant les logs de Config Mgr 2012 R2. Par défaut les logs se trouvent dans le chemin suivant :
[Program Files]\Microsoft Configuration Manager\Logs

Le fichier qui nous intéresse est nommé SMSAWEBSVCSetup.log. Celui-ci est dédié à l’installation du Web-Service du catalogue d’application.

2013-12-06_155255_2

Lors de l’installation du rôle, une analyse de l’ensemble des éléments prérequis pour la mise en service du Web Services est réalisée. En parcourant le fichier, je découvre que composant Windows Communication Foundation (WCF) n’est pas activé : « WCF is not activated ».

Pour remédier à ce problème, je vous invite à prendre connaissance aux prérequis spécifiques à l’implémentation du rôle « Application Catalog web service point ». http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_Win2k12SiteSystemPrereqs.

Rendez-vous dans votre console Server Manager pour installer la ou les fonctionnalités manquantes pour l’installation du rôle. Il est probable que l’option HTTP Activation ne soit pas activée et qu’elle soit à l’origine de l’erreur. Vous trouverez ci-dessous une capture du lien Technet proposé plus haut et qui détaille les éléments nécessaires pour le bon fonctionnement du portail d’application.

2013-12-10_164313

2013-12-10_165700

Après avoir ajouté les composants manquants, réinstaller le rôle « Application Catalog web service point ».

L’accès à votre portail d’application devrait être à présent fonctionnel.

2013-12-06_163851_3