Lync Central Management Store (CMS)

Anders als noch bei OCS legt Lync eine wichtige Konfigurationsinformation in einer SQL-Datenbank ab. Auf dem ersten Lync-Server wird bei der Installation diese "Master"-Datenbank mit dem Namen XDS in der SQL-Instanz RTC angelegt.

CMS Grundlagen

Der erste Lync-Server betreibt auch die Master-CMS-Datenbank. Diese liegt bei einem Standard Server "lokal", und bei der Installation als Enterprise Pool auf dem Backend SQL-Server. Alle Aktionen des Topologie-Builder werden immer auf diese Datenbank ausgeführt und über einen Replikationsmechanismus (Port 444) auf die anderen Server übertragen. In der CMS-Datenbank liegen aber nicht nur die Server und deren Verbindungen, die Sie im Topologie-Builder pflegen, sondern auch diverse andere Einstellungen, z.B. CSAllowedDomains oder CSHostingProvider, die über den Weg z.B.: den Weg zum Edge-Server finden. Insofern gibt es drei Programme, die die CMS verändern:

Und natürlich eigene Skripte, die z.B. die API über "Microsoft.Rtc.Management.Core.dll" ansprechen. Im CMS liegen aber NICHT die Informationen über die Lync Anwender (also SIP-Adressen) und auch nicht deren dynamischen Daten (Buddylisten etc.)

CMS im Active Directory

Damit alle Dienste sehr einfach heraus finden können welcher Lync Server gerade der "Master" ist, wird die entsprechende Information im Active Directory hinterlegt. Es ist wieder einmal ein "Service Connection Point" vom Typ "msRTCSIP-GlobalTopologySetting", nachdem sie auch einfach suchen können. er ist aber auch mit ADSIEDIT und anderen Tools einfach in der Configuration-Partition zu finden:

CN=Topology Settings, CN=RTC Service,DC=<domain>
Typ: msRTCSIP-GlobalTopologySetting
Attribute: msRTCSIP-BackEndServer enthält den FQDN und die SQL-Instanz des CMSMaster

Diese Daten können auch per Powershell ausgelesen werden.

Dies ist aber nur der "Verweis" für das Lync Control-Panel, um den Lync-Server mit der CMS zu finden. Kann das Control Panel diesen Wert nicht lesen, dann erfragt es vom Administrator einfach eine URL.

Replikation im Allgemeinen

Die CMS-Struktur beruht auf einer "Single Master" Replikation. Bei bei früheren NT4 Domain Controllern gabt es dort immer einen PDC, auf dem alle Änderungen vorgenommen wurden und die dann auf die BDCs repliziert wurden. Für "lebende Daten", wie einer Domäne skaliert dieses Modell nicht gut genug. Für relativ statische Konfigurationen hingegen ist eine solche einfacher zu handhabende Replikation durchaus passend.

Jeder Server mit einer Lync-Rolle betreibt daher eine kleine SQL-Express-Datenbank mit dem Namen "RTCLOCAL", in welcher die Kopie der Konfiguration vorliegt. Eine Instanz mit dem Namen RTC ist der Master und liegt bei kleineren Umgebungen mit auf dem ersten Standard Server, d.h. dort gibt es sogar zwei SQL-Instanzen.

Wurde als erster Server ein "Enterprise Pool" angelegt, dann liegt die Masterdatenbank auf dem Backend SQL-Server und wird von den Frontends mit bedient. Trotzdem haben dann auch die Frontends weiterhin eine lokale RTCLOCAL-Datenbank:

 

Für die Replikation sind drei Dienste maßgeblich:

Das Ganze nutzt dann noch den Windows Serverdienst, welcher die SMB-Freigaben auf den Servern bereit stellt und sieht wie folgt aus:

Die einzelnen Stationen sind:

