Crashs fréquents de WSUS 4.0

Depuis quelques jours, un serveur WSUS plantait au bout de quelques minutes de fonctionnement, sans dysfonctionnement notable côté système. Les logs de WSUS ne donnaient rien de particulier : toutes les requêtes y étaient journalisées, jusqu’au plantage sans code d’erreur particulier. Il suffisait d’un iisreset pour redonner l’accès au service, mais hors de question de créer un tâche planifiée pour effectuer un iisreset toutes les 5 minutes pour palier au dysfonctionnement.

Message d’erreur apparaissant sur la console WSUS peu de temps après le redémarrage du service.

J’avais cependant dans le journal d’événements Windows, deux entrées récurrentes, avec pour code d’erreur 5013 et 5138, et source « WAS ». Ces erreurs indiquent qu’une application utilisée dans le pool applicatif WsusPool n’a pas communiqué et ne s’est pas terminée dans le temps imparti.

J’ai procédé à quelques changements de variables concernant le pool applicatif WsusPool :

  • Queue Length : passage à 25000 au lieu de 5000 (il s’agit du nombre maximal de requêtes HTTP qui peuvent être en attente) ;
  • Augmentation de la Virtual Memory Limit à 5 Go (pour 8 installés physiquement sur le serveur) ;
  • Passage du « Service Unavailable » Response Type de HttpLevel vers TcpLevel : ceci permet d’éviter de renvoyer une erreur HTTP 503 Service Unavailable lorsque le serveur ne peut traiter la requête. Le serveur va à la place remettre en file d’attente la requête HTTP.

J’ai procédé ensuite à un redémarrage complet du serveur, WSUS fonctionne désormais depuis plus de 2 heures consécutives et aucun dysfonctionnement n’est à déplorer.

Restauration d’un contrôleur de domaine virtuel grâce à Veeam

Si la problématique de la sauvegarde de contrôleurs de domaine et surtout de leur restauration fut un temps épineuse, ce n’est plus tellement le cas de nos jours, grâce à des avancées côté Windows et côté outils de sauvegarde.

Dans le cadre d’un contrôleur de domaine virtuel, si réaliser un snapshot avant d’installer des mises à jour Windows par exemple peut partir d’un bon sentiment, c’est la catastrophe assurée en cas de retour en arrière, toute la cohérence de l’annuaire étant remise en question puisque le DC sera incapable de comprendre pourquoi il se voit présenter des mises à jour venant du futur puisqu’il aura été restauré à un état passé comme si rien ne s’était passé depuis la création du snap. L’outil Windows Server Backup peut être un bon point de départ pour la sauvegarde d’AD ; cependant l’emplacement de stockage n’est peut-être pas toujours défini à l’avance et l’outil peut ne pas s’intégrer dans les politiques de sauvegarde de l’infrastructure générale.

Récemment, j’ai pu effectuer sur une plateforme de tests la sauvegarde et la restauration de contrôleurs de domaines virtualisés sous vSphere ESXi grâce à Veeam Backup & Replication. Dans cet article, je vais aborder les points principaux d’une telle manipulation si un contrôleur de domaine ne démarre plus (et que par conséquent, la structure de l’AD est intacte), sans oublier de rappeler qu’il est indispensable de valider sur des environnements iso ces procédures de sauvegarde et restauration, en plus d’avoir connaissance de la documentation Veeam à ce sujet (p. ex. ces deux articles : ici et ). Dans le cas où la cohérence même de l’annuaire a été remise en question
(corruption, par exemple), d’autres étapes peuvent être requises
(je pense notamment par un passage par le DSRM) mais je ne les aborderai pas dans cet article.

La plateforme de test est composée de 4 machines : 3 contrôleurs de domaine 2012 R2 et un client Windows 10, sous vSphere 6.5 et sauvegardée par Veeam Backup & Replication en version 9.5.

