Mais pourquoi le profil de mon collègue parti à la retraite l’année dernière n’est-il pas nettoyé par la “GPO – Delete user profiles older than 180 days” ?

Sur les fermes de serveurs RDS, il est fréquent de purger les profils utilisateurs avec la GPO “Delete User Profiles older than x days” ou d’implémenter des outils de purge basés sur la date de modification du fichier ntuser.dat (ruche) du profil des utilisateurs.

Depuis Windows 8/Windows 2012, le “Component Manager” (composant kernel gérant le registre) a introduit une optimisation qui peut mettre à mal ces stratégies de purge. Lorsque l’on accède à des clés, les “cellules” contenant ces clés sont lues depuis le fichier sur le disque et montées en mémoire (dans la “Non Paged Pool”).

L’idée de cette optimisation est de regrouper les “cellules”  utilisées récemment pour limiter le nombre d’IO disque.

Pour mettre en oeuvre cette stratégie, chaque “cellule”  sera marquée comme :

• chaude : cette cellule a été accédée depuis la réorganisation (par exemple suite à la lecture des valeurs associées à la clé contenue dans la cellule)
• ou froide: cette cellule n’a pas été accédée depuis la dernière réorganisation. Lors du chargement de la ruche, si celle-ci n’a pas été réorganisée depuis 7 jours, alors la ruche est réorganisée et les cellules sont marquées comme froides.

Si plus tard, cette ruche est réutilisée et une des clés “froides” est accédée en lecture, la cellule associée va devenir “chaude”. L’effet pervers est que la cellule est considérée comme modifiée et la ruche devient “Dirty”. Lors de son déchargement,  la date du ficher ntuser.dat sera modifiée. Cette ruche ne sera alors plus candidat à l’application de la GPO !

Si sur votre serveur, votre antivirus ou vos outils de surveillance (par exemple via des classes WMI (Win32_Desktop,Win32_Environment,…) chargent les ruches utilisateurs pour des accès en lecture ) alors la date des fichiers ntuser.dat peut changer même si aucune modification “logique” n’a été faite dans le registre. Le profil de votre collègue parti restera sur le serveur !

Pour les courageux qui m’ont suivi jusqu’ici, je vais l’illustrer avec un exemple sur Windows 2012 R2, un fichier ntuser.dat “ancien”. Nous allons

1. analyser l’état du fichier
2. charger/décharger la ruche sans modification
3. recharger la ruche, énumérer des clés et décharger la ruche

et observer les modifications sur la “ruche”

Etape 1 – Etat initial :

1. La date de dernière modification du fichier est le 5/18/2017 3:28 PM (18 mai)
2. La date de dernière réorganisation stockée dans le fichier est le 5/18/2017 3:28PM

Etape 2 – Chargement/déchargement de la ruche sans aucun accès à des clés (via les commandes reg load , reg unload ) :

1. La date de dernière modification du fichier ne change pas
2. La date de dernière réorganisation stockée dans le fichier change et devient 6/1/2017 3:21 PM (1 juin)
3. Nous constatons également que la valeur LastRun dans HKLMSystemCurrentControlSetControlSessionManagerConfiguration ManagerDefrag indique bien qu’une défragmentation a eu lieu.
4. Si nous comparons le fichier avec une copie de l’état initial, nous constatons que 3 cellules sont devenues froides ( 02 => 00). On pourrait également vérifier que les autres cellules sont toutes froides (valeur 0 à l’offset 8 après la signature 6e 6b 20 00)

Etape 3 – Nouveau chargement avec l’outil regedit puis énumérations de quelques clés et enfin déchargement de la ruche

1. La date de dernière modification du ficher change : 6/1/2017 3/51 PM
2. Pas de réorganisation car la ruche a déjà été réorganisée récemment et reste au : 6/1/2017 3:21 PM (1 juin)
3. Les cellules accédées sont marquées comme “chaudes” (00 ==> 02 )

Conclusion :  si un composant effectue un “scan” en lecture de certaines ruches, depuis Windows  Seerver 2012,  ce scan peut perturber la prise en compte de vos stratégies de purge des profils utilisateurs.