16. September 2013

Warum soll Lync 2013 mindestens drei Frontend Server in einem Enterprise Pool haben?

Wer sich mit Lync beschäftigt steht immer wieder vor der Frage: Brauche ich einen Lync Standard Server oder benötige ich mehr Redundanz und mehr Verfügbarkeit mit einer Enterprise Version? und wie viele Front-Ends bentöige ich?

Der große Unterschied zwischen der Lync Enterprise Edition und dem Standard Server ist die Möglichkeit mit mehreren Front-End Servern im Pool einen redundanten Lync Enterprise Pool zu bauen. Hier werden auf mehreren Lync Frontend-Servern die Anwender und Ihre Daten automatisch verteilt. Dieser sogenannte Enterprise Pool kann in Lync 2013 bis zu 12 Server haben und alle Server haben die gleiche Lync-Konfiguration (Lync Pool). Fällt nun ein Server im Pool aus, so übernehmen automatisch die verbleibenden Front-End Server die Funktion und der Lync Client wird im Idealfall, ohne das es der Anwender merkt, auf einem anderen Server angemeldet/verschoben. Die Verteilung der User auf den Servern im Pool geschieht automatisch in sogenannte User Groups und lässt sich nicht durch den Administrator beeinflussen. Die User Groups werden auf zwei weitere Front-End Server im Lync Pool repliziert (vorausgesetzt es gibt mindestens drei Front-Ends). Gibt es weniger, so wird nur die entsprechende Anzahl an Kopien angelegt, mehr als drei sind es aber nie.

Somit wird die User Group einem primären (primary), sekundären (secondary) und tertiären (tertiary) Front-End zugeordnet und die Daten des Anwenders auf diese Server zusätzlich verteilt.

LyncFabric

Mit der neuen Lync 2013 Architektur hat Microsoft ein Hauptproblem der Skalierung von Lync behoben. So werden die Anwenderdaten primär auf dem primären Front-End des Users verwaltet. Dies schließt auch die Verwaltung der Präsenzinformationen ein. Dafür speichern die SQL Express 2012 Datenbanken mehr Informationen lokal auf jedem Front-End Server (RTCLOCAL Instanz).

Nur die dauerhaft zu speichernden Daten (z.B. Response Group Settings, Buddy List, geplante Meetings, Rufumleitungen, etc.) werden auf die SQL Backend Datenbanken als sogenannte „Lazy Writes“ gespeichert. In Lync 2010 gab es diese Trennung nicht. Deshalb führte ein Ausfall der SQL Backend Datenbanken auch immer gleich zu einem „limited functionality mode“ in Lync 2010. In Lync 2013 kann ein Lync Pool bis zu 30 Minuten „überleben“. Erst danach wird ein „limited functionality mode“ für den Anwender sichtbar.

Fällt ein Front-End Server im Pool aus, oder wird heruntergefahren, dann werden die User, die Ihre primäre Gruppe auf diesem Server hatten, auf den Server mit der sekundären, bzw. tertiären Kopie verschoben. Sind alle drei Kopien (Gruppen) nicht erreichbar, und es gibt noch mehr Front-End Server im Pool, dann werden die Daten aus der SQL Backend Datenbank (die mit den Lazy Writes) gelesen und auf dem vierten Front-End Server eine neue User Group erstellt. Anschließend werden die User dann dieser neuen User Group zugeordnet.

Was passiert im Hintergrund?

Bei der Installation eines Lync Enterprise Pools wird ein Windows Fabric Cluster mit allen Lync Front-End Servern als Knoten angelegt (.\Setup\amd64\WindowsFabric.msi). Jeder Knoten (also Lync Front-End Server) bekommt seine eigene eindeutige Routing Group ID und eine Node ID. Leider ist die Verwendung der Begriffe User Group und Routing Group in der Lync Dokumentation etwas verwirrend. Ich verwende in der Zeichnung oben den Begriff Group und meine zur Vereinfachung beide damit.

Aufgrund der eindeutigen Zuordnung von Routing Group ID und Node ID zu Servern und User Groups, weiß also jeder Anwender (Client), an welchem Server er sich anmelden muss. Jeder Front-End Server, bzw. jede Node ID hat einen aktuellen Fabric Status. Die Windows Fabric überwacht diesen Status dauerhaft und speichert dieses in der SQL Backend Datenbank.