Tout d’abord, il est important de vérifier que le job de sauvegarde des DC ait l’option Enable Application-aware Processing d’activée.

Bien sûr, avant de s’engager dans plus de manipulations, il sera bienvenu de s’assurer que les sauvegardes ont été réalisées avec succès en temps et en heures.

Suite à des manipulations sur dc03, j’obtiens un célèbre BSOD :

Ce DC doit donc être restauré. Dans VMware, je vais procéder à sa mise hors-tension, et à la suppression de la VM.

Dans Veeam, je vais procéder à la restauration de la VM, en utilisant les options Entire VM Restore puis Instant Recovery.

Je choisis de restaurer la VM to the original location, sans connecter le réseau ni directement démarrer la VM. Une fois cette opération terminée, la VM sera ajoutée dans VMware et stockée sur le pool de sauvegarde Veeam ; il faut la déplacer sur le stockage de production.

En allant sur Instant Recovery dans Veeam, je peux sélectionner mon dc03 et choisir Migrate to Production.

Une vérification des paramètres s’impose pour être sûr de finaliser la récupération au bon endroit, puis le déplacement sur l’environnement de production s’effectue.

Une fois l’opération terminée, je sélectionne l’option Stop Publishing sur dc03. Ainsi, il disparaît de VMware où il apparaissait en double : en tant que dc03 (fraîchement restauré) et dc03-xxxxx (la restauration de Veeam avant son déplacement sur l’environnement de production). Il ne reste donc plus que dc03.

Un petit tour dans les paramètres de la VM pour confirmer que tout est bien configuré : ne pas oublier de connecter la carte réseau avant de la démarrer.

Windows va s’initialiser puis redémarrer au bout de quelques minutes – c’est normal.

En réalité, Windows démarre en mode sans échec, se resynchronise avec les autres contrôleurs de domaine, réalise des mises à jour de fichiers de configuration avant de redémarrer. Une fois ce redémarrage terminé, l’OS est utilisable et répond aux requêtes AD comme si rien ne s’était passé. Tout le processus est entièrement automatique et géré par Veeam, qui lors de la sauvegarde, applique certains paramètres en détectant que la VM est un DC Windows.

Il ne reste plus qu’à réaliser quelques tests grâce à dcdiag et repadmin :

Un dcdiag /a /i devrait tout de même renvoyer quelques erreurs systèmes qui ont été journalisées dans l’event viewer en fonction de la manière dont le DC a planté mais tous les autres tests devraient être en succès, pour peu qu’ils l’aient été pré-crash. D’autres tests comme la jonction de stations aux domaine doivent toujours fonctionner sans anicroche.

Migration d’une paire de contrôleurs de domaine en 2003 vers 2008 R2 puis 2012 R2

Si j’ai installé un serveur 2003 (voir l’article précédent), ce n’est pas pur plaisir – quoique – mais car j’ai décidé de monter une maquette composée de deux contrôleurs de domaine en 2003 qui doivent être migré sous un OS plus récent, ici 2012 R2.

Dans cet article, je vais détailler les principales étapes pour mener à bien cette migration que j’ai réalisé en 2 temps, tout d’abord en migrant de 2003 vers 2008 R2, puis de 2008 R2 vers 2012 R2. Bien évidemment, avant de se lancer en production, valider la procédure sur un environnement de test me paraît indispensable ; tout comme valider ces quelques pré-requis : faire un dcdiag pour s’assurer qu’il n’y ait pas d’erreurs ou d’incohérences au niveau du domaine et être sûr de disposer de tous les mots de passe nécessaires aux promotions et dépromotions de contrôleurs de domaine. Je ne saurais être tenu responsable si vous appliquez ce procédé en production sur un environnement bancal et que ça coince quelque part sans que vous ayez de moyen de revenir en arrière !

Pour clarifier, j’ai nommé mon domaine maquette.local, et mes serveurs s’appelleront DCXXXPRI et DCXXXSEC.

