SRS harte Entfernung

Verstehen Sie die folgende Beschreibung nicht als "Anleitung", wie Sie mit aller Gewalt den SRS entfernen. Die folgende Beschreibung ist eine unvollständige Auflistung, was bei der Entfernung im Hintergrund alles passiert und versucht etwas die Zusammenhänge zu erklären.
Wenn die normale Deinstallation (siehe SRS entfernen) nicht auf Anhieb funktioniert, dann sollten Sie noch etwas warten, prüfen und es noch mal versuchen oder die Deinstallation verschieben, bis es keinen Exchange 5.5 Server mehr in ihrer gesamten Organisation mehr gibt.

Diese Beschreibung kann aber dazu dienen, die Zusammenhänge des SRS besser zu verstehen und eventuell am Ende einer Exchange Migfration manuell zu deinstallieren.

Wie Sie auf Native AG in Mixed Org schon gelesen haben, ist es durchaus möglich, in einer gemischten Umgebung mit Exchange 5.5 und Exchange 2000/2003 auch eine so genannte "native administrative Gruppe" zu installieren. Das ist eine administrative Gruppe in der es noch nie einen Exchange 5.5 Server gegeben hat und daher auch bei der Installation des Exchange 2000/2003 Servers kein SRS angelegt wurde. Also gibt es tatsächlich einen Weg, eine administrative Gruppe auch ohne SRS in einer gemischten Umgebung zu betreiben.

Vorteile

Da keimt natürlich gerade bei größeren Installationen der Gedanke auch eine administrative Gruppe, die bislang aus Exchange 5.5 und Exchange 2000/2003 Servern bestanden hat, in diese Betriebsart zu versetzen. Wenn Sie nämlich eine solche administrative Gruppe migriert haben und der letzte Exchange 5.5 Server deinstalliert ist, dann sind nur noch Exchange 2000/2003 Server mit mindestens einem SRS vorhanden. Das hat durch den erforderlichen Verzeichnisabgleich durchaus Nachteile:

  • ADC-UserCA
    Alle Benutzer, die auf dem Exchange 2000/2003 Server vorhanden sind, müssen über die Konstruktion einer ADC-Verbindungsvereinbarung auf den SRS repliziert werden
  • Exchange 5.5 Rückreplikation
    Die Benutzerobjekte in der SRS-Daten werden dann über den Exchange 5.5 DirSync Connector an die verbleibende Exchange 5.5 Welt weiter gegeben
  • Exchange 5.5 Hinreplikation
    Aber auch Änderungen aus den anderen Exchange 5.5 Standorten werden weiter an diesen Standort gesendet, obwohl diese Informationen nur in der SRS-Datenbank landen und von niemandem mehr ausgewertet werden.
  • Bandbreite
    Das ist sehr unökonomisch, besonders wenn die Exchange Organisation sehr groß ist und entsprechend viele Änderungen übertragen werden müssen. Handelt es sich sich dabei auch noch um eine kleine schmalbandig angebundene Niederlassung, dann ist die Bandbreite womöglich ein Problem, da fast identische Informationen doppelt übertragen werden. Einmal als AD-Replikation und ein anderes mal durch den Exchange 5.5. DirSync
  • SRS Betrieb
    Natürlich bringt auch der SRS Betrieb einige Nachteile mit sich. Neben dem Speicherplatz und dem Hauptspeicher müssen Sie den SRS weiterhin sichern. Verbunden mit dem SRS gibt es auch ein entsprechendes ConfigCA, welche die Daten zwischen dem AD und SRS abgleicht. Daher muss vor Ort auch noch ein ADC laufen. Nutzen Sie hierzu einen zentralen ADC-Server, dann werden auch diese Daten noch zweimal über das WAN übertragen.

Sie sehen also, es wäre so schön, wenn Sie den SRS vor Ort entfernen könnten und eine native Administrative Gruppe zu erhalten, so als wenn sie alle Postfächer einmal exportiert, Exchange deinstalliert und als neue Administrative Gruppe installiert und wieder importiert hätten.

Allerdings könnte man eine Aussage af http://weblogs.asp.net/exchange/archive/2004/11/19/266841.aspx von Microsoft Entwicklern zum SRS Deinstallieren auch als Erlaubnis werden:

NOTE: Microsoft strongly recommends that all Exchange 5.5 servers in the organization be decommissioned before removing the only SRS server in an administrative group. Changes to the replication topology caused when removing an SRS will have significant impact to interoperability between administrative groups.

