PI Services

Introduction

Le répertoire SYSVOL est répliqué entre tous les contrôleurs d'un domaine Active Directory. Celui-ci peut être répliqué par FRS (File Replication Service) ou DFS-R (Distributed File System Replication). FRS devient petit à petit obsolète et il convient de migrer vers DFS-R dès que tous les contrôleurs de domaine (DC) utilisent Windows 2008 ou supérieur. Il existe d'ailleurs une procédure fortement documenté par Microsoft pour effectuer cette bascule (https://technet.microsoft.com/en-us/library/dd640019(v=WS.10).aspx). En effet, DFS-R est beaucoup plus robuste et performant.

Cependant, celui-ci peut aussi rencontré des problèmes et la réplication peut se retrouver en erreur avec certains contrôleur de domaine. Lorsque cet incident survient, les stratégies de groupes (GPO) ou les scripts d'ouverture de session (ou de démarrage d'ordinateur) ne sont plus forcément en accord avec la dernière version mise en place. Pire, une stratégie de groupe récemment créée peut ne pas exister sur un contrôleur de domaine. On rencontre alors des erreurs d'application des GPOs sur des postes clients, serveurs ou utilisateurs. Pour pallier à ce problème, il existe une procédure permettant de resynchroniser la totalité (restaurer) du répertoire SYSVOL depuis un contrôleur de domaine valide.

Nous allons voir comment repérer les contrôleur de domaine dont la réplication DFS-R du SYSVOL est en erreur, puis nous aborderons le sujet de la restauration non autoritaire (principe expliqué ci-dessous) du répertoire SYSVOL.

Diagnostic

Pour repérer si un contrôleur de domaine ne réplique plus correctement le répertoire SYSVOL, il existe une multitude de méthodes. Tout d'abord, il suffit de comparer le contenu des dossiers SYSVOL de plusieurs contrôleurs de domaine. Si l'un d'entre eux est vide ou qu'il n'y a pas les mêmes objets alors il y a des problèmes de réplication DFS-R du répertoire SYSVOL.

Il existe aussi des techniques plus fiables. Tout d'abord, dans une invite de commande depuis un contrôleur de domaine, on peut exécuter le script ci-dessous :

Ce dernier affiche un statut de la réplication DFS-R pour chaque contrôleur de domaine. Le chiffre affiché pour chaque DC nous donne l'information. Lorsqu'il y a une erreur celui-ci possède la valeur 5 (une réplication sans erreur équivaut à un statut 4). Aussi, il peut arriver que la valeur soit “No instance avalaible”. Cette information indique qu'il n'y a donc pas de réplication du SYSVOL.

On peut confirmer une erreur de réplication DFS-R (ou même une absence de réplication du SYSVOL) via la recherche d'événements spécifiques dans l'observateur d'événements. Ceux-ci sont situés dans le journal “DFS Replication” et non dans les journaux Active Directory. Il faut rechercher les événements avec les IDs suivants :

• 2012

• 2013

• 4012

Event 2012

L'événement 2012 nous informe d'une erreur de réplication DFS lors d'un arrêt non prévu du serveur (coupure de courant). Si cet événement n'est pas accompagné d'un événement avec l'ID 2013 alors la réplication a repris son cours normal et ne nécessite pas d'action (vous devriez néanmoins obtenir un statut 4 avec la commande précédente pour confirmer cela).

Event 2013

Cet événement indique que la réplication n'a pas repris et qu'il convient de le faire manuellement via la commande suivante :

NB : Pensez à remplacer GUID_VOLUME par le votre. Pour cela, il suffit de copier coller la commande indiqué dans l'événement pour relancer la réplication du répertoire SYSVOL. Cependant, si celle-ci n'a pas été relancé depuis longtemps alors elle ne redémarre pas et on obtient l'événement 4012.

Pour information, les management packs SCOM AD ou DFS ne remontent pas ce type d'erreur.

Event 4012