Station Beschreibung
Änderungen an den Informationen in der XDS dürfen "nur" über die von Microsoft bereit gestellten APIs und Programme erfolgen. Das sind der Lync Topologybuilder, das Lync Control Panel und die Lync Powershell-Befehle. Eine direkte Veränderung der XML-Dateien ist nicht erlaubt und auch nicht ganz so einfach, da intern durchaus Versionen mitgezählt werden.
Auf dem CMS-Master läuft der "Lync Server Master Replicator Agent (MASTER)", welcher alle 60 Sekunden in der lokalen Datenbank nachschaut, ob eine Veränderung durchgeführt wurde. Ist die der Fall, dann erstellt dieser Dienst entsprechende Pakete und legt diese in der lokalen Dateistruktur ab.
Der ebenfalls auf dem Master-Server installierte "Lync Server File Transfer Agent (FTA)" überwacht die Verzeichnisse auf Änderungen (Change Notification) kann daher ohne Verzögerung die neuen Pakete zu den Replikationspartnern übertragen. Mit Ausnahme des Edge-Servers kopiert der FTA diese Paket per SMB auf die Freigaben (XDS-REPLICA) der Zielserver
Da der Edge-Server in der Regel eben nicht Mitglied der Domäne ist und auch nicht immer per SMB erreichbar sein wird (keine Dateiserverrolle installiert, Firewall blockt RPC etc.) ist es nur verständlich, das hierzu ein anderer Weg gewählt werden musste. Der Replika-Dienst auf dem Edge stellt auf Port 4443 (kein Tippfehler !!) einen Webservice bereit und bekommt so natürlich sofort mit, wenn etwas zu verarbeiten ist. Der IIS muss dazu nicht installiert sein.
Der Replika-Dienst auf den normalen Rollen wiederurm überwacht auch "seine" Verzeichnisse und bekommt über eine NTFS "Change Notification" eine neue Datei gemeldet. Die Änderungen werden in die lokale RTCLOCAL-Datenbank eingebucht.
Der Erfolg dieser Aktion wird als Statuspaket wieder zum Master zurück gesendet, indem das Paket in der Verzeichnisstruktur bzw. über den Webservice bereit gestellt wird
Die Lync-Dienste selbst prüfen eigenständig alle 60 Sekunden, ob sich für ihre Funktion relevante Konfigurationseinstellungen geändert haben, laden diese dann aus RTCLOCAL und setzen diese um
Der FTA prüft alle 60sek bei seinen Partnern nach, ob dort ein Statuspaket vorliegt. Dieses wird dann abgeholt und über die lokale Verzeichnisstruktur an den MASTER-Dienst weiter gegeben, welcher die Meldung verarbeitet und in der Datenbank den Status aktualisiert.

Mich wundert ein bisschen, dass Microsoft den Umweg über SMB gegangen ist und nicht gleich den gleichen WebService des Edge auf allen Servern implementiert hat. Oder einen ganz anderen Weg gewählt hat und die Konfiguration einfach als "SIP-Message" zwischen den Server überträgt. Aber Sie werden ihre Gründe gehabt haben.

Verzeichnisse und Shares

Achtung
Per Default haben nicht mal Administratoren Zugriffsrechte und sie müssen sich erst zum "Owner" machen. Das sollten Sie aber unterlassen, da dann die ACLs verändert werden, so dass NUR noch der Administrator berechtigt ist und die Replikation bricht.

Die Verzeichniss der CMS Replikation sind durch NTFS-ACLS gesichert. Die Rechte sind an entsprechende Lokale Gruppen und Domänengruppen vergeben. und sollten NICHT geändert werden.

Solche Fehler werden dann im Eventlog umgehend sichtbar:

Log Name:      Lync Server
Source:        LS File Transfer Agent Service
Event ID:      1034
Task Category: (1121)
Level:         Error
Description:
Microsoft Lync Server 2010, File Transfer Agent service encountered an error while accessing a file share
and will continuously attempt to access this file share until this issue is resolved. While this condition
 persists, replication to replica machines might not occur.

Can't watch nawlync001.netatwork.de.
Cause: Possible issues with file share permissions. This can occur if the computer hosting the file share 
has outdated cached credentials for the computer that is trying to access the file share.
Resolution:
For details about how to resolve file share permission issues, see the product documentation.
Log Name:      Lync Server
Source:        LS Replica Replicator Agent Service
Event ID:      3032
Task Category: (3003)
Level:         Error
Keywords:      Classic
Description:
Microsoft Lync Server 2010, Replica Replicator Agent service encountered an error while accessing a file 
share and will continuously attempt to access this file share until this issue is resolved. While this condition 
persists, replication to this replica machine might not occur.

Can't watch NAWLYNC001.netatwork.de.
Cause: Possible issues with file share permissions. This can occur if the computer hosting the file share 
has outdated cached credentials for the computer that is trying to access the file share.
Resolution:
For details about how to resolve file share permission issues, see the product documentation.

