PI Services

Le blog des collaborateurs de PI Services

[Windows Server] - Utiliser un gMSA pour ses tâches planifiées

Si il y a bien une chose que j'essaie de pousser dans un environnement Active Directory, c'est de supprimer les comptes avec un mot de passe qui n'expire jamais, utilisés pour exécuter des tâches planifiées; pour les remplacer par des gMSA.

Souvent mal appréhendé, je vais ici vous montrer qu'il n'y a quasiment pas de différence dans l'utilisation.

Créer une tâche

Via GUI

Pour créer une tâche en mode graphique, on ne change pas les habitudes.

Dans un premier temps on lance le Task Scheduler

Puis on créé un tâche que l'ion va nommer

On lui définit ses paramètres

Bon jusque la rien de différent de ce que vous avez l'habitude de faire.

Passons donc à la suite, éditez la tâche.

Et à partir d'ici remplaçons notre compte par le gMSA.

Donc on sélectionne "Change User or Group..." et on s'assure de rechercher sur le domaine donc on sélectionne "Location"

On sélectionne "Entire Directory" et on valide

à partir de la on va sélectionner "Object Types..."

Et tout désélectionner  sauf "Service Accounts" puis on valide

Enfin on recherche son gMSA et on valide

Et voilà, comme quoi il n'y a rien de plus simple car, on s'évite même de devoir gérer les identifiants du compte de service.

 

Via Powershell

 

$TaskAction = New-ScheduledTaskAction -Execute C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe  -Argument "-File C:\Temp\ImportPfx.ps1"
 
$TaskTrigger = New-ScheduledTaskTrigger -At 00:00 -Once # vous pouvez utiliser d'autre valeurs selon vos besoin Par exemple Daily
 
$TaskPrincipal = New-ScheduledTaskPrincipal -UserID Lab\gMSA01$ -LogonType Password
 
Register-ScheduledTask MygMSATask –Action $TaskAction –Trigger $TaskTrigger –Principal $TaskPrincipal

 

 

Modifier un tâche

Via GUI

Souvent, la première fois qu'on y fait face c'est un peu déroutant, car lors de la modification de la tâche le popup demandant les identifiants arrive.

Pour éviter cela rien de plus simple, ouvrez votre tâche planifié.

Modifiez vos paramètres, par exemple ici nouds allons modifier l'heure d'exécution.

Une fois modifié, nous validons avec "Ok", puis nous retournerons sur le menu "General"

Puis comme nous l'avons fais lors de la  création de la tâche planifiée, donc on sélectionne "Change User or Group..." et on s'assure de rechercher sur le domaine donc on sélectionne "Location"

On sélectionne "Entire Directory" et on valide

à partir de la on va sélectionner "Object Types..."

Et tout désélectionner  sauf "Service Accounts" puis on valide

Enfin on recherche son gMSA et on valide

Et enfin on sélectionne "Ok"

 

Via Powershell

$Task = Get-ScheduledTask -TaskName MygMSATask
$Time = New-ScheduledTaskTrigger -At 21:00 -Once
$TaskPrincipal = New-ScheduledTaskPrincipal -UserID Lab\gMSA01$ -LogonType Password

Set-ScheduledTask -TaskName $Task.TaskName -Trigger $Time -Principal $TaskPrincipal

 

Windows Server - Collecter des logs de crash applicatifs avec Windows Error Reporting

Windows Error reporting aussi abrégé WER a été introduit depuis Windows Vista et permet de générer un fichier de dump lorsqu'un processus crash. C'est particulièrement utile car tous les processus ne génèrent pas forcément leur propre logs.

 

Identifier le processus fautif

L'identification du processus qui crash se fait à l'aide du gestionnaire d'événement ou event viewer en anglais. Il permet d'accéder à plusieurs informations du crash tel que l'heure et le nom du processus en erreur.

