Teil 3 - Inter-Site-ReplicationReplication Schedules unter Windows Server 2003

Teil 4 - Schlusswort

Autor: olc, MCSEboard.de

 

Grundsätzlich lassen sich vom KCC erzeugte Connection Objects auch bearbeiten. Sobald jedoch eine Änderung an dem Connection Object vorgenommen wurde, ist dieses Objekt kein automatisch generiertes Objekt mehr, sondern gilt als manuell erstelltes. Änderungen an diesem Objekt werden von nun an nicht mehr vom KCC vorgenommen und der KCC bezieht dieses Objekt in seine Berechnungen als „statisch“ ein. Hintergrund dafür ist die Ownership für das entsprechende Connection Object: Erzeugt der KCC ein Connection Object, wird er als Owner des Objekts im AD eingetragen. Sobald eine manuelle Änderung über die Standorte und Dienste MMC erfolgt, verändert sich der Owndership.

Möchte man ein Objekt trotzdem manuell bearbeiten, ohne es jedoch zu einem statischen Connection Object zu machen, kann man dies mittels ADSIEdit erreichen: Änderungen, die direkt am Objekt durchgeführt werden und nicht über die Standorte und Dienste MMC, verändern den Ownership nicht. So wäre es theoretisch möglich, den Schedule eines automatisch erzeugten Connection Objects zu ändern, ohne Anpassungen an den NTDS Settings der Site oder dem IP Site Link vornehmen zu müssen bzw. andere Connection Objects zu beeinflussen. Dieses Vorgehen sollte jedoch mit Bedacht gewählt werden. Macht man hier einen Fehler, kann das schnell zu Problemen innerhalb der Replikationstopologie führen, die so leicht nicht zu finden sind…

Abb. 9

Ob ein Connection Objekt den KCC als Owner besitzt, kann man ebenfalls über ADSIEdit herausfinden: Dazu navigiert man zum gewünschten Connection Object und überprüft das Attribut “options”. Steht der Wert hier auf „1“, ist der KCC Owner dieser Verbindung.

CN=<GUID_des_Connection_Objects>,CN=NTDS Settings,CN=<Servername>,CN=Servers,CN=<Site-Name>,CN=Sites,
CN=Configuration,DC=<domain>,DC=<tld>

 

© MCSEboard.de, olc

Teil 3 - Inter-Site-ReplicationReplication Schedules unter Windows Server 2003