Ein Anleitung für einen "Undo" habe ich noch nicht gelesen. Es gibt Hinweise, dass man die Verzeichnisse von einem anderen Server wieder kopieren kann. Alternativ können Sie natürlich versuchen, den Dienste die Rechte zu geben (Network System, RTC Local Replicator Agent (Servername)).

Wenn Sie unbedingt der CMS Replikation auf die Finger schauen wollen, dann addieren Sie ihr Konto einfach in die Gruppe der "SERVER\RTC Local Config Replicator"oder "DOMAIN\RTCUniversalConfigReplicator" (Default Mitglieder sind die Frontends). Dann können Sie ohne Veränderungen der NTFS-ACLs die Inhalte einsehen.

Die Replikation erfolgt über gepackte Dateien in den Verzeichnissen. Hier eine aufgeklappte Verzeichnisstruktur:

Struktur Share Bedeutung

Das Unterverzeichnis "xds-replica" ist freigegeben

Berechtigung xds-replicat

Dieses Verzeichnis gibt es auf jedem Server, der eine aktive Rolle in einer Lync-Umgebung spielt.

Im Verzeichnis "xds-replica\from-master" landet die DATA.ZIP, welche vom CMS Filetransferagent dort hin kopiert wird.

Umgekehrt erstellt der "Replica Replicator Agent" nach dem Import des Pakets eine STATUS.ZIP im Verzeichnis "xds-replica\to-master".

Diese wird dann wieder vom Client abgeholt

Das Stammverzeichnis "LyncShare" ist freigegeben. Name der Freigabe wird über den Topologie-Builder hinterlegt.

Diese größere Struktur auf dem zentralen Server ist im LyncShare zu finden. Hier finden Sie unter der xds-master-Struktur unter dem Verzeichnis "replica" auch ein Unterverzeichnis je Zielserver.

Hier erstellt der Master Replication Service pro Ziel ein Verzeichnis mit den Unterverzeichnissen, in denen dann die "DATA.ZIP Päckchen landen. Diese werden vom File Transfer Service dann an die Zielserver übertragen.

Aus diesem Verzeichnisbaum sind zwei Verzeichnisse auch "Freigegeben"

Replikation zu anderen Lync Rollen (außer Edge)

Wenn nun ein Server quasi der "Master" ist, dann müssen sich die Informationen natürlich auf die anderen Server übertragen werden. Entsprechende Datenbanken auf den anderen Servern mit einer Lync-Rolle werden bei der Installation von Lync dort schon angelegt. Die Replikation der Konfiguration erfolgt letztlich über XML-Dateien, die von der Quelle in das Ziel übertragen und dann in die SQL-Datenbank "XDS" eingespielt werden.

Replikation zum Edge-Server

Die Edge-Rolle unterliegt einer Besonderheit. Da hier üblicherweise nicht davon ausgegangen wird, das der Edge Server aus einem Perimeter-Netzwerk z.B. auf den internen Lync-Server  Anders als "intern" werden die Konfigurationen zum Edge nicht per Dateishare kopiert, sondern vom CMS Master per HTTPS hochladen. Dazu bietet der Replication-Agent auf dem Edge einen Webservice auf dem Port 4443 an. Vom internen CMS-Master können Sie auch einfach per Browser diese Adresse ansprechen, aber erhalten natürlich eine Meldung, dass der Webservice keine Metadaten veröffentlicht.

Dennoch ist dies ein guter Test, dass die Namensauflösung und eventuelle Firewall-Freigaben funktionieren. Ein Blick in den Taskmanager oder mit NETSTAT auf dem Edge-Server sollte auch zeigen, das er auf Port 4443 auf Verbindungen wartet.

Oft gibt es hier Probleme, weil sich die Server per Zertifikate gegenseitig authentifizieren. Speziell wenn auf dem Edge Server zu viele Root oder Intermediate -Zertifikate sind und sich damit das Zertifikat "aufbläht", kann die Replikation unterbrochen werden, weil einfach die Zertifikatskette nicht mehr geprüft werden kann. Folgender Eintrag auf dem Edge kann dann helfen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"SendTrustedIssuerList"=dword:0

Damit wird die schannell.dll angewiesen, die RootCA-Liste nicht mehr mit zu senden und damit im SSL-Handshake nicht an die Grenze des Puffers zu stoßen. Voraussetzung ist dann aber, dass die Server die Stammzertifikate und Intermediate-Zertifikate lokal vorliegen haben.

