7 votes

l'un des DCs à un seul dc par domaine a subi un rollback USN

J'ai hérité d'une forêt Active Directory qui est très mal disposée. Il y a une seule forêt avec un arbre de domaine pour chaque site, chacun avec un seul contrôleur de domaine. Aucun domaine n'est l'enfant d'un autre domaine.

Maintenant, l'un des DCs, appelons-le M1 pour le domaine M, a eu un problème lorsque nous avons déplacé la VM d'un hyperviseur à un autre, nous sommes donc revenus à celui qui fonctionnait, ce qui a provoqué un rollback USN, et le DC M1 2008r2 l'a détecté. Au cours de cette opération, deux entrées DNS ont été effectuées dans le domaine M, qui sont probablement les seules choses perdues pendant le rollback, car aucun utilisateur n'était actif dans le domaine M à ce moment-là. Actuellement, la réplication entrante et sortante du DC M1 a été réactivée avec les paramètres suivants repadmin /options M1 -DISABLE_INBOUND_REPL y repadmin /options M1 -DISABLE_OUTBOUND_REPL et son service netlogon a continué après qu'il ait démarré dans un état de pause avec l'id d'événement 2103.

La solution que j'aimerais est de créer un nouveau domaine unique pour les 10 sites et de recommencer. Cependant, à part le désagrément du démarrage de netlogon dans un état de pause, tout semble fonctionner correctement. Les questions que je me pose sont les suivantes :

  1. Y a-t-il des suggestions moins sévères ou est-ce que ce serait tout autant de travail de recommencer et de le faire correctement ?
  2. Si j'ai juste supprimer la clé de registre HKLM\System\CurrentControlSet\Services\NTDS\Parameters\DSA Not Writable et ignorer le retour en arrière, quel sera l'effet sur le domaine DC unique dans une forêt multi-domaine ?

Comme il s'agit d'un seul DC, nous ne pouvons pas effectuer

  • rétrograder puis promouvoir le DC pour répliquer à partir d'un autre DC existant car il n'y en a pas dans le même domaine pour répliquer.
  • Effectuez une restauration d'état du système non-autoritaire, car cela nécessite un DC sain et fonctionnel pour la réplication.

Edit : oui, nous avons, ou pouvons faire une sauvegarde de l'état du système à partir d'une ancienne image système, qui est plus jeune que la durée de vie de la pierre tombale.

3 votes

Wow, je n'ai jamais rencontré un design AD aussi pauvre dans la nature.

0 votes

J'ai de la chance. Je pense qu'il s'est développé à partir de sites DC uniques qui étaient complètement isolés les uns des autres en termes d'AD, de sorte que chaque site avait sa propre forêt. Les sauvegardes étaient faites, les restaurations étaient possibles sans provoquer de rollbacks. Puis ils les ont réunis en une seule forêt :(

0 votes

Nous avons toute la complexité et les problèmes d'un système à haute disponibilité sans aucun des avantages.

5voto

Ryan Ries Points 54671

Je pense que la chose la plus sûre à faire est d'appeler le support Microsoft et de demander qu'il vous guide. Le problème, c'est que faire quelque chose d'aussi simple que de modifier manuellement le fichier Dsa Not Writable L'entrée dans le registre peut vous mettre dans un état de non assistance permanente.

Cette mise en garde étant faite, le problème avec les rollbacks USN est que vous avez besoin d'un autre DC dans le domaine pour être la norme faisant autorité pour le rollback de votre domaine. Comme vous n'avez qu'un seul DC dans le domaine, vous n'avez pas cela.

Vous avez une sauvegarde de l'état du système ?

Un contrôleur de domaine correctement restauré réinitialise son attribut ID d'invocation locale d'invocation locale lorsqu'il redémarre dans Active Directory après que son système a été désactivé. a été restauré à l'aide d'un supporté par méthode de sauvegarde et de restauration. Lorsque l'ID d'invocation de réinitialisation est outbound-replicated, les contrôleurs de domaine distants de la forêt enregistrent l'ID d'invocation de réinitialisation comme une nouvelle instance de base de données sur le contrôleur de domaine restauré. Bien que le contrôleur de domaine restauré soit toujours le même contrôleur de domaine, les contrôleurs de domaine distants reconnaissent ce contrôleur de domaine restauré comme un nouveau partenaire de réplication car l'ID d'invocation a changé. (L'ID d'invocation ID d'invocation est l'identité de l'instance de la base de données). Le contrôleur de domaine restauré de domaine restauré acceptera lui-même les modifications des autres contrôleurs de contrôleurs de domaine distants qui proviennent des contrôleurs de domaine distants et du contrôleur de domaine avant sa restauration. le contrôleur de domaine avant qu'il ne soit restauré.

C'est à peu près votre bible sur ce sujet : http://support.microsoft.com/kb/875495/en-US

Vous n'avez pas de sauvegarde de l'état du système ? Vous pourriez configurer la base de données AD pour qu'elle se donne un nouvel ID d'invocation :

http://technet.microsoft.com/en-us/library/d2cae85b-41ac-497f-8cd1-5fbaa6740ffe(v=ws.10)#sauvegarde_et_restauration_considérations_pour_les_contrôleurs_de_domaine_virtualisés

Rien de tout cela n'a fonctionné ? Alors regardez le bon côté des choses : au moins vous n'avez perdu que un domaine !

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X