En effet, lorsqu'une réplication DFS-R a été stoppé pendant plus de 60 jours (valeur par défaut du paramètre MaxOfflineTimeInDays) alors il est nécessaire de lancer une synchronisation complète du dossier répliqu��. L'événement donne une procédure qui peut s'appliquer dans le cas où il s'agit d'une réplication DFS-R créé par un administrateur. Néanmoins celle-ci n'est pas applicable dans le cas du répertoire SYSVOL car nous n'avons tout simplement pas accès à cette réplication via la console DFS Management. Il faut alors réaliser une restauration du répertoire SYSVOL.

Procédure de restauration

Cette procédure n'est pas compliquée mais nécessite de la rigueur afin de rétablir la réplication Active Directory du répertoire SYSVOL. Toutefois, celle-ci ne s'applique que lorsque le nombre de contrôleurs de domaine en erreur est faible et que l'on est sûr que celui-ci répliquera le répertoire SYSVOL depuis un contrôleur de domaine sain. Par exemple, cela peut être le cas dans une topologie en étoile lorsque un ou plusieurs contrôleurs de domaine présent sur des sites distants ne répliquent plus le répertoire SYSVOL.

Dans le cas où l'on souhaiterait restaurer le dossier SYSVOL depuis un contrôleur de domaine précis et restaurer tous les autres DC alors il convient de réaliser une restauration autoritaire du SYSVOL (la restauration est forcé depuis un contrôleur de domaine précis et la réplication DFS-R est coupé temporairement sur les autres DC).

Lors de l'exécution du processus ci-dessous, on ne choisit pas un contrôleur de domaine comme source de la restauration, cette dernière est donc dite non autoritaire. Il n'existe pas véritablement de règle pour savoir s'il faut préférer une restauration autoritaire ou non. Cela dépendra donc des cas (pourcentage de DC en erreur, topologie Active Directory complexe). Microsoft recommande toutefois de réaliser une restauration autoritaire dès qu'il y a plus d'un DC qui rencontre ce type de problème (dans des gros environnements cela peut vite devenir compliqué à mettre en œuvre et une restauration non autoritaire peut rester une solution viable).

Pour réaliser une restauration non autoritaire, il faut lancer ADSIEdit avec un compte administrateur du domaine.

Il faut ensuite effectuer un clic droit sur ADSI Edit puis choisir l'option “Connect To”.

Dans les paramètres de connexion il faut choisir de se connecter au contexte d'attribution de noms par defaut (Default Naming Context) et valider.

Enfin, il faut naviguer jusqu'à l'objet du contrôleur de domaine posant problème (Exemple de chemin : CN=DC01,OU=Domain Controllers,DC=myenterprise,DC=com) puis se rendre dans le conteneur “DFSR-LocalSettings” puis “Domain System Volume”.

Sur ce dernier, il faut effectuer un clic droit puis choisir “Properties”. Il faut ensuite trouver l'attribut “msDFSR-Enabled” et passer la valeur à “False” (cette dernière doit être à “True” par défaut). Cela permet de rendre le contrôleur de domaine non authoritaire pour la réplication.

Par la suite, on force une réplication Active Directory depuis un DC sain via l'outil en ligne de commande repadmin :

Sur le DC en erreur, on exécute la commande ci-dessous qui aura pour effet de désactiver la réplication du répertoire SYSVOL :

Un événement avec l'ID 4114 doit être présent dans le journal “DFS Replication” de l'observateur d'événement du contrôleur de domaine en erreur dont voici le contenu :

Nous pouvons maintenant réinitialiser la réplication du répertoire SYSVOL. Dans ADSI Edit, il faut éditer de nouveau l'objet “Domain System Volume” du contrôleur de domaine en erreur et remettre la valeur de l'attribut “msDFSR-Enabled” à “True”.

Il suffit ensuite de forcer une réplication Active Directory depuis un DC sain via l'outil en ligne de commande repadmin :

Puis, on lance une réplication initiale du répertoire SYSVOL depuis le DC sur lequel on effecture une restauration via la commande :

Un premier événement de type avertissement doit être visible dans le journal “DFS Replication”. Celui-ci possède l'ID 4614. Il indique que la réplication Active Directory s'est lancée.