In Verbindung mit Windows 2012 kommt noch ein anderes Thema zum Tragen. Wenn ihre Edge Server keine CMS-Replikation mehr bekommen, dann lesen Sie bitte auch Windows 2012 und TLS.

Replikation zu anderen Servern, die aber keine lokale Lync Datenbank vorhalten

Wer z.B. in der Lync Umgebung noch andere Dienste (z.B. Exchange OWA, OCS2007R2 CWA) betreibt, kann diese als "Trusted Server" addieren. Diese Server haben aber in der Regel keine "Lync Rolle", sondern sind eben Server, die z.B. per UCMA oder andere Schnittstellen mit Lync arbeiten und als "vertrauenswürdig" behandelt werden sollen:

Da diese Systeme natürlich kein Replikation der Datenbank bekommen, sollten Sie diese im Topologie Builder auch entsprechend kennzeichnen.

Wenn Sie dies nicht tun, dann hat das erst mal keine direkten Auswirkungen. Nur wird der CMS natürlich weiter versuchen diese Systeme mit Daten zu beliefern bzw. in seiner Datenbank den Status als "False" mitführen.

Replikation im Control Panel anzeigen

Wie "aktuell" die verschiedenen Instanzen kann ein Administrator einfach im Lync Control Panel anzeigen:

Die kleinen grünen Haken in der letzten Spalte zeigt den aktuellen Status der Replikation. Wer das automatisieren will, ist bei der Powershell besser aufgehoben.

Replikation mit Get-CSManagementStoreReplicationStatus prüfen

Lync bringt auf der Powershell einen Befehl mit, welcher in die XDS-Datenbank des Masters schaut und dort den Replikations-Status aller Server anzeigt. Diese Information kann natürlich etwas "verzögert" sein, da Sie von der Rückkehr der Statusmeldungen abhängig ist. Wenn Sie also gerade eine Änderung durchgeführt haben, dann kann es durchaus einige Minuten dauern, bis alle Server die Infos bekommen haben und die Statusmeldungen zurück gekommen sind.

Sollte aber eine Verzögerung länger als z.B. 10 Minuten anhalten, dann dürfte irgendwie der Kommunikationskanal unterbrochen sind. Bei dem Bild ist gut zu sehen, dass von dem Edge-Server bei dem Kunden schon fast 2 Monate unbemerkt keinen Status mehr angekommen ist. Die "Funktion" hat das aber nicht weiter betroffen, weil in der Zeit keine Server oder Domains addiert wurden und sich für die Edge-Rollen nichts weitere ergeben hat. Ob wirklich nur der Status gefehlt hat oder die Konfiguration nicht im Ziel angekommen ist, musste eine genauere Untersuchung zeigen.

Wer die Replikation per Powershell überprüfen will, kann dies z.B. mit folgendem Befehl sehr einfach tun.

$lastupdate = (Get-CsManagementStoreReplicationStatus -centralManagementStoreStatus).LastUpdatedOn
Get-CsManagementStoreReplicationStatus | Where-Object {$_.LastUpdateCreation -lt $lastupdate}

Alternativ kann man natürlich das Feld "UpToDate" abfragen. Wer es perfekt machen will, liest natürlich das Datum der letzten Änderung aus und stellt sicher, dass die Prüfung erst nach Ablauf einer Wartezeit (z.B. 5 Minuten) erfolgt.

Replikation mit Invoke-CsManagementStoreReplication forcieren

In der Regel löst eine neue Forcierung nicht ein eh vorhandenes Problem. Das erneute Anstoßen ändert nur einen Eintrag in der Datenbank, damit die Konfiguration als "geändert" erscheint. Sie sehen dann in der Regel nach zwei Minuten, welche Server sich problemlos replizieren. Aber es kein aktives Anstoßen von Diensten.

Normalerweise sorgt schon Lync dafür, dass die Daten sauber repliziert sind und wenn wirklich mal eine Instanz nicht funktioniert, dann ist ein Blick ins Lync Eventlog meist aussagekräftig. Sie können aber über einen Powershell Befehl auch eine Replikation erzwingen, wenn Sie nicht sowieso per Topology-Builder eine neue "Version" der Topologie veröffentlichen wollen.

Invoke-CsManagementStoreReplication -ReplicaFqdn lync.msxfaq.de

Dieser Befehl entfernt den Replikationsstatus in der CMS und erzwingt damit eine komplette Replikation.

Fehlersuche mit Eventlog

