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:
-
Checklisten
Eine Übersicht aller Checklisten der MSXFAQ - Updates für Skype für Business Server
2015
https://support.microsoft.com/de-de/help/3061064/updates-for-skype-for-business-server-2015
Beschreibung der Installation über 11 Punkte
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:
- 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. - Update der Edge Server
Danach aktualisiere ich in der Regel die Edge Server und, sofern vorhanden, Director Server - 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:
- 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. - 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- SkipFabricHealthCheck
Zuerst wird zuerst sicher gestellt, dass die Windows Fabric korrekt an die verbleibenden Server übertragen wird und so kein Problem auftreten sollte. - 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
- 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.
- 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. - 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.
- SkipFabricHealthCheck
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.
- Invoke-CsComputerFailOver
https://technet.microsoft.com/en-us/library/dn985882.aspx
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
- Invoke-CsComputerFailback
Dieses Commandlet aktiviert wieder den Server durch folgende Schritte:- Aktivieren der Dienste
auf Autostart
Die vorher "deaktivierten" Dienste werden nun wieder auf "Autostart" gestellt - Aktivieren des IIS
Zuletzt wird auch der IIS wieder aktiviert, damit die Loadbalancer wieder Clientzugriffe auf den neuen Server leiten. - Start der Dienste
Die Skype for Business Dienste werden gestartet, was durchaus einige Minuten dauern kann, bis die Pools wieder verteilt sind
- Aktivieren der Dienste
auf Autostart
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:
- Invoke-CsComputerFailBack
https://technet.microsoft.com/de-de/library/dn985825.aspx
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
- Lync Patchmanagement
- WAC Server
- Ex2016 Update Checkliste
-
Checklisten
Eine Übersicht aller Checklisten der MSXFAQ - Skype for Business Readiness Series
(8/15)
http://kressmark.blogspot.de/2015/03/skype-for-business-readiness-series-815.html - Updating Skype for Business Front
End Servers
http://uccorey.com/2015/05/06/updating-skype-for-business-front-end-servers/ - #Skype4B : Install cumulative Updates on
Skype for Business
Part I: http://insidemstech.com/2016/01/31/skype4b-install-cumulative-updates-on-skype-for-business-part-i/
Part II: http://insidemstech.com/2016/01/31/skype4b-install-cumulative-updates-on-skype-for-business-part-ii/ - LYNC 2013 DATABASE MIRROR MANAGER TOOL
http://www.myskypelab.com/2013/05/lync-2013-database-mirror-manager-tool.html - Simple Understanding of Lync/Skype For
Business Windows Fabric & Failover
https://lyncdude.com/2014/12/29/simple-understanding-of-lync-windows-fabric-failover/ - Skype for Business CU1 Install –
Challenges and Lessons Learned
http://lyncnews.blogspot.de/2015/11/skype-for-business-cu1-install.html