Mise à jour de votre contrôleur de domaine vers Windows Server 2012 (in-place upgrade)

Sommaire

 

 

Introduction

L’article présente les différentes étapes pour mener à bien la mise à jour de vos contrôleurs de domaine vers Windows Server 2012.

 


Prérequis et limitations

La mise à jour de vos contrôleurs de domaine va dépendre d’un ensemble de limitations et de contraintes que nous vous listons ci-dessous.

  • Version des systèmes d’exploitation : seuls les systèmes d’exploitation en version Windows Server 2008 x64 ou 2008 R2 sont supportés. De manière générale, les versions 32-bit ne sont pas supportées (pas de migration possible avec une version Windows 2008 32-bit).
  • Edition des systèmes d’exploitation : le choix de l’édition va dépendre bien entendu de celle du système d’exploitation existant. Ci-dessous, vous avez le tableau listant les possibilités en fonction de votre système d’exploitation existant (source Microsoft http://technet.microsoft.com/fr-fr/library/jj574204.aspx):

Système d’exploitation existant

Edition(s) compatible(s)

Windows Server 2008 Standard with SP2 or Windows Server 2008 Enterprise with SP2

Windows Server 2012 Standard, Windows Server 2012 Datacenter

Windows Server 2008 Datacenter with SP2

Windows Server 2012 Datacenter

Windows Web Server 2008

Windows Server 2012 Standard

Windows Server 2008 R2 Standard with SP1 or Windows Server 2008 R2 Entreprise with SP1

Windows Server 2012 Standard, Windows Server 2012 Datacenter

Windows Server 2008 R2 Datacenter with SP1

Windows Server 2012 Datacenter

Windows Web Server 2008 R2

Windows Server 2012 Standard


  • Compatibilité des applications : nous partons également du principe que vos contrôleurs de domaine n’hébergent pas d’applications spécifiques et ne remplissent que le rôle de contrôleur de domaine. Si cela n’est pas le cas, il faudra s’assurer de la compatibilité des applications tierces hébergées sur vos contrôleurs de domaine auprès des différents éditeurs. Pour la compatibilité des applications Microsoft vous pouvez consulter le lien http://technet.microsoft.com/en-us/library/hh994618.aspx#BKMK_AppCompat.
  • Espace disque : vous devez disposer d’un espace disque libre sur la partition stockant le fichier NTDS.DIT d’au moins égale à 20% de la taille totale du fichier NTDS.DIT (il est possible de réduire la taille de la base en passant par une défragmentation hors-ligne).
  • Niveau fonctionnel de la forêt : L’intégration d’un contrôleur de domaine sous Windows Server 2012 nécessite un niveau fonctionnel de forêt Windows Server 2003 ou supérieur.
  • Mode Core : au moment où l’article est rédigé, la mise à niveau d’un Windows Server 2008 en mode Core n’est pas supportée suite à des problèmes connus de compatibilité. Il est toutefois possible que dans un futur proche le problème soit corrigé.
  • Langue :il est impératif que langue du support d’installation soit identique à la langue du système d’exploitation à mettre à jour.

 

 

Préparation du schéma Active Directory

Si vous vous apprêtez à faire l’intégration du premier contrôleur de domaine sous Windows Server 2012, il faudra au préalable mettre à jour le schéma de la forêt et du domaine Active Directory.

Pour cela, il est préférable de réaliser l’opération de mise à directement sur le contrôleur de domaine « maître de schéma ». Pour l’identifier vous pouvez utiliser la commande « netdom query /domain:[MONDOMAINE] fsmo ».

Remarque : La version 32-bit d’ADPREP (ADPREP32) n’existant plus, il faut impérativement que votre maitre de schéma soit hébergé sous une version 64-bit. Vous pouvez déplacer le maitre d’opération si nécessaire et de façon temporaire.

Une fois connecté sur le maître de schéma, insérez votre support d’installation de Windows Server  2012 et lancer la commande suivante : « X:\support\adprep\adprep .exe /forestprep » (X: étant la lettre de votre lecteur DVD).

{gallery}55_INPLACEUPGRADE2012/01{/gallery}

 

 

 

 

 

Il faut relancer ensuite la commande pour préparer, cette fois-ci, le schéma du domaine. La commande reste identique mais avec un commutateur différent : X:\support\adprep\adprep .exe /domainprep

{gallery}55_INPLACEUPGRADE2012/02{/gallery}

 

 

 

 


 

 

Mise à niveau

Les vérifications faites, les prérequis respectés et le schéma Active Directory mis à jour, il ne reste plus qu’à mettre à jour le contrôleur de domaine.

Pour démarrer le processus, vous devez lancer le « setup.exe » du support d’installation.

{gallery}55_INPLACEUPGRADE2012/03{/gallery}

 

 

 

 

 

 

 


Vous avez la possibilité de récupérer automatiquement les dernières mises à jour relatives à l’installation de Windows Server 2012. L’opération est recommandée.

{gallery}55_INPLACEUPGRADE2012/04{/gallery}

 

 

 

 

 

 


Une fois la clé de produit entrée, vous allez devoir sélectionner le mode d’installation. Plus précisément, vous aurez le choix entre le mode Core ou GUI. Sachant que vous ne pouvez pas mettre à jour une version Core, nous choisirons la version GUI.

{gallery}55_INPLACEUPGRADE2012/05{/gallery}

 

 

 

 

 

 


Dans le contexte actuel, nous allons choisir le type d’installation « Upgrade : Install Windows and keep files, settings, and applications ».

{gallery}55_INPLACEUPGRADE2012/06{/gallery}

 

 

 

 

 

 


L’assistant d’installation génére également une rapport de comptabilité disponible directement depuis votre bureau et listant les applications non compatibles avec Windows Server 2012.

{gallery}55_INPLACEUPGRADE2012/07{/gallery}

 

 

 

 

 

 


La mise à jour vers Windows Server 2012 débute…

{gallery}55_INPLACEUPGRADE2012/08{/gallery}

 

 

 

 

 

 


… Mais en cas de soucis le retour-arrière est automatique !

{gallery}55_INPLACEUPGRADE2012/09{/gallery}

 

 

 

 

 

Vérifications

La montée de version est terminée mais si vous le désirez, vous pouvez faire quelques vérifications.

A titre d’exemple, vous pouvez vérifier l’état de santé du contrôleur de domaine à l’aide de la commande « DCDIAG ».

{gallery}55_INPLACEUPGRADE2012/10{/gallery}

 

 

 

 

 

Vous pouvez également utiliser le « Best pratices analyzer » du rôle AD DS depuis la console « Server Manager ».

{gallery}55_INPLACEUPGRADE2012/11{/gallery}

 

 

 

 

 

 


Enfin, vous pouvez également vérifier l’état des réplications à l’aide de la commande « repadmin /showrepl ».

{gallery}55_INPLACEUPGRADE2012/12{/gallery}

 

 

 

 

 

 


Gérez vos serveurs 2008 à distance avec la console « Server Manager » de Windows Server 2012

La console « Server Manager » de Windows Server 2012 nous permet de gérer plusieurs serveurs et, entre autres, des serveurs sous Windows  Server 2008 / 2008 R2 (même Windows Server 2003 mais de manière toutefois nettement plus limitée).

Pour cela, il va être nécessaire d’installer certaines mises à jour :

  1. Le .Net Framework 4
  2. Le Windows Management Framework 3.0 (intègrant entre autres PowerShell V3, Windows « PowerShell Web Service » et surtout le « Server Manager CIM Provider »)
  3. Le hotfix disponible depuis http://go.microsoft.com/fwlink/p/?LinkID=245487 pour corriger certains problèmes relatifs à la collecte des données des compteurs de performances.

Remarque: Le Windows Management Framework 3.0 n’est pour l’instant disponible qu’en version anglaise (version Release Candidate). Lors de nos tests, il n’a pas été possible de l’installer sur une version de Windows Server 2008 R2 en version française.

Une fois les prérequis ci-dessus respectés, il suffit d’ajouter vos serveurs à la console « Server Manager » de Windows Server 2012. Pour cela, il faut se rendre dans « Manage | Add Servers » et rechercher les serveurs à ajouter en fonction des critères désirés.

{gallery}48_SRVMAN_2012/01{/gallery}

 

 

 

 

 

 

Dans l’exemple ci-dessous, nous avons ajouté le serveur « DC03 »  dont le système d’exploitation est Windows Server 2008 R2. Nous avons toutefois rencontré un problème de communication. Cela est dû au fait qu’il est nécessaire d’activer Windows Remote Management (WinRM) sur chaque serveur à gérer. Vous pouvez le configurer de manière basique mais rapide à l’aide de la commande « winrm qc » depuis une invite de commandes ou une console PowerShell.

{gallery}48_SRVMAN_2012/02{/gallery}

 

 

 

 

 

 

Le serveur sous Windows 2008 R2 est désormais gérable depuis la console « Server Manager ». Vous pouvez commencer par lancer les collectes à l’aide des Best Pratices Analyzer depuis « All Servers » ou pour chacun des rôles présents (exemple : DNS / AD DS / IIS…).

{gallery}48_SRVMAN_2012/03{/gallery}

 

 

 

 

 

 

 

Si vous désirez plus de détails sur BPA vous pouvez consulter l’article Technet Run Best Practices Analyzer Scans and Manage Scan Results.

Dynamic Access Control : Part 1 – Présentation

Sommaire

 

 

Introduction

Le présent article va nous permettre d’introduire la nouvelle solution de gouvernance des données (dossiers ou fichiers) de Microsoft introduite avec Windows Server 2012. L’article s’appuie exclusivement sur la documentation officielle de Microsoft:

 

 

Qu’est-ce que le “Dynamic Access Control”?

« Dynamic Access Control »  (DAC) est une solution de gouvernance des données ou plus simplement un ensemble de fonctionnalités nous permettant d’organiser, gérer, distribuer et sécuriser les dossiers et fichiers au sein de notre infrastructure. L’enjeu principal ? Pouvoir gérer le cycle de vie et l’intégrité de l’information au sein d’une organisation.

Avec « Dynamic Access Control », on retrouve les 4 principaux points d’une solution de gouvernance de données:

  • L’Identification : à l’aide de la classification des données de manière automatique ou manuelle (File Classification Infrastructure).
  • La gestion et la distribution : en définissant des politiques d’accès centralisées au niveau de l’entreprise et provisionnant automatiquement les accès.
  • La sécurisation : en améliorant la pertinence des  journaux d’audits et en permettant l’encryptage automatique des données sensibles de l’entreprise.

 

Les composants de « Dynamic Access Control »

« Dynamic Access Control » n’est pas une fonctionnalité à proprement parlé mais un regroupement d’améliorations et de nouveautés introduites avec Windows Server 2012. Nous retrouvons entre autres :

  • Active Directory : pour la gestion centralisée des règles d’accès, des propriétés de ressources et des revendications utilisateurs.
  • Kerberos : pour le support des nouvelles revendications d’accès.
  • File Server : pour autoriser les accès s’appuyant sur les nouvelles autorisations d’accès et les nouveaux types de revendication.
  • File Server Ressources Manager : pour classifier les données automatiquement et assurer une meilleure gestion des serveurs de fichiers.

En surface, le fonctionnement est assez simple. Vous devez disposer d’au moins  un contrôleur de domaine sous Windows Server 2012 qui va vous permettre dans un premier temps de déclarer toutes les propriétés de ressources possibles au sein de votre organisation. Elles seront ensuite automatiquement mises à la disposition de vos serveurs de fichiers, eux-mêmes impérativement sous Windows Server 2012. Ces propriétés de ressources seront exploitées sur ces serveurs de fichiers pour la classification de vos données.

Toujours depuis un contrôleur de domaine, vous allez ensuite définir que, désormais, certains attributs utilisateurs vont être exploités pour l’attribution d’autorisation. En clair, nous pouvons par exemple faire en sorte que l’attribut « Country » de nos objets utilisateurs au sein de l’annuaire Active Directory soit exploité pour réaliser du contrôle d’accès. Lorsque l’utilisateur s’authentifiera, son ticket Kerberos sera constitué désormais de cette nouvelle revendication.

Enfin, nous poussons des règles d’accès sur nos serveurs de fichiers, à base d’expressions conditionnelles mettant en relation les propriétés de ressources et les nouvelles revendications utilisateur.

Lorsque l’utilisateur tente d’accéder à une donnée sur le serveur de fichiers, ce dernier va autoriser ou non l’accès aux données en fonction des propriétés de la ressource, des revendications de l’utilisateur et surtout selon les règles d’accès définies.

{gallery}44_DAC-1/01{/gallery}

 

 

 

 

 

 

 

 

Remarque : Nous verrons de manière plus approfondie les prérequis du « Dynamic Access Control » dans un article dédié.

 

 


Un exemple de contrôle d’accès

Le type de contrôle d’accès introduit par DAC en est, bien entendu, la clé de voute. Elle démultiplie les possibilités dans ce sens et en simplifie grandement la gestion. Cela essentiellement par l’identification des ressources, l’extension des revendications utilisateurs et la gestion centralisée.

Prenons le cas concret suivant :

  1. Vous disposez de deux comptes utilisateurs Active Directory qui ont les attributs Active Directory « Country » et « Department » renseignés.  D’un autre côté, vous disposez également de deux dossiers qui ont été classifiés à l’aide de  propriétés.
  2. Vous créez une règle d’accès spécifiant que les attributs  « Country » et  « Department » de l’utilisateur doit correspondre aux propriétés désirées de chaque dossier.
  3. Le serveur de fichiers vérifie à chaque tentative d’accès que les revendications utilisateurs (attributs AD) correspondent avec les règles d’accès.

{gallery}44_DAC-1/02{/gallery}

 

 

 

 

 

 

Nous voyons donc que, d’après le schéma ci-dessus, l’utilisateur « Sophie » accède au dossier  « Marketing » car la demande respecte la règle d’accès. Cela n’est pas le cas  avec le dossier « Finance ». La propriété de ressources « Department » ne correspond pas à l’attribut « Department » de l’utilisateur.

Dans cet exemple, nous retrouvons donc :

  • La classification des données à l’aide de propriétés personnalisées.
  • L’extension des revendications utilisateurs qui ne s’appuient plus exclusivement sur son identifiant de sécurité ou sur son appartenance à des groupes de sécurité.
  • Des règles d’accès mettant en relation les propriétés des données avec les revendications utilisateurs.

Bien entendu, ceci n’est qu’un bref aperçu mais vous vous en rendrez compte tout au long de nos articles traitant le sujet que le point fort de Dynamic Access Control est la mise en corrélation dynamique des données et des utilisateurs en améliorant les moyens de les identifier.

 

 


Pourquoi se tourner vers « Dynamic Access Control » ?

Le « Dymanic Access Control » représente tout simplement l’opportunité tant espérée de pousser vers la sortie la méthode AGDLP.

Pour bref rappel, la méthode AGDLP est une bonne pratique Microsoft pour la gestion des accès aux données de l’entreprise et pour la mise en place d’un contrôle d’accès sur rôle (RBAC). La méthode passe exclusivement par la nidification de groupes Active Directory. Elle se définie simplement de la manière suivante : les comptes utilisateurs ou ordinateurs (Account) sont rattachés à des groupes globaux (Global)  représentatifs de la structure organisationnelle de l’entreprise et qui seront intégrés eux-mêmes à des groupes de domaine local (Domain Local)  définissant les permissions (Permissions)  à une ressource.

Malheureusement AGDLP n’est qu’une méthode qui s’appuie sur un modèle très rigide et qui peut s’avérer extrêmement complexe à gérer. De plus, elle ne peut pas garantir l’intégrité des informations de l’entreprise.

Grâce à « Dynamic Access Control » Nous allons désormais pouvoir :

  • Limiter l’usage de groupes en s’appuyant un  contrôle d’accès dit « claim-based » et étendre les possibilités.
  • S’affranchir des contraintes techniques et coller au mieux aux besoins métiers grâce à aux expressions conditionnelles.
  • Garantir une politique d’accès à l’information au niveau de l’entreprise.

 

Conclusion

Dans ce premier article sur « Dymanic Access Control », nous avons pu survoler les nouveautés introduites. L’objectif étant par la suite de s’intéresser spécifiquement à chacun des composants le constituant.

Les nouveautés apportées au centre d’administration Active Directory (ADAC)

Sommaire

 

 

Introduction

Dans notre article Le centre d’administration Active Directory (ADAC) nous vous avons présenté cette toute dernière console pour la gestion des objets utilisateurs et ordinateurs Active Directory. Fraichement sortie sous Windows 2008 R2, elle ne pouvait qu’évoluer sous Windows Server « 8 » et pousser encore un peu plus vers la sortie la fameuse mais non moins vieillissante console  « Utilisateur et ordinateurs Active Directory ».

Nous vous proposons donc, dans ce court mais non moins intéressant article, de découvrir ses améliorations.

 

 

La gestion de la corbeille Active Directory

La console intègre désormais la gestion de la corbeille Active Directory pour faciliter la restauration d’objets et évite de passer par du PowerShell. Bien entendu, il faut au préalable que vous ayez déjà la possibilité d’activer la fonctionnalité en disposant d’un niveau fonctionnel de domaine suffisant (Article Technet : Enable Active Directory Recycle Bin).

Passé cette contrainte, vous pouvez l’activer directement depuis la console à l’aide d’un clic droit sur la racine du domaine et en sélection « Enable recycle bin… ».

{gallery}43_ADAC_8/01{/gallery}

 

 

 

 

 

 

 

Dès lors, la restauration d’un objet se limite donc à se rendre directement dans le conteneur « Deleted Objects », de sélectionner le(s) objet(s) à restaurer à l’aide d’un clic droit et de cliquer sur l’option « Restore » ou « Restore To… ».

{gallery}43_ADAC_8/02{/gallery}

 

 

 

 

 

 

 

 

 

La gestion des stratégies de mot passe granulaires

Depuis son introduction sur Windows 2008, la création de nouvelles stratégies de mot de passe était jusqu’à présent une opération complexe ou du moins manquant de convivialité. En effet, il était nécessaire de créer un nouvel objet PSO (Password Settings Objects) pour chaque nouvelle stratégie de mot de passe depuis ADSIEdit. Avec la version de ADAC sur Windows Server « 8 », vous créez une stratégie de mot de passe aussi simplement que pour la création d’un compte utilisateur.

Les Objets de paramètres de mot de passe sont stockés dans le conteneur « [MONDOMAINE] » | « System » | « Password Settings Container ». Pour y accéder plus simplement, nous allons créer au préalable un lien depuis la racine du domaine grâce à la fonctionnalité de gestion des nœuds de navigation sous ADAC. Pour cela, il suffit de réaliser un clic droit sur le conteneur « Password Settings Container » et de sélectionner l’option « Add as navigation node ».

{gallery}43_ADAC_8/03{/gallery}

 

 

 

 

 

 

 

Pour créer un nouveau PSO, faites un clic droit sur le conteneur et choisissez « New » | « Password Settings ». Il ne reste plus qu’à spécifier les paramètres de votre nouvelle stratégie de mot de passe !

{gallery}43_ADAC_8/04{/gallery}

 

 

 

 

 

 

 

 

 

La gestion des objets relatifs au « Dynamic Access Control »

Sans entrer dans le détail sur cette nouvelle solution de gouvernance de données de Microsoft et qui va nécessiter quelques articles sur le sujet… sachez toutefois qu’il est possible de gérer les objets Active Directory relatifs au Dynamic Access Control directement depuis ADAC. Vous pourrez créer vos propriétés de ressources, vos types de revendication et vos règles d’accès de manière simple grâce à elle.

{gallery}43_ADAC_8/05{/gallery}

 

 

 

 

 

 

 

 

Visionner l’historique des commandes exécutées en PowerShell

Si vous avez déjà consulté notre précédent article sur le sujet, vous avez appris que la console ADAC utilise des commandes PowerShell pour communiquer avec les contrôleurs de domaine. Désormais, il est possible de visualiser directement les commandes PowerShell exécutées en arrière-plan lorsque vous réalisez des actions dans ADAC. La volonté de Microsoft étant de vous permettre de vous familiariser avec les cmdlets Active Directory et avec PowerShell d’une manière générale.

{gallery}43_ADAC_8/06{/gallery}

 

 

 

 

 

 

 

 

Conclusion

Certes ces nouveautés ne se sont pas une révolution mais on peut espérer qu’elles vont pousser définitivement vers la sortie « Utilisateurs et ordinateurs Active Directory » et surtout que les éditeurs proposant des plugins vous s’adapter également…

Déploiement centralisé et à distance de AD DS sous Windows Server 8 Beta

Sommaire

 

 

Introduction

L’arrivée prochaine de Windows Server 8 et sa sortie en version Beta depuis fin février 2012, nous permet de découvrir les futures nouveautés apporter au nouveau système d’exploitation dans sa version serveur.  Une des belles nouveautés est l’amélioration de la console « Server Manager » qui permet désormais d’administrer de manière centralisée plusieurs serveurs. Le déploiement de AD DS en est un bel exemple.

Nous allons donc découvrir ensemble ce qu’est devenu la console « Server Manager » et le déploiement d’Active Directory sur Windows Server 8 Beta.

Les exemples présentés dans notre article s’appuient sur deux machines disposant de Windows 8 Server Beta  et nommées « DC » et « SERVER1 ». La machine « DC » est contrôleur de domaine et la machine « SERVER1 » est un serveur membre. Nous réalisons toutes les opérations directement depuis la console « Server Manager » de la machine « DC ».

 

 

Ajouter la machine à gérer dans la console « Server Manager »

Nous débutons donc notre présentation en démarrant la console « Server Manager » depuis la machine « DC ».

Dans un premier temps  et afin de pouvoir gérer plusieurs machines depuis la console « Server Manager », il est nécessaire de déclarer ces dites machines. De ce fait, depuis la console « Server Manager », il faut se rendre dans le menu « Manage » depuis la barre d’outils et sélectionner l’option « Add Servers ». La fenêtre « Add Servers » est dotée de fonctionnalités de recherche afin de mettre la main sur les différentes machines à gérer. Nous allons simplement rechercher la machine « SERVER1 » depuis l’onglet « Active Directory » et l’ajouter à notre sélection.

{gallery}42_DEPLOY_ADDS_8/01{/gallery}

 

 

 

 

 

 

 

Une fois le ou les serveurs ajoutés, nous vérifions depuis « All Servers » que l’ajout a bien été pris en compte.

{gallery}42_DEPLOY_ADDS_8/02{/gallery}

 

 

 

 

 

 

 

 

Déploiement à distance du rôle

Maintenant que la machine à gérer est déclarée depuis la console « Server Manager » de la machine « DC », nous allons pouvoir l’administrer et plus particulièrement déployer le rôle « Active Directory Domain Services ». Pour cela, nous allons nous rendre une nouvelle fois dans le menu « Manage » et sélectionner l’option « Add Roles and Features ».

{gallery}42_DEPLOY_ADDS_8/03{/gallery}

 

 

 

 

 

 

 

L’assistant « Add Roles and Features » n’est pas bien différent de celui déjà présent sous Windows Server 2008. La grosse différence se situe à l’étape « Server Selection » où nous allons sélectionner la machine sur laquelle nous désirons intervenir. Notez également qu’il est possible d’agir directement depuis un VHD!

{gallery}42_DEPLOY_ADDS_8/04{/gallery}

 

 

 

 

 

 

 

Le processus reste encore tout à fait similaire à Windows Server 2008. Nous sélectionnons le(s) rôle(s) et/ou le(s) fonctionnalité(s) désirée(s) et nous la validons. En l’occurrence, nous allons choisir le rôle « Active Directory Domain Services ».

{gallery}42_DEPLOY_ADDS_8/05{/gallery}

 

 

 

 

 

 

 

 

 

Il est possible de forcer le redémarrage du serveur de destination si nécessaire à l’aide de l’option « Restart the destination server automatically if required ». Cela n’est toutefois pas nécessaire pour l’installation du rôle « Active Directory Domain Services ».

{gallery}42_DEPLOY_ADDS_8/06{/gallery}

 

 

 

 

 

 

 

Une fois l’installation débutée, notez que vous pouvez d’ores et déjà fermer l’assistant. En effet, vous pouvez à tout moment suivre son cours depuis la console centrale « Server Manager » et en cliquant sur le petit drapeau représentant la zone de notifications (en rouge dans notre exemple). Vous pouvez également rouvrir l’assistant en cliquant sur « Task Details » et voir plus en détail sa progression.

{gallery}42_DEPLOY_ADDS_8/07{/gallery}

 

 

 

 

 

 

 

 

 

Promotion du contrôleur de domaine supplémentaire

Maintenant que le rôle « Active Directory Domain Services » est installé sur la machine « SERVER1 », nous allons pouvoir procéder à la promotion de la machine en tant que contrôleur de domaine supplémentaire. Jusque-là, le processus est similaire à Windows Server 2008 où nous devions exécuter « dcpromo.exe ». Cependant, et fait majeur dans Windows Server 8, DCPROMO a disparu! La promotion d’un contrôleur de domaine se réalise désormais directement depuis la console « Server Manager ».

Pour cela, nous pouvons procéder de plusieurs manières. Nous pouvons soit nous rendre directement dans la zone « AD DS » depuis le menu situé sur la gauche de la console « Server Manager », soit depuis la zone de notifications. Nous optons pour cette dernière. Cliquez sur la zone de notifications symbolisée par le petit drapeau rouge et sélectionnez « Task Details ».

{gallery}42_DEPLOY_ADDS_8/08{/gallery}

 

 

 

 

 

 

 

Une fois dans la fenêtre « Task Details », nous avons la liste des dernières tâches réalisées ainsi que celles possibles et désignées comme étant « Post-deployment Configuration ». Notez que chaque tâche dispose d’un champ « Action ». Nous allons donc cliquer sur celle indiquant « Promote this server to a domain controller ».

{gallery}42_DEPLOY_ADDS_8/09{/gallery}

 

 

 

 

 

 

Dès lors, apparait à l’écran l’assistant de configuration Active Directory qui remplace donc DCPROMO. Clairement l’assistant reprend dans sa grande majorité ce que proposait déjà DCPROMO.

{gallery}42_DEPLOY_ADDS_8/10{/gallery}

 

 

 

 

 

 

 

A l’étape « Additional Options », notez que vous pouvez désormais choisir un partenaire de réplication spécifique ou/et opter uniquement pour la réplication des données critiques. Nous reviendrons de manière plus approfondie sur ces fonctionnalités dans un prochain article.

Remarque: la fonctionnalité IFM a également été améliorée.

{gallery}42_DEPLOY_ADDS_8/11{/gallery}

 

 

 

 

 

 

 

L’assistant reprend son cours tel que nous le connaissions déjà dans les précédentes versions de DCPROMO.

{gallery}42_DEPLOY_ADDS_8/12{/gallery}

 

 

 

 

 

 

 

A l’étape récapitulative des options choisies pour l’installation du contrôleur de domaine supplémentaire, nous avons la possibilité d’exporter la configuration sous la forme d’un fichier. La grosse nouveauté est que le fichier unattend a été désormais remplacé par un script PowerShell! Cela va permettre désormais d’automatiser et de simplifier le déploiement d’un contrôleur de domaine.

{gallery}42_DEPLOY_ADDS_8/13{/gallery}

 

 

 

 

 

 

 

Une fois tous les pré-requis validés et quelques avertissements … l’assistant débute l’installation.

{gallery}42_DEPLOY_ADDS_8/14{/gallery}

 

 

 

 

 

 

 

Comme toute version Beta, il est de mise de rencontrer quelques disfonctionnements.  En l’occurrence, il est possible que vous rencontriez un problème lors du redémarrage du serveur avec le message d’erreur ci-dessous. Le problème est connu et sera sans doute corrigé dans la version RC. Toutefois, pour pallier au problème, vous pouvez vous rendre dans le menu « AD DS », réaliser un clic droit sur le serveur concerné et choisir « restart server ». Notez également le nombre d’actions à distance à notre disposition !

{gallery}42_DEPLOY_ADDS_8/15{/gallery}

 

 

 

 

 

 

 

 

Conclusion

Notre nouveau contrôleur de domaine est désormais installé et configuré et cela sans avoir eu la nécessité de s’y connecter. De plus, nous avons pris comme exemple le rôle AD DS mais l’ensemble des rôles disponibles sous Windows Server 8 peuvent être déployés de la même manière. Enfin, et nous le verrons par la suite, la console « Server Manager » ne se cantonne pas qu’au déploiement de nouvelles fonctionnalités mais va nous permettre d’administrer et de surveiller tout un ensemble de serveurs depuis un point central !