OCS Communicator Web Access R2 – Teil 2: Aus administrativer Perspektive

Dem Teil 1 zum Thema CWA R2 folgend, hier nun die administrative und damit vor allem technische Betrachtung des Servers / der Serverrolle.

Voraussetzungen

CWA R2 wird bei der Installation in die Microsoft Internet Information Services (IIS) auf Windows Server 2003 ab SP2 oder Windows Server 2008 integriert. Eine Freigabe für Windows Server 2008 R2 gibt es wie für alle OCS R2 Rollen meines Wissens noch nicht. In meinem "Sandbox"-Deployment (komplett auf W2K8 R2 x64 RTM) sieht bisher alles gut aus. 🙂 Es ist sehr wahrscheinlich, dass das Communications Server Produktteam kurz nach dem Verkaufsstart dazu Stellung nimmt. Wie alle OCS R2 Rollen bzw. Server setzt der CWA ein 64-bit Betriebssystem voraus.

Die Installation / der Betrieb des Communicator Web Access Server R2 ist standalone nicht möglich. Es muss also immer ein OCS Deployment Standard oder Enterprise vorhanden sein, das u.a. die Benutzerdatenbank umfasst. Die minimalen Hardwarevoraussetzungen, welche Microsoft für den CWA R2 empfiehlt:

• Processor. Server with dual Quad-Core 2.0 gigahertz (GHz) or higher processor or PC with 4-way Dual-Core 2.0 GHz or higher processor
• Memory. 8 gigabyte (GB) double data rate (DDR) RAM
• Disks. 2 x 72 GB 15K or 10K RPM disk drives, RAID 0 (striped) or equivalent
• Network card. 2 x gigabit (1 gigabit per second) Ethernet network adapter

dürften auf den ersten Blick für Überraschung sorgen und die Frage aufwerfen: "Darf’s auch etwas weniger sein?". Aus meiner Erfahrung kann ich sagen: "Ja darf’s, aber…". 🙂 Die genannten Mindestanforderungen genügen für circa 5000 gleichzeitige CWA Nutzer (kein Zahlendreher!) auf einem dedizierten Server, solange nur Instant Messaging und Presence verwendet werden. Daher kann man bei geringem Bedarf des CWA auch gern zu einen schwächeren System greifen. Vermutlich würde man auch dann noch Support von Microsoft erhalten. Absolut tabu dagegen ist es aber den CWA mit anderen Rollen auf einem System zusammen zu betreiben oder der Betrieb auf einer virtuellen Maschine. Dabei ist es völlig egal ob die Virtualisierungstechnik Hyper-V, ESX, etc. heißt, bzw. durch das Server Virtualization Validation Program (SVVP) zertifiziert ist oder nicht. Alle OCS Rollen / Server die Medienströme (RTP) umfassen werden virtualisiert nicht supported! Ein spezielles Whitepaper des OCS Serverteams geht detailliert auf die Hintergründe ein, die zu dieser Support-Politik geführt haben. Kurz umrissen geht es dabei um Paketverluste, Delays, Jitter und Timerabweichungen (auch zwischen Host & Guest Maschine). Diese beeinträchtigen maßgeblich die Qualität der echtzeitkritischen Medienströme und treten bei virtualisierten Deployments verstärkt auf. Es ist mit Problemen bei der Audio & Video-Übertragung und beim Desktopsharing zu rechnen.

Auch hier kann ich aus der Praxis berichten: "Ja es geht virtualisiert und auch eine Co-Location bspw. mit dem OCS Standard Edition Server ist möglich, aber…". 🙂 In kleinen Umgebungen wird schon mal auf den MS-Support verzichtet und man "lebt" mit den eher selten spürbaren Qualitäts-Einbußen. Empfehlen kann ich es in keinem Fall, da es nebenbei auch die Bereitstellung deutlich erschwert. Bei konsequentem Einsatz der Möglichkeiten, die die Microsoft UC Plattform bietet, werden diese mittelfristig ohnehin als geschäftskritisch eingestuft. Spätestens dann kommt man um eine Ablösung der virtualisierten oder kollokierten Systeme nicht herum.

