Saisie des rôles FSMO à partir du contrôleur de domaine Windows mort

J'ai vu d'autres questions et documents à ce sujet, mais il y a des choses qui me troublent encore. Voici les documents et les questions que j'ai vus:

• Retirer un contrôleur de domaine Windows 2003 mort
• Saisir les rôles FSMO de Petri
• Utilisation de NTDSUtil.exe pour transférer ou saisir des rôles FSMO vers un contrôleur de domaine - Microsoft Knowledgebase
• Placement et optimisation FSMO sur les contrôleurs de domaine Active Directory - Base de connaissances Microsoft
• Comment supprimer des données dans Active Directory après une rétrogradation du contrôleur de domaine infructueuse

L'environnement contient deux serveurs Windows et de nombreux clients. Le contrôleur de domaine est Windows 2003 SP2 exécuté avec un AD natif Windows 2000. L'autre serveur (pas un DC du tout) est Windows 2000 SP4 (il héberge un utilitaire de détection de virus).

Résultats de netdom query fsmo:

Schema owner                missing.office.local

Domain role owner           myself.office.local

PDC role                    missing.office.local

RID pool manager            missing.office.local

Infrastructure owner        missing.office.local

The command completed successfully.

Résultats de dcdiag:

Domain Controller Diagnosis

Performing initial setup:
   Done gathering initial info.

Doing initial required tests

   Testing server: Default-First-Site\MYSELF
      Starting test: Connectivity
         The host 841d395a-2139-49d9-82c1-7c7e31ccb33b._msdcs.office.local could not be resolved to an
         IP address.  Check the DNS server, DHCP, server name, etc
         Although the Guid DNS name
         (841d395a-2139-49d9-82c1-7c7e31ccb33b._msdcs.office.local) couldn't be
         resolved, the server name (MYSELF.office.local) resolved to the IP
         address (192.168.9.101) and was pingable.  Check that the IP address
         is registered correctly with the DNS server. 
         ......................... MYSELF failed test Connectivity

Doing primary tests

   Testing server: Default-First-Site\MYSELF
      Skipping all tests, because server MYSELF is
      not responding to directory service requests

   Running partition tests on : ForestDnsZones
      Starting test: CrossRefValidation
         ......................... ForestDnsZones passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones passed test CheckSDRefDom

   Running partition tests on : DomainDnsZones
      Starting test: CrossRefValidation
         ......................... DomainDnsZones passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones passed test CheckSDRefDom

   Running partition tests on : Schema
      Starting test: CrossRefValidation
         ......................... Schema passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Schema passed test CheckSDRefDom

   Running partition tests on : Configuration
      Starting test: CrossRefValidation
         ......................... Configuration passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Configuration passed test CheckSDRefDom

   Running partition tests on : office
      Starting test: CrossRefValidation
         ......................... office passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... office passed test CheckSDRefDom

   Running enterprise tests on : office.local
      Starting test: Intersite
         ......................... office.local passed test Intersite
      Starting test: FsmoCheck
         Warning: DcGetDcName(PDC_REQUIRED) call failed, error 1355
         A Primary Domain Controller could not be located.
         The server holding the PDC role is down.
         ......................... office.local failed test FsmoCheck

Voici mes questions (pardonnez-moi si elles sont trop de questions pour débutants):

• Les rôles sont-ils listés parmi netdom query fsmoceux que j'ai vus listés ailleurs? Par exemple, le propriétaire du rôle de domaine est-il le même que le maître d'attribution de noms de domaine ? Le gestionnaire de pool RID est-il le même que le rôle RID ?
• Quelles sont les mauvaises choses qui pourraient arriver si je saisis l'un de ces rôles?
• Les utilisateurs le remarqueront-ils?
• Cette configuration dure depuis longtemps et les gens fonctionnent plus ou moins normalement; la prise du rôle PDC va-t-elle changer cela?
• Certains de ces documents prédisent des conséquences désastreuses pour avoir tous les rôles sur un seul contrôleur de domaine. Avec une clientèle de pas plus de 20 - et peut-être moins de 10 la plupart des jours - est-ce que tous les rôles sur un DC sont un vrai problème?
• Existe-t-il des mises en garde concernant l'exécution du processus de nettoyage recommandé par Microsoft pour supprimer l'ancien contrôleur de domaine d'Active Directory?