Dans l'exemple suivant, on voit que c'est une défaillance du process lsass.exe qui fait planter la machine et le module responsable du crash de lsass.exe est ntdll.dll

 

Activer la génération de crash dump pour le processus en erreur

  1. Ouvrir l'éditeur de registre regedit sur le serveur qui est concerné par le crash
  2. Naviguer jusqu'à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
  3. Créer une nouvelle Key qui a comme valeur le nom du processus défaillant, dans notre exemple lsass.exe
  4. Dans la précédente clé, créer un premier DWORD (32-bit)
    1. Name : DumpCount
    2. Valeur : le nombre de crash dump a sauvegarder, par exemple 5
  5. Créer un deuxième DWORD (32-bit) value
    1. Name : DumpType
    2. Valeur : 2 cela permet de générer un full crash dump, celui-ci est le plus complet
  6. Créér une String value
    1. Name : DumpFolder
    2. Valeur : le chemin complet du dossier qu'il faudra créer et qui contiendra les dumps, par exemple c:\temp
  7. Créer un dossier temp dans le disque C:

 

Récupérer le fichier de log et l'analyser

Au prochain crash du processus, un fichier de log sera créé dans le dossier choisi dans la base de registre.

Pour pouvoir lire les fichiers de log, il est nécessaire d'installer un outil tel que WinDbg

 

Supprimer la génération de fichiers de dump

Pour supprimer la génération de log, il faut supprimer la clé précédemment créée dans la base de registre, dans notre exemple cela reviendrait à supprimer la clé lsass.exe

 

Pour aller plus loin

Documentation officielle Microsoft sur l'activation de Windows Error Reporting

Powershell : Supprimer les KB "Declined"

Quand on veut faire du ménage sur son WSUS et également dans la base de ce dernier, il peut s'avérer utile de supprimer les KB dont le statut est "IsDeclied".