LyncFabricSQL

Damit ein Lync Pool läuft und dem Anwender Dienste anbietet muss eine Mindestanzahl an Lync Servern verfügbar sein. Microsoft beschreibt die Anforderungen hier: http://technet.microsoft.com/en-us/library/gg412996.aspx

In diesem Artikel schreibt Microsoft außerdem, dass sie mindestens drei Front-End Server für einen Enterprise Pool empfehlen.

Warum benötige ich mindestens drei Front-End Server in einem Enterprise Pool?

Man kann es bereits erahnen: Wir haben idealerweise drei Kopien der User Groups in unserem Windows Fabric Cluster. Die Windows Fabric setzt ein sogenanntes Cluster Quorum voraus. Dieses Quorum dient dazu die Datenintegrität im Falle eines Ausfalls von Teilkomponenten zu wahren. Damit die Bewertung des Quorums valide ist, muss immer mindestens mehr als die Hälfte der beteiligten Einheiten/Dienste/Komponenten verfügbar sein (Split-Brain Problem). Bein einem Lync Enterprise Pool mit drei Front-End Servern ist also die Mehrheit sehr leicht herzustellen. (2:1 oder 1:2 = 33% : 66%).

Was ist bei einem Enterprise Pool mit nur zwei Front-End Servern?

Wir haben gelernt, dass der Windows Fabric Cluster immer eine Mehrheit (Quorum) benötigt, damit er seine Lync Dienste bereitstellt. Bei einem Lync Pool mit nur zwei Servern bekommen wir diese Mehrheit nicht zustande: (1:1 oder 50% : 50%). Hier behilft sich die Windows Fabric eines Tricks um einen Entscheidungsmehrheit herbeizuführen. Es ernennt den SQL Backend Server zu einem weiteren „Voter“. Damit haben wir wieder eine ungerade Anzahl von Stimmberechtigten und wir erhalten in jedem Fall eine Mehrheit (Quorum). Schaut man sich die aktuelle Windows Fabric Konfiguration auf einem Lync Server in einem „2 Front-End Server“ Pool an sieht man den SQL Server als zusätzlichen „Voter“.

FabricVoter

Was aber auch auffällt, ist das hier in diesem Beispiel nur der Name des SQL Mirror Principals (SQL01.uccloud.net) gespeichert ist. Tatsächlich ist in diesem Beispiel der SQL01 noch mit dem Server SQL02 gemirrored (sh. Bild oben). Findet also ein Failover des SQL Principal auf den Mirror statt, verlieren wir unseren zusätzlichen „Voter“, und damit die Mehrheit im Windows Fabric Cluster. Ohne die Mehrheit (Quorum) ist unser Lync Pool nicht mehr einsatzfähig und schaltet nach fünf Minuten in den „Limited Functionality Mode“. Ob die Windows Fabric in zukunft noch ein Update erhält um auch einen SQl Mirror als Voter zu unterstützen, kann ich derzeit nicht sagen.

Sollte ich einen Front-End Pool mit zwei Server betreiben?

Nun, das überlasse ich Ihnen. Ihnen muss bewusst sein, das derzeit ein 2 Front-End Server Pool zusammen mit SQL Mirroring keine gute „Überlebensfähigkeit“ darstellt. Nach fünf Minuten Ausfall des SQL Principals wird der Limited Functionality Mode initiiert. Sie gewinnen durch das SQL Mirroring also keine höhere Verfügbarkeit Ihrer Dienste. Auch werden Ihre Benutzerdaten nicht wie sonst auf drei Replicas verteilt, sondern stehen nur als primary und secondary Kopie zur Verfügung. Ansonsten läuft ein Lync Pool mit zwei Server wie ein Pool mit drei ober mehr Servern.