De plus - une question presque tangentielle - si je mettais à niveau le domaine vers Windows 2003 AD (maintenant ou à l'avenir), est-ce que cela change quelque chose dans la prise de rôles FSMO?

PS: Je soupçonne que les problèmes DNS ont à voir avec l'utilisation d'un DNS non Microsoft qui ne prend pas en charge le DNS dynamique de Microsoft; Je pense qu'il y a un DNS Windows en cours d'exécution mais je ne l'ai pas encore vérifié pour le bon fonctionnement et la configuration.

Les rôles répertoriés dans netdom query fsmo sont-ils les mêmes que ceux que j'ai vus ailleurs? Par exemple, le propriétaire du rôle de domaine est-il le même que le maître d'attribution de noms de domaine? Le gestionnaire de pool RID est-il le même que le rôle RID?

Oui, exactement. Je ne sais pas pourquoi ils ont les noms légèrement différents dans cet affichage particulier.

Quelles sont les mauvaises choses qui pourraient arriver si je saisis l'un de ces rôles?

La saisie elle-même? Pas beaucoup. La plupart des problèmes potentiels qui sont mis en garde concernent la remise sous tension de l'ancien DC après son rôle saisi - et même alors, il y a beaucoup d'hystérie pour pas beaucoup de risques; il faut des scénarios assez étranges pour rompre quoi que ce soit avec une saisie au lieu d'un transfert de rôle. Pour avancer sur une tangente un instant, passons en revue les rôles et les risques potentiels:

• Schema Master: Celui-ci rend tout le monde assez nerveux, mais le casser n'est pas un scénario très probable. La documentation dit que vous ne devriez jamais remettre en marche l'ancien Schema Master après avoir pris le rôle, que j'appelle alarmiste. L'ancien serveur sera informé du changement de rôle et dès qu'il le sera, il abandonnera le rôle. Le risque potentiel ici est que si des modifications sont apportées au nouveau maître de schéma, puis l'ancien maître de schéma est mis en ligne, puis avant qu'il ne se réplique à partir des autres contrôleurs de domaine , des modifications de schéma différentes et conflictuelles sont effectuées sur l'ancien serveur. Cette situation est peu probable, mais détruirait votre domaine.

• Naming Master: même accord qu'avec le Schema master, vous devez apporter des modifications (dans ce cas, créer un nouveau domaine dans la forêt) sur l'ancien contrôleur de domaine, après avoir saisi son rôle mais avant qu'il n'ait connaissance de la saisie.

• Émulateur PDC: aucun risque, il n'est responsable de rien où vous risquez de divergence.

• RID Master: Vous auriez besoin d'une structure de réplication foirée pour briser celle-ci - imaginez que vous avez 2 DC; un ancien maître RID qui ne connaît pas son rôle a été saisi et un nouveau maître RID. Dans cette situation, vous devez créer suffisamment d'objets pour épuiser le pool RID sur les deux (ils sont distribués en 500) et les faire attribuer aux pools qui se chevauchent. Créez des objets avec des RID identiques, reconnectez les contrôleurs de domaine et regardez l'apocalypse se dérouler.

• Infrastructure Master: Honnêtement, probablement 50% des domaines dans le monde n'ont même pas du tout d'Infrastructure Master, car il ne fonctionne pas quand il est sur un GC. Dans tous les cas, vous ne pouvez pas le briser avec une saisie.

Les utilisateurs le remarqueront-ils?

Ils ne devraient pas.

Cette configuration dure depuis longtemps et les gens fonctionnent plus ou moins normalement; la prise du rôle PDC va-t-elle changer cela?

Non. Avec un seul DC, aucune des fonctions du PDC n'est manquée du tout, sauf peut-être que votre DC non-PDC ne peut pas synchroniser le temps avec la source qu'il veut (le PDC manquant).

D'autant plus:

• Vous ne manquerez le maître de schéma que lorsque vous essayez de mettre à jour le schéma
• Vous ne manquerez le Naming Master que lorsque vous essayez de créer un nouveau domaine dans la forêt
• Vous ne manquerez le maître RID que lorsque vous créerez trop d'objets et épuiserez le pool RID de votre DC (c'est probablement le plus susceptible de vous rencontrer si vous continuez à fonctionner tel quel)
• Vous ne manquerez que le maître d'infrastructure pour les mises à jour de groupe de catalogue global dans une forêt multi-domaine

Certains de ces documents prédisent des conséquences désastreuses pour avoir tous les rôles sur un seul contrôleur de domaine. Avec une clientèle de pas plus de 20 - et peut-être moins de 10 la plupart des jours - est-ce que tous les rôles sur un DC sont un vrai problème?

Non - mais obtenez un deuxième DC. Vous ne voulez pas que votre seul CC échoue.

Existe-t-il des mises en garde concernant l'exécution du processus de nettoyage recommandé par Microsoft pour supprimer l'ancien contrôleur de domaine d'Active Directory?

