Skype for Business Patching

Updates auf Lync Servern zu installieren, war bislang wirklich sehr mühselig. Man musste eine ganze folge von Schritten einhalten, wenn ein Lync Pool "störungsfrei" aktualisiert werden sollte. Insbesondere sollten die Dienste vorher "pausiert" werden, damit die Anwender auf einen Frontend verwiesen werden. Wer Benutzer nicht verärgern wollte, sollte dann prüfen, ob alle Konferenzen beendet sind und dann die Dienste stoppen und deaktivieren. Das ist auf jedem Server quasi allein schon monatlich für die Windows Updates erforderlich gewesen. Die zusätzlichen Updates für den Lync Server waren noch gar nicht mitgerechnet. Mit Skype for Business ist das nun aber deutlich einfacher geworden. Wenngleich sie immer noch etwas Vorsicht walten lassen sollten. Mit dem Update auf Skype for Business Server gibt es zwei neue Commandlets, die hier wichtig werden:

Generelle Vorgehensweise

Um ihre eigenen Anforderungen an die Verfügbarkeit von Skype for Business Servern gerecht zu werden, sollten Sie Updates nicht einfach zu installieren, sondern einen Patchplan haben, den sie jedes Mal entsprechend abarbeiten. Dies gilt insbesondere für "hochverfügbar" ausgelegte Umgebungen mit Enterprise Pools, SQL-Mirroring und Loadbalancern. Ich habe mir angewöhnt, Skype for Business Server als "Inside Out" zu patchen, d.h. zuerst die Pools und dann die Edge und Director Server. Die Datenbankserver sind unabhängig aber Updates hierfür sollen sie auch installieren. In der Regel nutze ich folgenden Ablauf:

  1. Update der Frontend Server
    Dazu zählen Windows Updates, lokale SQL-Updates und Skype for Business Updates. Ggfls. sind hier zusätzliche Schritte wie ein "Enable-CSComputer" oder ein Update der Datenbanken mit "Install-CSDatabase" erforderlich.
  2. Update der Edge Server
    Danach aktualisiere ich in der Regel die Edge Server und, sofern vorhanden, Director Server
  3. SQL-Backend
    Sofern es auch für die Backend Datenbank eines Enterprise Pools anstehende Updates gibt, werden diese ebenfalls "geplant" installiert

All das ist flankiert von Überprüfungen.

Offen ist auf dieser Seite noch die Beschreibung für zwei gespiegelte Pools. Allerdings ist dies relativ einfach, da die meisten Firmen hier einen Pool einfach "patchen" und in der Zeit die Anwender auf dem BackupPool im "Reduced"-Mode arbeiten. Beim Einsatz von Telefonie und besonders Response Groups oder vielen Meetings kann es ratsam sein, die Anwender "umzuziehen". Das ist aber eine individuelle Entscheidung. Pool Pairing ist eben keine "Hochverfügbarkeit"

Ich beschreibe bei den Schritten nicht, dass sie vor dem Update natürlich ihre Überwachungslösung entsprechend pausieren, damit sie keine Alarme und Tickets generiert und vor allem keine korrigierenden Maßnahmen einleitet.

Patch Tabelle

Eine Skype for Business Umgebung besteht eigentlich immer aus mehreren Servern die aufeinander abgestimmt aktualisiert werden müssen. Entsprechend habe ich in der Regel eine Tabelle, auf der ich die erledigten Schritte abhake. Hier ein Beispiel, die ich für Kunden natürlich ausführlicher erstelle und dann Zeile für Zeile und dann Spalte für Spalte abarbeite. Dies ist eine vereinfachte Tabelle.

Tätigkeit FE1 FE2 FE3 Edge1 Edge2 SQL1 SQL2 SQLW Share

Information Helpdesk

 

 

 

 

 

 

 

 

 

Pausieren im Monitoring

 

 

 

 

 

 

 

 

 

Check Get-CSPoolUpgradeReadynessState

 

 

 

 

 

 

 

 

 

Invoke-CSComputerfailover –waittime 30:00

 

 

 

 

 

 

 

 

 

stop-cswindowsservices

 

 

 

 

 

 

 

 

 

Installation SfB Updates

 

 

 

 

 

 

 

 

 

Installation Windows/SQL Updates

 

 

 

 

 

 

 

 

 

