Site Replication Service - SRS

Die Kurzform: Der SRS ist der Exchange Site Replication Service und simuliert einen EX55 DirSync Server, damit die Koexistenz der Welten gewährleistet ist.  Das ConfigCA des ADC liest diese Daten dort aus und schreibt sie ins AD. Also gibt es das Postfach nur auf SRS Servers und die gibt es standardmäßig nur einmal je Site.

Der Site Replikation Dienst selbst wird bei jedem Exchange 2000 mitinstalliert, wenn die Exchange Organisation im Mixed Mode (vgl. Native Mode) ist und Exchange 5.5 Server existieren. Allerdings ist der Dienst auf allen Server deaktiviert mit Ausnahme des ersten Exchange 2000 Servers bzw. einem Exchange 5.5 Bridgehead Server nach dem Update auf Exchange 2000 in einer Site.

Dieser Server simuliert mit dem SRS-Dienst einen Exchange 5.5. Server. Über diesen Weg repliziert die Exchange 5.5 Welt ihre Konfigurationsdaten mit der Exchange 2000 Umgebung. Und der SRS-Dienst ist etwas wie eine "kleine DIR.EDB", damit Konnectoren zur Verzeichnissynchronisation eingerichtet werden können.

Wie funktioniert das genau ?

Wenn sie KEIN Exchange 5.5 haben, dann können Sie jetzt aufhören zu lesen. für alle die Exchange 5.5 haben, hole ich zwei Dinge in ihre Erinnerung zurück:

  • Alle Exchange 5.5 Server in einem Standort (SITE) replizieren ihre Verzeichnisdatenbank (DIR.EDB) über RPC in regelmäßigen Abständen.
  • Verschiedene Standorte werden mit einen DirSync Connector verbunden. Die notwendigen Informationen zur Verzeichnisreplikation werden von einem Server in einem Standort zum anderen Server im entfernten Standort per MAIL versenden.

Soweit noch ganz einfach. Exchange 2000/2003 kennt aber keine "DIR.EDB mehr. Diese Informationen stehen im Active Directory in der Konfigurationspartition. (Siehe Exchange und das Active Directory). Also muss ein Prozess her, der die beiden Informationen abgleicht. Hierfür ist das "Config_CA" zuständig, welches im Active Directory Connector angelegt wird. Diese Verbindungsvereinbarung repliziert diese Information. Dazu verbindet es sich auf der einen Seite mit einem Active Directory Domain Controller. Auf der anderen Seite könnte es sich theoretisch mit dem Exchange 5.5 Server verbinden. Aber Gründe, auf die ich nu nicht näher eingehe, verbieten dieses. Daher behilft sich Exchange 2000/2003 damit, den SRS zu installieren.

Der SRS läuft auf einem Exchange 2000x Server mit und ist völlig unabhängig von den anderen Diensten, die ein Exchange Server noch so installiert (Store, SMTP, IIS, Systemaufsicht, MTA etc.). Dieser Dienst stellt sich der 5.5er Welt als Exchange Server mit einer DIR-EDB dar und nimmt einfach an der Replikation über RPC innerhalb des Exchange 5.5 Standortes teil. Damit es keinen Konflikt mit einem Active Directory auf dem gleichen Server geben kann, nutzt der SRS immer den Port 379. Erst ab Exchange 2003 kann dieser Port auch geändert werden.

Bild entnommen aus Exchange 2003 Buch.  Dort gibt es weitere Informationen zum SRS z.B: mit mehreren Administrativen Gruppen.

Und jetzt ist auch klar, warum das Config_CA sich immer mit dem SRS auf Port 379 verbindet und das auch nicht geändert werden kann.

Hinzu kommt, dass der SRS auch als System für die Verzeichnisreplikation mit dem Exchange 5.5 Connector zur Verzeichnisreplikation genutzt werden kann und in bestimmten Fällen auch als Gegenstelle für userCAs dienen muss.

Wann installiert sich der SRS ?

