Wednesday, February 7, 2018

Active Directory - Add a Windows Server 2016 domain controller with PowerShell (FR)

English summary: in 2013 I dedicated a blog post to the basic configuration of Windows 2012 with PowerShell. Now that I've finished my series on Active Directory forest recovery, I wanted to take advantage of my previous lab (still available for use) to look at Windows 2016 in the following scenario: add a Server 2016 domain controller to an existing Windows 2008 (R2) domain. What is the connection with the blog post from 2013? We'll use PowerShell (for just about everything - as in the 2013 blog, I went ahead and configured time and date with the graphic tools). Since the last test lab I built used the French version of Server 2008 R2 (evaluation version), I'll compose the post in French but with or without Google Translate, the screenshots should speak for themselves.

***


Exception faite des paramètres de la date et de l'heure (que je n'ai pas configurés avec PowerShell), la première chose que je fais en préparant un nouveau serveur, c'est le nom. Avec PowerShell 5.1 (la version disponible avec Server 2016), il suffit de taper (avec "DC1" pour exemple) :

Rename-Computer DC1


Astuce : cliquez sur l'image pour l'agrandir.

Nous pouvons éviter la confirmation avec le paramètre...

-force

Et nous pouvons faire redémarrer avec le paramètre...

-restart


Ensuite, je m'occupe des paramètres TCP/IP. Plusieurs peuvent coexister, tant IPv4 que IPv6, et sur de multiples interfaces. Je m'intéresse avant tout aux paramètres IPv4 de l'interface qui servira à communiquer avec les autres membres du domaine. Pour y voir plus clair, je peux afficher la liste des interfaces avec cette commande :

Get-NetIPAddress | ft

Remarque : "ft" est un raccourci de "format-table", une des options d'affichage.


Je constate que l'interface 2 (voir la colonne "ifIndex") s'est vue attribuer une adresse IPv4 par un serveur DHCP. C'est donc par cette interface que le serveur communique avec le reste du réseau. Mais comment lui configurer une adresse statique, choix plus judicieux pour un futur contrôleur de domaine ?

Voici la commande qu'il nous faut (avec des valeurs qui conviennent à mon réseau d'essai) :

New-NetIPAddress -InterfaceIndex 2 -IPAddress 10.4.1.11 -PrefixLength 8 -DefaultGateway 10.1.1.3

Remarque : le paramètre -PrefixLength correspond au masque de sous-réseau, comme la plupart des lecteurs auront compris. Malgré l'absence de barre oblique, "8" correspond bien à 255.0.0.0, "16" à 255.255.0.0 et "24" à 255.255.255.0

Quand la commande s'exécute, il en résulte une sortie assez prolixe de deux ensembles de paramètres presque (mais pas tout à fait) identiques :



Je préfère ne pas alourdir mon texte avec une explication des paramètres "AddressState" et "PolicyStore" (les seuls des deux ensembles qui soient différents) mais le lecteur peut se renseigner en suivant ces liens :

New-NetIPAddress

Set-NetIPAddress

Remarque : les articles n'ont pas été traduits ("Ce contenu n’est pas disponible dans votre langue. Voici la version anglaise.").


Quoi qu'il en soit, nous pouvons observer le changement en exécutant à nouveau cette commande :

Get-NetIPAddress | ft




La valeur du paramètre "PrefixOrigin" n'est plus "DHCP" mais plutôt "Manual".



Il nous reste à configurer l'adresse du serveur DNS avec cette commande :

Set-DnsClientServerAddress "Ethernet" -ServerAddresses 10.4.1.12




Nous pouvons vérifier le résultat avec cette commande :

Get-DnsClientServerAddress -InterfaceAlias Ethernet




Quelques mots sur l'affichage des propriétés TCP/IP...

La commande "Get-NetIPAddress" fournit des détails sur la configuration qu'on pourrait juger surabondants (vous pouvez essayer vous-même). C'est l'affichage en liste ("format-list" ou "fl") par défaut. C'est pourquoi j'ai préféré "format-table" ou "ft".

Nous pouvons désigner l'interface soit par l'index ("InterfaceIndex" ou "ifIndex" selon les affichages), soit par son alias ("InterfaceAlias"). Nous pouvons aussi nous concentrer sur les addresses IPv4 (ou IPv6) avec le paramètre -AddressFamily. Nous pouvons donc afficher tous les paramètres (et valeurs) et simplement chercher ce que nous voulons là-dedans - ou produire un affichage plus concis avec les variations suivantes :



