Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Problembeschreibung
Sie können das Cmdlet Invoke-CsManagementServerFailover nicht ausführen, um ein Failover des zentralen Verwaltungsspeichers (CMS) (Failback) auszuführen, nachdem ein weiteres Failover ausgeführt wurde. Dieses Problem tritt in einem der folgenden Szenarien auf:
Szenario 1
Angenommen, Sie führen ein Erzwungenes Failover aus, da einer der Pools nicht verfügbar ist. Nachdem die Poolfunktionalität wiederhergestellt wurde, versuchen Sie, einen weiteren Failovervorgang auszuführen, indem Sie das Cmdlet Invoke-CsManagementServerFailover ausführen, und Sie erhalten die folgenden Fehlermeldungen:
###50020:XDSForceReplication: Dieser zentrale Verwaltungsspeicher wird an einen anderen Speicherort verschoben. Bis zum Abschluss dieser Verschiebung können keine Änderungen vorgenommen werden.
WARNUNG: Die Datenbank des zentralen Verwaltungsspeichers in Active Directory stimmt nicht mit der Datenbank in der Topologie überein.
Szenario 2
Dieses Problem tritt auf, wenn Sie das zweite Failover unmittelbar nach dem vorherigen Failover ausführen und sich der Pool noch nicht in einem konsistenten Zustand befindet. Wenn Sie versuchen, das Cmdlet Invoke-CsManagementServerFailover auszuführen, erhalten Sie die folgenden Fehlermeldungen:
Invoke-CsManagementServerFailover: Für den zentralen Verwaltungsserver kann kein Failover ausgeführt werden. Der neue zentrale Verwaltungsspeicher unter "skypepool.contoso.com" befindet sich nicht im Sicherungsmodus.
Invoke-CSManagementServerFailover: Der zentrale Verwaltungsserver kann nicht in den Pool skypepool.contoso.com verschoben werden, da entweder ein vorheriger Failoverversuch ausgeführt wird oder bereits ein Failover ausgeführt wird. Wenn der zentrale Verwaltungsserver kürzlich in einen anderen Pool verschoben wurde, kann diese Bedingung durch eine Verzögerung bei der Active Directory-Replikation verursacht werden.
Szenario 3
Die ActiveMasterFqdn-status ist leer, wenn Sie das Cmdlet Get-CsManagementStoreReplicationStatus –CentralManagementStoreStatus ausführen.
Ursache
Szenario 1
Wenn der Standard Pool nicht verfügbar ist, wird die CMS-status, die in Datenbanken beibehalten wird, weiterhin als aktiv festgelegt. Wenn die Poolfunktionalität wiederhergestellt wird, kann es länger dauern, bis die Sicherungsdienste das CMS als im Sicherungsmodus markieren, die CMS-Replikation fehlschlägt, und ein Failover kann blockiert werden.
Szenario 2
Wenn ein Failover nicht abgeschlossen wird und unmittelbar danach ein weiteres Failover ausgeführt wird, kann das CMS aufgrund eines Racebedingungsproblems entweder als aktiv oder als Sicherungsmodus gekennzeichnet werden.
Szenario 3
Dieses Szenario kann als Nebeneffekt von Szenario 1 oder Szenario 2 auftreten.
Lösung
Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:
- Überprüfen Sie, ob die folgenden Dienste in beiden Pools gestartet werden:
- Skype for Business Server Backup Service
- Skype for Business MasterReplikator-Agent
- Skype for Business Replikatreplikations-Agent
- Skype for Business-Dateiübertragungs-Agent
Führen Sie in der Skype for Business Server-Verwaltungsshell das Cmdlet Get-CsManagementConnection aus, und ermitteln Sie, welcher Pool derzeit dem SQL Server Speicher zugeordnet ist, der von der SQL Server Ausgabe zurückgegeben wird.
Führen Sie auf einem der Dem identifizierten Pool zugeordneten Server das Cmdlet Invoke-CsManagementServerFailover -Restore in der Skype for Business Server-Verwaltungsshell aus.
Führen Sie auf jedem Server des identifizierten Pools die folgenden Cmdlets in der Skype for Business Server-Verwaltungsshell nacheinander aus:
- Export-CsConfiguration -FileName c:\temp\configuration.zip
- Import-CsConfiguration -FileName c:\temp\configuration.zip -LocalStore
Hinweis
Nachdem der Prozess ergänzt wurde, kann die configuration.zip Datei gelöscht werden. Es wird jedoch empfohlen, eine Kopie der Datei für die Notfallwiederherstellung aufzubewahren.
Führen Sie auf jedem Server des zuvor identifizierten Pools das Cmdlet Invoke-CsManagementStoreReplication in der Skype for Business Server-Verwaltungsshell aus.
Führen Sie das Cmdlet Invoke-CsManagementServerFailover aus, um erneut ein CMS-Failover auszuführen.
Weitere Informationen
Benötigen Sie weitere Hilfe? Navigieren Sie zu Microsoft Community.