Wie für jedes anständige Windows Programm ist eine Meldung von Fehlern und Problemen im Eventlog der beste Weg, den Administrator zu informieren. Daher gilt der erste Blick natürlich dem Lync-Eventlog, welche auf dem CMS-Master vorhanden ist. Hier sollte sich der "Lync Master Agent" und der "Lync File Transfer Agent" melden. Und tatsächlich meldete hier der Lync File Transfer Agent Server schon länger mit einem:

Log Name:      Lync Server
Source:        LS File Transfer Agent Service
Event ID:      1022
Task Category: (1121)
Level:         Information
Description:
Waiting on a response from the replica machine nawlyncedge.netatwork.de. Microsoft Lync Server 2010, 
File Transfer Agent will continue to wait and retry this operation if it experiences a timeout.

Es scheitert also schon am Versand der aktualisierten Konfiguration an den WebService des Edge Servers. Natürlich könnten Sie nun gleich mal NetMon starten und alle Verbindungen auf Port 443  (Filter  "tcp.port == 4443") mitschneiden.

Einfacher und schneller ist aber der Blick auf das Eventlog des Edge Servers, welcher ja die Gegenstelle der Verbindung ist. In meinem Fall war die Ursache für die Störung hier auch schon zu sehen: In diesem Fall hat also nicht ein übereifriger Firewall-Admin den Port 4443 aus Unkenntnis geschlossen.

Log Name:      Lync Server
Source:        LS Replica Replicator Agent Service
Event ID:      3032
Task Category: (3003)
Level:         Error
Description:
Microsoft Lync Server 2010, Replica Replicator Agent service encountered an error while accessing a file share
 and will continuously attempt to access this file share until this issue is resolved. While this condition 
persists, replication to this replica machine might not occur.

IO failure occurred for Path=C:\RtcReplicaRoot\xds-replica\working\replication\tmp. 
Exception=Access to the path 'C:\RtcReplicaRoot\xds-replica\working\replication\tmp\1e4a1458f' is denied..
Cause: Possible issues with file share permissions. This can occur if the computer hosting the file share 
has outdated cached credentials for the computer that is trying to access the file share.
Resolution:
For details about how to resolve file share permission issues, see the product documentation.

Der Replika-Dienst auf dem Edge konnte die empfangenen Dateien einfach nicht speicher. Ursache war hier eine irrtümlich Veränderungen der Berechtigungen auf dem Server. Anscheinend wollte da jemand in den Ordner "XDS-Replica" schauen und hat sich zum "Owner" gemacht und damit nicht nur sich die Rechte gegeben, sondern auch die ACL-Vererbung abgeschaltet und damit die RTC-Replikationsdienste ausgesperrt. Kaum war dieses Problem behoben, war der Status wieder auf "grün"

Manchmal helfen auch die kleinen allseits bekannten Helfer wie PROCMON und NETMON, um eventuellen Fehlern auf die Schliche zu kommen. Hier ein Beispiel mit Procmon und dem File Replications Dienst

Fehlersuche mit Snooper

Wenn das Eventlog alleine nicht weiterhilft, dann ist sind die bekannten Lync Protokollfunktionen hilfreich bei der Fehlersuche, Aktivieren Sie in Snooper bei der Auswahl die passenden Optionen und starten Sie die Replikation.

Nach einigen Minuten können Sie den Trace anhalten und sich die geschriebene Textdatei auf Fehler anschauen. In der Regel sind die Meldungen sehr ausführlich. Sie sollten aber sicherstellen, das sie S4 und SIP-Stack und andere Einträge deaktiviert haben, damit wie wirklich nur die relevanten Einträge bekommen

Manuell exportieren und importieren

Wer den ersten Edge ohne Domänenmitgliedschaft installiert, wird beim Setup schon gefragt, wo denn die XML-Datei mit der Konfiguration ist. Aber auch wenn Sie eine Lync-Rolle installieren und kein Zugriff auf den SCP im Active Directory oder die SQL-Datenbank des Master möglich ist, müssen die die Konfiguration einmalig auf den Server importieren. In seltenen Fällen scheint es auch in Verbindung mit umfangreichen Änderungen (IP-Adressen etc.) schon erforderlich geworden zu sein, die Konfiguration manuell zu kopieren, weil die Dienste sich einfach nicht mehr gefunden haben. Dazu helfen die folgenden Befehle:

Auf dem CMS-Master kann die Konfiguration einfach exportiert werden