Cette commande aussi produit un affichage plus concis (et comprend les paramètres pour DNS et pour la passerelle par défaut - non encore configurés ici) :

Get-NetIPConfiguration




Quant à l'adaptateur réseau lui-même, cette commande en révèle les propriétés :

Get-NetAdapter



Avant de fermer cette parenthèse sur l'affichage des propriétés TCP/IP, je tiens à rappeler au lecteur que nous pouvons nous procurer des renseignements plus amples sur n'importe quel applet de commande PowerShell avec Get-Help (suivi de l'applet qui vous intéresse).



***


La configuration des paramètres TCP/IP achevée, je vais ajouter notre nouveau serveur au domaine et puis le promouvoir au contrôleur de domaine (à côté d'un contrôleur de domaine Windows 2008 R2 dans un domaine existant).

D'abord, nous ajoutons notre serveur au domaine avec cette commande :

Add-Computer -DomainName <nom de notre domaine>



Et c'est tout ! Nous verrons une requête pour des informations d'identification (celles d'un admin du domaine du domaine existant) et et un message nous invitant à faire redémarrer le serveur. A cet égard, nous avons l'option d'ajouter le paramètre -Restart pour que le serveur redémarre sans autre action de notre part.


La prochaine étape consiste à installer le rôle AD-Domain-Services avec la commande...

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools


Remarque : oui, la commande sert à installer les rôles aussi bien que les fonctionnalités (features). Le paramètre -IncludeManagementTools est important, car il assure l'installation des outils pour la gestion d'Active Directory, de DNS et des stratégies de groupe.



La promotion au rang de contrôleur de domaine se fait avec la commande suivante :

Install-ADDSDomainController -DomainName <nom du domaine>


Là aussi, c'est tout. Nous sommes seulement obligés de fournir un mot de passe pour le mode sans échec (en fait "mode de récupération des services d'annuaire" ou "DSRM") et de confirmer notre intention de promouvoir le serveur.

Nous verrons s'afficher beaucoup des mêmes informations qu'on voit dans l'interface graphique mais avec moins d'interactivité (nous n'avons pas besoin d'approuver ou d'accepter les choix). Par défaut, le nouveau contrôleur de domaine devient un catalogue global et un serveur DNS (si DNS est déjà intégré à Active Directory sur les contrôleurs existants).



Tout compte fait, cette méthode me semble plus directe et rapide que les multiples étapes de l'interface graphique.

***

Nous avons donc notre second contrôleur de domaine et le premier qui exécute Windows Server 2016. Je pourrais mettre fin à ce texte ici mais je tiens à présenter tout de même deux autres aspects : le transfert des rôles dits "FSMO" à notre nouveau contrôleur et le passage au niveau fonctionnel "Windows 2016" pour le domaine et la forêt.

D'abord, comment déterminer quel contrôleur de domaine tient les rôles FSMO ? Bien sûr, nous pourrions toujours faire appel à NETDOM :

netdom query fsmo

Cependant, il s'agit de présenter les applets de commande PowerShell.

En voici les commandes équivalentes :


Remarque : il ne semble pas y avoir une commande unique, comme "netdom query fsmo" pour tout afficher.


En revanche, et à la différence de NTDSUTIL, nous pouvons transférer tous les rôles avec une seule commande en une seule ligne :

Move-ADDirectoryServerOperationMasterRole DC1 S,D,I,R,P


Nous indiquons donc le serveur cible (DC1) et la première lettre de chacun des rôles. Puisque aucun rôle ne commence par la même lettre, aucune ambiguïté n'est à craindre et nous pouvons profiter de ce raccourci utile.


Quant aux niveaux fonctionnels, nous constatons le statu quo avec les commandes suivantes :

Get-ADDomain | fl DomainMode

Get-ADForest | fl ForestMode


Remarque : nous n'avons qu'un seul domaine et une seule forêt, ce qui écarte le risque de méprise pour les noms (que je ne précise pas).


Nous augmentons le niveau fonctionnel du domaine et de la forêt au niveau Windows 2016 avec ces commandes :

Set-ADDomainMode <nom du domaine> -DomainMode 7

Set-ADForestMode <nom de la forêt> -ForestMode 7


Ainsi, nous pouvons indiquer le niveau soit par le nom, soit par le numéro correspondant (si vous les savez). Par exemple :

Windows2016Domain = 7

Je m'en suis rapporté à ces documents, notamment pour la correspondance entre noms et numéros :

Set-ADDomainMode

Set-ADForestMode

Dans la capture d'écran ci-dessous, je me suis permis une approche différente en utilisant des variables pour désigner les noms de domaine et de forêt (mais nous pouvons certainement les nommer de façon explicite) : 



Je confirme le succès de l'opération avec les commandes déjà présentées plus haut :



Sunday, February 4, 2018

Active Directory - récupération de la forêt (FR) - 7 - suite et fin

English summary: after completing the steps in the previous blog posts of this series, I can begin to add domain controllers back into our forest. I will replace domain controller DC7 through a new installation. I then examine the status of the domain controllers (with repadmin for replication) and dcdiag (for overall health). 

***

A la suite des opérations présentées dans les articles précédents de cette série, nous en sommes maintenant au point où nous pouvons commencer à remplacer les contrôleurs de domaine non-restaurés de notre forêt (soit DC6 et DC7 dans notre scénario).

Remarque : nous aurions pu restaurer d'autres contrôleurs de domaine (en plus de DC5) mais il y a un risque : la dernière restauration écrase les données existantes en Active Directory. Si, par exemple, je restaure le contrôleur de domaine A tel jour, le contrôleur B le lendemain et le contrôleur C le surlendemain, c'est C qui gagne (en cas de conflit) et sa restauration écrase les données restaurées plus tôt. Cela pourrait ne pas être un problème mais il faut en être conscient.

Dans ce scénario, donc, je vais mettre sur pied de nouveaux serveurs et installer le rôle Services de domaine Active Directory ou "AD DS" en version originale (le rôle DNS et la fonctionnalité Gestion des stratégies de groupe s'ajoutent alors de façon automatique). La plupart des lecteurs ont sans doute déjà "promu" des contrôleurs de domaine avec ce qu'on appelait "dcpromo" mais je vais en montrer les étapes tout de même afin que ma présentation de l'ensemble du processus soit complète (et encore, je ne montre que la remise en place de DC7 - par une nouvelle installation. Pour DC6, il suffirait de répéter les mêmes actions).

D'abord, nous devons ajouter le rôle "AD DS". Dans le Gestionnaire du serveur, nous allons dans la section "Rôles" où nous cliquons sur "Ajouter des rôles" :




Si la page "Avant de commencer" s'affiche, vous pouvez la lire (si vous voulez) et cliquer sur "Suivant". A la prochaine page, nous cochons la case "Services de domaine Active Directory". Selon le système d'exploitation (Windows Server 2008 R2 dans mon cas), un message pourrait s'afficher et nous apprendre que d'autres éléments doivent s'ajouter en tant que pré-requis. Il faut donc choisir de les installer aussi :




Vous pouvez lire l'introduction à Active Directory puis cliquer sur "Suivant" jusqu'à ce que l'installation du rôle s'achève :










***


Le rôle est donc installé. Encore faut-il promouvoir notre serveur à un contrôleur de domaine. Pour cela, il suffit de cliquer sur le lien désigné par le point rouge dans la capture d'écran ci-dessous :





Au fond, il s'agit de cliquer sur "Suivant", faisant les choix qui conviennent à notre environnement et, le cas échéant,  fournissant les données sollicitées :






Comme nous avons déjà restauré un contrôleur de domaine, notre environnement compte un domaine existant. Nous voulons maintenant ajouter d'autres contrôleurs de domaine (par nouvelle installation). Il s'agit donc de choisir l'option pour une forêt / un domaine existant :




Le nom du domaine devrait s'afficher et si nous sommes en session avec des informations d'identification d'administrateur de domaine, nous pouvons nous servir des mêmes pour passer à la prochaine étape :




Puis, nous sélectionnons un domaine (un seul existe dans mon scénario) et un site (là encore, le choix est facile) : 







De nos jours, la meilleure pratique (dans une forêt à un seul domaine) consiste à faire de tous nos contrôleurs des serveurs DNS et des catalogues globaux : 




Dans mon cadre (et peut-être dans d'autres), nous pouvons ne pas tenir compte de ce message :




Nous garderons l'emplacement par défaut de la base de données NTDS, des fichiers journaux, et du dossier SYSVOL : 




Il faut fournir un mot de passe pour le mode DSRM (mode restauration des services d'annuaire) :




Un résumé des sélections s'affiche (j'ai déroulé le texte pour que tout soit visible, d'où un apparent doublon des captures d'écran) :





L'Assistant effectue la configuration :




A la fin, il suffit de cliquer sur "Terminer"...




Et de faire redémarrer le serveur :




***


Le bilan

Selon l'outil repadmin, la réplication entre les deux contrôleurs de domaine réussit sans erreurs :




La commande dans la seconde capture d'écran a été exécutée sur DC5 mais le résultat est pareil sur DC7.


L'analyse de dcdiag est plus complexe. Après un démarrage, cet outil fait souvent état d'une multitude d'avertissements et d'erreurs dans l'Observateur d'événements, dont la plupart tiennent au décalage dans le démarrage de certains services spécifiques (DNS ou DFSR par exemple). En effet, certains services font appel à d'autres services et si ceux-ci ne sont pas encore disponibles, ceux-là doivent attendre avant de pouvoir fonctionner correctement. Il en résulte donc des avertissements et des erreurs qui cessent de s'afficher dès que tout se met en marche et qui cessent, après un moment, de se voir dans la sortie de dcdiag. Je me garde donc bien de reproduire ici la longue liste de tous les avertissements qui se retrouvent dans la sortie de dcdiag et m'en tiens à ceux qui ont nécessité une action de ma part.

Au contrôleur DC7, dcdiag fait état de cet avertissement:


Remarque : vous pouvez cliquer sur l'image pour l'agrandir.


Cela s'explique par le fait que j'ai créé un compte ordinateur pour DC7 avant de le joindre au domaine (et de le promouvoir contrôleur). Il suffit de mettre la valeur juste dans ADSIEdit :




Pour de plus amples renseignements, rapportez-vous à cet article :



Quant à DC5, l'avertissement suivant a retenu mon attention dans la mesure où il ne s'est pas effacé après une heure ou deux (ce qui est parfois le cas avec d'autres avertissements) :




J'accomplis trois actions pour vérifier que tout va bien, malgré cet avertissement.

D'abord, je repère l'avertissement dans le journal DFSR de l'Observateur d'événements :



Le service de réplication DFS de DC5 n'a pas pu établir la communication avec DC7. Cependant, l'entrée suivante indique que cette défaillance n'a été que passagère dans la mesure où la communication a fini par se faire :



En deuxième lieu, j'exécute la commande net share et constate que le répertoire SYSVOL existe là où il faut :




En troisième lieu, je crée un fichier texte d'essai dans le répertoire "scripts" de DC5 et vérifie qu'il se retrouve bien au même endroit sur DC7 :


Remarque : faites attention au chemin visible dans la capture d'écran. Vous pouvez supprimer le fichier ensuite. Il s'agit simplement de s'assurer que les objets dans SYSVOL sont répliqués d'un contrôleur de domaine aux autres.


***

C'est la première fois que j'ai essayé de récupérer une forêt Active Directory en me fondant sur le guide officiel de Microsoft à ce sujet. J'ai beaucoup appris et crois que je serais mieux à même de réussir l'opération si jamais je devais la faire pour de vrai. Pourtant, je prends note de plusieurs limites de mon expérience :

  • Mon scénario se bornait à la récupération d'une forêt à un seul domaine. C'est un scénario valable. Beaucoup de forêts comptent effectivement un seul domaine et c'est la topologie préférée selon Microsoft. Mais je serais obligé de gérer plus de complexité dans un environnement à plusieurs domaines.
  • Mon scénario ne nécessitait pas vraiment l'isolement du contrôleur de domaine à restaurer et j'ai donc pu restaurer à partir d'un fichier de sauvegarde dans un dossier partagé.
  • Mon réseau d'essai ne comprenait que les trois contrôleurs de domaine. J'ai tenté (avec succès) d'ajouter un client Windows 7 au domaine après la restauration mais j'aurais dû l'y ajouter d'emblée pour vérifier la connectivité au cours des différentes étapes.