Wednesday, February 28, 2018

Exchange 2016 CU8 - Server 2016 (FR) - some changes / quelques changements

English summary: Exchange 2016 CU8 was released on December 19, 2017. As of this writing, it is the most recent version of Exchange 2016 and includes the following notable changes:
  • Support for .NET Framework 4.7.1. Apparently, this version of .NET will be required with CU9.
  • Minimal Forest Functional Level (FFL) is Windows 2008 R2. It already was with CU7 but is now verified and enforced at installation.
  • Coexistence with Exchange 2010 SP3 now requires RU19 (for Exchange 2010).
I had not taken a look at Exchange 2016 since CU5 and have never installed it on Windows Server 2016. I'll try that in this blog post and present updated pre-requisites for installation on this OS. Note: I also use Windows Server 2016 for my domain controller in this new test environment.


***


Exchange 2016 CU8 sur Windows Server 2016

Au moment où j'écris cet article, CU8 est la mise à jour cumulative la plus récente pour Exchange 2016. A la lecture de l'annonce de sa mise en disponibilité au public, je remarque quelques changements récents - et à venir - concernant les exigences logicielles.

Exchange 2016 CU8 Released

  • .NET Framework 4.7.1 est pris en charge et sera même obligatoire pour la mise à jour cumulative de juin 2018 (CU9). A en croire Rhoderick Milne (voir le hyperlien ci-dessus), .NET 4.7 n'est pas pris en charge. 
  • Le niveau fonctionnel de la forêt (FFL) minimal pour Exchange 2016 (voire depuis CU7) est Windows 2008 R2. Il faut donc retirer du service les éventuels contrôleurs de domaine Windows 2008 restants avant de passer à CU8. C'est désormais obligatoire. Le programme d'installation échouerait dans le cas contraire (je ne l'ai pas essayé moi-même mais la source (toujours M. Milne) est digne de confiance.
  • En cas de coexistence avec Exchange 2010 SP3, il faut installer RU19 pour résoudre un problème de proxy (l'annonce ne fournit aucun autre détail).

Je constate que même en version originale anglaise, la documentation sur les exigences logicielles n'a pas encore été mise à jour (FFL toujours 2008, RU11 pour Exchange 2010 SP3 plutôt que RU19) :

Exchange 2016 system requirements

J'avais acquis une certaine expérience avec Exchange 2016 CU5 installé sur Windows 2012 R2 (en ce moment, les seuls systèmes d'exploitation pris en charge sont Server 2012, 2012 R2 et 2016). Je veux profiter de la sortie de CU8 pour bâtir un nouveau réseau d'essai avec un contrôleur de domaine Windows Server 2016 et un serveur avec le même SE (OS) pour Exchange 2016. Rien que du 2016 donc. La dernière fois, j'ai ajouté un second serveur Exchange pour expérimenter avec les DAG et même un Citrix NetScaler VPX pour la répartition de la charge. Je ne sais pas si je referai tout cela. A priori, les différences entre 2012 R2 et 2016, et celles entre CU5 et CU8, ne sont pas assez significatives (loin s'en faut) pour justifier que je refasse toutes mes expériences de l'an passé.

En fait, je compte aller assez vite pour simplement voir ce qu'il y a de nouveau.



Les étapes à suivre


1. Installer .NET 4.7.1

Il s'agit d'abord de préparer Active Directory pour Exchange 2016 CU8 et pour cela, nous avons besoin de .NET (4.7.1). Si nous le mettons sur le serveur où nous installerons Exchange plus tard (comme je le fais ici), nous aurons l'avantage d'avoir .NET déjà en place (c'est aussi un des pré-requis pour Exchange).


Nous exécutons le fichier téléchargé et suivons les étapes de l'installation :



Remarque : CU8 n'apporte pas de changements par rapport à CU7 mais éventuellement par rapport aux mises à jour antérieures). 

---

Et Windows Management Framework (pour PowerShell) ? Désormais (si j'ai bien compris), nous utilisons la version intégrée au système d'exploitation (SE). Nous ne devons pas installer de version de WMF téléchargée séparément. En tout cas, avec Windows Server 2016, nous n'avons besoin de rien faire de plus à cet égard.

Astuce : nous pouvons vérifier la version de PowerShell avec cette commande :






2. Install-WindowsFeature RSAT-ADDS

Nous exécutons cette commande afin de pouvoir agir sur Active Directory à l'étape suivante :

Install-WindowsFeature RSAT-ADDS






3. Préparer Active Directory pour CU8

Nous devons exécuter les commandes suivantes :

setup /PrepareSchema /IAcceptExchangeServerLicenseTerms


setup /PrepareAD /IAcceptExchangeServerLicenseTerms



Pour ceux qui n'ont pas l'habitude de ce genre de préparation, je devrais tout de même préciser qu'il s'agit de télécharger Exchange 2016 CU8 (désormais sous forme d'un fichier .iso), de monter ce fichier et de naviguer (à la ligne de commande) jusqu'à "setup.exe". Ensuite, on exécute les commandes présentées ci-haut avec les paramètres en question.

Si tout va bien, vous devriez voir s'afficher un message selon lequel "l'installation s'est terminée correctement".




4. Installer certaines composantes Windows

A la ligne de commande PowerShell, nous exécutons la commande suivante :

Install-WindowsFeature NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

Remarque : RSAT-ADDS est peut-être déjà installé. Dans ce cas, nous pourrions enlever RSAT-ADDS de la liste (ou le laisser - c'est sans importance).



---

Attention : si nous n'avions pas installé .NET 4.7.1 plus tôt (pour la préparation du schéma et du domaine, il faudrait l'installer à cette étape).

---


5. Installer UCMA 4.0 (Unified Communications Managed API)

Unified Communications Managed API 4.0 Runtime

Il suffit de télécharger le fichier au lien ci-dessus et de l'exécuter, suivant les étapes du processus d'installation (je ne fournis pas une capture d'écran pour chaque étape) :





Installation d'Exchange 2016 CU8

Nous pouvons utiliser l'interface graphique ou la ligne de commande. Je choisis cette seconde option. La commande est simple et concise :

setup /M:Install /R:Mailbox /IAcceptExchangeServerLicenseTerms



  • M = Mode (nous pouvons mettre l'un ou l'autre)
  • R = Rôle (c'est pareil)

Les commandes sont insensibles à la casse (minuscules ou majuscules, peu importe)


Si tout va bien, nous devrions voir ceci à la fin :



***

Je fais donc redémarrer le serveur après quoi je me connecte et ouvre l'EMS (Exchange Management Shell) sans problème. Par contre, je n'ai pas pu ouvrir l'EAC (Exchange Admin Console / Console d'Administration Exchange), me retrouvant face à différents messages d'erreur. J'ai surmonté un premier obstacle en installant un certificat tiers (du genre Comodo, Digicert ou Verisign ). Cela peut se faire à la ligne de commande (ou même avec la console "Certificats - magasin de l'ordinateur) si l'EAC n'est pas accessible. Je ne me heurte plus alors à la "page introuvable" mais plutôt à une page blanche, quelque chose que je n'ai jamais observé avec les mises à jour cumulatives précédentes. Quoi qu'il en soit, je ne traiterai pas de la résolution de ce problème-là ici.

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.