ABER das ist eine "Empfehlung", keine Vorschrift, denn dann geht es weiter:

An SRS can only be safely deleted if the following conditions are met:

Another SRS exists in the administrative group to take over responsibility für replicating the configuration naming context

or

There are no Exchange 5.5 servers in the administrative group and the SRS is not the endpoint of an Exchange 5.5 directory replication connector.

SRS normal entfernen

Zur Sicherheit:Diese Vorgehen wird in keinster Weise von Microsoft oder mir unterstüzt.

Ausgangssituation ist eine TestUmgebung mit einer Zentrale (Exchange 2003 und Exchange 5.5 Server) und einer Niederlassung, die durch eine Migration von Exchange 5.5 nach Exchange 2003 nur noch einen Exchange 2003 Server samt SRS enthält.

Folgende Schritt wurden durchgeführt.

  • ADC replizieren
    Wenn der ADC und SRS noch funktionieren und Sie den SRS nicht aufgrund eines Fehlers entfernen wollen, dann sollten Sie noch einmal eine Replikation durchführen lassen und deren Abschluss auch im Eventlog überprüfen (Siehe Active Directory Connector Grundlagen ff)
  • ADC für die Niederlassung stoppen
    Da wir den SRS in der Niederlassung entfernen wollen, müssen wir auch sicherstellen, dass die folgenden Löschbefehle nur die erwünschten Objekte entfernen. Daher müssen Sie die CAs für Benutzer, Gruppen und öffentliche Ordner stoppen, die diesen SRS verwenden. Dazu werden die entsprechenden Verbindungsvereinarungen auf "NEVER" gestellt und die Replikation des AD abgewartet. Sie dürfen aber auf keinen Fall das ConfigCA stoppen. Diese ist noch erforderlich.
  • PreferredSRS
    Wenn Sie eine neue Administrative Gruppe einrichten und Exchange 2000/2003 installieren, dann ist dort kein SRS enthalten. Ein anderer SRS übernimmt dann die Aufgabe. Es ist sinnvoll, dass der SRS diese Aufgabe übernimmt, der im Hinblick auf die  Verzeichnisreplikation günstig liegt, z.B. in der Zentrale. Welcher SRS die Funktion übernimmt kann über die Beschreibung der administrativen Gruppe gesteuert werden (Q315408 How to control which Site Replication Service owns a site). Tragen Sie den Servernamen des gewünschten SRS als "preferredSRS" in der Beschreibung der AG ein (Hier z.B. "preferredSRS SRV1".
  • DirSync löschen
    Als nächster Schritt wird der Connector zur Verzeichnisreplikation zwischen dem SRS und der Gegenseite gelöscht. Ab dem Moment verschwindet die Niederlassung aus der Exchange Organisation der Zentrale und nachgeschalteter Standorte und die Niederlassung "sieht" nur noch sich selbst. für einen gewissen Zeitraum sind damit die Personen in der Niederlassung aus der Exchange 5.5 Welt nicht mehr erreichbar.
    Warten sie nach diesem Schritt, bis das ConfigCA die Änderung ins AD übernommen hat
  • SRS im Standort entfernen
    Nun löschen wir den SRS auf dem Niederlassungsserver, indem wir den Exchange System Manager "AUF" dem Server selbst starten und SRS deinstallieren.
    Es kann sein, dass die Deinstallation nicht gelingt, weil die Replikation des ConfigCA noch nicht abgeschlossen ist. Die Einträge des DirSync Connectors sind im Active Directory an folgender Stelle zu finden: Hier sollten keine Einträge zu finden sein. Kontrollieren Sie das ConfigCA

AD\Config\Services\Microsoft Exchange\Orgname\Administrative Groups\AG-Name\Directory Replication

Nach dieser Deinstallation sollte die Administrative Gruppe in den "Native Mode" versetzt worden sein.

  • SRS Zentrale Neustarten
    Der SRS der Zentrale wird nach einiger Zeit erkennen, dann der nun für diese Administrative Gruppe zuständig ist. Der SRS prüft solche Veränderungen nur alle 3 Stunden (SKCC). Nach einiger Zeit sollte dann die Niederlasung wieder in der SRS-Datenbank erscheinen. Die Arbitation wird durch den SKCC alle 3 Stundendurchgeführt und kann nicht manuell forciert werden. (siehe Q271806 XADM: Error c10306a7 Running Knowledge Consistency Checker on Exchange 2000 Server Computer)
  • ADC einpassen
    Sie müssen nun natürlich die Verbindungsvereinbarungen für die Benutzer, Verteiler und öffentlichen Ordner für diesen Standort anpassen. Die CAs, die bislang auf den SRS der Niederlassung verwiesen haben, müssen nun auf den SRS verweisen, der als "preferredSRS" die Aufgabe nun übernommen hat. Dann werden auch wieder die Benutzer der Niederlassung in der verbliebenen Exchange 5.5 Welt sichtbar.
    Allerdings betrifft dies nur neue Anwender. Die bestehenden Anwender werden durch den ADC nicht repliziert, da diese im Active Directory schon das Feld "ADCGlobalNames" haben. Dieses müssen Sie natürlich im AD bei allen betroffenen Benutzern noch löschen. Dazu können Sie Benutzer basierend auf dem LegacyExchangeDN suchen und ändern.
    Ob der SRS für diese administrative Gruppe zuständig ist, können Sie mit ADSIEDIT bei den Eigenschaften des ConfigCA prüfen.

In einer TestUmgebung waren danach keine Probleme zu bemerken.

Ich habe diese Umstellung auch mehrfach in einer größeren Umgebung durchführen müssen, wenn nämlich der SRS-Server durch einen Ausfall nicht wieder herstellbar war bzw. andere Fehler diese Umstellung quasi erzwungen haben. Alternativ können Sie natürlich immer noch die Datenbank des Servers auf die Seite kopieren und die administrative Gruppe komplette deinstallieren, wieder neu installieren und dann die Daten wieder einzuspielen. Auch der Umweg über EXMERGE ist möglich oder MailMig.

SRS hart entfernen

Wenn sich der SRS nicht über den Exchange System Manager deinstallieren lässt, dann können Sie den SRS auch manuell mit ADSIEDIT entfernen.

  • Preferred SRS vorgeben
    Wie bei der obigen Beschreibung sollten Sie dafür sorgen, dass der gewünschte SRS die Funktion übernimmt
    315408 How to control which Site Replication Service owns a site Lösche AD\Config\Services\Microsoft
  • SRS Stoppen und deaktivieren
    Beenden Sie den SRS Dienst auf dem Server und stellen Sie den Dienst auf "deaktiviert". Die SRS.EDB und die dazu gehörigen Protokolldateien können Sie später löschen.
  • ADISEDIT:DirSync Connector entfernen
    Löschen Sie die Verzeichnisdienstconnectoren dieses SRS mittelst ADSIEDIT auf dem Active Directory unter

Configuration\Services\Microsoft Exchange\Orgname\Administrative Groups\AG-Name\Servers\SERVERNAME\Microsoft DSA\*

  • ADSIEDIT:SRS -Eintrag entfernen
    Als nächsten Schritt müssen Sie im Active Directory den Eintrag für den SRS entfernen. Dazu löschen Sie ebenfalls mit ADSIEdit den Eintrag unter:

Configuration\Services\Microsoft Exchange\Orgname\Administrative Groups\AG-Name\Servers\SERVERNAME\Microsoft DSA\*

  • ADSIEdit: ConfigCA löschen
    Das manuelle Löschen des SRS entfernt nicht das dazu gehörige ConfigCA. Dies müssen wir ebenfalls von Hand mit ADSIEdit löschen. Erst dann wird auch der entsprechende Export Container frei gegeben, so dass ein anderer SRS sich zuständig fühlen kann.
  • AdminGroup auf NATIVE stellen
    Zuletzt müssen wir die administrative Gruppe ebenfalls in den "Native Mode" stellen. Hierzu ist mit ADSIEdit das Feld msExchAdminGroupMode auf 0 stellen (0=Native E2K AG, 1= native EX55, 2= mixed AG). (Siehe auch http://blogs.msdn.com/exchange/archive/2004/04/13/112453.aspx)

Configuration\Services\Microsoft Exchange\Orgname\Administrative Groups\AG-Name\msExchAdminGroupMode

  • Die Arbitation wird durch den SKCC alle 3 Stundendurchgeführt und kann nicht manuell forciert werden.
    Siehe Q271806 XADM: Error c10306a7 Running Knowledge Consistency Checker on Exchange 2000 Server Computer

Weitere Links