Zusammengefasst sind für den Betrieb eines 2 FE Pools folgende Punkte zu beachten:

  • Wenn Sie für Updates einen Front-End herunterfahren müssen, sollten Sie diesen so schnell wie möglich wieder online bringen.
  • SQL Mirroring bringt Ihnen nicht viel. Ohne den SQL Principal wird der Pool nach fünf Minuten in den Limited Functionality Mode gehen.
  • Am Besten starten Sie beide Front-Ends gleichzeitig neu. So vermeiden Sie Probleme bei der Bestimmung des Fabric Quorums!
  • Können Sie nicht beide Front-End Server gleichzeitig starten, so starten Sie diese in umgekehrter Reihenfolge zum Shutdown. Die Reihenfolge der Server können Sie sich mit folgendem cmdlet ausgeben lassen:

Get-CsPoolFabricState -PoolFQDN <FQDN>

  • Können Sie die Server nicht in umgekehrter Reihenfolge starten, so müssen Sie vor dem Start der Lync Dienste das Windows Fabric Quorum neu berechnen lassen:

Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery -PoolFQDN <FQDN>

Was ist mit einem Lync Enterprise Pool und nur einem Front-End Server?

Diese Variante ist ähnlich dem Setup des 2FE Pools. Einen echten Vorteil gegenüber einer Standard Edition sehe ich aber nicht. Sollten Sie planen einen zweiten und dritten Front-End Server zeitnah (am nächsten Tag/Woche) zu installieren, dann ist dieser Schritt natürlich legitim. Haben Sie aber noch keine konkreten Pläne für die Installation der weiteren Server, und wollen sich einfach alles offenhalten, dann empfehle ich dennoch nur die Installation einer Standard Edition. Lizenztechnisch ist dieses dieselbe Lizenz, und sie sparen sich eine SQL Server Lizenz. Der Betrieb einer Standard Edition ist für den Einstieg sicherlich die einfachere Option, denn die Funktionen aus Anwendersicht sind die gleichen. Sie verbauen sich nichts mit der Entscheidung zu einer Standard Edition.

9. Juli 2013

Aktuelle und alte Lync Versionen und Updates


Hier ist einmal eine Zusammenfassung aller kumulativen Updates für Lync und ihre zugehörigen Versionen. Ältere Versionen der CUs sind immer in den neueren CUs enthalten. Einzige Ausnahme bilden hier die Anforderungen an die Datenbank Schema Updates. Bitte beachtet hierzu die jeweiligen Release notes!
Produkt Artikel Version CU
Cumulative update package for Lync 2010: April 2013 2815347 4.0.7577.4384 CU10
Cumulative update package for Lync 2010: March 2013 2791382 4.0.7577.4378 CU9
Cumulative update package for Lync 2010: October 2012 2737155 4.0.7577.4356 CU8
Cumulative update package for Lync 2010: June 2012 2701664 4.0.7577.4103 CU7
Cumulative update package for Lync 2010: February 2012 2670326 4.0.7577.4072 CU6
Cumulative update package for Lync 2010: November 2011 2514982 4.0.7577.4051 CU5
Cumulative update package for Lync 2010: July 2011 2571543 4.0.7577.314 CU4
Cumulative update package for Lync 2010: May 2011 2551268 4.0.7577.280 CU3
Cumulative update package for Lync 2010: April 2011 2496325 4.0.7577.253 CU2
Cumulative update package for Lync 2010: January 2011 2467763 4.0.7577.108 CU1
       
Cumulative update for Lync Server 2010: March 2013 2791381 4.0.7577.216 CU8
Cumulative update for Lync Server 2010: October 2012 2737915 4.0.7577.203 CU7
Cumulative update for Lync Server 2010: June 2012 2701585 4.0.7577.199 CU6
Cumulative update for Lync Server 2010: February 2012 2670352 4.0.7577.190 CU5
Cumulative update for Lync Server 2010: November 2011 2514980 4.0.7577.183 CU4
Cumulative update for Lync Server 2010: July 2011 2571546 4.0.7577.166 CU3
Cumulative update for Lync Server 2010: April 2011 2500442 4.0.7577.137 CU2
Cumulative update for Lync Server 2010,
Core Components: January 2011
2467775 4.0.7577.108 CU1
       
MS13-054: Description of the security update for Lync 2013: July 9, 2013 2812465 15.0.4454.1005 CU2
Description of the Lync 2013 updates: February 2013 2812461 15.0.4454.1509 CU1
       
Cumulative update for Lync Server 2013: July 2013 2819565 5.0.8308.420 CU2
Cumulative update for Lync Server 2013: February 2013 2781547 5.0.8308.291 CU1

