Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

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.

Active Directory : Migration SYSVOL de FRS vers DFS-R – Préparation (Partie 1)

Bonjour à tous,

Aujourd’hui nous commençons une série de billets consacrée à la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R.

Historique

FRS (File Replicating System) est un mécanisme de réplication de fichiers introduit avec Windows 2000 et à été utilisé au sein d’Active Directory pour la réplication du dossier SYSVOL.

Avec l’arrivée de Windows Server 2008, Microsoft a introduit une nouvelle technologie appellée DFS (Distributed File System). Cette technologie se décline en deux composants : DFS-N (qui gère les espaces de noms de dossiers partagés) et DFS-R (qui gère la réplication entre des dossiers).
Microsoft a rendu possible l’utilisation de DFS-R pour la réplication du dossier SYSVOL depuis Windows Server 2008 (et son niveau fonctionnel de forêt/domaine correspondant).

A partir de Windows Server 2008 R2, Microsoft ne permet plus l’utilisation de la technologie FRS pour la réplication de dossiers mais pour des raisons de compatibilité laisse cette possiblité pour le dossier SYSVOL jusqu’à Windows Server 2012 R2 (et son niveau fonctionnel de forêt/domaine correspondant).

Pourquoi migrer ?

Le mécanisme FRS n’est plus supporté par aucun contrôleur de domaine à partir de Windows Server 2016.

Plus précisemment, même si vous voulez ajouter un contrôleur de domaine sous OS Windows Server 2016 et garder un niveau fonctionnel de forêt/domaine Windows Server 2012 R2, ce n’est pas possible car Microsoft à tout simplement retiré les binaires FRS de l’OS ! (ce n’était pas le cas jusqu’à la RS3).

Même si vous avez effectué une montée du niveau fonctionnel d’une forêt AD, la migration de FRS vers DFS-R n’est pas éffectuée automatiquement.

DFS-R est le mécanisme de réplication utilisé par défaut pour le dossier SYSVOL depuis le niveau fonctionnel de forêt/domaine AD 2008 pour toute création d’une nouvelle forêt AD avec un niveau fonctionnel de forêt/domaine 2008. Si vous êtes dans ce cas, alors il n’y a pas de migration à prévoir.

En revanche, si vous avez hérité d’une forêt AD historique remontant à Windows Server 2003 et que vous n’avez éffectué uniquement que des montées de niveau fonctionnel de forêt/domaine AD sans vous préoccuper du SYSVOL, il y a de fortes chances pour que FRS soit toujours utilisé pour sa réplication.

Comment vérifier si FRS est toujours utilisé ?

Il faut passer par la console ADSIEdit.

Connectez-vous au Default Naming Context (Contexte de nommage par défaut).

Dans l’aborescence, allez dans CN=votredomaine,DC=local -> CN=System -> CN=DFSR-GlobalSettings. Ouvrez les propriétés de CN=DFSR-GlobalSettings.

Cherchez la propriété msDFSR-Flags et notez la valeur présente.

Si la valeur est nulle, alors c’est FRS qui est actuellement utilisé pour la réplication du dossier SYSVOL.

Si la valeur est 48, alors c’est DFS-R qui est actuellement utilisé pour la réplication du dossier SYSVOL.

Si la valeur est 0, 16 ou 32 alors c’est que la migration du mécanisme de réplication est en cours (0 correspond à l’état Start, 16 correspond à l’état Prepared, 32 correspond à l’état Redirected et 48 correspond à l’état Eliminated).

Dans le prochain billet, nous aborderons la procédure de migration du dossier SYSVOL du mécanisme FRS vers DFS-R.

SQL Server–La suppression du contenu d’une table ne se termine pas

Contexte

Afin de purger une table, deux solution sont possibles :

“TRUNCATE table Table_a_vider” ou “DELETE from Table_a_vider”

La principale différence entre ces deux commandes est la suivante :

  • TRUNCATE est une commande DDL, cette commande est beaucoup plus rapide, mais son action est irrémédiable,
  • DELETE est une commande DML, sa durée d’exécution dépends du volume de données à traiter.

Ces deux commandes ont malgré tout pour point commun de nécessiter un lock exclusif sur les données à supprimer. Si ce lock n’est pas obtenu, la commande vas continuer de s’exécuter jusqu’à l’obtenir.

Afin de ne pas attendre, il faut détecter la session provoquant le blocage et la stopper si possible.

Résolution

La commande suivante permet de lister toutes les transactions bloquées :

USE Master
GO
SELECT *
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;
GO

La commande sp_who2 liste toute les sessions avec leur numéro de SPID, il suffit de retrouver la session remontée par la commande précédente puis de se référer à la colonne “BlkBy” afin d’identifier le process qui la bloque.

image_thumb1

La commande suivante permet d’afficher la commande exécutée par le SPID indiqué, cela permet d’évaluer le risque avant de stopper la session à l’aide de la commande “kill”

dbcc inputbuffer(SPID)