Lorsque la réplication est terminée, un second événement avec l'ID 4604 indique la bonne exécution de celle-ci.

Enfin, on peut vérifier le statut de la réplication du répertoire SYSVOL du contrôleur de domaine via la commande suivante :

NB : Pensez à changer NOM_DC par le nom du contrôleur de domaine à tester.

Présentation

Nous allons ici découvrir un outil graphique permettant de manipuler des images WIM au travers d’une interface GUI.

L’outil DISM_64bits_Mount-Unmount en version 1.0 est disponible sur ce lien :

https://onedrive.live.com/?cid=b370cc46ea3ab572&id=B370CC46EA3AB572%21137&ithint=folder,exe&authkey=!ANkLug_PPC-kh-8

Les chapitres que vous pouvez trouver ci dessous présentent les possibilités de l’outil DISM_64bits_Mount-Unmount :

• Changer de version DISM [nécessite l’installation du Windows Kits]
• Monter une image WIM
• Ajout de Drivers
• Ajout de Package
• Démonter une image WIM
• Création d’une image ISO WinPe [ nécessite le Windows Kits]
• Création d’un VHDX
• Appliquer une image WIM
• Obtenir des informations sur un VHDX (Module Hyper-V nécessaire)
• Capturer une image WIM
• Ajouter du contenu (index) à une image WIM

Rappel : une image wim est un fichier d’image de disque. Ce format est utilisé nativement pour les installations de Windows depuis Vista et Windows Server 2008. Pour accéder au contenu d’une image WIM et le modifier, vous devez monter l’image dans un répertoire et y apporter les modifications. Une fois les modifications effectives, vous devez démonter l’image.

Pré requis

.Net Framework 3.5 doit être installé

L’outil est packagé en 64 bits. Donc un OS en 64 bit est nécessaire pour son exécution. L’outil DISM_64bits_Mount-Unmount nécessite au minimum l’utilisation de Windows 7 qui intègre la version DISM 6.1.7600.16385.

Facultatif : vous pouvez installer les outils de déploiement présent dans une version d’ADK pour changer la version de DISM utilisé durant les opérations de l’outil.

Récupération et installation du Windows Kits (ADK 10) [Facultatif]

Vous pouvez récupérer la dernière version de ADK en version 10 via le lien suivant :

http://download.microsoft.com/download/8/1/9/8197FEB9-FABE-48FD-A537-7D8709586715/adk/adksetup.exe

Installer les outils de déploiement.

Modification de la politique d’exécution PowerShell

Il est nécessaire de modifier la politique d’exécution PowerShell pour lancer l’outil DISM_64bits_Mount-Unmount.

Lancer une fenêtre PowerShell en tant que administrateur.

Lancer la commande

Set-ExecutionPolicy unrestricted et valider.

Nous allons désormais lancer l’outil et voir ces possibilités.

Changer de version DISM [ nécessite l’installation du Windows Kits]

Lancer l’outil en tant que administrateur.

L’interface se lance

Vous pouvez sélectionner l’emplacement ou se situe votre répertoire Windows Kits. Celui ci détectera les versions d’ADK présente sur votre système.

Les version d’ADK installés dans le Windows Kits apparaissent. En sélectionnant une version d’ADK, vous utiliserez l’exécutable DISM associé pour les différentes actions de l’outil.

le bouton Unlock  permet de retirer la sélection du Windows Kits et donc la version ADK choisie. La version DISM utilisé sera alors celle présente dans votre OS nativement.

Monter une image WIM

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner l’image Wim et l’index.

Sélectionner le répertoire de montage

Cliquer sur le bouton Mount pour lancer les opérations de montage

Une fenêtre PowerShell se lance pour effectuer les opérations de montage.

L’image est maintenant monté.

Ajout de Drivers

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner le répertoire ou votre image est montée.

Sélectionner le répertoire ou se situe les drivers à injecter

Cliquer sur Add-Drivers pour procéder à l’injection des drivers.

Une fenêtre PowerShell se lance pour effectuer le traitement

