Lync 2010 Mobile

Mobiletelefone sind heute leistungsfähige PDAs und kleine Computer und immer häufiger "online": Schon mit OCS2007 konnten Anwender mit Communicator Mobile auch unterwegs mit OCS arbeiten. Lync-Anwender mussten hierauf etwas länger warten. Aber mit Lync 2010 CU4 + dem gesondert zu installierenden Mobility-Service kann es dann auch hier los gehen: Hier die Links für ganz Eilige.

Ich hab natürlich alles schon installiert. War ganz einfach (auf Windows Phone 7):
1. Download aus Marketplace
2. Eingeben von SIP-Adresse und Kennwort
3. Willkommensmeldung weg drücken
4. Die Mobilfunknummer für "Call from Office" bestätigen (bzw. anpassen)
5. Fertig.

Und nun sind sie dran :-). Dummerweise ist das nur die Beschreibung für den Client. Auf dem Server muss ein Administrator natürlich noch einiges einrichten.

Tech·Ed North America 2011 Keynote Address
Keynote zur TechEd 2011.
Interessant auch der erste Blick auf den Lync Mobile Client ab ca. Minute 40

Stückliste

Ehe Sie nun gleich an das Konfigurieren gehen, möchte ich als "Kurzfassung" eine Stückliste der Komponenten aufführen. Das ein oder andere könnten Sie bereit haben, fehlendes wäre aber nachzurüsten.

Komponente Beschreibung Ok

Lync Edge.

Alle Clients sprechen per HTTPS mit einem Webservice. Aber bei iPhone und Windows Phone 7 schlafen die Anwendungen, wenn Sie nicht im Vordergrund sind. Meldung an das Telefon werden über den Edge Server als SIP-Paket an "lync.com" gesendet, welches diese dann über die Push-Funktion an das Telefon weiterreicht.

  • Server (Physik oder virtuell aber mit zwei Netzwerkkarten)
  • 1 oder 3 offizielle IP-Adressen (notfalls hinter NAT)
  • 2 offizielle Zertifikate  (z.B. sip.firma.de, webconf.kunde.de)
  • 3 externe DNS-Einträge  (z.B. sip.firma.de, webconf.firma.de, av.firma.de)
  • ca. 2-4h Lync Arbeit  (ohne Server/Firewall Installation)

Die Aufwandsschätzungen beziehen sich auf Erfahrungswerte für durchschnittliche Arbeitszeiten ohne Wartezeiten bei korrekt installierten "einfachen" Umgebungen ohne Hochverfügbarkeit

  

Lync WebServices im Internet per Reverse Proxy veröffentlichen.

Die Webservices werden von iPhone und Windows Phone 7 genutzt. Der vorhandene Lync Poolserver kann zwar um die Mobility-Dienste erweitert werden, aber müssen diese dann dennoch im Internet sicher "veröffentlicht" werden.

  • Reverse Proxy
    Idealerweise haben Sie schon einen TMG/ISA Server oder etwas, was z.B. „Outlook Web Access“ veröffentlicht.
  • 2 externe DNS Einträge
    Der Webservice (z.B. lyncweb.firma.de) und Lyncdiscover.<sipdomain.tld>
  •  externes Zertifikat mit dem Namen des WebService (z.B. lyncweb.firma.de)
  • ca. 1-2h Arbeit, wenn Reverse-Proxy und Firewall Freischaltungen vorhanden sind

Die Aufwandsschätzungen beziehen sich auf Erfahrungswerte für durchschnittliche Arbeitszeiten ohne Wartezeiten bei korrekt installierten "einfachen" Umgebungen ohne Hochverfügbarkeit.

  

Es ist zwar schön, dass seit Lync die Edge-Rolle keine eigene Lizenz mehr benötigt, aber wer bislang Lync nur intern genutzt hat, wird nun erst mal in einen weiteren Server, IP-Adressen, Zertifikate und Dienstleistung investieren müssen. Als kleiner Nebeneffekt können Sie dann aber eine vollständige externe Lync-Anbindung umsetzen, wenn Sie dies wollen, was ihnen z.B. erlaubt...

Sie bekommen also mehr als nur etwas Mobilität, wenn Sie diese Funktionen noch komplett nachrüsten müssten.

