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

SQL Server–Création d’un job de Vérification de cohérence d’une base SQL

Contexte

Ce post explique comment créer un job qui permet de vérifier automatiquement la cohérence d’une base de donnée.

Résolution

Depuis SQL Server Management Studio, depuis le dossier “Management”, créer un nouveau plan de maintenance :

image

Ajouter la tâche de vérification de l’intégrité de la base depuis la ToolBox :

image_thumb5_thumb

Indiquer les bases à vérifier :

image_thumb7_thumb

Eventuellement, indiquer l’action à réaliser en cas de succès ou d’échec du job :

image_thumb9_thumb