Ajout de Package

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner le répertoire ou votre image est montée

Cocher le type d’extensions ou répertoire que vous souhaitez parcourir pour l’ajout de Package et sélectionner le Package à ajouter.

Cliquer sur Add pour procéder à l’injection du Package.

Une fenêtre PowerShell se lance pour le traitement des instructions.

Démonter une image WIM

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner le répertoire ou est monté l’image WIM.

Cliquer sur le bouton radio Commit ou Discard et cliquer sur Unmount

Commit enregistre les modifications apportées à l’image wim.

Discard n’enregistre pas les modification apportées à l’image wim.

Une fenêtre PowerShell se lance pour effectuer le démontage.

L’image est maintenant démontée.

Création d’une image ISO WinPe [nécessite le Windows Kits]

Lancer l’outil en tant que administrateur.

L’interface se lance

Pour profiter de la fonctionnalité ISO de l’outil, vous devez utiliser Windows Kits.

Sélectionner l’environnement de construction de votre WinPe

Exemple d’environnement  de construction :

Donner un nom à votre ISO puis cliquer sur le bouton Build.

Une fenêtre PowerShell se lance pour la création de l’ISO.

Votre ISO est désormais créée dans l’environnement de construction précédemment définit.

Création d’un VHDX

Lancer l’outil en tant que administrateur.

L’interface se lance

La section VHD permet la création de VHDX.

Pour la création du VHDX vous pouvez choisir si celui ci sera  de type

• Fixed
• Dynamic

• MBR
• GPT

Vous pouvez également choisir la taille du VHDX et son emplacement de création.

Une fois les éléments de configuration du VHDX sélectionnés et définis, cliquer sur le bouton Create.

Remarque : lors de la création du VHDX, celui ci sera formaté en NTFS et monté dans l’explorateur.

Une fenêtre PowerShell se lance pour effectuer les opérations.

Le VHDX est maintenant créé et monté dans l’explorateur de fichier

Appliquer une image WIM

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner l’image WIM et l’index que vous désirez appliquer

Sélectionner maintenant l’emplacement ou vous désirez appliquer l’image WIM.

Cliquer sur le bouton Apply pour lancer l’application de l’image.

L’application de l’image est désormais effectuée.

Remarque : Si vous appliquez une arborescence d’un OS Windows tel que Windows 10 ou WinPe par exemple sur une racine de lecteur, l’outil va alors détecter qu’il s’agit d’une arborescence type “OS Microsoft” et vous proposer de copier les fichiers de démarrages dans la partition système.

Si vous cliquez sur oui

Les entrées du magasin BCD ont été mis à jour.

Au prochain redémarrage du poste, il vous sera possible de démarrer sur l’OS depuis le VHD.

Obtenir des informations sur un VHDX (Module Hyper-V nécessaire)

Lancer l’outil en tant que administrateur.

L’interface se lance

Cliquer sur le bouton ci joint et sélectionner votre VHDX

Cliquer sur le bouton Infos VHDX

Des informations apparaissent sur la configuration du VHDX sélectionné.

Capturer une image WIM

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner un répertoire à capturer en image WIM

Sélectionner maintenant le répertoire ou sera créé l’image WIM.

Taper le nom de fichier de l’image WIM ainsi que le nom qui sera donné à l’index; cocher des options si besoin.

Cliquer sur Go pour lancer la capture

L’opération s’effectue.

L’image WIM est désormais créée.

Vous pouvez obtenir des informations de la WIM créée en sélectionnant l’image dans la section WIM.

Ajouter du contenu (index) à une image WIM

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner le répertoire à capturer.

Cocher la case Append

Sélectionner l’image WIM à éditer

Ajouter le nom qu’aura le nouvel index dans l’image WIM.

Cliquer sur Go pour lancer les opérations

L’opération s’effectue.

Vous pouvez obtenir des informations sur l’image WIM en sélectionnant l’image dans la section WIM.

ADK 10

Vous pourrez trouver la version de ADK 10 (10.0.10240.16384) disponible via ce lien :