Hinweis zu VoIP mit GSM/WiFi und "Call via Work"

Hinweis:
Die Funktion "Call from Work" ist für Android leider noch nicht verfügbar
http://technet.microsoft.com/en-us/library/hh691004.aspx

Die aktuelle Version des mobilen Client kann NICHT über eine bestehende TCP/IP-Verbindung (GSM oder WIFI) telefonieren. Es gibt verschiedene andere Firmen (insbesondere Cisco auf http://blogs.cisco.com/collaboration/maximizing-mobile-collaboration-for-the-post-pc-era/), die sich darüber etwas lustig machen. Sicher wäre es ein nettes Gimmick, wenn ich auf meinem Mobiltelefon per Datentarif auch telefonieren könnte. Die Frage ist nur, ob ich das überhaupt möchte. Denn innerhalb von Deutschland ist die Sprachverbindung über GSM immer noch deutlich besser als jedes VoIP-Telefonat über UMTS. Versuchen Sie das mal mit ihrem PC. Das Thema "Laufzeiten" und Jitter sind hier die Schlüssel. Eine "Schnelle Leitung" ist nicht auch immer eine "gute Leitung. Die Spielernaturen unter uns können sich sicher noch an "Pingzeiten" erinnern und Themen wie "FastPath" beim DSL-Anschluss. Auch bei VoIP sind die meisten Menschen weit weniger tolerant, was Laufzeiten betrifft als beim Surfen. Dass ein YouTube-Video vielleicht ein paar Sekunden "gepuffert" hat und daher minimal zeitversetzt abspielt, stört nicht. Bei einer bidirektionalen Sprachkommunikation ist das aber nicht tolerierbar. Und dann gibt es ja immer noch die "Drosselung" bei Überschreiten entsprechender Datenvolumen. 300 Megabyte/Monat  (Stand T-Mobile Business Complete M 2011) sind sehr schnell aufgebraucht. Wir erklären Sie dann ihrem Außendienstmitarbeiter, wann er welches Medium nutzen sollte ? Im Inland ist VoIP über GSM eher noch kein Argument. Zumal es in vielen Verträgen sogar explizit verboten ist. (und da man VoIP recht einfach erkennen und blocken kann. ist das sicher keine stabile Basis).

Und dass ich per VoIP mit WiFi im Hotel im Ausland billig nach hause telefonieren könnte ist für Skype-Benutzer vielleicht ein Argument, aber weniger für Firmenanwender. Die sollen ja im Urlaub gerade nicht für die Firma arbeiten und wenn Sie beruflich unterwegs sind, dann haben Sie eh ihren Laptop dabei. (Ich zumindest). Und dann kommen ja noch horrende Roaming-Kosten beim Auslandseinsatz auf sie zu. Da können Sie lange "klassisch" telefonieren. Oder sich eben von Lync anrufen lassen.

Aber auch das Thema WiFi ist noch lange nicht ausgestanden. Wie möchten Sie denn hier sinnvoll priorisieren und Bandbreite bereit halten, wenn jeder Senden kann. Es ist auch nicht damit getan einen Access-Point aufzustellen. Damit das Medium ernst genommen wird, muss dann schon eine große Fläche abgedeckt werden. Es gibt Aussagen, dass man nicht mehr als 10-12 Endgeräte pro AP betreiben sollte, damit VoIP sinnvoll nutzbar ist. Interessanterweise beschreibt gerade Cisco, dass es eine neue Generation von APs geben soll.

Ich denke dass auch hier die Entwicklung natürlich weiter gehen wird. Aktuell ist mir aber eine stabile funktionierende Sprachverbindung zu einen akzeptablen Preis bei optimierter Bedienung wichtiger. Eine richtige "TelefonieFlat"-Rate gibt es schon. Eine echte Datenflatrate ohne Drosselung und mit garantierten Laufzeiten sehe ich noch nicht. Wenn sie ihre DSL-Leitung kündigen, weil Sie Internet per Funk haben, dann könnte auch die Zeit reif sein, VoIP per Funk zu machen.

Hier gibt es noch ein paar ähnliche Stimmen.

Funktionsweise

Da nicht alle mobilen Geräte den parallelen permanenten Betrieb von Programmen im Hintergrund erlauben, muss Lync Mobile für das jeweilige Endgerät die passende Option finden, über eingehende Meldungen zu informieren. Beim Abgleich von E-Mails mit Activesync wird dies auch als "Push"-Notification bezeichnet. Der Client stellt eine HTTP(s)-Anfrage an einen Webserver/WebService und bekommt vom Server eine Antwort, wenn etwas ansteht. Das eigentliche Programm kann in der Zeit schlafen und den Akku schonen.

Eine permanente Statusanzeige der Kontakte erfolgt nur, wenn der Lync Client im Vordergrund ist. Nutzt der Anwender andere Programme auf dem Smartphone, sind diese Informationen ja nicht relevant.

Endgerät Server Endpunkt Push
Windows Phone 7 HTTPS Lync Web Service wenn im Vordergrnud SIP über Edge zu Microsoft Cloud
iPhone HTTPS Lync Web Service wenn im Vordergrund
Apple Push-Notification über Port 5332 zu Apple		 SIP über Edge
Android HTTPS Lync Web Service. Verbindung bleibt aktiv ! HTTPS (?)
Symbian HTTPS Lync Web Service. Verbindung bleibt aktiv ! (?)
Blackberry RIM SRP via NOC gegen Firmen BES-Server
BES-Server geht per SIP an Lync Pool		 Proprietär über BES

Sie sehen schon, dass Windows Phone 7 und iPhone selbst per HTTPS mit einem von ihnen veröffentlichten Webservice arbeiten und Meldungen an den Client werden über den Edge-Server quasi per "Federation" an den Provider gesendet, der diese dann über die eigenen Plattformen an das Endgerät meldet. Sie müssen also sowohl einen Lync Webservice installieren und veröffentlichen als auch einen Edge-Server mit Federation betreiben. Nur die Blackberry Clients nutzten ihre eigene Infrastruktur über das Blackberry NOC zum internen Blackberry Enterprise Server, welcher dann die Anfragen per SIP an den Lync Pool intern sendet.

Es kommen als ganz schön viele verschiedene Kommunikationswege zusammen. und erst wenn alle funktionieren, ist das System betriebsbereit:


Quelle: Microsoft Powerpoint: "Lync Mobile – Clients, Server & Deployment Planning"

Der Mobilclient spricht über einen Reverse Proxy mit den Lync Webservices und der Edge-Server übernimmt die Arbeit, ausgehende Push-Benachrichtigungen über ein Clearinghouse zu versenden.

DNS für Lyncdiscover.<sipdomain> und Lyncdiscoverinternal.<sipdomain>

Analog zu Autodiscover bei Exchange hat sich Microsoft für die mobilen Lync Clients einen Mechanismus einfallen lassen, bei dem ein Client quasi mit Angabe der ihm bekannten SIP-Adresse und eines Kennworts eine Verbindung herstellen kann. Der mobile Client sucht einfach nach einem fest definierten Namen, der sich nur nach Intern und Extern unterscheidet. In der Microsoft Dokumentation ist dazu ein nettes Bild, wie die Webservices mit einem Reverse Proxy und den Namen zusammen arbeiten.


Quelle: Microsoft Mobility Deployment White paper (Word-Dokument: "LS_Mobility.doc")

Sie sollten erkennen, dass nur das "Lync External Web" auf Port 4443 auch das Mobility-Verzeichnis hostet. Das "lync Internal Web" hingegen enthält nur einen kleinen Autodiscover-Eintrag.

Wenn Sie Lync Mobile so konfigurieren, dass ein Client auch von extern arbeiten darf, dann greifen interne Clients auch über extern zu. Die hat als Grund, dass ein Client ja per WiFi intern und per GSM extern kommen kann und beim Standortwechsel dies beiden Netzverbindungen sich abwechseln. Damit die Session dann bestehen bleiben kann, muss der Client immer über den Reverse Proxy gehen, welcher auch über "Cookies" die Affinität bei einem Lync-Pool herstellen muss. Der Loadbalancer muss dazu natürlich den SSL-Traffic inspizieren.

Der Client versucht beim Start zwei URLs zu erreichen, die per per DNS natürlich auflösen muss:

Der interne Name lyncdiscover.<sipdomain> darf im Internet demnach nicht auflösbar sein. Beide URLs haben aber nur die Funktion, den Client auf die richtige URL umzuleiten. Das hört sich für kleine Firmen erst mal komplex an, ist aber für Cloud-Anbieter natürlich einfacher, da der Zugriff auf diese URLs auch ohne SSL erfolgen kann und daher kein Zertifikat erforderlich ist. Der Redirect kann dann aber auf eine ganz andere URL gehen, deren Domain-Part auch nicht mit dem SIP-Part übereinstimmen muss. So kann ein Hoster eben viele SIP-Domains über die gleiche Veröffentlichung abwickeln.

Der mobile Client versucht immer beide URLs zu erreichen. Kann er die interne URL erreichen nimmt er an er ist im lokalen Netz.

Lync Mobile und Edge Server

Eigentlich könnte man erwarten, dass der mobile Lync Client einfach per Webservice nun funktionsfähig wäre. Die meisten Dienste werden auch über die Webservices abgewickelt, aber ein WebService kann immer nur vom Client angesprochen werden aber nicht selbst zum Client hin aktiv werden.

Wenn eine eingehende Verbindung vom Client zum Webservice aufgebaut ist, dann kann der Client natürlich eine Anfrage stellen und der Webservice zu gegebener Zeit darauf antworten. Nun sind aber mobile Clients eben "Mobil" und es ist nicht gerade sicher, dass eine Verbindung noch besteht. "Zuverlässig" wäre dies demnach nicht.

Daher gibt es auch den Edge-Server, welcher für ausgehende Nachrichten verwendet wird. Der Android-Client, der permanent im Hintergrund aktiv sein kann, nutzt diesen Weg auch für die normale Kommunikation aber iPhone und Windows Phone 7 werden von ihrem "Anbieter" mit Updates per Push versorgt. Der WebService auf dem Lync Server sendet daher ausstehende Anfragen per SIP über den Edge zum Provider, welcher dann die Nachricht über die eingebauten Push-Funktionen an das mobile Gerät sendet.

Hier sehen Sie so eine Meldung. Ein Kollege von Net at Work hat von interne eine Message an mich gesendet. Sie sehen gut, dass der Absender der McxUser ist, der sich aber im "Displayname" als Frank Carius" ausgibt und die Meldung an "push@pushl.lync.com gesendet wird. 

Auf dem Handheld wird natürlich die "richtige" Information ausgegeben, die hier unten im "MessageBody" enthalten ist. Der wurde aber hier im Log per Default abgeschnitten. Es bleibt dann der "Push-Plattform" überlassen, die Daten an das Mobiltelefon zu senden, welches sich dort natürlich als Empfänger registriert hat.

Software

Auf der Seite Lync Updates habe ich schon beschrieben, dass mit dem CU4 die Lync Serverdienste entsprechend erweitert werden. Wer die Hilfe zu "Set-CSWebService" aufruft, erkennt auch schon neuen Parameter:

PS C:\> get-help Set-CsWebServer

NAME
    Set-CsWebServer

SYNOPSIS
    Modifies one or more of the Web Server services used by Microsoft Lync Serv
    er 2010.


SYNTAX
    Set-CsWebServer [-Identity <XdsGlobalRelativeIdentity>] [-AppSharingPortCou
    nt <UInt16>] [-AppSharingPortStart <UInt16>] [-Confirm [<SwitchParameter>]]
     [-ExternalFqdn <Fqdn>] [-ExternalHttpPort <UInt16>] [-ExternalHttpsPort <U
    Int16>] [-Force <SwitchParameter>] [-InternalFqdn <Fqdn>] [-McxSipExternalL
    isteningPort <UInt16>] [-McxSipPrimaryListeningPort <UInt16>] [-PrimaryHttp
    Port <UInt16>] [-PrimaryHttpsPort <UInt16>] [-PublishedExternalHttpPort <UI
    nt16>] [-PublishedExternalHttpsPort <UInt16>] [-PublishedPrimaryHttpPort <U
    Int16>] [-PublishedPrimaryHttpsPort <UInt16>] [-ReachExternalPsomServerPort
     <UInt16>] [-ReachPrimaryPsomServerPort <UInt16>] [-UserServer <String>] [-
    WhatIf [<SwitchParameter>]] [<CommonParameters>]

Und auch ein Auslesen der aktuelle Einstellungen ist möglich:

Vor dem CU4 Update gab es noch nicht die Parameter McxSipPrimaryListeningPort und McxSipExternalListeningPort

Da der String "Mcx" da nun interessant ist kann man danach auch mal per Powershell mit "get-help *mcx*" suchen.

Name                              Category  Synopsis
----                              --------  --------
Get-CsMcxConfiguration            Cmdlet    Get-CsMcxConfiguration [[-Identi...
New-CsMcxConfiguration            Cmdlet    New-CsMcxConfiguration [-Identit...
Remove-CsMcxConfiguration         Cmdlet    Remove-CsMcxConfiguration [-Iden...
Set-CsMcxConfiguration            Cmdlet    Set-CsMcxConfiguration [[-Identi...
Test-CsMcxConference              Cmdlet    Test-CsMcxConference [-TargetFqd...
Test-CsMcxP2PIM                   Cmdlet    Test-CsMcxP2PIM [-TargetFqdn] <S...

Das CU4 alleine reicht aber nicht, denn wichtigster Dreh und Angelpunkt ist ein Webservice, welcher auf dem Lync Server installiert wird und per HTTPS einen Zugriff von Intern und Extern bereit stellen.

Einrichtung DNS

Da speziell die Konfiguration von DNS im Internet auch immer etwas zeit dauert, sollten Sie mit dem Schritt anfangen und dafür sorgen, dass in der DNS-Domäne, die auch die SIP-Domäne des Anwenders ist, die entsprechenden Einträge vorgenommen werden.

So findet der Client immer den Weg zum Server, der ihm als erstes eine Datei mit den richtigen "Autodiscover URLs" übermittelt.

Zertifikate und HTTP-Request

Durch den Einsatz weitere DNS-Namen, die per A oder CNAME auf einen Webserver gelenkt werden, müssen diese Services natürlich auch im Zertifikat um den Namen erweitert werden. Die beiden Namen können gefahrlos als SAN-Eintrag addiert werden.

Laut LS_Mobility.doc ist es auch möglich ein "SAN=*.<sipdomain>" zu nutzen. Ein Wildcard-Zertifikat, in dem der CN kein Wildcard ist, funktioniert. Siehe auch Wildcard Zert

CNAME oder A-Record,  HTTP oder HTTPS
Beide Varianten sind voll unterstützt. Ein Client findet so oder so einen Webserver. Beim Einsatz von HTTPS muss der Webserver aber natürlich den Namen auch im Zertifikat haben

Einrichtung auf dem Server

Auf den Lync Frontend bzw. Standard-Servern sind nun einige Installationen vorzunehmen.

Durch das Update werden die Lync Dienste für eine kurze Zeit gestoppt. Wenn Sie vorher den IIS und die Lync-Dienste manuell stoppen, reduziert sich die Wahrscheinlichkeit, dass das Setup einige Dateien nicht aktualisieren kann und einen Neustart anfordert.

Install-CsDatabase 
   -Update 
   -ConfiguredDatabases 
   -SqlServerFqdn sqlservername
   -ExcludeCollocatedStores
Set-CSWebservice `
    - MCXSIPPrimaryListeningPort 5086 `
    - MCXSIPExternalListeningPort 5087

Enable-CSTopology

Import-Module ServerManager
Add-WindowsFeature Web-Server, Web-Dyn-Compression
C:\ProgramData\MicrosoftLync Server\Deploymentcache\4.0.7577.0\setup
cd C:\Program Files\Microsoft Lync Server 2010\Deployment\
.Bootstrapper.exe
Get-CsService -WebServer | fl identity,mcx*

Identity                    : WebServer:nawlync001.netatwork.de
McxSipPrimaryListeningPort  : 5086
McxSipExternalListeningPort : 5087
McxServiceExternalUri       : https://lyncweb.netatwork.de/Mcx/McxService.svc
McxServiceInternalUri       : https://nawlync001.netatwork.de/Mcx/McxService.svc

Hinweis: Ich habe noch keine klare Aussage dazu gefunden aber mein Lync Server hat ein Wildcard-Zertifikat und bislang funktioniert Lync Mobile problemlos.

Normalweise ist der Zugriff auf Mobility in der globalen Richtlinie eingeschaltet. Ein prüfender Blick kann aber nicht schaden:

Get-CsMobilityPolicy
Identity : Global 
Description :
EnableOutsideVoice : True
EnableMobility : True

Einrichtung auf dem Reverse Proxy

Anhand dem Parameter "McxServiceExternalUri" ist es offensichtlich, dass aus dem Internet ein Webservice angesprochen werden soll, welcher natürlich genauso sicher wie die anderen Lync Webservices (LyncWeb) abzusichern und per Loadbalancer zu verteilen ist. Die meisten Firmen können hier schon den bestehenden ReverseProxy (z.B. TMG und UAG) oder andere Lösungen einsetzen.

Wer hingegen den Zugriff nur von intern erlauben möchte, kann dies über folgenden Powershell-Befehl erreichen.

# Beschraenkung von Lync Mobile auf intene Clients

Set-CsMcxConfiguration -ExposedWebUrl Internal

Damit wird der internen Lyncdiscover-URL mitgeteilt, dass er keine externe URL als Umleitung an den Client senden soll.

If you support push notifications and want Apple mobile devices to receive push notifications over your Wi-Fi network, you also need to open port 5223 on your enterprise Wi-Fi network. Port 5223 is an outbound TCP port used by the Apple Push Notification Service (APNS). The mobile device initiates the connection. For details, see http://support.apple.com/kb/TS1629
Quelle: Microsoft: LS_Mobility.doc

Hinweis:
Die Mobility Webseite unterstützt keinen "unencrypted Traffic" und damit kein Offloading. Er einen Loadbalancer einsetzt, um die Anbindung hochverfügbar zu machen, MUSS das Zertifikat auf dem Loadbalancer installieren und die Affinity auf Cookies ausrichten. Eine Lastverteilung auf Basis von Source-IP soll nicht ausreichen, da die Clients ja auch mal die IP-Adresse wechseln (Sie sind ja mobil!)

Einrichtung bezüglich Edge-Server

Damit der Edge-Server die Push Notifications senden kann, muss die Konfiguration erweitert werden.

Hinweis
Bei OCS mussten Sie solche Einstellungen noch auf jedem Edge Server machen. Bei Lync stellen Sie dies alles auf einem Frontend per Powershell ein und lassen die Konfigurationseinrichtung über die Lync CMS-Replikation auf den Edge Server bringen.

Folgende Powershell-Befehle sind notwendig

New-CsHostingProvider 
   -Identity "LyncOnline" 
   -Enabled $true 
   -ProxyFqdn "sipfed.online.lync.com"
   -VerificationLevel UseSourceVerification

New-CsAllowedDomain 
   -Identity push.lync.com 
   -Comment "Lync Mobile Push Notifications"

Set-CsPushNotificationConfiguration 
   -EnableApplePushNotificationService $true 
   -EnableMicrosoftPushNotificationService $true

Set-CsAccessEdgeConfiguration 
   -AllowFederatedUsers $true

Diese Befehle "öffnen" Lync dafür, dass SIP-Anfragen an "lync.com" nach draußen gehen und nebenbei dieser Access-Edge sipfed.online.lync.com auch für andere Domains (Siehe Office 365 Lync) dann eingerichtet, die bei Office 365 gehostet werden.

Konfiguration für den Benutzer

Die Konfiguration für die Anwender erfolgt wie bei Konferenzen und anderen Einstellungen über Policies, d.h. es wird nicht pro Benutzer gepflegt, was er darf, sondern ein Verweis auf eine Richtlinien. Ein get-help zeigt die Befehle nach der Installation von CU4 schon an

PS C:\> Get-Help *csmob*

Name                              Category  Synopsis
----                              --------  --------
Get-CsMobilityPolicy              Cmdlet    Retrieves information about the ...
Grant-CsMobilityPolicy            Cmdlet    Grants a per-user mobility polic...
New-CsMobilityPolicy              Cmdlet    Creates a new mobility policy at...
Remove-CsMobilityPolicy           Cmdlet    Removes an existing mobility pol...
Set-CsMobilityPolicy              Cmdlet    Modifies an existing mobility po...

Die per default wirkende "Globale" Richtlinie ist sehr "offen"

PS C:\> Get-CsMobilityPolicy

Identity           : Global
Description        :
EnableOutsideVoice : True
EnableMobility     : True

Sie können natürlich eine eigene Policy anlegen und den Benutzern zuweisen.

Funktionstest

Der Lync Client macht eine HTTP/HTTPS Anfrage und das können Sie genauso mit einem Browser testen.

https://lyncdiscover.<sipdomain>

Sie sollten ohne weitere Authentifizierung eine Datei zum Download angeboten bekommen, welche Sie in Notepad öffnen können und ihre URLs zum Lync Autodiscover Service enthält, etwas in der folgenden Form. (Zeilenumbrüche zur Lesbarkeit addiert.

{"AccessLocation":"External","Root":
{"Links":[{"href":"https:\/\/lyncweb.netatwork.de\/Autod
iscover\/AutodiscoverService.svc\/root\/domain","token":"Domain"},
{"href":"https:\/\/lyncweb.netatwork.de\/Auto
discover\/AutodiscoverService.svc\/root\/user","token":"User"}]}}

Einschränkungen

Der mobile Client trägt zwar die Versionsnummer 4.0 aber ist letztlich noch eine Version 1.0 die sicher bald noch weiter entwickelt werden wird. Es gibt also noch die ein oder andere Einschränkung, die ich selbst schon festgestellt habe.

Ich kann nicht sagen, ob diese Funktionen nur bei mir oder in Verbindung mit meinem Clients nicht gehen. Wenn jemand etwas andere Beitragen kann, bitte ich um eine kurze Mail.

Kontrolle von Außen

Wer "Dienste" für seine Clients anbietet, bietet diese auch immer automatisch "jedem" an. Natürlich gibt es eine entsprechende Absicherung über Benutzername/Kennwort oder Zertifikate aber wer kein VPN oder Direct Access einsetzt, muss zwangsläufig einen anonymen Zugriff erst mal erlauben. Auch auf die OWA-Anmeldeseite kommt man als Angreifer erst mal drauf.

Diese Zugänge sind aber auch ein erster einfacher Test zur Funktion. Dabei sind zwei URLs interessant

Https://<poolname>/autodiscover/autodiscoverservice.svc/root/domain

https://<poolname>/mcx/mcxservice.svc

Beide sollten ihnen einige Daten zurück liefern.

Andere Lösungen

Auch vor der "offiziellen Lösung" durch Lync gab es schon Programme, AddOns und Tools, die auf Mobilgeräte eine Lync Funktion gebracht haben. Mit der von Lync offiziell unterstützten Lösung sind die meisten Programme aber hinfällig oder es ist zumindest fraglich, ob diese weiter entwickelt werden. Es war sicher Ende 2010 bis Dez 2011 interessant, die Lücke, die Microsoft gelassen hat, zu füllen.

ClientOS Funktion
Windows Mobile 6.5 Für Windows Mobile 6.5 gibt es aktuell nur den Communicator Mobile, welcher aber nicht mit Lync 2010 zusammen arbeitet. Mal sehen wann sich hier etwas tut.
Windows Mobile 7

Ältere Anwendungen wie der CoMo laufen nicht auf Windows Mobile 7. Bis es einen passenden Client gibt, ist aktuell wohl noch kein Communicator auf Windows Mobile 7 verfügbar.

Umgekehrt beinhaltet WM7 leider keinen Messenger Client, der mit OCS/Lync kompatibel ist. Aber ich bin recht sicher, dass Microsoft daran ist.

Erste Hinweise gibt es schon

Lync Mobile brings the Lync experience to Windows Phone customers by delivering Unified Communications capabilities, including instant messaging and the ability to see the presence of your co-workers. The Lync app will be a free download from Windows Phone Marketplace and will be enabled with support from your business organization
Quelle: Productivity takes a big step forward in Mango
http://windowsteamblog.com/windows_phone/b/windowsphone/archive/2011/05/16/productivity-takes-a-big-step-forward-in-mango.aspx

Unabhängig von der offiziellen Produktgruppe hat Michael W. Olesen (Ebenfalls Microsoft) in seiner Freizeit dran gesetzt)
http://blogs.msdn.com/b/mwo/archive/2011/03/11/lync-client-for-wp7-faq.aspx
http://blogs.msdn.com/b/mwo/archive/2011/04/05/lp-v2-0-coming-up.aspx
http://blogs.technet.com/b/cs2010/archive/2011/04/24/lync-mobile-lp-client-and-lp-server-software-released.aspx
http://blogs.technet.com/b/fareedmk/archive/2011/03/04/unofficial-lync-client-for-windows-phone-7.aspx
http://wmpoweruser.com/third-party-lync-client-lp-in-the-works/
https://msmvps.com/blogs/nunoluz/archive/2011/03/01/windows-phone-7-client-for-lync.aspx
http://www.youtube.com/watch?v=UABgObGTk6o
Apple iPhone OS

Noch keine Integration. Es gibt wohl eine App für die Kommunikation mit OCS 2007R2 CWA, der auch noch gegen Lync arbeiten kann. (Status, Präsenz, Kurzmitteilungen)

Mit dem Produkt Xync gibt es aktuell schon eine passende App für IPhone, Android und Symbian
https://xync.damaka.com/xync/
http://itunes.apple.com/ch/app/xyncconf/id464366291?l=en&mt=8

Blackberry

RIM hat mit dem Blackberry Enterprise Server 5.0 SP3 nun endlich auch eine direkte Verbindung zwischen BES und OCS/Lync entwickelt ohne über den CWA Web Access gehen zu müssen. Auf dem BES müssen dazu die "Blackberry Collaboration Services" und UCMA API 2.0 installiert sein.

OCS mit Blackberry

Beachten Sie aber das Limit

The BlackBerry Collaboration Service supports up to 2000 connections for instant messaging sessions ...
Quelle: Blackberry Administration Guide
Android

Noch keine Integration. Ich habe auch hier gehört dass es einen Client gäbe der mit OCS und danke CWA auch mit Lync arbeitet

Mit dem Produkt Xync gibt es aktuell schon eine passende App für IPhone, Android und Symbian
https://xync.damaka.com/xync/
https://market.android.com/details?id=com.damaka.ucc.Xync.A.ui
https://market.android.com/details?id=com.damaka.ucc.XyncConf.C.ui

Symbian

Noch keine Integration. Für OCS gibt es eine App, die aber noch den OCS2007 CWA benötigt aber so auch mit Lync arbeiten kann (Status, Präsenz, Kurzmitteilungen)

Mit dem Produkt Xync gibt es aktuell schon eine passende App für IPhone, Android und Symbian
https://xync.damaka.com/xync/
Browser Noch keine Integration. Abgesehen von der Nutzung per CWA
Mac http://blog.officeformac.com/announcing-communicator-for-mac/

Natürlich gibt es für verschiedene Clients natürlich Instant Messenger Clients für MSN, AOL, Google, Yahoo etc., die dann wieder über Federation mit Lync/OCS verbunden werden können. Aber das ist keine Lösung in dem hier gewünschten Sinne.

Aktuell arbeiten noch viele Clients über den "alten" Communicator Web Access von OCS 2007 R2, der auch mit Lync eingesetzt werden kann. Eine Middleware ist sicher eine vernünftige Idee, um den Client auf dem Mobilgerät möglichst schlank zu haben. Zudem lassen sich Updates auf einem Backend einfacher einspielen und diverse Protokolle erfordern regelmäßige "ich bin noch da"-Pakete. Müsste die ein PDA selbst erzeugen, würde das Datenvolumen und Strombedarf steigen. Auch bei ActiveSync (Pushmail) kommuniziert der PDA ja nicht direkt mit dem Postfach, sondern nutzt die WebApplikation "ActiveSync" als Vermittler.

Weitere Weitere Links

Keywords: Lync Mobil iPhone WinPhone7 Android Blackberry