Migration Std2Pool

Viele Firmen starten einfach mal mit einem Lync Standard Server, welchen Sie in ihre Umgebung für Testzwecke installieren. Natürlich wissen wir alle, dass Test und Produktion genau genommen zwei strickt getrennte Bereiche sind und auf Lync Pilot, Ressourceforest und OCS-Aktion habe ich auch die verschiedenen Optionen beschrieben, wie man Lync in einer eigenen TestUmgebung installiert und dennoch "nahtlos" in der Produktion nutzen kann. für all die Administratoren, die ihren "Test-Standardserver" aber nun durch einen anderen produktiven Standardserver oder gar einen neuen Enterprise Server austauschen wollen, kann diese Anleitung ein Leitfaden sein.

Schwerpunkt dieser Anleitung ist die Überführung aller relevanten Daten in eine produktive Umgebung. Leider gibt es in Lync immer nur eine Federation Route, ein Edge hat immer nur genau einen "Next Hop" und die WebServiceURLs müssen auch eindeutig sein. Auch kann ein PSTN-Gateway immer nur einem Mediation Server/Pool zugeordnet sein, wenn man nicht mit HOSTS-Dateien oder sekundären DNS-Namen arbeiten will. Daher ist bei der Migration etwas Überlegung erforderlich. Dazu gibt es zwei Wege

  • Sauberer Weg
    Hierbei wird ein zweiter Pool komplett Funktionsfähig aufgebaut. Das bedeutet aber u.a. auch Zertifikate, Veröffentlichung nach Extern etc. Dieser Weg erlaubt aber eine längere Phase der Koexistenz und ausführliche Tests. Sie können sogar parallel Edge Server und weitere Gateways einrichten und testen.
  • Schneller Weg
    Vielen dauert der erste Weg aber zu lange bzw. eigentlich soll die neue Umgebung den alten Server schnellstens Ablösen und die URLs möglichst gleich bleiben- Das erkauft man sich aber mit einer Betriebsunterbrechung von wenigen Stunden, um die Dienste quasi zu ersetzen.

Diese Beschreibung dient einer schnellen Migration.

Migrationsbeschreibung

Unter der Berücksichtigung einer "schnellen Migration" ohne lange Koexistenz und der Erlaubnis einer Downtime von wenigen Stunden werden folgende Start und Zielvorgaben angenommen

Ausgangssituation

  • 1x Standard Server als erster Server, der auch den CMS-Master hostet
  • 1x Webservice per TMG veröffentlicht
    Nur vorhanden, wenn Sie auch Teilnehmer aus dem Internet unterstützt haben
  • 1x Edge Server
    Nur vorhanden, wenn Sie auch Teilnehmer aus dem Internet, Remote Access, Federation oder Lync Mobile unterstützt haben
  • 1x Gateway zu PSTN
    Nur vorhanden, wenn Sie eine Kopplung an die TK-Anlage für Voice, Konferenz Dialin etc konfiguriert haben
  • Nicht beschrieben:
    Prüfen Sie, was Sie ansonsten noch konfiguriert haben, was diese Beschreibung aber unnötig kompliziert gemacht hätte, wie z.B. Remote Call Control, Trusted Application, UCMA-Anbindungen von Callcenter o.ä.

Zielsituation

  • 1x Enterprise Pool mit Loadbalancer für internen Zugriff auf Webservices
  • 1x WebService per TMG auf Pool veröffentlicht
  • 1x Nutzung des bestehenden Edge Server
  • 1x Nutzung des bestehenden Gateways zu PSTN

Migrationsschritte

In der Regel kann so eine Migration in mehrere Phasen untergliedert werden, zwischen denen immer wieder eine Pause eingelegt werden kann. Dies sind

  • Vorbereitung und Parallelaufbau des Pools
  • Migration CMS
  • Migration Benutzer und Konferenzen
  • Switch und Abbau der alten Umgebung

Heraus gekommen ist die folgende Checkliste. Sie erhebt keinen Anspruch auf Vollständigkeit. Wer z.B. Dialpläne auf Pools (statt Global oder auf Benutzer) gebunden  hat, wird weitere Nacharbeiten durchführen müssen. Es gibt viele Dinge, die in Lync "pro Pool" definiert werden können.

Phase Beschreibung Status

Basis

Windows Server Installation