http://download.microsoft.com/download/8/1/9/8197FEB9-FABE-48FD-A537-7D8709586715/adk/adksetup.exe

une fois le kit de déploiement installé, la version détectée au travers de appwiz.cpl est 10.0.26624

En utilisant la build précédente de l’ADK, lors de l’ajout de Powershell dans le PE celui ci s’ajoutait correctement.

Cependant lors de son utilisation un message d’erreur apparaissait.

Avec cette build, l’intégration de PowerShell est fonctionnelle. 

GeneratorWinPE 1.1

L’application a été mis à jour.

Disponible ici :

https://onedrive.live.com/redir?resid=B370CC46EA3AB572!137&authkey=!ANkLug_PPC-kh-8&ithint=folder%2cexe

il est maintenant nécessaire de sélectionner le Path du Windows Kits.

Une fois celui ci définit, les versions d’ADK présentes s’’affichent :

Cette action permet de s’affranchir d’une installation avec le Path par défaut de Windows Kits sur C: par exemple.

Rappel : Présentation  de GeneratorWinPE  http://blog.piservices.fr/post/Apps-Generateur-de-WinPE.aspx

Vous pouvez maintenant via GeneratorWinPE créer votre WinPe 10 avec l’utilisation de cette version d’ADK  

Vous avez besoin de connaitre la différence entre deux variables de temps différente

Exemple :

$source="23/06/2015 11:43:50"

$dest="23/06/2015 18:42:38"

La commande New-TimeSpan nous permet de calculer cette différence.

Cependant, les valeurs de nos 2 variables ont été récupérées sur un ordinateur ou la culture était fr-FR.

L’interprétation de la commande New-TimeSpan ne posera pas de problème si celle-ci est exécutée sur un poste ayant une culture fr-Fr

Exemple :

Cependant, si la culture du poste est différente de fr-FR. Cela peut poser problème.

Exemple : avec un poste ayant une culture en-US, la commande New-TimeSpan n’est pas capable de bien interprété la valeur de nos 2 variables qui sont formatés dans une culture fr-FR.

Si nous voulons que la commande New-TimeSpan puisse interpréter correctement la valeur de nos 2 variables, il va donc falloir les formater correctement.

[System.Globalization.CultureInfo]$French = 'fr-FR'

[System.Globalization.CultureInfo]$English = 'en-US'

$DateTime = [datetime]::Parse($source, $French)

$source = $DateTime.ToString($English)

$DateTime = [datetime]::Parse($dest, $French)

$dest = $DateTime.ToString($English)

Résultats :

New-TimeSpan peut maintenant calculer la différence des deux variables

Introduction

Les Exchanges Web Services (EWS) sont très pratiques pour manipuler le contenu d'une boite aux lettres. Ceux-ci ont été créés pour s'intégrer dans des applications en C# mais peuvent aussi être utilisés dans un script Powershell. Grâce aux EWS, nous pouvons manipuler des dossiers, des messages, le calendrier. Il est possible de réaliser des opérations de créations (comme l'envoi d'un email), suppressions et modifications. Cependant, nous verrons qu'il est nécessaire d'avoir des droits sur la boite aux lettres d'un utilisateur ou d'utiliser un mécanisme d'impersonation pour réaliser ces opérations.

Contexte

Cet article est basé sur un retour d'expérience d'utilisation des EWS dans un environnement Exchange 2010 SP3. Le système de réservation de ressources d'une entreprise (salle, équipements) devait migrer vers Exchange. Un mécanisme de reprise de l'existant a dû être mis en place pour créer les réservations dans les calendriers des ressources et des personnes réservant la ressource.

EWS

Afin d'utiliser les Exchange Web Services dans un script Powershell, il faut installer le package permettant d'interagir avec ceux-ci.

Ce dernier est actuellement en version 2.2 et peuvent s'interfacer avec toutes les versions d'Exchange de 2007 SP1 à la dernière en date : 2013 SP1 (Les cumulatives updates n'ont pas d'importance).

Il est disponible en suivant le lien ci-dessous :