Export-CsConfiguration -FileName "C:\Config.zip"

Übrigens ist dies auch eine einfache Möglichkeit, z.B. jeden Tag einen "Schnappschuss" abzulegen. Diese ZIP-Datei können Sie auch für die Installation eines Edge-Servers verwenden. Auf dem Zielsystem kann die Konfiguration wie folgt importiert werden.

Import-CsConfiguration -FileName "C:\Config.zip" -LocalStore

Der Import ist aber, wie gesagt, eher der Notfall und nicht die Regel

CMS verschieben

Soll der Lync Server deinstalliert werden, dann sind einige Dinge vorab zu erledigen, z.B. Lync Anwender verschieben, Konferenz-Verzeichnisse verschieben etc. Und letztlich muss irgendwann auch die CMS verschoben werden. Da aber alle Server ja hoffentlich die Datenbank "in Sync" haben, ist das Verschieben mehr ein Bestimmen des Masters

Achtung:
Move-CsManagementServer kann auch für einen "Desaster Fall" genutzt werden, z.B. wenn ihr CMS-Server zerstört wurde und ein Restore nicht möglich ist. Dann können Sie auch "hart" einen anderen Server, der möglichst eine aktuelle Version der Konfiguration hat, über diesen Befehl zum Master hochstufen.

Die "normale" Verlagerung des CMS-Masters auf einen anderen Server erfolgt in wenigen Schritten:

Install-CSDatabase -CentralManagementDatabase -SqlServerFqdn sql01.msxfaq.de -SqlInstanceName rtc

Enable-CsTopology

Move-CsManagementServer

Beachten Sie aber, dass nun auch die Replikation der anderen Server gegen den neuen Server läuft. Prüfen Sie daher, ob die Firewalls dieses neue Ziel zulassen.

Ehe Sie einen alten Lync-Server deinstallieren, müssen Sie aber noch andere Dienste verschieben. Einen Teil davon meldet ihnen schon der Topology-Builder, wenn Sie den Computer "entfernen" wollen. Dazu gehören auch LIS-Datenbanken, Konferenzverzeichnisse, ResponseGroups etc.

DeletedReplicas

Wird ein Lync Server abgebaut, dann sollten Sie diesen nicht einfach " Ausschalten", sondern geordnet außer Betrieb nehmen. Bei Lync erfolgt die über die Topologie. Hier muss zuerst der Server entfernt werden. Der Topologie Builder prüft dabei noch einmal etwaige Abhängigkeiten. Wenn sie hier den Server und davon abhängige Komponenten (z.B. FileShare, SQL-Datenbank) entfernt habe, können Sie die geänderte Topologie "veröffentlichen", d.h. in den zentralen CMS speicher. Es dauert dann wieder ein paar Minuten, bis alle Lync Server die neue Topologie haben. Der Topologie Builder meldet bei ihnen aber auch, welche weiteren Aktionen erforderlich sind (To-Do Liste)

Eine Aktion ist die Ausführung des "Deployment Builders auf dem Server, der noch mit Lync installiert aber nun aus der Topologie entfernt ist. Wenn die CMS-Replikation erforderlich war, sollte das Setup erkennen, welche Rollen der Server nun nicht mehr hat und diese Komponenten in der richtigen Reihenfolge vom Server entfernen. Warten sie auch hier noch etwas ab, damit die Deinstallation und der damit verbundene "Disable-CSComputer"

Wenn Sie dies nicht gemacht haben, dann ist ihre Liste hier nicht leer sondern enthält noch Server in "DeletedReplicas".

Zusätzlich finden Sie aber auch im Eventlog des CMS-Servers dann noch Hinweise bei der Replikation auf den nicht mehr vorhandenen Server. Der Hinweis MUSS nicht in der Datenbank stehen. Auch wenn Lync viele Dinge im CMS speichert, so liefen einige Einstellungen durchaus noch in der Configuration-Partition des Active Directory:

CN=Global Settings,CN=RTC Service,CN=Services,CN=Configuration,DC=netatwork,DC=de

Hier können Sie also auch einmal nachschauen, ob es noch Reste eines alten Servers gibt.

Weitere Datenbanken

Die CMS-Datenbank ist aber bei weitem nicht die einzige Datenbank. Sie ist verglichen zu seinen Brüdern und Schwestern sogar die kleinste und am wenigsten veränderliche Datenbank.

Weitere Links

Tags:Microsoft Lync 2010 CMS XDS Replika FTA