23. November 2012

Neue Office 2013 Visio Stencils

Diese Woche hat Microsoft neue Visio Stencils veröffentlicht. Sie beinhalten über 300 Symbole für Office 2013 inklusive Exchange, SharePoint und Lync.

o2013-visio

10. September 2012

Lync 2013 Preview Installation - Teil 4

Lync 2013 wird eine weitere Serverrolle benötigen. Während in Lync 2010 die vollwertigen Lync Clients einen internen PowerPoint Viewer verwendeten und der Web App Client die Präsentationen auf dem Lync Server in DHTML und Silverlight umwandelten, wird Lync 2013 PowerPoint mithilfe der Office Web Applications auf einem Office Web Apps Server darstellen.

Die Vorteile sind vor allem die Unabhängigkeit zu den darstellenden Clients. Hier wird nur noch DHTML und JavaScript eingesetzt werden. Somit kann einfach für die Clients skaliert werden und heterogene mobile Endgeräte werden unterstützt.

Der Nachteil ist die Notwendigkeit eines weiteren Servers, denn Office Web Apps kann nicht auf einem Lync Server installiert werden und muss alleine laufen. Wie alle anderen Server kann aber auch dieser virtualisiert werden.

Vorbereitende Maßnahmen

Bevor es los geht müssen wir wieder ein paar Dinge vorbereiten. Der Office Web App Server benötigt das .NET Framework 4.5 und Windows PowerShell 3.0.

Außerdem sollte man den Hotfix KB2592525 installieren. Damit wird ein Problem behoben, das das Starten der Web Apps Server Dienste behindert.

Office Web Apps benötigt folgende Features auf dem Windows 2008 R2 Server:

Import-Module ServerManager
Add-WindowsFeature Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,Web-Security,Web-Windows-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Ink-Handwriting,IH-Ink-Support,AS-NET-Framework,NET-Win-CFAC 

Nun müssen wir noch ein Zertifikat mit dem vollständigen Namen des Office Web Apps Servers im Namen auf dem Server installieren. Meistens ist dieses bereits vorhanden. Sollte der Hostname nicht mit dem Namen der Office Web App URL übereinstimmen, so können Sie auch ein Zertifikat mit entsprechenden Subject Alternate Names (SAN) verwenden. Stellen Sie dabei sicher, das der Name der Office Web Apps URL dort im SAN auftaucht. Damit später das Zertifikat auch für die Office Web Apps Farm konfiguriert werden kann, ist es wichtig das der “Friendly Name” für das installierte Zertifikat eindeutig ist.

Office Web Apps Installieren

image

Den Office Web Apps Server kann man zur Zeit nur als Preview aus dem Microsoft Download Center herunterladen.

Starten Sie die Installation über die Setup.exe vom Installationsimage.

Übrigens: Wenn Sie die .img Datei nach .iso umbenennen, kann man diese auch in Hyper-V mounten. Mein Dank geht an meinen Kollegen Marco für diesen Tipp Zwinkerndes Smiley.

Akzeptieren Sie die Lizenzbedingungen und bestätigen Sie den Installationspfad. Bitte ändern Sie diesen nicht. Es handelt sich noch um eine Vorabversion und Probleme mit anderen Pfaden sind nicht ausgeschlossen. Klicken Sie auf “Install Now”.

Die Installation wird nun ausgeführt und benötigt ja 5 Minuten. Wenn das Setup durchgelaufen ist, klicken Sie auf “Close”.

Nachdem wir nun Office Web Apps installiert haben, müssen wir eine Office Web Applications Server Farm einrichten. Hierzu starten wir die frisch installiert PowerShell 3.0 und laden das OfficeWebApps Modul:

Import-Module OfficeWebApps

Nun heißt es die Office Web Apps Farm zu erstellen. Hierfür müssen wir die interne und externe URL, sowie das bereits erstellte Zertifikat angeben. Im vorherigen Teil haben wir für die Lync Topologie als Office Web Apps den Hostnamen wac.uccloud.net definiert. Den müssen wir hier wieder angeben. Da wir noch keine externe Anbindung für unser Lync planen, geben wir hier für die interne und externe URL die selbe URL an.