Situation actuelle : 2 DC 2003 – DC2K3PRI et DC2K3SEC. C’est parti ! 💪

Tout d’abord, faire en sorte que le niveau fonctionnel de la forêt du domaine soit en 2003 : se rendre dans les consoles Active Directory Domains and Trusts et Active Directory Users and Computers pour faire les montées de version.

Le niveau fonctionnel de l’ActiveDirectory est en 2000 sur un domaine fraîchement configuré sur un 2003.    

Procéder à l’installation d’un serveur 2008 R2. Ce nouveau serveur sera mis sur le domaine et s’appellera DC2K8PRI. Une fois les rôles ADDS installés sur ce serveur, il est nécessaire de préparer la forêt pour recevoir un AD 2008.

Pour ce faire, monter l’ISO de Windows Server 2008 sur DC2K3PRI. Puis, ouvrir une invite de commande, se placer sur l’ISO (répertoire d:\support\adprep par défaut) et exécuter les instructions suivantes :

adprep32.exe /forestprep
adprep32.exe /domainprep
adprep32.exe /gpprep
adprep32.exe /rodcprep

La première instruction avec le paramètre forestprep demandera une confirmation en saisissant « c ».

adprep32.exe demande une confirmation lors de la demande de mise à niveau du schéma pour accueillir un DC 2008.
Préparation du schéma en cours…
Le domaine est prêt, il reste plus qu’à implémenter la nouvelle gestion des GPO et des RODC (Read-Only Domain Controller) si besoin.

Une fois que tout s’est bien déroulé, retour sur DC2K8PRI. Exécuter dcpromo pour en faire un DC. Le serveur sera donc ajouté à la forêt existante, les autres paramètres ne doivent pas être modifiés et le serveur doit être ajouté comme un contrôleur de domaine supplémentaire.

 
On ajoute simplement un DC au domaine maquette.local.  
 
On spécifie le compte d’administration à utiliser pour la promotion.      
 
 
La promotion est prête à être effectuée.

Dès que l’assistant est terminé et le
serveur promu en DC avec succès, ce dernier redémarrera. Une fois le reboot
terminé, contrôler dans la console ActiveDirectory Users and Computers sa
présence dans l’OU Domain Controllers.

Si l’étape précédente a été concluante, le domaine est donc composé de 2 DC 2003 et d’un DC 2008 R2. Le serveur DC2K3SEC doit être dépromu afin qu’il ne reste plus que 2 DC.

Se rendre sur DC2K3SEC, et effectuer un dcpromo.

Il ne faut surtout pas cocher cette case car nous souhaitons bien conserver le domaine !
 
Il y a des répertoires et arborescences propres à 2003 qui
seront supprimées en même temps que la dépromotion du serveur ; il n’est pas nécessaire d’en tenir
compte car elles ne seront plus utilisées par la suite. Une fois l’assistant terminé, le serveur va redémarrer, il ne
sera plus DC. Il ne reste plus qu’à lui retirer les rôles AD et à l’éteindre. Il nous reste donc 1 DC 2003 (master) et 1 DC 2008 R2.
 
On arrive maintenant sur l’étape cruciale de la migration. L’étape suivante consiste à
transférer les rôles opérationnels de DC2K3PRI vers DC2K8PRI.
 
Se connecter sur DC2K8PRI, ouvrir une
invite de commandes ou une invite Powershell et obtenir la confirmation que
c’est DC2K3PRI qui héberge les rôles opérationnels du domaine grâce à l’instruction netdom query fsmo :
 
Les rôles opérationnels sont bien portés par DC2K3PRI.
 
Dans cette même invite de commandes, exécuter regsvr32 schmmgmt.dll pour ajouter la console ActiveDirectory Schema. Une fois que l’instruction a été exécutée, ouvrir mmc.exe et ajouter le Snap-In ActiveDirectory Schema. Effectuer le transfert du rôle Schema Master en sélectionnant le domaine puis Operations Master. Ensuite, ouvrir la console ActiveDirectory Domains and Trusts puis effectuer le transfert du rôle Naming Operations Master.
 