Speziell beim CWA stellt sich aber schnell die Frage, warum und wie dieser über in RTP-Streams involviert ist. Dazu lohnt es sich die Integration des CWA R2 in die OCS Infrastruktur unter die Lupe zu nehmen.

Integration

Bei Verwendung der Standardfunktionen von CWA R2 kommen vor allem die Protokolle HTTPS und SIP zum Einsatz (Presence, Instant-Messaging, etc.). Das Feature Desktopsharing setzt auf das Remote Desktop Protocol welches in einem SRTP (Secure Real-Time Transport Protocol) Stream übertragen wird. Daher kommt es auch beim CWA zum Austausch von echtzeitkritischen Medienströmen.

Das zentrale Mixing der Desktopfreigabe für alle Teilnehmer erfolgt auf dem OCS Frontend Server(n) in der Application Sharing Multipoint Control Unit (MCU). Diese MCU läuft als eigenständiger Dienst RTCASMCU welcher die ASMCUSVC.exe ausführt. Der Communicator Web Access Server ist in der Lage, die von der ASMCU empfangenen Inhalte in AJAX Dynamic HTML (DHTML) umzuwandeln. Diese DHTML "Screenshot" Webseiten werden ständig neu nachgeladen und erzeugen so den Eindruck einer Remote Desktop Session. Deshalb können diese browserunabhängig betrachtet werden.

Externer Einsatz

Die Grafik zeigt auch einen wesentlichen Unterschied bezüglich der Zugriffe externer Clients. Microsoft Office Communicator Nutzer (Full Desktop Client und Mobile auf Windows Plattformen) melden sich über den Edge Server an. Dagegen nutzen Anwender mit Communicator Web Access oder Communicator Mobile (JAVA based express Edition) die Reverse Proxy Veröffentlichung des CWA R2.

Die Microsoft Empfehlungen zur sicheren Veröffentlichung des CWA gehen soweit, dass man einen dedizierten Server nur für externe Zugriffe bereitstellen soll. Dieser soll außerdem über zwei Netzwerkkarten verfügen – die eine extern, die andere intern. In den meisten Fällen wird man wohl eher von folgender Möglichkeit Gebrauch machen. Nach Fertigstellung der Installation und Aktivierung der CWA Rolle erstellt man mit Hilfe der Communicator Web Access MMC einen Virtual Server im IIS. Hierbei bietet der Wizard die Option dessen Typ auf extern oder intern festzulegen.

Beide CWA Virtual Servertypen können auf einem Server koexistieren. Der einzige Unterschied besteht in den verfügbaren Authentifizierungsmethoden.

So gibt es beim externen VS keine windows integrierte Authentifizierung. Statt dem Standard-Port 443 für die Webzugriffe verwendet man am externen VS bspw. den Port 444 und berücksichtigt diesen dann beim Port Bridging am Reverse Proxy. Hier am Beispiel von ISA Server 2006:

Wie das folgende Bild der CWA R2 Verwaltungskonsole zeigt können,wie erwähnt zwei oder mehrere virtuelle Instanzen auf dem gleichen System existieren. Die Trennung der externen und internen Zugriffe durch die Instanzen bietet neben der Verringerung der Angriffsfläche auch die Option die maximalen Sitzungszeiten unterschiedlich zu konfigurieren.

Natürlich kann man, wie Microsoft empfiehlt die VS Instanzen gezielt auf zwei Netzwerkkarten (extern / intern) zuweisen. Doch zuvor sollte man sich fragen ob man bei der Veröffentlichung von Outlook Web Access, Exchange Web Services und Active Sync auch soweit gegangen ist – im Normalfall vermutlich nicht. J

Hinweise zur Nutzung

Beim Einsatz von CWA sind noch einige Besonderheiten zu beachten.