Bereiten Sie die neuen FE-Server, den SQL-Cluster (so erforderlich) entsprechend für die Installation von Lync vor. Dazu gehören auch Themen wie:

  • Windows Basisinstallation
  • Mitgliedschaft in der Domäne
    Beachten sie, das der FQDN korrekt gesetzt ist.
  • Basiskonfiguration
    Hierbei denke ich an Patchmanagement, Datensicherung, Monitoring, Antivirus
  • Firewall, Routing
    Wenn Sie eine externe Anbindung (Edge) betreiben oder ihre PSTN-Gateway in einem eigenen Subnetz betreiben, dann sollten Sie sicherstellen, dass die erforderlichen Ports und IP-Leitwege zwischen den Servern und den Clients frei geschaltet sind.

 

Add Server

Addieren der neuen Server im Topologie Builder

  • Addieren Sie hier die neuen Server, die zukünftig als FE-Pool o.ä., arbeiten sollen mit dem FQDN
  • Addieren des EE Pools mit SQL mit internen WebURLs und temporären external WebServiceURLs. Diese werden später auf den Wert des aktuellen Servers verändert um die öffentlichen Zertifikate weiter verwenden zu können
  • Edge Namensauflösung
    Der Edge-Server hat oft einen internen FQDN, der statisch im DNS hinterlegt ist. Aber umgekehrt muss der Edge natürlich auch die geplanten Poolnamen und Server erreichen. Aktualisieren Sie daher auf dem Edge die HOSTS-Datei
  • Federation Route via Edge
    Der neue Pool kann ausgehende Federationanfragen an den Edge senden. Allerdings werden eingehende Antworten noch über den "alten" Server laufen
  • Publish Topology
    Diese neuen Einstellungen müssen in die aktuelle Topologie geschrieben und repliziert werden

Damit ist die Basis für die Installation geschaffen.

 

Install

FE1/FE2: Deployment

Nun geht es daran, die neu in der Topologie angelegten Server auch physikalisch aufzubauen. Die Aktionensind auf beiden Frontend Servern einzurichten

  • Installation Lync Basis
  • Installation Lync Rollen mit SQL Backend
  • Einrichten Zertifikate
    Hinweis: Addieren Sie auch den FQDN der bisherigen external Webservices. Diese werden am Ende ja auf den Wert der früheren Server geändert
  • Einrichtung Loadbalancer, um die neuen Webservices intern erreichbar zu machen. Beachten Sie, dass diese Dienste später auch unter dem Namen erreichbar sein sollen, die aktuell noch der Standard Server hat. Zumindest die Simple URLs sollten passen.
  • DNS-Einträge für Pool und die Webservices.
    Die external Webservices müssen nicht nicht pflegen, da wir nie vorhaben, diese zu nutzen. Wir haben ja auch nicht vor dafür ein offizielles Zertifikat zu kaufen
  • Installation Updates
    Eine gute Gelegenheit noch mal nach Update für Lync aber auch Windows und SQL zu schauen, da wir neue Dienste installiert haben
  • Kontrolle der Replikation
    Die neuen Server sollte in der Lync Umgebung nun korrekt funktionieren.

Nun sollte der neue Pool schon halbwegs produktiv sein. Telefonie geht noch über den alten Server und auch die Federation über Edge nutzt noch den alten Server. Der Server muss aus ihrer Sicht nun "zuverlässig" sein, um den nächsten Schritt anzugehen

 

CMS Move

Verschieben der CMS Masterdatenbank

Nun geht es darum die Konfigurationsdatenbank auf den neuen Server zu bringen.

  • Sicherung der CMS/LIS-Datenbank
    Export-CsConfiguration –Filename config.zip
    Export-CsLisConfiguration –Filename lis.zip
  • Test „Enable-CSTopology“ auf einem FE, der das Ziel ist
    Das ist nach dem Move wichtig und sollte das nicht gehen, dann wird es knifflig
  • Installation einer neuen CMS-Datenbank auf dem Pool
    Install-CSDatabase –CentralManagementDatabase –SQLServerFQDN -SQLInstancename RTC
    Enable-CSTopology
  • Verschieben der CMS-Datenbank
    Anmelden auf dem Zielserver
    move-CsManagementServer
  • Lync DeploymentWizard auf den Servern laufen lassen
    Damit werden eventuell fehlende Dienste aufgrund der neuen Funktionen nachinstalliert bzw. entfernt. Dies betrifft z.B. den Lync MasterReplicat/Filetransfer Service
  • Kontrolle der Replikation
    get-CsManagementStoreReplicationStatus

Nun sollte die CMS-Instanz sauber auf dem neuen Server laufen und die anderen Server diese auch als Replikationsquelle ansehen. Erst dann sollten wir den nächsten Schritt angehen:

 

Dienste

Umstellen der Dienste