Ouais - fais attention. Mais aiguisez vos ntdsutilcouteaux et détachez les anciennes données - des déchets supplémentaires ne contribuent pas à la maintenabilité du domaine.

Votre configuration actuelle (sans maître d'opérations fonctionnel) est une configuration dangereuse et non prise en charge qui doit être corrigée dès que possible. Si le serveur manquant est mort et enterré, la saisie des rôles FSMO est une étape nécessaire vers la reprise du fonctionnement normal.

Réponses à votre question spécifique:

1. Oui, les titres de rôles portant le même nom que vous mentionnez signifient tous la même chose.
2. De mauvaises choses sont susceptibles de se produire si vous saisissez un rôle et essayez ensuite de ressusciter le serveur manquant qui l'avait. Veuillez vous assurer qu'il est mort et enterré avant de saisir les rôles.
3. Il est peu probable que les utilisateurs remarquent de nouveaux problèmes à la suite de la prise des rôles FSMO.
4. Le fait de ne pas assumer ce rôle entraînera des problèmes à long terme. Prendre le rôle rapidement après l'échec de son ancien titulaire ne posera pas de problème.
5. En fait, il est courant pour les petites entreprises de 10 à 20 utilisateurs d'avoir un seul serveur avec tous les rôles FSMO et Exchange et Sharepoint. Cela ne crée pas de problèmes de performances insolubles si le serveur a été spécifié correctement, mais le site est garanti de subir des temps d'arrêt en cas de défaillance du serveur unique. Il est préférable d'avoir au moins deux contrôleurs de domaine par domaine, même si l'un d'eux est un serveur Atom D525 de moins de 500 $ dans un châssis 1U.
6. Pas particulièrement, mais toute maintenance de serveur comporte au moins un certain risque. Comme toujours, assurez-vous de disposer de sauvegardes complètes et testées et d'un plan de récupération avant de continuer.
7. Cela ne devrait pas être un problème tant que vous saisissez d'abord les rôles FSMO, puis mettez à niveau le niveau fonctionnel du domaine.
8. Il n'y a aucune bonne raison d'utiliser un DNS non Microsoft pour la résolution de domaine dans un environnement Active Directory. Vous devez préparer et mettre en œuvre un plan pour migrer vos services DNS internes vers vos contrôleurs de domaine.

Vous avez indiqué que vous disposez d'un «utilitaire de détection de virus» en cours d'exécution sur un serveur Windows 2000. Vous savez sûrement que Windows 2000 lui-même est un "utilitaire de collecte de virus" avec de nombreuses vulnérabilités connues et aucune mise à jour de sécurité disponible. Retirez immédiatement ce serveur.

Oui, saisissez ces rôles. Vous êtes une fluctuation de puissance / blocage du système / éruption solaire loin d'une catastrophe.

C'est peu probable, mais les utilisateurs peuvent remarquer si les modifications de compte mises en cache sur leurs machines locales ne correspondent pas à AD.

Vous ne devriez jamais avoir qu'un seul DC. Deux minimum et un dans chaque bureau distant. Si vous souhaitez utiliser des machines virtuelles, (à mon humble avis), elles ne servent qu'à compléter les boîtes physiques. Et ce n'est qu'après avoir lu sur l'utilisation des machines virtuelles en tant que contrôleurs de domaine.

Je préfère que tous les contrôleurs de domaine soient des GC. C'est ma préférence personnelle, mais cela signifie qu'une copie complète du contenu d'AD est stockée sur chaque DC avec ce rôle. Si vous avez deux DC, mais qu'un seul est un GC, et que l'un meurt, je pense que vous devenez à peu près aussi vissé que si vous n'aviez qu'un seul DC.

Votre émulateur PDC va obtenir tout le trafic des systèmes hérités («systèmes», c'est-à-dire des machines, des applications et des services, tels que SQL Server 2000); mettre sur le matériel.

Il n'est pas nécessairement mauvais qu'un DC ait tous les rôles, SI vous avez d'autres DC et que votre réplication est saine.

À moins qu'il n'y ait une très bonne raison, vous devez absolument utiliser Microsoft DNS pour la résolution de noms interne.

Réparez votre environnement, puis mettez à niveau. Vous ne peignez pas un bateau qui coule. Pendant que vous y êtes, pensez sérieusement à vous rendre en 2008. 2003 est sur le maintien de la vie.

Voir aussi: Que faut-il faire après une panne du contrôleur de domaine? et Comment mettre en place un autre DC avec tous les rôles lorsque le premier DC n'est plus disponible