• Da der Communicator im CWA als Popup erscheint, müssen Popup Blocker durch eine entsprechende Ausnahme für die CWA URL "ruhig gestellt" werden.
  
  Zum Glück weißt die Anmeldewebsite den Nutzer daraufhin, wenn auch etwas zu umfassend.
  
  Würde man den Tipps aus der Hilfe tatsächlich folgen, deaktiviert man Popup Blocker grundsätzlich was sicher nicht im Sinne des Anwenders sein kann.
• Die windows-integrierte Authentifizierung, die ohnehin nur beim internen Einsatz zur Verfügung stehen dürfte, ist nur unter folgender Bedingung möglich: Die vom Anwender eingebene URL zum Zugriff auf den CWA bspw. https://webchat.ucc.de muss im Internet Explorer zu den lokalen Intranetseiten gehören oder über das automatische Ermitteln als solche erkannt sein.
  
  Hierbei helfen natürlich auch die Gruppenrichtlinien für den IE weiter.
• Sollte trotz allem die Anmeldung mal nicht funktionieren und der CWA "wirft" ulkige Fehlermeldungen, wie in diesem Fall:
  "Die Anmeldung kann nicht ausgeführt werden, da die Uhr Ihres Computers nicht richtig eingestellt oder Ihr Konto ungültig ist. (Fehlercode: 0-1-492)"
  – lohnt sich auch ein Blick in die erweiterten Sicherheitseinstellungen im IE:
  
  Erfahrungsgemäß hilft nämlich alles Troubleshooting an den Servern, DNS und AD null-komma-nix, solange der IE gar keine windows-integrierte Authentifizierung unterstützt. 🙂 (Bitte das Sternchen an der Option beachten – Neustart des IE also nicht vergessen!)

• Das Communicator Web Access Plugin wird nur dann benötigt, wenn man selbst den Desktop freigeben möchte.
  
  Die Installation des Plugin setzt unter Vista / Windows 7 voraus dass User Account Control aktiviert ist und der Browser mit den normalen Anwender Privilegien ausgeführt wird. Das ermöglicht zwar nahezu jedem Standard-Anwender die Nutzung des Plugin, stellt jedoch Administratoren vor ein Problem.
• Das AddOn (CWAPlugin.exe) rendert während der Desktopfreigabe den Bildschirm des Nutzers und sendet diese Inhalte in RDP innerhalb eines SRTP Streams an den Audio Video Edge Server. Es genügt also für den externen Einsatz dieser Funktion nicht nur den CWA Server bereit zu stellen und zu veröffentlichen. Nur über den Audio Video Edge Server kann der Desktopinhalt des externen Nutzers an die Application Sharing MCU auf dem OCS Front End Server "durchgereicht" werden.
• Dieses AddOn ist außerdem nur auf Windows Plattformen (ab Windows XP SP2) installierbar. Die unterstützten Browser sind auf Internet Explorer und Firefox beschränkt. Das heißt Linux und Apple Systeme können zwar an Desktopsharing Sitzungen teilnehmen, aber selbst keine Freigaben ausführen.

Fazit

Das Deployment des Communicator Web Accces Server R2 ist per Wizards und einigen Klicks schnell und unkompliziert erledigt. Bei der Einbindung in die OCS Infrastruktur und bei der Veröffentlichung zur externen Nutzung sollte man die Abhängigkeiten und Zusammenhänge genauestens kennen. Im Falle der Funktion web-basiertes Desktopsharing kommt man um ein komplettes Deployment inklusive Edge Server nicht herum. Will man die Nutzung der Telefonfunktionen mit einbeziehen, ist die Infrastruktur um den Mediation Server zu ergänzen. Bereits ein Ausblick zu einem der Themen würde jedoch den Rahmen dieses Beitrags sprengen. J

Über den Autor:

Jan Boguslawski ist Consultant bei der ITaCS GmbH. Als Spezialist für die Microsofts Unified Communications und Messaging Lösungen liegt sein technischer Focus auf Office Communications Server & Exchange Server, inklusive deren Integration in Telekommunikationssysteme.