Der SRS kann nicht manuell installiert werden. Das Exchange 2000/2003 Setup erkennt bei der Installation des Servers, ob es in der Site, in die Exchange 2000/2003 installiert wird, schon einen weiteren Exchange 2000/2003 Server gibt. Dann entfällt der SRS-Dienst auf diesem Server. Ich kann aber den SRS-Dienst später manuell aktivieren, d.h. den Dienst konfigurieren und starten, wenn ich dies für notwendig erachte (z.B. Fehlerredundanz oder Serververlagerung)

Ist der Exchange 2000/2003 Server der erste Server in einer gemischten Site, dann wird der SRS automatisch installiert. Es gibt also je Exchange 5.5 Site (= Exchange 2000 Administrative Gruppe), in der auch ein Exchange 2000 Server ist, genau einen SRS-Dienst. Exchange 2000 Administrative Gruppe ohne Exchange 5.5 Server haben keinen SRS-Dienst. Standorte ohne Exchange 2000/2003-Server haben auch keinen SRS. für diese beiden Standorttypen übernimmt dann ein anderer SRS die Aufgabe (->Preferred SRS)

Der Administrator kann nun weitere SRS-Dienste manuell hinzufügen. Allerdings erreicht man damit keine Fehlerredundanz, da immer nur ein SRS für eine Site zuständig ist. Ein zweiter SRS ist nur dann erforderlich, wenn andere Exchange 2000/2003 Native Sites installiert werden und Sie die Replikation dieser Inhalte verteilen wollen oder wenn Sie den bisherigen SRS deinstallieren wollen.

Was repliziert der SRS ?

Der SRS-Service ist aber nur indirekt für die Synchronisation der Postfächer, Verteiler und Strukturen verantwortlich. Der Active Directoy Connector ist weiterhin eine wichtige Komponente. Und das "Config-CA"-Agreement ist für die Synchronisation zwischen dem Active Directory und dem SRS-Dienst zuständig. Diese CA wird automatisch bei der Installation von Exchange 2000 eingerichtet. Sie dienst dazu, dass die Exchange 2000 Administrative Gruppen nach Exchange 5.5 und die Exchange 5.5 Standorte als Administrative Gruppen nach Exchange 2000 synchronisiert werden. Über den SRS werden weiterhin.

Weiterhin werden über den Zwischenschritt des SRS auch die Connectoren und Leitwege zwischen Exchange 5.5 und Exchange 2000 synchronisiert. Daher ist die einwandfreie Funktion des SRS ein essentielles Element zum erfolgreichen Parallelbetrieb von Exchange 5.5 und Exchange 2000 in einer Organisation. Siehe auch http://www.Microsoft.com/mspress/books/sampchap/4918a.asp

SRS und Administrative Gruppen ohne Exchange 5.5 Server, PreferredSRS

Eine weitere Besonderheit kommt der SRS-Datenbank zu, wenn es Standorte (bzw. Administrative Gruppen) gibt, in denen nur Exchange 2000 Server installiert sind. Da diesen Standorten ein Exchange 5.5 Server fehlt, kann daher auch kein Connection Agreement für Benutzer und Gruppen im ADC eingerichtet werden. Dies ist aber notwendig, damit Benutzer und Verteiler repliziert werden. Hierzu wird das CA auf den Exchange Server mit dem SRS eingerichtet, da dieser als einziger auch diese Standorte im Exchange 5.5. Verzeichnis beschreiben kann, obwohl er selbst in einem anderen Standort ist. Normalerweise kann ein Exchange 5.5. Server immer nur die Benutzer und Ordner in seinem eigenen Standort im Verzeichnis ändern.

Nur welcher SRS ist denn für solche eine administrative Gruppe zuständig, die keinen SRS hat ?. Ein anderer SRS übernimmt die Aufgabe und zur Ermittlung nutzt Exchange ein sehr seltsames Verfahren über Hashwerte der Namen der administrativen Gruppen. Der SRS, dessen Hashwert am nächsten kommt, ist der zuständige SRS. Dass das in größeren Umgebungen nicht immer sinnvoll ist, versteht sich von selbst. In der Regel möchte der Administrator, dass ein bestimmter SRS z.B.: in der Hauptstelle hierfür zuständig ist, weil da auch der ADC installiert ist. Seit Exchange 2000 SP2 können Sie steuern, welcher SRS zuständig ist.

  • 315408 XADM: How to Control Which Site Replication Services Owns a Site

