AU SECOURS !!!!!!!!
 
Une OU contenant près de 50 utilisateurs a été effacée par erreur sur un de nos contrôleurs de domaine !!  Cette OU apparaît encore sur un autre contrôleur qui ne s'est pas encore synchronisé (il le fera ce soir). Je voudrais savoir comment forcer la réplication de ce serveur distant VERS le serveur "endommagé" pour récupérer l'OU perdue....
Ou alors une autre méthode pour restaurer l'OU en question.
 
C'est de l'Active Directory sous Win2000 server

Eclaircissement du sujet....

va dans "Sites et services Active Directory", Sites, Premier-Site-par-defaut,Servers, "ton DC1 qui a PAS la bonne config", NTDS setting
dans la partie droite tu vas voir une ligne avec le nom de ton DC2 qui lui A la bonne config (au dessus c'est marqué DEPUIS LE SERVEUR" , clic droit sur cette ligne et "répliquer maintenant"
 
Ne te gourre pas, la logique a avoir c'est: je restaure DEPUIS le serveur qui est bon vers celui qui n'est pas bon.
 

Es-tu certains qu'il va me redescendre correctement l'OU sans s'occuper se savoir quelle a été la dernière modification effectuée?

la config du DC2 va s'appliquer au DC1 sans ce soucier de quoi que ce soit

exporter au format csv tout ou une partie d'AD -> csvde.exe

il faut que tu fasse un "authoritative restore"  
demarre ton DC en mode "directory service restore mode" ensuite avec ntdsutil tu dois marquer ton OU comme etant Authoritative et reboot. a la prochaine replication ton OU sera repliquée sur les autres DC.

C'est bon, c'est effectivement ce qu'on a trouvé comme méthode...ça a fonctionné presque correctement
Le seul problème qui reste, c'est que les utilisateurs ont tous perdu leurs groupes d'appartenance. Il faut les leur réassigner. Mais bon c'est pas le plus grave.
Merci

comment ça perdu leurs groupes d'appartenance?

Un topic comme je les  

 
Juste au cas où :
le DC sur lequel il faut faire la manip est celui qui a tjrs l'objet que l'on veut concerver (en l'occurence DC2)
 

 
J'ai comme l'impression que cette manip n'est pas bonne dans ce genre de cas, car meme si c'est Dc2 qui demande la réplication, la suppression de l'UO sera répliquée non ?
Confirmation ?

en gros, chaque objet AD possede un USN (update sequence numbers), quand on fait une modif sur un objet ce nombre augmente et lors de la replication, AD compare tout ca pour determiner quel objet est le plus recent et ne replique que ce qui a ete modifié.
y'a aussi des info comme le GUID du DC sur lequel le changement a ete effectué qui ce rajoute qq par sur l'objet.
 
bref, c pas du tout le DC qui initialise la replication qui a authorité sur ce qui est repliqué ou pas.
 
j'espere que j'ai pas dis trop d'anneries, corrigez moi si c le cas

 
je pense comme toi

 
ça je suis d'accord pour l'USN mais si tu fais une modif sur un objet de l'AD cette modif' est répliquée au moment de la synchronisation. Et je ne crois pas que l'on puisse changer ça par le fait de dire à un DC qu'il doit répliquer sa version de l'AD

 
C'est en me basant sur l'USN que j'ai émis ma réserve, donc je suis d'accord avec toi et avec krapaud ca fait 3.
Motion adoptée  

Moi je crois me rappeler qu'il y a une commande en mode restauration des services d'annuaire pour incrémenter l'id d'un objet ou d'une arborescence afin qu'elle soit conservée à la réplication
 
ps : faut être un sacré boulet pour effacer une OU par erreur !

 
je connais ça pour exchange (authrest.exe) mais est-ce que ça existe aussi pour l'AD
 
peut-être repadmin.exe : http://support.microsoft.com/defau [...] -us;229896

mes cours sont loin loin derrière moi, et comme je supprime pas d'OU par erreur j'ai pas eu l'occasion de m'en reservir

de même

On avait tester le fait de forcer une réplication selon la méthode de PCvision. Mais ça ne donne rien. L'OU sur le serveur d'origine n'est pas pour autant supprimée, mais elle ne se réplique pas.
La méthode donnée par Knives a effectivement fonctionné. Elle est bien entendu à faire sur DC qui a encore l'OU à récupérer. La méthode permet de remonter la priorité de l'OU en question, qui redescend alors sur les autres serveurs lors de la réplication.
 
Enfin quand je parles de "groupe d'appartenance", je veux dire qu'ils ont disparus de la plupart des groupes de sécurité. Tous ces utilisateurs n'appartenaient plus qu'à un seul groupe, généralement le groupe "Utilisa. du domaine".

ben quand l'OU a ete supprimé tout les comptes ont ete viré des groupes de secu et tout ces changements sur les groupes ont ete repliqué.
il aurait fallu je pense restaurer les groupes en mme temps que ton OU pour retrouver tout comme avant.

Ah oui bien vu !!

En fait l'idéal aurait été de redescendre également l'OU contenant les groupes de sécurité, quoi. M'enfin ça va encore, il n'y a que 50 users, et pour une bonne moitié, j'avais un historique de leurs droits d'accès.

bon maintenant que t'es sorti d'affaire
explique nous comment t'as fait pour faire suppr, puis répondre oui au message d'avertissement sur une OU de 50 utilisateurs
qu'on se marre un peu

j'ai renverse le cafe sur le clavier

C'est bien ça le problème. On ne sait pas ce qui s'est passé. Sachant qu'on doit être environ une dizaine à avoir des droits d'administration, c'est difficile de savoir qui l'a fait

vous etes une dizaine et vous avez pas activé l'audit sur AD?!?! spabien
profite en pour mettre ca en place, comme ca la prochaine fois t'aura qq un a pointer du doigt

On est en pleine restructuration de l'architecture. On va avoir 5 contrôleurs de domaine en plus...donc à mon avis on va effectivement activer l'Audit

Au fait si vous avez quelques minutes pour m'expliquer (je suis curieux de nature !) : c'est quoi un OU ?? et de quoi vous parlez là en gros...

Organisational unit / unitee organisationelle (ortho?)
 
www.commentcamarche.net