http://www.microsoft.com/en-us/download/details.aspx?id=42951

Impersonation

Les Exchange Web Services utilisent l'autodiscover pour communiquer avec une boite aux lettres spécifique.

Exemple de connexion aux EWS :

Cependant, dès que j'effectuerai une opération sur la boite aux lettres, il me faudra des droits sur cette boite aux lettres comme le contrôle total. Dans le cas contraire, j'obtiendrai des erreurs.

Donner des droits sur un grand nombre de boites aux lettres n'est pas recommandable car cela complexifie l'administration. il existe donc une seconde option permettant de se faire passer pour le compte utilisateur de la boite aux lettres. Il s'agit de l'impersonation. C’est un rôle à attribuer à un compte de service (via le mécanisme RBAC). Cette solution offre plusieurs avantages :

• Simplicité d'administration : on peut rapidement ajouter ou supprimer les droits d'impersonation à un compte.
• Contrôle des comptes visés : le scope des utilisateurs pouvant être "remplacer" par un compte de service peut facilement être modifié sans devoir changer les propriétés de chaque boite aux lettres.
• Décoreller des délégations : le processus d'impersonation n'apparait pas dans les délégations et il est ainsi plus simple de faire la différence entre les deux mécanismes et les différentes autorisations.

Implémentation RBAC

Le rôle permettant l'impersonation est nommé ApplicationImpersonation. Pour l'implémenter, nous allons d'abord créer un scope, c’est-à-dire définir les utilisateurs sur lesquels le compte de service pourra faire de l'impersonation.

Dans l'exemple ci-dessous, nous créons un scope contenant toutes les boites aux lettres utilisateurs :

Puis, nous ajoutons le rôle ApplicationImpersonation à l'utilisateur souhaité en spécifiant le scope créé précédemment.

NB : Pensez à changer la valeur MYUSER par le nom d'utilisateur de du compte réalisant de l'impersonation.

Script

Ci-dessous vous trouverez différentes fonctions Powershell commentées permettant la création d’une réunion avec la possibilité de réserver une salle mais aussi la validation que ces réunions ont bien été créées. Ces fonctions gèrent l’impersonation tant que le compte avec lequel la connexion aux EWS possède ce droit sur les boites aux lettres visées.

Fonction de création de réunions :

Fonction de validation de la réunion dans le calendrier utilisateur :

Cette fonction valide qu’une réunion possédant les bonnes ressources ainsi que les bonnes dates de début et de fin existe dans le calendrier de l’utilisateur.

Elle permet aussi de vérifier qu’il n’y a pas eu de création de doublons dans le calendrier (utile si un script de création de réunion à été exécuté plusieurs fois).

Fonction de validation de la réunion dans le calendrier de la boîte aux lettres de ressources :

Cette fonction cherche une réservation de la ressource en validant les dates et heures ainsi que le nom de la personne ayant créé cet objet. Cette vérifications s‘effectue sur le calendrier de la boite aux lettres de ressource. Le statut de la réservation est aussi vérifié (valeur attendue : Accept) afin d’être certain que la ressource n’ait pas été réservée pas une autre personne.

Tips

La création de nombreuses réservations peut engendrer un grand nombre d'envoi d'email aux utilisateurs ayant réservés ces ressources. En effet, ils vont recevoir des réponses des ressources (acquittement ou refus de la demande) si le système de réservation automatique a été activé (Resource booking attendant). Une solution de contournement peut être mise en place pendant la phase de migration. Elle consiste à limiter le nombre de destinataires à 0 lors de l'envoi d'un mail par la boite aux lettres de ressources.

Pour réaliser cette opération, il suffit de lancer une invite de commande Powershell Exchange (EMS) et d'exécuter la commande suivante :

Ou bien, si l'on souhaite changer la valeur sur toutes les boites aux lettres de salles en une seule commande (on peut remplacer RoomMailbox par EquipmentMailbox pour les boites aux lettres d'équipements).

NB : Pensez à remplacer IDENTIFIANT_BAL par l'identifiant de la boite aux lettres de ressources (Alias par exemple).