Über einen Eintrag in der Beschreibung der Admin Group wird gesteuert, welcher SRS zuständig ist

Natürlich ist auch die SRS-Datenbank geeignet zu sichern, um beim Defekt des Servers die Datenbank erfolgreich wieder herstellen zu können. Daher ist auch hierzu ein Exchange 2000 kompatibles Backup notwendig. Der SRS nutzt auch hierzu eine der DIR.EDB ähnliche Datenbank. Genau wie die anderen Datenbanken sollte ein dateibasierter Virenscanner hier die Finger von lassen.

SRS im Exchange System Manager

Den SRS finden sie, obwohl er eigentlich an den Server gebunden ist, unter dem Menü "Tools". Im Active Directory hingegen sind die Einstellungen schon beim Server abgespeichert.

Hier ist es auch möglich, die Ansicht derart umzustellen, um die im SRS konfigurierten Konnectoren zur Verzeichnissynchronisation zu sehen.

Die Einstellungen können und sollten auch hier nicht geändert werden.

Super KCC

Im Active Directory gibt es den KCC (Knowledgebase Consistency Checker), Dessen regelmäßige Aufgabe ist die Prüfung der Infrastruktur auf Veränderungen um gegebenenfalls Aktionen durchzuführen, z.B.: Connectoren zur Replikation einzurichten. Mit dem SRS gibt es einen SKCC (Site Knowledge Consistency Checker), der im Bezug auf Exchange alle drei Stunden die Infrastruktur überprüft. In einer gemischten Umgebung, nur hier brauchen Sie den SRS, kann es auch Standorte geben, in denen nur Exchange 5.5 oder nur Exchange 2000/2003 Server installiert sind. für diese Standorte gibt es keinen SRS. Trotzdem müssen auch diese Informationen über einen SRS und das dazu gehörige ConfigCA zwischen den Welten repliziert werden. Daher stellt der SKCC dies fest und bestimmt einen SRS für jeden einzelnen Standort. Jeder Exchange 5.5 Standort "gehört" sozusagen einem SRS. Dies können Sie anhand der Beschreibung der administrativen Gruppe auch selbst steuern, um z.B. die Replikation zu optimieren. Damit nicht zwei SRS-Services die gleiche Administrative Gruppe nutzen, wird der Besitzer in das Active Directory geschrieben. Der Besitzer einer reinen Exchange 2000x administrativen Gruppe steht in "msExchServer1ExportContainer", der SRS für einen Exchange 5.5 Standort steht entsprechend in "msExchServer2ExportContainer".

Weitere Infos zum Hintergrund sind dann auch hier: http://blogs.msdn.com/exchange/archive/2004/04/13/112453.aspx

4. If the local SRS wins arbitration, it does a few things to take ownership of the site. It adds that AG’s DN to its msExchServer1ExportContainers on the Config CA. It also adds that site as an inbound site on the local ADNAutoDRC directory replication connector. Note that the ADNAutoDRC is a disabled DRC, it doesn’t actually replicate anything – but it does have a special purpose which we will get to

5. Once the Config CA replicates to the SRS, it will see the new export container, and it will create some new naming contexts in the local SRS database für the pure AG. It creates these as writeable replicas so that it can actually write changes für that site directly in the local database – much different than usual dirrep of remote sites, where the local replica is NOT marked as writeable. So, now, the Config CA can write stuff like the Pure AGs servers and connectors and other config information directly into the SRS database

ADNAutoDRC

In diesem Zuge ist auch der Eintrag "ADNAutoDRC" zu nennen, der nach der Installation eines SRS im Exchange 5.5 Verzeichnis auftaucht und auf "Never" steht. In Exchange 5.5 werden die Verzeichnisinformationen zwischen den Standorten per Mail mittels den Connectoren zur Verzeichnisreplikation übertragen. Gibt es nun "reine" Exchange 2000/2003 Standorte, dann würden diese samt ihrer Benutzerinformationen nicht in der Exchange 5.5 Welt auftauchen. Und genau hier simuliert der ADMAutoDRC die Verbindung. Aus Sicht der Exchange 5.5 Welt sind die reinen Exchange 2000/2003-Standorte über diesen Verzeichniskonnector angebunden und die Exchange 5.5 Welt zufrieden.