Pour réaliser cela rien de plus simple que quelques lignes de Powershell et de la patience (beaucoup de patience si ça fait longtemps que cela n'a pas été fait).

Connexion

# Define Server Name
$WsusServer = "Mon-Server-WSUS"
# Define connection port
$WsusPort = "8530"

# Initiate Connection
[void][reflection.assembly]::loadwithpartialname("microsoft.updateservices.administration")
$Wsus = [microsoft.updateservices.administration.adminproxy]::getupdateserver($WsusServer,$false,$WsusPort)

# Verifying connection (Should be return the name of the wsus server)
$Wsus.name

 

Définition des Updates à supprimer

# List All Kb in WSUS database
$AllKb = $Wsus.GetUpdates()

# Filter on "IsDeclined" status
$IsDeclined = $AllKb.Where({$_.IsDeclined -eq $True})

 

Suppression des KB

# Delete KB
$IsDeclined | foreach {
    # Define Current Id
    $Id = $_.Id
    Try {
        $Wsus.DeleteUpdate($Id.UpdateId.ToString())
        }
    Catch {
        Write-Warning $($_)
        }
    # Release variable
    $Id = $null
    }

Cette commande est un peu longue mais si elle est exécutée régulièrement, la purge dure moins longtemps.

WSUS Server : Connection Error

Vous venez de déployer un serveur WSUS, finir sa configuration et rattacher les premières machine à se dernier; mais lorsque vous vous rexonnectez sur le serveur afin d'exécuter la console "Windows Server Update Services" vous avez le droit au message d'erreur suivant :

La cause :

Bien souvent cette erreur est lié à IIS, je vous invite donc à exécuter "Internet Information Services (IIS) Manager" puis déroulez le serveur et sélectionnez "Application Pool", ici vous pourrez constater que le "WsusPool" est arrêté.

La solution :

Sélectionnez le et faite "Advanced Settings..." dans le volet de droite, sélectionnez le "Start Mode" pour le passer de "OnDemand" à "AlwaysRunning" puis validez en faisant "OK".

Démarrez le "WsusPool", puis vous pourrez fermer la console IIS.

NB : Tant que le serveur WSUS n'aura pas redémarrez la configuration du IIS ne sera pas effective (vous devrez relancez le "WsusPool" Manuellement à chaque nouvelle connexion au serveur).

Retournez dans la console "Windows Server Update Services" et faites "Reset Server Node"

Enjoy

 

Netdom Trust et les OS Français

Un environnement homogène avec des OS installé en Anglais, c'est la vision de notre éditeur préféré (je parle bien sur de Microsoft).

Dans la pratique on a pas toujours l'opportunité d'avoir tous les OS dans la même version et pire encore dans la même langue d'installation.

 

Quel impact ?

Même si pour certain, installer un OS en Français est plus "Confortable / facile d'administration", en terme de "recherche / résolution" d'incident on est quand même nettement moins bien aidé (entre les messages d'erreur qui ne veulent rien dire ou les commandes qui diffèrent, avoir un langage différent de l'anglais peut vous faire perdre quelques heures).

 

Des Exemples :

Prenons un exemple simple l'activation ou la désactivation du "SID Filtering" dans un "Trust" entre deux domaines.

OS Anglais :

Si les OS des serveurs contrôleur de domaine sont en Anglais les commandes sont simples :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:No  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

 

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Yes

 Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

 

OS Français :

Lorsque les OS sont en Français il y a une petite subtilité :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Non  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

 

 

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Oui

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

 

Vous l'avez ?

Et oui la commande est quasi identique puisqu'elle est en Anglais, mais les arguments eux sont en Français et le pire dans tout ça c'est que si vous passez la commande en Anglais avec les arguments en Anglais, l'OS vous dira que la commande s'est terminée avec succès même si ce n'est pas le cas; mais dans la pratique cette dernière aura échouée.

 

Alors de grâce ayez le réflex lors d'une installation serveur de sélectionner un Iso en Anglais et de l'installer en Anglais (rassurez vous pour le clavier et le fuseau horaire le Français est autorisé ^^ ).

Hyper-V : Créer un disque de différenciation (Partie 1)

Comme certain d'entre vous j'en ai eu marre de ne plus avoir de place sur mon disque mais surtout de devoir re-déployer Windows Server à chaque nouvelle VM pour un Lab; voici donc comment créer un disque de différenciation sous Hyper-V.

1. Créer la VM de référence

1- Dans un premier temps, sur votre poste de travail définissez un répertoire dans lequel sera stocké le disque de référence.

Dans mon cas je vais créer le serveur de référence dans mon disque "D" dans un répertoire "Template" et placer son disque dans un sous répertoire "Virtual Hard Disk".

 

2- Ensuite lancez "Hyper-V Manager"

 

3- Puis sélectionnez le serveur Hyper-V et faites un clic droit « New » puis « Virtual Machine ».

Dans la fenêtre « Before you Begin » faites « Next »

4- Dans la fenêtre « Specify Name and Location » donnez un nom à votre machine de référence et sélectionnez « Store the virtual machine in a different location » et cliquez sur « Browse… »

5- Sélectionnez le répertoire dans lequel seront stocké les éléments de configuration de la VM puis « Select Folder »

6- Faites « Next »

7- Sélectionnez le type de génération de la VM (dans mon cas une VM de génération 2) et faites « Next »

8- Assignez une quantité de RAM à la VM (au moins le prérequis système) et faites « Next ».

9- Il n’est pas obligatoire d’assigner une carte réseau pour la machine de référence, faites « Next ».

10- Dans la configuration du disque dur choisissez une taille suffisante pour l’OS (et éventuellement les mises à jour), puis faites « Next ».

11- Sélectionnez l’ISO du Système d’exploitation et faites « Next »

12- Relisez le résumé de la configuration et faites « Finish »

13- Une fois la VM créée dans Hyper-V Manager sélectionnez la et faites « Settings »

14- Naviguez jusque « Checkpoint » et désélectionnez « Enable Checkpoints » puis faites « OK »

La VM est maintenant prête, nous allons donc pouvoir déployer l'image, rendez vous donc dans la partie 2.

 

Active Directory : Migration SYSVOL de FRS vers DFS-R - Etape Eliminated (Partie 5)

Bonjour à tous,

Aujourd'hui nous abordons la partie 5 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à la dernière étape Eliminated.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR
 

Particularités

Comme vous pouvez le voir ci-dessus, l'état 3 (Eliminated) n'est pas le plus impactant :
  • En arrière-plan, le mécanisme de réplication DFS-R réplique une copie du dossier SYSVOL (cette copie étant devenue depuis l'étape Redirected celle utilisée par les services AD DS), la version répliquée par le mécanisme FRS est supprimée.
  • En façade, c'est le dossier SYSVOL répliqué par le mécanisme DFS-R qui est présenté aux postes clients via les partages NETLOGON et SYSVOL
Il faut souligner les points suivants :
  • Tout retour arrière est impossible une fois cette etape éffectuée.
  • Il convient de vérifier que la copie du dossier SYSVOL répliquée par le mécanisme DFS-R est intègre avant de supprimer la version répliquée par FRS. A toute fin utile, on pourra éxécuter un Rapport de Propagation de la Réplication DFS dans la console DFS Management pour le groupe de réplication Domain System Volume.
  • Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC.

En pratique

Etat Redirected

Si l'étape précédente a été correctement réalisée, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Redirected.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Eliminated.

Passage vers l'état Eliminated

Etat global (Domaine AD) : dfsrmig /setglobalstate 3

Le passage vers l'état Eliminated est bien indiqué ainsi que son irréversibilité.
Si malgré un certain délai, les RODCs ne passent pas en état Eliminated, il faudra forcer la suppression des objets FRS correspondant avec la commande dfsrmig /DeleteRoNtfrsMember (à éxécuter seulement une fois depuis le PDC)
 

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).

Etat Eliminated atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Eliminated. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Le message est explicite, tous les contrôleurs de domaine sont dans l'état Eliminated, le même que celui défini au niveau du domaine AD (état global).
On dit que la migration a atteint un état consistant sur tous les contrôleurs de domaine.
 
A partir de ce moment, la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R est officiellement terminée.
 
Bonus :
En cas de succès, on constate également la présence sur tous les controleurs de domaine de l'évènement 8019 dans le journal d'évènements Applications and Servicies logs -> DFS Replication

La console DFS Management pour le groupe de réplication Domain System Volume nous confirme que la version du dossier SYSVOL présentée aux postes clients est celle répliquée par le mécanisme DFS-R.

 

Active Directory : Migration SYSVOL de FRS vers DFS-R - Etape Redirected (Partie 4)

Bonjour à tous,

Aujourd'hui nous abordons la partie 4 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à l'étape Redirected.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR
 

Particularités

Comme vous pouvez le voir ci-dessus, l'état 2 (Redirected) est le plus impactant :
  • En arrière-plan, le mécanisme de réplication DFS-R réplique une copie du dossier SYSVOL, toujours en parallèle de la version répliquée par le mécanisme FRS.
  • En façade, c'est le dossier SYSVOL répliqué par le mécanisme DFS-R qui est présenté aux postes clients via les partages NETLOGON et SYSVOL
Il faut souligner les points suivants :
  • Un retour arrière reste possible (il faut utiliser la commande dfsrmig /setglobalstate X où X est le numéro de l'étape voulue)
  • Il convient de vérifier que la copie du dossier SYSVOL répliquée par le mécanisme DFS-R est intègre avant d'effectuer la bascule vers celle-ci. A toute fin utile, on pourra éxécuter un Rapport de Propagation de la Réplication DFS dans la console DFS Management pour le groupe de réplication Domain System Volume.
  • Le dossier SYSVOL est copié une seule et unique fois lors de la premiere étape. Toute modification faite sur les GPOs ou le dossier SYSVOL lui même entre l'état 1 (Prepared) et l'état 2 (Redirected) est perdue.
  • Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC

En pratique

Etat Prepared

Si l'étape précédente a été correctement réalisée, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Prepared.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Redirected.

Passage vers l'etat Redirected

Etat global (Domaine AD) : dfsrmig /setglobalstate 2

On remarque que la bascule vers la version du dossier SYSVOL répliquée par le mécanisme DFS-R est bien indiquée.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).

Etat Redirected atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Redirected. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Le message est explicite, tous les contrôleurs de domaine sont dans l'état Redirected, le même que celui défini au niveau du domaine AD (état global).
On dit que la migration a atteint un état consistant sur tous les contrôleurs de domaine.
 
Bonus :
En cas de succès, on constate également la présence sur tous les controleurs de domaine de l'evenement 8017 dans le journal d'évènements Applications and Servicies logs -> DFS Replication

La commande net share executée sur un contrôleur de domaine nous confirme que la version du dossier SYSVOL présentée aux postes clients est celle répliquée par le mécanisme DFS-R.

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la troisième étape, Eliminated.

Active Directory : Migration SYSVOL de FRS vers DFS-R - Etape Prepared (Partie 3)

Bonjour à tous,

Aujourd'hui nous abordons la partie 3 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à l'étape Prepared.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR
 

Particularités

Comme vous pouvez le voir ci-dessus, l'état 1 (Prepared) n'est pas le plus impactant :
  • En arrière-plan, le mécanisme de réplication DFS-R est mis en place pour répliquer une copie du dossier SYSVOL, en parallèle de la version répliquée par le mécanisme FRS.
  • En façade, c'est toujours le dossier SYSVOL répliqué par le mécanisme FRS qui est présenté aux postes clients via les partages NETLOGON et SYSVOL
En revanche, il faut souligner les points suivants :
  • Un retour arrière reste possible (il faut utiliser la commande dfsrmig /setglobalstate X où X est le numéro de l'étape voulue)
  • Une copie du dossier SYSVOL actuel sera réalisée. Il convient de vérifier que le dossier SYSVOL est intègre avant de commencer les étapes de migration sinon vous vous retrouverez avec un dossier SYSVOL qui sera toujours corrompu en fin de migration.
  • Le dossier SYSVOL est copié une seule et unique fois lors de la premiere étape. Toute modification faite sur les GPOs ou le dossier SYSVOL lui même entre l'état 1 (Prepared) et l'état 2 (Redirected) est perdue.
  • Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC

En pratique

Etat Start

Si aucune tentative de migration n'a été faite auparavant, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Start.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Prepared.

Passage vers l'etat Prepared

Etat global (Domaine AD) : dfsrmig /setglobalstate 1

On remarque qu'il est indiqué un délai concernant le début de la migration pour les contrôleurs de domaine.
Ceci est parfaitement normal car les contrôleurs vont aller lire l'information sur l'état de la migration depuis la partition Active Directory qu'ils auront répliqué.
Vous pouvez donc avoir un début de migration tardif à cause :
  • D'une réplication Active Directory lente
  • D'un RODC ne voulant pas passer en état Prepared. Les RODCs ne pouvant pas modifier les objects Active Directory par eux mêmes (création des objets DFS-R leur correspondant), c'est le PDC qui est chargé de le faire à leur place. Toutefois, si malgré un certain délai, les RODCs ne passent pas en état Prepared, il faudra forcer la création des objets DFS-R correspondant avec la commande dfsrmig /CreateGlobalObjects (à éxécuter seulement une fois depuis le PDC)

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).

Etat Prepared atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Prepared. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Le message est explicite, tous les contrôleurs de domaine sont dans l'état Prepared, le même que celui défini au niveau du domaine AD (état global).
On dit que la migration a atteint un état consistant sur tous les contrôleurs de domaine.
 
Bonus : 
En cas de succès, on constate également la présence sur tous les controleurs de domaine de l'evenement 8014 dans le journal d'évènements Applications and Servicies logs -> DFS Replication

 

La commande net share executée sur un contrôleur de domaine nous confirme que la version du dossier SYSVOL présentée aux postes clients est toujours celle répliquée par le mécanisme FRS.

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la deuxieme étape, Redirected.

Active Directory : Migration SYSVOL de FRS vers DFS-R - Déroulement (Partie 2)

Bonjour à tous,

Aujourd'hui nous abordons la partie 2 de notre série sur la migration du dossier SYSVOL du mécanisme FRS vers DFS-R, elle sera consacrée au déroulement global de celle-ci.

Etats de migration

Etats de migration globaux et locaux

Il existe deux types d'états de migration :

  • Global : Les commandes pour initier les étapes de migration vont agir sur le PDC. Une fois que l'état de migration a changé sur le PDC, il est défini au niveau du domaine Active Directory, d'oû sa portée globale.
  • Local: Une fois que l'état de migration a été défini sur le PDC, chaque contrôleur de domaine annexe va évaluer son propre état de migration par rapport à celui du domaine et va effectuer les opérations demandées si les deux ne correspondent pas. D'ou un état de migration local propre à chaque contrôleur de domaine.

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR

 

Au niveau de chaque controleur de domaine, il existe 6 états locaux qui sont les suivants :

Etat  Etat de transition 
 Etat 4 Preparing (valable uniquement pour les RODC)
 Etat 5  Waiting for initial synchronization
 Etat 6  Redirecting
 Etat 7  Eliminating
 Etat 8  Undo redirecting
 Etat 9  Undo preparing

 

Schématiquement, nous pouvons résumer la migration (et un retour arrière) comme ceci :

 

Remarques importantes

  • Un niveau fonctionnel de forêt/domaine AD 2008 minimum est nécéssaire pour démarrer la migration.
  • Une copie du dossier original SYSVOL, appelée SYSVOL_DFSR et située au même endroit que le dossier SYSVOL orinigal, est utilisée en parallèle par DFS-R pour la réplication des données.
  • La commande dfsrmig est utilisée pour configurer les états de migration et est à utiliser de préférence sur le PDC du domaine conerné, ou tout du moins sur n'importe quel contrôleur de domaine accéssible en écriture (hors RODC donc).
  • Le retour arrière n'est possible que jusqu'à l'état 2. Pas de retour arrière possible une fois le domaine en état 3.
  • Il faut vérifier manuellement l'état de réplication du dossier SYSVOL à chaque étape. Il n'y a pas de vérification automatique de l'intégrité du dossier SYSVOL lors de l'utilisation de la commande dfsrmig.
  • Il n'est pas possible de renommer un contrôleur de domaine pendant toute la durée de la migration.
  • Toute modification de GPOs, ou d'ajout/suppression de contrôleur de domaine durant la durée de la migration est fortement déconseillée, mais reste toutefois possible.
  • Un contrôleur de domaine peut être éteint et allumé de nouveau pendant la migration.
  • Les états de transitions sont plus longs pour les RODCs (c'est le PDC qui fait les opérations pour eux) et les sites distants.

Commandes utiles

  • dfsrmig /GetGlobalState : Indique l'état de migration du dossier SYSVOL au niveau du domaine AD
  • dfsrmig /SetGlobalState Numero_etat_de_migration (0,1,2,3) : Configure l'état de migration du dossier SYSVOL au niveau du domaine AD
  • dfsrmig /GetMigrationState : Indique l'état de migration du dossier SYSVOL pour tous les contrôleurs de domaine du domaine AD
  • repadmin /syncall /AeD : Force la syncronisation de tous les contrôleurs de domaine AD

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la première étape, Prepared.