Transfert du Naming Master

Ensuite, ouvrir la console
ActiveDirectory Users and Computers et faire de même pour les rôles RID, PDC et
Infrastructure.

Une fois le transfert effectué pour
les 5 rôles, exécuter de nouveau la commande netdom query fsmo. Voici ce qui devrait
ressortir de l’instruction si tout s’est bien déroulé :
 
Le transfert s’est bien déroulé : tous les rôles ont basculé sur DC2K8PRI.    
 
 
Si et seulement si les rôles ont bien
été déplacés, il est envisageable de continuer. Maintenant que le DC maître est DC2K8PRI, installer un serveur
2008 R2 nommé DC2K8SEC. Le mettre sur le domaine, installer les rôles AD,
réaliser un dcpromo pour le déclarer contrôleur de domaine. Nous avons donc en l’état 1 DC 2003 et 2 DC 2008 R2 (dont un maître). Il nous reste plus qu’à retirer le dernier DC en 2003 pour que la première partie de la migration soit réalisée.
 
 
Se connecter à DC2K3PRI. Effectuer un dcpromo de la même manière qu’il a été effectué sur DC2K3SEC. Ne pas supprimer le domaine, simplement accepter la suppression des répertoires et arborescences propres à 2003. Une fois l’assistant terminé et le redémarrage effectué, contrôler sur un des DC 2008 dans la console ActiveDirectory Users and Computers qu’il ne reste plus que les 2 DC 2008.
 
Il n’y a plus de trace des serveurs 2003 dans l’OU des contrôleurs de domaine.

Si tout s’est bien déroulé jusqu’ici, il suffit de retirer le rôle AD sur le serveur 2003 et à l’éteindre pour conclure proprement cette première partie.

Nous sommes à mi-chemin, c’est le moment de souffler un bon coup, de pourquoi pas se prendre un café, un thé, un coca, un verre d’eau ou une bonne pinte avant de continuer ! 🍺
 
 
En fonction de ce qui est hébergé sur le domaine, il peut
être nécessaire d’effectuer une montée de niveau fonctionnel de la forêt et du
domaine vers 2008 R2. Si besoin, répéter l’opération effectuée en début de
procédure pour monter de 2000 vers 2003 (ouvrir la console ActiveDirectory
Domains and Trusts
, puis Raise forest functional level vers 2008, puis 2008
R2 ; ouvrir la console ActiveDirectory Users and Computers et monter le niveau
du domaine de la même manière).
Montée du niveau fonctionnel de la forêt en 2008.
Forêt et domaine en niveau fonctionnel 2008 R2.

Et c’est reparti pour une installation : un serveur 2012 R2, le mettre sur le domaine, y installer les rôles ADDS, et le promouvoir en contrôleur de domaine.

Installation des rôles ADDS
Prêt pour l’installation.

La promotion comme contrôleur de domaine se fait directement par le Server Manager, dcpromo n’existant plus en tant qu’application appelable par l’utilisateur. Il n’y a pas besoin d’effectuer un adprep avec 2012 R2 car c’est l’assistant qui va préparer le schéma. Lorsque l’assistant est terminé, le serveur redémarre, vérifier dans la console ActiveDirectory Users and Computers que DC2012PRI apparaît bien dans l’OU des DC. A ce moment, il y a 2 DC 2008 R2 (dont maître) et un DC 2012 R2.

Le transfert des rôles vers le nouveau DC en 2012 R2 s’effectue maintenant. Vérifier avec netdom query fsmo que DC2K8PRI est toujours porteur des rôles. Dans une invite de commande ou Powershell, saisir regsvr32 schmmgmt.dll puis ouvrir un mmc.exe et y ajouter la console ActiveDirectory Schema. Dans la console, s’assurer que l’on est bien connecté sur DC2012PRI.