Nur wirklich zu tun hat der Connector nichts, denn die Daten bekommt die SRS-Datenbank direkt über das ConfigCA und die zusätzlich eingerichteten ADC-Verbindungsvereinbarungen für Benutzer, Verteiler und öffentliche Ordner. (Siehe auch Active Directory Connector Grundlagen).

SRS und Exchange 5.5 Administrator

Der Exchange 2000 Server mit der SRS-Datenbank ist auch der einzige Server, auf den mit dem Exchange 5.5 Administrator zugegriffen werden kann. Dies ist auch gelegentlich zu machen, das sie so z.B. erkennen können, ob die Exchange 2000 Welt komplett in die Exchange 5.5. Welt abgebildet wird. Besonders ist hier die Anzahl der Empfänger in der "Globalen Adressliste" zu kontrollieren, da so sehr schnell und einfach unstimmigkeiten bei der Synchronisation mit dem ADC festgestellt werden können.

SRS und Grenzen

Der SRS nutzt wie der Exchange 5.5 Verzeichnisdienst selbst Mails zum Austausch der Verzeichnisnachrichten. Damit können Sie diese Funktion natürlich empfindlich stören, wenn Sie mit Empfangsbeschränkungen (siehe Limits, oder wie kann ich Grenzen setzen) arbeiten.

Weitere Links

  • Active Directory Connector ConfigCA
  • Exchange 2000/2003 SRS entfernen
  • SRS hart entfernen
  • Q239758 XADM: SRS Can't Run in Native Exchange 2000 Environment
  • Q251126 XADM: Troubleshooting the Site Replication Service When Information Does Not Replicate to Active Directory
  • 251395 XADM: Summary of the Exchange 2000 Recipient Update Service
  • 253828 XADM: How the Recipient Update Service Populates Address Lists
  • Q255285 XADM: How to Create an Additional SRS für Mixed Site
  • Q261227 XADM: Exchange 2000 Servers Not Replicated to Exchange Directory
  • Q271378 XADM: Exchange Server 5.5 Administrator Program Connects to an Exchange 2000 Computer
  • Q272314 XADM: Preparing a Mixed Mode Organization für Conversion to Native Mode
  • Q282061 XADM: How to Rebuild a Site Replication Service Without a Backup
  • Q282108 XADM: Exchange 2000 Site Replication Service Cannot Be Moved
  • Q284148 XADM: How to Remove the Last Exchange Server 5.5 Computer from an Exchange 2000 Administrative Group
  • 288807 XADM: Troubleshooting the Recipient Update Service
  • Q291170 XADM: Cannot See Exchange 2000 Mailboxes from Exchange 5.5
  • 297124 XADM: Recipient Update Service Does Not Stamp users and No Error Is Logged
  • Q298611 XADM: SRS May Stop Responding Because of an RPC Denial of Service Attack
  • 313646 XADM: Services Are Disabled on Front-End Servers After an Exchange 2000
  • Probekapitel aus einem MCSE
    http://www.Microsoft.com/mspress/books/sampchap/4918a.asp
  • 315408 XADM: How to Control Which Site Replication Services Owns a Site
  • 319065 HOW TO: Work with the Recipient Update Service in Exchange 2000
  • 319889 The Configuration Connection Agreement Does Not Replicate the Information
  • Blog: Exchange 2000/2003 SRS - how does it fit into the big picture?
    http://blogs.msdn.com/exchange/archive/2004/11/12/256560.aspx
  • Blog: More on Exchange 2000/2003 SRS + SRS troubleshooting tips!
    http://blogs.msdn.com/exchange/archive/2004/11/19/266841.aspx
  • Blog: Pure Exchange 2000 Admin Groups and Group Membership
    http://blogs.msdn.com/exchange/archive/2004/04/13/112453.aspx