Shutdown

 

 

 

 

 

 

 

 

 

ggfls. Änderungen Hardware

 

 

 

 

 

 

 

 

 

Restart

 

 

 

 

 

 

 

 

 

Invoke-CSComputerFailback

 

 

 

 

 

 

 

 

 

Kontrolle des Servers, Aktivieren Monitoring

 

 

 

 

 

 

 

 

 

Test/Update SQL Datenbanken

 

 

 

 

 

 

 

 

 

Fertigmeldung

 

 

 

 

 

 

 

 

 

Ich gehe hierbei von aus, dass z.B. der Loadbalancer erkennt, dass die Webseite beim "Invoke-CSComputerFailover" down ist und daher auch alle anderen Zugriffe nicht mehr dort hin sendet. Auch beim Edge Server muss man beim Pool natürlich etwas aufpassen und ebenso beim SQL-Cluster oder SQL-Mirroring. Der Office Web App Server unterliegt einem eigenen Patch-Prozess, insbesondere wenn dieser Dienst auch von Exchange und SharePoint genutzt wird. Die Schritte für Skype for Business sind im einzelnen noch noch mal erklärt.

Pool-Health überprüfen (Get-CsPoolUpgradeReadinessState)

Ehe Sie geplant etwas an einem Lync oder Skype for Business Pool machen, sollten Sie immer die "Gesundheit" des Pools verifizieren. Wer eine entsprechende Monitoring-Lösung hat, muss das nicht mehr gesondert machen, da das Monitoring diesen Check immer wieder durchführen sollte. Aber es hat sich doch gezeigt, dass lieber ein manueller Check ratsam ist. Ich nutze dazu als primäres Werkzeug das Commandlet "Get-CsPoolUpgradeReadinessState". Hier die Ausgabe eines Pools mit vier Servern.

PS C:\> Get-CsPoolUpgradeReadinessState

PoolName             : poo1.msxfaq.de
State                : Ready
TotalFrontends       : 4
TotalActiveFrontends : 4
UpgradeDomains       : {
                       UpgradeDomainName: UpgradeDomain1
                       IsReadyForUpgrade: True
                       Total FrontEnds: 1
                       Total Active FrontEnds: 1
                       Frontends: FE1.msxfaq.de
                       ,
                       UpgradeDomainName: UpgradeDomain2
                       IsReadyForUpgrade: True
                       Total FrontEnds: 1
                       Total Active FrontEnds: 1
                       Frontends: FE2.msxfaq.de
                       ,
                       UpgradeDomainName: UpgradeDomain3
                       IsReadyForUpgrade: True
                       Total FrontEnds: 1
                       Total Active FrontEnds: 1
                       Frontends: FE3.msxfaq.de
                       ,
                       UpgradeDomainName: UpgradeDomain4
                       IsReadyForUpgrade: True
                       Total FrontEnds: 1
                       Total Active FrontEnds: 1
                       Frontends: FE4.msxfaq.de
                       }

Bei allen steht ein "IsReadyFor Upgrade".

Übrigens sollten Sie in dem Zuge natürlich auch gleich mal die freie Festplattenkapazität checken, denn Lync-Share (Anlagen zu Meetings), IISLogs und vor allem die Fabric-Logs können ganz schnell die Festplatte auffüllen.

dir C:\programdata\Windows Fabric\Fabric\log\Trace

Logman Update trace FabricLeaseLayerTraces -f bincirc --cnf

Fabric Prüfen mit Get-CsPoolFabricState

Ebenso sollten Sie die Fabric prüfen. Das machen die folgenden Programme auch aber ich prüfe das gerne vorab:

PS C:\U> Get-CsPoolFabricState -PoolFqdn cpool1.msxfaq.net

Replica Instances for MCUFactory Service
    Address: FE1.msxfaq.net - Primary: 2 Secondary: 3
    Address: FE2.msxfaq.net - Primary: 1 Secondary: 4
    Address: FE3.msxfaq.net - Primary: 1 Secondary: 3
    Address: FE4.msxfaq.net - Primary: 2 Secondary: 2

Local MCUFactory Service:
Missing Primary             : 0
Missing Both Secondary      : 0
Missing One Secondary       : 0
No Missing Replicas         : 6
Total Count                 : 6