Der nächste Schritt ist die Umstellung aller Benutzer und anderer Dienste auf den neuen Pool. Hierbei kann man "langsam" vorgehen, um Replikationen, DNS-Caches u.a. zu berücksichtigen. Diese kurze Beschreibung stellt einfach "um". Während der Phase wird es Unterbrechungen geben.

  • TMG-Veröffentlichung URLs aus EE-Pool einrichten
    Das gleich gilt für Zugriffe aus dem Internet, die auf den neuen Pool verweisen sollen. Zwar stimmen die Daten dann einige Zeit noch nicht, aber das ist nur temporär
  • DNS-Einträge auf EE Pool umstellen
    Dies ist ungefährlich, weil die Clients beim Zugriff auf den EE Pool schon wieder auf den richtigen Backend Server verschoben werden. Allerdings wird hier auch der Name der WebServices umgestellt, der vom Pool abweicht
  • Verschieben der Konferenzdienste
get-csConferenceDirectory | move-CsConferenceDirectory –targetpool <neuerFQDN>
  • Verschieben von DialIn Zugriffsnummern
    Wenn ihre Konferenz per Telefon erreichbar war, müssen Sie die Kontaktelemente auf den neuen Pool umstellen
Move-CsApplicationEndpoint 
    -Identity <SIP URI of the access number to be moved>
    -TargetApplicationPool <FQDN of the pool to which the access number is moving>
  • Verschieben der Benutzer und Kontakte
    Ich verschiebe die Benutzer lieber erst dann, wenn die kritischen Dinge (Vor allem CMS, RGS etc.) schon umgestellt sind. Vergessen Sie dabei nicht die Exchange UM Subscriber Access und AutoAttendants
  • Responsegroup
    RGS-Dienste sind "pro Pool" definiert. Der Abbau eines Pools erfordert die Migration dieser Daten. Leider geht das nur, indem man die Konfiguration auf dem Quellpool exportiert und dann auf dem Ziel wieder
  • Topology Builder: WebServiceURLs
    Damit die nun gedrehten Webservices wieder sauber funktionieren
  • Topology Builder: Edge und Federation route
    Korrigieren sie in der Konfiguration die Einträge der Federation route vom neuen Pool zum Edge und auch den Rückweg, d.h. dass der Edge nun eingehende SIP-Pakete an den Pool sendet
  • Telefonie mit PSTN-Gateway/Sip-Trunk
    Hier kann ich nur eine grobe Information geben, da sie je nach Konfiguration einiges umstellen müssen. Ich persönlich nutze keine Dialpläne auf Poollevel (nur Global oder per User) und auch keine Normalisierungen auf Trunks (machte ich lieber auch dem Gateway. Wenn Sie dies aber gemacht haben, dann wird ein Wechsel des Trunks auf einen anderen Pool zusatzarbeit nach sich ziehen.
    Wer schnell umschaltet, der hängt einfach das Gateway auf den Enterprise Pool und passt das Routing an. Da man aber kein Gateway mit dem gleichen Namen "Zweimal" in der Topologie pflegen kann, wird man bei einer "langsamen" Migration das Gateway eben mit einem zweiten Namen auf die gleiche IP konfigurieren und so parallel routen und langsam umstellen. In einer kleinen Umgebung mit vielleicht nur einem Routing auf genau dieses eine Gateway können Sie aber auch überlegen, das Gateway einfach "umzuhängen" und die fehlenden Stellen nach zu konfigurieren. Vergessen Sie aber nicht, das auch auf dem Gateway der "next hop" auf den Enterprisepool gehen muss.

Damit sind nun die meisten Dienste (Ausnahme PSTN-Anbindung) schon auf dem Enterprise Pool angekommen)

 

Abbau

Stufe 3: Abbau STD Pool

Eigentlich sollte nun ihre alter Standard Server "frei" sein.

  • Monitoring abschalten
    Nicht dass SCOM o.a. das Anhalten der Dienste und die Deinstallation als "Fehler" ansehen und schlimmstenfalls korrigierend eingreifen.
  • TopologyBuilder:
  • TopologyBuilder:
    Hier sind nun gleich mehrere Dinge zurecht zu rücken:
  • PSTN-Gateway an den neuen Pool zu verbunden
  • EdgeServer: NextHop zum EE
  • Federation route wie EE
  • Entfernen des STD-Pools
  • PSTN-Gateway umhängen
  • Anpassen der „WebServiceURL“ des EE-pools

 

Die Liste kann nie komplett sei, da ich bei viele Kunden immer wieder Komponenten gesehen habe. Lassen Sie sich überraschen :-) 

Weitere Links