Bien sélectionner DC2012PRI afin de le désigner comme nouveau maître du schéma.  

Ensuite réaliser l’opération de transfert des rôles, de la même manière qu’effectuée sur le 2003 (Operation Masters puis Change). Ouvrir les consoles ActiveDirectory Domains and Trusts et ActiveDirectory Users and Computers pour y réaliser le transfert des rôles de naming, RID, PDC et Infrastructure. Vérifier que le transfert a bien été appliqué :

DC2012PRI est le nouveau serveur « maître » du domaine.

Maintenant que le DC primaire est DC2012PRI, installer un serveur 2012 R2 nommé DC2012SEC. Le mettre sur le domaine, installer les rôles AD, réaliser un dcpromo pour le définir contrôleur de domaine et le définir contrôleur de domaine avec l’assistant. Si tout s’est bien déroulé jusqu’alors, il y a 3 DC : 1 2008 R2 et 2 2012 R2 (dont le maître).

Tous les rôles étant sur DC2012PRI et DC2012SEC étant fonctionnel, exécuter dcpromo sur DC2K8PRI, le dépromouvoir, puis supprimer les rôles ADDS, et procéder à l’extinction du serveur.

DC2K8PRI n’est plus que l’ombre de ce qu’il fut pendant quelques heures…

Enfin, nous avons 2 DC en 2012 R2. Afin de vérifier que tout s’est bien déroulé, réaliser un dcdiag et s’assurer que tous les tests sont concluants – pass :

dcdiag /v /c /d /e /s:DC2012PRI

Les tests sont complets et si tout s’est bien déroulé du début à la fin, ils doivent tous être passés avec succès.  

Pour conclure, il ne reste plus qu’à reconfigurer la synchronisation du temps sur le contrôleur de domaine hébergeant le rôle PDCEmulator afin d’être sûr qu’il se synchronise sur une source de temps valide et qu’il ne conserve pas une référence caduque suite aux migrations. Dans cet exemple, je prends le serveur de temps Microsoft mais il peut s’agir d’un serveur en interne.

w32tm /config /manualpeerlist:time.windows.com /syncfromflags:manual /reliable:yes /update

Migration de serveur DHCP sous Windows Server 2012 R2

Afin de remplacer un serveur DHCP physique défaillant, j’ai monté un nouveau serveur DHCP basé sur une machine virtuelle. Grâce à Powershell, on peut s’occuper de la migration des données propres au serveur DHCP (paramètres, plages, baux…) en 2 coups de cuillère à pot.

Sur l’ancien serveur, on exporte les données :

Export-DhcpServer –ComputerName dhcp-srv -Leases -File C:\dhcp-mig\DhcpSrv-Export.xml -verbose

Puis on importe sur le nouveau serveur ce fichier XML ; à noter que le paramètre -BackupPath permet de spécifier un emplacement où Powershell va sauvegarder la configuration avant importation :


Si jamais l’importation renvoie une erreur « There are no more endpoints available« , il faut alors passer en valeur du paramètre ComputerName le nom NetBIOS de la machine et non son nom DNS (p. ex. : dhcp-srv01 et non dhcp-srv01.domain.com). Pour plus d’informations, vous pouvez consulter ce lien.

Ensuite, pour vérifier que tout est bien importé, en plus d’un contrôle visuel pour les scopes et réservations, cette instruction permet de compter le nombre d’enregistrements : si ils sont identiques avant l’export et après l’importation, cela veut dire que tout s’est bien déroulé (attention, il est possible d’obtenir tout de même une valeur différente si des baux ont expiré depuis l’importation sur le nouveau serveur) :

(Get-DhcpServerv4Scope -Computername dhcp-srv-new | Get-DhcpServerv4Lease -Computername dhcp-srv-new).Count

Vous pouvez trouver tous les cmdlets Powershell propres à DHCP sur le TechNet.