Pool MCUFactory Server and Services Summary:
Fqdn: FE1.msxfaq.net Primary: 2 Secondary: 3
Fqdn: FE2.msxfaq.net Primary: 1 Secondary: 4
Fqdn: FE3.msxfaq.net Primary: 1 Secondary: 3
Fqdn: FE4.msxfaq.net Primary: 2 Secondary: 2

Replica Instances for ConferenceDirectory Service
    Address: FE1.msxfaq.net - Primary: 0 Secondary: 2
    Address: FE2.msxfaq.net - Primary: 1 Secondary: 1
    Address: FE3.msxfaq.net - Primary: 1 Secondary: 1

Local ConferenceDirectory Service:
Missing Primary             : 0
Missing Both Secondary      : 0
Missing One Secondary       : 0
No Missing Replicas         : 2
Total Count                 : 2

Pool ConferenceDirectory Server and Services Summary:
Fqdn: FE1.msxfaq.net Primary: 0 Secondary: 2
Fqdn: FE2.msxfaq.net Primary: 1 Secondary: 1
Fqdn: FE3.msxfaq.net Primary: 1 Secondary: 1

Replica Instances for Routing Service
    Address: FE1.msxfaq.net - Primary: 5 Secondary: 10
    Address: FE2.msxfaq.net - Primary: 5 Secondary: 10
    Address: FE3.msxfaq.net - Primary: 5 Secondary: 10
    Address: FE4.msxfaq.net - Primary: 0 Secondary: 0 Other: 15

Local Routing Service:
Missing Primary             : 0
Missing Both Secondary      : 0
Missing One Secondary       : 0
No Missing Replicas         : 15
Total Count                 : 15

Pool Routing Server and Services Summary:
Fqdn: FE1.msxfaq.net Primary: 5 Secondary: 10
Fqdn: FE2.msxfaq.net Primary: 5 Secondary: 10
Fqdn: FE3.msxfaq.net Primary: 5 Secondary: 10
Fqdn: FE4.msxfaq.net Primary: 0 Secondary: 0

Replica Instances for LYSS Service
    Address: FE1.msxfaq.net - Primary: 5 Secondary: 10
    Address: FE2.msxfaq.net - Primary: 5 Secondary: 10
    Address: FE3.msxfaq.net - Primary: 5 Secondary: 10

Local LYSS Service:
Missing Primary             : 0
Missing Both Secondary      : 0
Missing One Secondary       : 0
No Missing Replicas         : 15
Total Count                 : 15

Pool LYSS Server and Services Summary:
Fqdn: FE1.msxfaq.net Primary: 5 Secondary: 10
Fqdn: FE2.msxfaq.net Primary: 5 Secondary: 10
Fqdn: FE3.msxfaq.net Primary: 5 Secondary: 10

Replica Instances for Fabric Service
    Address: FE1.msxfaq.net - Primary: 1 Secondary: 2
    Address: FE2.msxfaq.net - Primary: 2 Secondary: 1
    Address: FE3.msxfaq.net - Primary: 0 Secondary: 3
    Address: FE4.msxfaq.net - Primary: 0 Secondary: 3

Local Fabric Service:
Missing Primary             : 0
Missing Both Secondary      : 0
Missing One Secondary       : 0
No Missing Replicas         : 3
Total Count                 : 3

Pool Fabric Server and Services Summary:
Fqdn: FE1.msxfaq.net - Health: Ok Status: Up [Seed Node] Primary: 1 Secondary: 2
Fqdn: FE2.msxfaq.net - Health: Ok Status: Up [Seed Node] Primary: 2 Secondary: 1
Fqdn: FE3.msxfaq.net - Health: Ok Status: Up [Seed Node] Primary: 0 Secondary: 3
Fqdn: FE4.msxfaq.net - Health: Ok Status: Up [Seed Node] Primary: 0 Secondary: 3

Pool All Server and Services Summary:
Fqdn: FE1.msxfaq.net Primary: 12 Secondary: 25
Fqdn: FE2.msxfaq.net Primary: 12 Secondary: 25
Fqdn: FE3.msxfaq.net Primary: 12 Secondary: 24
Fqdn: FE4.msxfaq.net Primary: 2 Secondary: 2

Auch hier sollte alles "Sauber" sein.

Server geplant "in Service" stellen (Invoke-CsComputerFailover)