New-OfficeWebAppsFarm -InternalUrl "https://wac.uccloud.net" -ExternalUrl "https://wac.uccloud.net" –CertificateName "wac.uccloud.net" 
Nach ca. 5 Minuten sollte man dann die Bestätigung erhalten, das die neue Office Web App Farm konfiguriert wurde.
image


Nun kann man testen, ob die OWA Installation erfolgreich war. Hierzu rufen wir die Office Web Apps Server discovery URL auf. Diese URL besteht aus dem festgelegten Wert für den Hostnamen aus dem obigen InternalUrl Parameter und einem angehängten “/hosting/discovery”. In unserem Beispiel sieht die URL also wie folgt aus:





Es sollte sich eine Webseite mit den WOPI XML Daten öffnen.

image

 


Tritt ein ASP.NET Fehler auf, kann man versuchen die IIS ASP.NET Komponenten erneut zu registrieren. Hierzu gibt es einen entsprechenden Kommandozeilenbefehl:
%systemroot%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe –iru



Ein anschließender Neustart des IIS sollte dann das Problem beheben:
iisreset /restart /noforce



 

Damit sich Office Web Apps auch nur für unseren Lync Server verantwortlich fühlt müssen wir nun eine “Allow List” definieren. Wenn die Liste werte enthält, wird der Office Web Apps Server nur mit Rechnern aus den Domänen aus dieser Liste “sprechen”. Hierfür benötigen wir wieder PowerShell:
 New-OfficeWebAppsHost –Domain "uccloud.net" 

image


Wenn Sie mehrere Domänen haben, die Sie auch dem Office Web Apps Host konfigurieren möchten, wiederholen Sie bitte den “New-OfficeWebAppsHost” Befehl entsprechend.



Ein “Get-OfficeWebAppsHost” liefert eine Liste der konfigurierten Domänen. Mit “Remove-OfficeWebAppsHost” können Sie einzelne Domänen wieder entfernen. 


Jetzt sind alle benötigen Schritte für die Installation der Lync Server 2013 Preview durchlaufen. Im fünften und letzten Teil werden wir dann die Lync Dienste starten.

7. September 2012

Lync 2013 Preview Installation - Teil 3

Nachdem wir die Topologie bereits im Teil 2 vorbereitet haben, kommen wir jetzt zur eigentlichen Installation des Lync Front End Servers.

Installation Lync Server

Wir melden uns auf dem Lync Server mit einem Domänen Benutzer, der lokale Adminrechte und entsprechende Lyncberechtigungen (Mitglied der CsAdministrator Gruppe) hat auf dem Server an.

Wir starten den Deployment Wizard: image und wählen diesesmal “Install or Update Lync Server System” aus.

image

Wieder startet ein Assistent der uns schrittweise durch die Installation führt. Der erste Schritt ist die Installation des lokalen Konfigurationsspeichers.

image

Da die Daten bereits im CMS veröffentlicht sind, können wir diese direkt von dort auslesen.

image

Der Assistent installiert nun die notwendigen Dateien. Dieses dauert ca. 5 Minuten

image

Nun folgt Schritt 2. Hierbei werden gemäß der Topologievorgaben die benötigten Komponenten installiert. Dieses dauert ca. 10-15 Minuten.

image

image image

Installation Zertifikate

Nun folgt der dritte Schritt und die Installation der Zertifikate.

image

Auch hier hilft wieder ein Assistent. Ich nehme in dieser Installation an, das eine interne Enterprise CA zur Verfügung steht und wir direkt online den Certificate Signing Request (CSR) einreichen und abkönnen können.

image

image image image imageimage image

image image

image image

image image

image image

image image 

image 

Nun haben wir bereits ein Zertifikat das wir auch für die Server-zu-Server Kommunikation einsetzen können. Somit müssen wir nur das selbe Zertifikat nur noch dem OAuthTokenIssuer zuordnen.
Technet Referenz zum Thema Server-to-Server Authentifizierung

image

 

image image image image 

image

Damit ist dann auch der dritte Schritt abgeschlossen und wir kehren zum Deployment Wizard zurück.

image

Der nächste Schritt ist es nun den Office Web Apps Server zu installieren Server.