Nun muss der erstes Server "geplant" in Wartung gefahren werden. Das ist mit dem neuen Commandlet "Invoke-CsComputerFailover" sehr einfach geworden.

Achtung: Starten Sie die folgenden Commandlets unbedingt in einer Admin-Powershell, da ansonsten die Deaktivierung der Dienste nicht gelingt und eine Fehlermeldung angezeigt wird.

Achtung: Das Commandlet wartet relativ lange, bis alle Dienste "idle" sind. Aber nach einer Wartezeit stoppt es die Dienste dann auch unsanft.

Dennoch sollten sie ein paar Dinge vorher beachten:

  1. Monitoring pausieren
    Wenn Sie gleich im nächsten Schritt den Service außer betrieb nehmen, sollten sie vorher ihre Überwachungslösung entsprechend auf "pause" stellen. Dies gilt um so mehr, wenn die Überwachungslösungen sogar "Reparaturschritte" durchführen würde.
  2. Invoke-CsComputerFailover
    Dieses Commandlets kann optional auch mit einem Computernamen gestartet werden und nimmt den Server geordnet aus einer Farm. Dazu führt es mehrere Schritte nacheinander aus
    1. SkipFabricHealthCheck
      Zuerst wird zuerst sicher gestellt, dass die Windows Fabric korrekt an die verbleibenden Server übertragen wird und so kein Problem auftreten sollte.
    2. IIS-Blockieren
      Damit Client nicht mehr die WebServices nutzen, wird der IIS blockiert. Dies ist wichtig, damit z.B.: Loadbalancer dies "erkennen" können und entsprechend Zugriffe von Clients an die verbliebenen Server weiter reichen
    3. Dann werden die Skype for Business Server Dienste auf "pausiert" gestellt. Damit werden keine neuen Verbindungen mehr angenommen und die bestehenden Verbindungen, soweit möglich, auf anderen Server umgeleitet. Das ist ein "Graceful" down.
    4. Warten auf Konferenzen
      Solange noch MCUs aktiv sind, können die Dienste zwar "pausiert" aber nicht beendet werden, so dass dieses Commandlet an dieser Stelle einige Zeit stehen bleiben kann. Hoffen wir mal, dass es keine 8h Konferenz ist.
    5. Stoppen und Deaktivieren der Dienste
      Wenn dann MCUs gestoppt sind, stoppt das Commandlet alle Skype for Business Dienste und stellt diese sogar auf "deaktiviert". Damit wird sichergestellt, dass auch nach einem Neustart des Servers die Dienste nicht sofort wieder aktiv werden.

Während der Ausführung werden all die Dienste angezeigt, auf deren Ende noch gewartet wird:

Die Aktionen des Commandlets werden in einer Protokolldateien (Per Default "„AppData\Local\Temp“ abgelegt. Der Pfad kann per Parameter "Report" geändert werden.

Die HTML-Datei kann auch einfach im Browser angezeigt werden.

Eigentlich schade, dass diese Dateien in AppData/Temp landen und nicht an einer Stelle, die eine spätere Nachvollziehbarkeit erlaubt.

Servicearbeit

Der Server ist nun "in Wartung" und kann gemäß den geplanten Aufgaben umgestaltet werden. Er kann also z.B. mit Windows Updates oder Skype for Business Updates versehen werden. Auch ein oder mehrere Neustarts des Servers sind unkritisch, da alle Skype for Business Dienste deaktiviert sind.

  • Skype for Business Updates
  • Windows Updates
  • SQL Updates

Back in Service

Nachdem Sie alle Wartungsarbeiten an dem Server abgeschlossen haben, können Sie ihn wieder geplant in Funktion setzen. Das geht mit dem Gegenstück von "Invoke-CsComputerFailover", nämlich Invoke-CsComputerFailback.

Achtung: Starten Sie die folgenden Commandlets unbedingt in einer Admin-Powershell, da ansonsten die Deaktivierung des IIS nicht gelingt

  1. Invoke-CsComputerFailback
    Dieses Commandlet aktiviert wieder den Server durch folgende Schritte:
    1. Aktivieren der Dienste auf Autostart
      Die vorher "deaktivierten" Dienste werden nun wieder auf "Autostart" gestellt
    2. Aktivieren des IIS
      Zuletzt wird auch der IIS wieder aktiviert, damit die Loadbalancer wieder Clientzugriffe auf den neuen Server leiten.
    3. Start der Dienste
      Die Skype for Business Dienste werden gestartet, was durchaus einige Minuten dauern kann, bis die Pools wieder verteilt sind

Anscheinend startet das Commandlet den IIS sehr früh und schon ehe die Skype for Business Services schon alle wieder gestartet sind. Auch diese Aktionen werden in der XML und HTML-Datei protokolliert:

Nacharbeiten in der Skype for Business Topologie

Vielleicht haben Sie diese Beschreibung genutzt, um auf all ihren Servern die aktuelle Version eines CU zu installieren. Dann sind Sie nun an der Stelle angekommen, an der alle "Binaries" aktuell sind aber vermutlich noch nicht die Datenbank und vielleicht auch noch die die lokalen Rollen.

Kontrollieren Sie daher die Installationsbeschreibung, ob sie die folgenden Schritte noch ausführen müssen:

  • Datenbankupdates
    Eventuell müssen Sie mit Install-CSDatabase noch Aktualisierungen einspielen
  • Enable-CSComputer
    Eventuell ist dieses Kommando auf jedem Server erforderlich, um neue Komponenten zu installieren oder Einstellungen einzurichten. Dies war in der Vergangenheit z.B. für den mobilen Client (virtuellen Verzeichnis auf der Webseite) erforderlich oder zur Einrichtung eines neuen Dienstes-

Wenn das alles aber gelaufen ist und ihre Server wieder im Regelbetrieb sind, dann sollten sie umgehend auch wieder ihr Monitoring aktivieren.

Update der Edge Server

Wer nur genau einen Edge-Server hat, der kann ein Update nur mit einer Betriebsunterbrechung durchführen. Suchen Sie sich hier also einen Zeitraum aus, in dem die Funktionen RemoteUser, Federation, ExternMeeting nicht benötigt ist. Haben Sie jedoch einen Edge Pool, dann können Sie einen Server geplant außer Betrieb nehmen, wie das auch beim Enterprise Pool geht. Allerdings erfolgt dies nicht durch "Invoke-CSPoolFailover" sondern wie schon beim Lync Server mit Stop-CSWindows-Service.

  • StopCSWindows Server (Admin Powershell !)
    Das Commandlet stoppt alle Edge Dienste, aber deaktiviert diese nicht. Vorsicht also bei mehreren Neustarts des Servers. Das Commandlet macht per Default einen "Graceful Shutdown", d.h. die Client werden disconnected und verbinden sich mit dem anderen Edge-Server, wenn denn einer da ist.
  • Updates einspielen
    Dann können Sie wie gehabt die Updates einspielen
    • Windows-Updates
    • SQL-Updates
    • Skype for Business Updates
  • Neustart des Server oder der Dienste
    Wenn der Server nach den Updates keinen Neustart möchte, können Sie sogar die Skype for Business Dienste mit einem "Start-CSWindowsService" in einer Admin Powershell wieder starten. Ich nutzt aber die Zeit schon den Server einfach mit einem "Restart-Server" durch zu starten und so sicherzustellen, dass am Ende alle Dienste auch alleine wieder funktionsfähig bereitgestellt werden.

Wiederholen Sie die Funktion dann auch bei den anderen Edge-Servern.

Update Datenbank Backend im Enterprise Pool

Wer nur einen Standard Server hat, der muss sich wenige Gedanken um die Verfügbarkeit machen. Wenn Sie den Standard Server patchen, dann ist die Funktion eh "offline" oder maximal auf einen Backup-Pool im "Reduced Function mode" übertragen worden. Dann gilt es einfach möglichst schnell mit den Windows Updates auch die erforderlichen SQL-Updates zu installieren, damit der Server schnell wieder bereitgestellt werden kann. Mit einem SQL-Cluster sind die Optionen schon besser aber auch hier kann es zu einer kleinen Unterbrechung kommen. Mit Lync 2013 wird aber auch SQL-Mirroring unterstützt und das haben fast alle meine Installation mit Enterprise Pools umgesetzt.

Zuerst prüfe ich nach dem Update aller Frontend Server eines Pools erst mal, ob für die Datenbank selbst ein Update erforderlich ist um z.B. neue Funktionen zu unterstützen. Zwei Befehle bringen hier klarheit

Test-CsDatabase `
   -ConfiguredDatabases `
   -SqlServerFqdn `
| ft databasen*,Expe*,Inst*,Suc* -AutoSize

Test-CsDatabase `
   -CentralManagementDatabase `
   -SqlServerFqdn  `
| ft databasen*,Expe*,Inst*,Suc* -AutoSize

Die Versionsnummern der Datenbankschemata sollten übereinstimmen. Ansonsten ist hier ein Update-CSDatabase erforderlich. 

  • Check des Status
    Von einem Frontend aus prüfe ich zuerst den aktuellen Status. Das sollte dann wie folgt etwa aussehen
PS C:\> Get-CsDatabaseMirrorState -PoolFqdn pool.msxfaq.net | ft

DatabaseName     StateOnPrimary   StateOnMirror MirroringStatus MirroringStatus
                                                OnPrimary       OnMirror
------------     --------------   ------------- --------------- ---------------
xds                   Principal          Mirror synchronized    synchronized
lis                   Principal          Mirror synchronized    synchronized
rtcab                 Principal          Mirror synchronized    synchronized
rtcxds                Principal          Mirror synchronized    synchronized
rtcshared             Principal          Mirror synchronized    synchronized
lcscdr                Principal          Mirror synchronized    synchronized
qoemetrics            Principal          Mirror synchronized    synchronized
rgsconfig             Principal          Mirror synchronized    synchronized
rgsdyn                Principal          Mirror synchronized    synchronized
cpsdyn                Principal          Mirror synchronized    synchronized
  • Updates des Whittness
    Wenn beide SQL-Server "laufen", hat der Witness nichts zu tun. Er kann dann einfach mit den anstehenden Patches versorgt werden
  • Updates des Mirror-Servers
    Solange der Frontend Pool auf dem Primary Server agiert, ist der Mirror-Server nur Replikationsziel. Er kann also recht hemmungslos gepatched und durchgestartet werden. Allerdings sollte der Witness dann schon laufen, damit der primäre Server auch weiter aktiv bleibt. Nachdem Sie alle Updates installiert haben, sollten Sie erneut den aktuellen Status prüfen
PS C:\> Get-CsDatabaseMirrorState -PoolFqdn pool.msxfaq.net | ft

DatabaseName     StateOnPrimary   StateOnMirror MirroringStatus MirroringStatus
                                                OnPrimary       OnMirror
------------     --------------   ------------- --------------- ---------------
xds                   Principal          Mirror synchronized    synchronized
lis                   Principal          Mirror synchronized    synchronized
rtcab                 Principal          Mirror synchronized    synchronized
rtcxds                Principal          Mirror synchronized    synchronized
rtcshared             Principal          Mirror synchronized    synchronized
lcscdr                Principal          Mirror synchronized    synchronized
qoemetrics            Principal          Mirror synchronized    synchronized
rgsconfig             Principal          Mirror synchronized    synchronized
rgsdyn                Principal          Mirror synchronized    synchronized
cpsdyn                Principal          Mirror synchronized    synchronized
  • Switchover der Datenbanken auf den Mirror
    Wenn die Datenbanken alle "synchronized" sind, dann ist es an der Zeit den Mirror-Server zum aktiven Part zu erheben. Skype for Business kennt dazu das Commandlet "Invoke-CSDatabaseFailover". Leider gruppiert Microsoft die Datenbanken und es sind mehrere Aufrufe erforderlich. Das Commandlet akzeptiert leider keine Werte von der Pipeline, so dass ich per For-Schleife die Datebanken umschwenke
("App", "CentralMgmt", "Monitoring", "User") `
| %{ Invoke-CsDatabaseFailover `
   -PoolFqdn pool.msxfaq.net `
   -DatabaseType $_ `
   -NewPrincipal Mirror `
   -confirm:$false}
  • Kontrolle des Switchover
    Auch wenn der "Invoke-CSDatabaseFailover" ohne Fehler durchgelaufen ist, sollte eine Statusabfrage nun so aussehen
PS C:\> Get-CsDatabaseMirrorState -PoolFqdn pool.msxfaq.net | ft

DatabaseName     StateOnPrimary   StateOnMirror MirroringStatus MirroringStatus
                                                OnPrimary       OnMirror
------------     --------------   ------------- --------------- ---------------
xds                      Mirror       Principal synchronized    synchronized
lis                      Mirror       Principal synchronized    synchronized
rtcab                    Mirror       Principal synchronized    synchronized
rtcxds                   Mirror       Principal synchronized    synchronized
rtcshared                Mirror       Principal synchronized    synchronized
lcscdr                   Mirror       Principal synchronized    synchronized
qoemetrics               Mirror       Principal synchronized    synchronized
rgsconfig                Mirror       Principal synchronized    synchronized
rgsdyn                   Mirror       Principal synchronized    synchronized
cpsdyn                   Mirror       Principal synchronized    synchronized
  • Patch des primären Servers
    Nun können Sie den primären Server, der nun eben als Replikationsziel arbeitet, einfach Patchen, Durchstarten etc.
  • Kontrolle der Replikation
    Nach dem Updates und Neustarts ist auch hier eine Kontrolle angebracht, ob der Server schon wieder "snychronized" ist
PS C:\> Get-CsDatabaseMirrorState -PoolFqdn pool.msxfaq.net | ft

DatabaseName     StateOnPrimary   StateOnMirror MirroringStatus MirroringStatus
                                                OnPrimary       OnMirror
------------     --------------   ------------- --------------- ---------------
xds                      Mirror       Principal synchronized    synchronized
lis                      Mirror       Principal synchronized    synchronized
rtcab                    Mirror       Principal synchronized    synchronized
rtcxds                   Mirror       Principal synchronized    synchronized
rtcshared                Mirror       Principal synchronized    synchronized
lcscdr                   Mirror       Principal synchronized    synchronized
qoemetrics               Mirror       Principal synchronized    synchronized
rgsconfig                Mirror       Principal synchronized    synchronized
rgsdyn                   Mirror       Principal synchronized    synchronized
cpsdyn                   Mirror       Principal synchronized    synchronized
  • SwitchBack
    Dann ist der Weg auf die normale Konfiguration offen. Das geht wieder mit einer Schleife
("App", "CentralMgmt", "Monitoring", "User") `
| %{ Invoke-CsDatabaseFailover `
   -PoolFqdn pool.msxfaq.net `
   -DatabaseType $_ `
   -NewPrincipal Primary `
   -confirm:$false}
  • Schlusskontrolle
    Auch wenn der Switchback ohne Fehler gelaufen ist, schaue ich dennoch lieber noch einmal nach:
PS C:\> Get-CsDatabaseMirrorState -PoolFqdn pool.msxfaq.net | ft

DatabaseName     StateOnPrimary   StateOnMirror MirroringStatus MirroringStatus
                                                OnPrimary       OnMirror
------------     --------------   ------------- --------------- ---------------
xds                   Principal          Mirror synchronized    synchronized
lis                   Principal          Mirror synchronized    synchronized
rtcab                 Principal          Mirror synchronized    synchronized
rtcxds                Principal          Mirror synchronized    synchronized
rtcshared             Principal          Mirror synchronized    synchronized
lcscdr                Principal          Mirror synchronized    synchronized
qoemetrics            Principal          Mirror synchronized    synchronized
rgsconfig             Principal          Mirror synchronized    synchronized
rgsdyn                Principal          Mirror synchronized    synchronized
cpsdyn                Principal          Mirror synchronized    synchronized

Damit ist dann auch ein SQL-Mirror-Paar mit minimalen Betriebsunterbrechungen durchgepatched.

Fileshare-Service, Office WebApp, ReverseProxy und Co

Es gibt rund um Skype for Business natürlich noch weitere Dienste, die ebenfalls ab und an eine Aktualisierung erforderlich machen. Hier ist vielleicht noch der DFS-Share bzw. ein hochverfügbarer Fileserver eine knifflige Komponente eines Skype for Business Deployment. Ohne den Share funktionieren ganz viele Dinge nicht, z.B. Konferenzen, Adressbuch-Download etc. Mit DFSR können Sie ja mehrere Server bereitstellen nach und nach diese Durchpatchen. Skype for Business "überlebt" dies in der Regel problemlos. Wer den Vorgang optimieren will, kann natürlich die DFS-Freigaben nacheinander "offline" schalten und erst dann den Server patchen.

Die Aktualisierung von Office Web App finden Sie mit auf der Seite WAC Server

Die Update von Firewalls, Reverse Proxies etc. sind hier nicht weiter beschrieben.

Weitere Links