Es gibt seit dem 18.11.2011 neue Updates (CU4) für Lync 2010 vom November 2011. Hiermit ist es auch möglich die kommenden Mobile Clients anzubinden. Es gibt hierfür entsprechende zusätzlich Powershell Befehle. Diese sollten aber erst verwendet werden, wenn die entsprechende Beschreibung zur Verfügung steht.
CsAutodiscoverConfiguration – Modifies an existing collection of Autodiscover configuration settings. The Autodiscover service provides a way for client applications such as Lync Web Access or Microsoft Lync Mobile to locate key resources such as a user’s home pool or the URL for joining a dial-in conference.
New-CsWebLink – Creates a new web link that points to the Autodiscover service. The Autodiscover service provides a way for client applications such as Lync Web Access or Microsoft Lync Mobile to locate key resources such as a user’s home pool or the URL for joining a dial-in conference.
Test-CsMcxPushNotification – Verifies that the push notification service is working. The push notification service (Apple Push Notification Service and Microsoft Lync Server 2010 Push Notification Service) provides a way to send notifications about event s such as new instant messages or new voice mail to mobile devices like iPhones and Windows Phones, even if the Microsoft Lync 2010 application on those devices is currently suspended or running in the background.
CsMobilityPolicy – Modifies an existing mobility policy. Mobility policies determine whether o r not a user can use Microsoft Lync 2010 Mobile. These policies also manage a user’s ability to employ Call via Work, a feature that enables users to make and receive phone calls on their mobile phone by using their work phone number instead of their mobile phone number.
CsMcxConfiguration – Modifies an existing collection of Microsoft Lync Server 2010 Mobility Service configuration settings. The Mobility Service enables users of mobile phones such as iPhones and Windows Phones to do such things as exchange instant messages and presence information; store and retrieve voice mail internally instead of with their wireless provider; and take advantage of Microsoft Lync Server 2010 capabilities such as Call via Work and dial-out conferencing.
CsPushNotificationConfiguration – Modifies an existing collection of push notification configuration settings . The push notification service (Apple Push Notification Service and Micros oft Lync Server 2010 Push Notification Service) provides a way to send notifications about events such as new instant messages or new voice mail to mobile devices such as iPhones and Windows Phones, even if the Microsoft Lync 2010 application on those devices is currently suspended or running in the background.
<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> Lync 2010|Leave a comment
Man kann hier gut sehen, dass hier nur die Features von Cisco verwendet werden und der Lync Client nur noch für Instant Messaging verwendet werden soll. Auch für Konferenzen werden die Cisco Services wie WebEx genutzt. D. h. es müssen zusätzlich die entsprechenden Rollen von Cisco installiert werden. Hier muss natürlich jede Firma für sich entscheiden Cisco und Lync zu nutzen oder gleich nur noch Lync einzusetzten und damit auch Voice über Lync zu nutzen.
Aus meiner Sicht und Erfahrung spricht aber nichts dagegen nur noch Lync einzusetzen.
Es ist sogar in den Installationsanweisungen von Cisco beschrieben, dass Voice und Video in Lync deaktiviert werden sollen.
Wer hat es nicht auch schon erlebt, man erhält eine Sofortnachricht in Lync, ist aber gerade mit anderen Sachen auf seinem Desktop beschäftigt.
Abhilfe schaft hier ein kleines Tool von Modalitysystems. Die Sofortnachricht wird als IM in den Vordegrund gebracht und mann verpasst keine Sofortnachricht mehr.
Es gibt eine aktualisierte Version des Lync Workload Posters mit der gesamten Übersicht der verwendeten Ports und dem Traffic der einzelnen Rollen und Komponenten.
Es gibt ein neues Wireless- Telefon von Polycom Spectralink 8440, welches sich als Lync Client mit dem Lync Server verbinden kann.
Polycom SpectraLink 8400 Wireless-Telefone verbessern die Produktivität und Erreichbarkeit von mobilen Mitarbeitern vor Ort in unterschiedlichen Branchen, unter anderem im Gesundheitswesen, Einzelhandel, in der Fertigung und im Gastgewerbe. Die SpectraLink 8400-Serie basiert auf offenen Standards und verändert die Bereitstellung mobiler Unternehmensanwendungen, indem sie Kundendienstmitarbeitern die Leistungsfähigkeit von Thin-Client und Browsertechnologie mit einer benutzerfreundlichen und leicht zu verwaltenden Benutzeroberfläche bietet. Darüber hinaus unterstützt die SpectraLink 8400-Serie die meisten Schnittstellen zu professionellen PBX, drahtlosem LAN und Infrastrukturen zur Bereitstellung maximaler Interoperabilität mit den geringsten Gesamtbetriebskosten der Branche.
Verbessern von Workflows mit Anwendung, Sprache und Datenintegration
Maximieren der Mitarbeitereffizienz durch Nutzung webbasierter Anwendungen durch das einzige VoWLAN-Gerät der Branche mit einem integrierten WebKit-basierten Webbrowser
Optimieren von Workflows durch nahtlose Verbindung mit Peripheriegeräten vor Ort über die exklusive Polycom Quick Barcode Connector™-Schnittstelle (QBC-Schnittstelle)
Direkte Kommunikation mit dem IM-Client des Microsoft® Office Communications Servers auf einem dedizierten VoWLAN-Gerät
Unterstützt die speziellen Anforderungen mobiler Mitarbeiter vor Ort
Minimieren von Dateneingabefehlern mit einem integrierten Barcode-Imager (nur für Modell SpectraLink 8450)
Schnelle Kommunikation zwischen Gruppen mit integriertem Push-to-Talk
Maximieren der Handset-Lebensdauer dank hochwertigem Spritzguss und robustem Design
Vereinfachen der Benutzereinweisung durch große Anzeige, einfache Benutzeroberfläche und dedizierte Softkeys
Betrieb in lauten Umgebungen mit fortschrittlicher Rauschunterdrückungstechnologie
Breiteste Interoperabilität basierend auf offenen Standards
Verbindung zu zahlreichen PBX dank umfassender und bewährter Polycom UC-Software, die auf dem Industriestandard Session Initiation Protocol (SIP) basiert
Vereinfachte Bereitstellung mit dokumentierten und von Drittanbietern zertifizierten AP-Konfigurationen
Installieren einer zukunftssicheren Lösung, die den 802.11n-Standard nutzt
Geringste Gesamtbetriebskosten der Branche
Konsolidieren unterschiedlicher Funkruf-, Telefon-, Scan-, Funksprechgeräte-, Conferencing- und Standort-Tags in einem Gerät
Nutzen der branchenweit besten Garantie für Reparaturen und Ersatzprodukte
Geringere Bereitstellungs- und Wartungskosten dank integrierter Diagnose- und zentralisierter Verwaltungsfunktionen
<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> Lync 2010|Leave a comment
In den meisten Umgebungen wird dieser Fehler nicht auftreten. Abhängig von ihrer Umgebung wird währen der Anmeldung eventuell die folgende Fehlermeldung angezeigt.
Sie fragen sich sicherlich warum?
Hintergrund
Microsoft Lync 2010 hat eine erweiterte Vertrauensüberprüfung für die automatische suche des Lync oder Exchange Servers hinzugefügt. Diese erweiterte Überprüfung wurde hinzugefügt um einen zusätzlichen Schutz gegen DNS Spoofing Angriffe zu gewährleisten. Server werden automatisch nach dem SRV oder Host A DNS Eintrag, basierend auf der SIP URI oder der primären SMTP Domain Adresse als auch über DHCP mit der Option 120. Servern welche manuell im Lync Client eingetragen werden, wir automatisch vertraut, da diese ja manuell eingetragen wurden. Dasselbe trifft auch für Lync Server zu, welche zu anderen Servern weitergeleitet werden, deren Domänen vertraut wird.
Vertrauen überprüfen
Wenn Lync einen Server über DNS gefunden hat, wird dieser gegen die Liste der vertrauten Domains geprüft. Wenn diese Überprüfung erfolgreich war, wird diesem Server vertraut und die Verbindung hergestellt. Ist diese Überprüfung nicht erfolgreich, kann der Benutzer Entscheiden diesem Zertifikat zu vertrauen oder auch nicht. Der Benutzer kann also entscheiden sich zu verbinden oder den Anmeldevorgang abzubrechen.
Die Liste der vertrauenswürdigen Server wird nach Folgenden Regeln erstellt:
Die Benutzer SIP URI Domäne via AD als Standard Sign-in oder manuell konfiguriert
Die Domäne des Lync Servers, an welche sich Lync als letztes erfolgreich angemeldet hat
Lync überprüft den Server gegen die Liste der sicheren Server. Es wird geprüft, ob der Server ein Mitglied der Domäne oder einer entsprechenden Sub Domäne ist.
Beispiele
Es ist sicherlich einfacher, das Ganze anhand der folgenden Beispiele zu verstehen:
Die SIP URI des Benutzers ist Holger@bunkradt.com
Server.contoso.com ist ein Lync SE Server in der Umgebung
Es gibt einen DNS A Eintrag für den Server contoso.com mit der IP Adresse 192.168.0.10
Es gibt einen DNS SRV Eintrag _sipinternaltls._tcp.bunkradt.com mit dem Ziel server.contoso.com auf Pot 5061
Der Benutzer hat sich noch nie mit dem Lync Server von diesem PC verbunden
Automatische Konfiguration in Lync ist aktiviert.
In der oben beschriebenen Umgebung enthält die Liste der vertrauenswürdigen Domänen bunkradt.com. Wenn Holger sich mit Lync anmeldet wird der SRV Eintrag _sipinternaltls._tcp.bunkradt.com gefunden und Lync wird versuchen sich an server.contoso.com über Port 5061 anzumelden. Bevor dies aber passiert, überprüft Lync den Server anhand der Liste für vertrauenswürdige Domänen. Diese Überprüfung schlägt fehl und die oben gezeigte Warnmeldung dem Benutzer angezeigt.Nun ändern wir die Konfiguration wie folgt:
Die SIP URI des Benutzers ist Holger@bunkradt.com
server.contoso.com is der Lync Director in der Umgebung
Es gibt einen DNS A Eintrag für den Server contoso.com mit der IP Adresse 192.168.0.10
Es gibt einen DNS SRV Eintrag _sipinternaltls._tcp.bunkradt.com mit dem Ziel sip.bunkradt.com auf Port 5061
Es gibt einen DNS A Eintrag für sip.bunkradt.com mit der IP Adresse 192.168.0.10
Der Benutzer hat sich noch nie mit dem Lync Server von diesem PC verbunden
Automatische Konfiguration in Lync ist aktiviert
Die Liste der vertrauenswürdigen Domänen ist weiterhin bunkradt.com. Wenn Holger sich an Lync anmeldet wird der DNS SRV Eintrag _sipinternaltls._tcp.bunkradt.com gefunden und Lync versucht sich an sip.bunkradt.com mit Port 5061 anzumelden. Bevor dies aber passiert, überprüft Lync den Server anhand der Liste für vertrauenswürdige Domänen. Diese Überprüfung ist erfolgreich und die oben gezeigte Warnmeldung wird nicht angezeigt. Es wird nun das Zertifikat des Directors überprüft, ob darin auch der FQDN sip.bunkradt.com enthalten istNun fügen wir auch noch die automatische Suche für den Exchange Server hinzu:
Die SIP URI des Benutzers ist Holger@bunkradt.com
Holger hat ein Exchange 2010 Postfach mit der primären SMTP Adresse Holger@bunkradt.de
Der DNS A Eintrag für autodiscover.bunkradt.de mit der IP Adresse 192.168.0.20
Der DNS A Eintrag für cas.bunkradt.de mit der IP Adresse 192.168.0.20
Der Exchange 2010 Client Access Server läuft auf cas.bunkradt.com
server.bunkrad.com ist der Lync Director in dieser Umgebung
Der DNS A Eintrag für server.bunkradt.com mit der Adresse 192.168.0.10
Der DNS SRV Eintrag _sipinternaltls._tcp.bunkradt.com zeigt auf sip.bunkradt.com Port 5061
Der DNS A Eintrag für sip.bunkradt.com mit der IP Adresse 192.168.0.10
Der Benutzer hat sich noch nie mit dem Lync Server von diesem PC verbunden
Automatische Konfiguration in Lync ist aktiviert
Die Liste der vertrauenswürdigen Domänen ist weiterhin bunkradt.com. Wenn Holger sich an Lync anmeldet, will Lync auch den Exchange Autodiscover Dienst abfragen, um Informationen über Holgers Postfach abzufragen. Es wird dafür die Primäre SMTP Adresseichen. verwendet. Lync versucht diese beiden URLs https://bunkradt.de/autodiscover/autodiscover.xml und https://autodiscover.bunkradt.de/autodiscover/autodiscover.xml zu erreichen. In unserem Fall wird der DNS A Eintrag für autodiscover.bunkradt.de gefunden und Lync überprüft die Liste der vertrauenswürdigen Domänen. Diese Überprüfung schlägt fehl und es wird dem Benutzer eine Warnmeldung für autodiscover.bunkradt.de angezeigt.Nun ändern wir die Konfiguration wie folgt:
Die SIP URI des Benutzers ist Holger@bunkradt.com
Holger hat ein Exchange 2010 Postfach mit der primären SMTP Adresse Holger@bunkradt.de
Der DNS SRV Eintrag für _autodiscover._tcp.bunkradt.de zeigt auf autodiscover.bunkradt.com on Port 443
Der DNS A Eintrag für autodiscover.bunkradt.com mit IP Adresse 192.168.0.20
Der DNS A Eintrag für cas.bunkradt.de mit der IP Adresse 192.168.0.20
Der Exchange 2010 Client Access Server läuft auf cas.bunkradt.com
server.bunkrad.com ist der Lync Director in dieser Umgebung
Der DNS A Eintrag für server.bunkradt.com mit der Adresse 192.168.0.10
is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target sip.fabrikam.com on port 5061
Der DNS A Eintrag für sip.bunkradt.com mit der IP Adresse 192.168.0.10
Der Benutzer hat sich noch nie mit dem Lync Server von diesem PC verbunden
Automatische Konfiguration in Lync ist aktiviert
Die Liste der vertrauenswürdigen Domänen ist hier bunkradt.com. Wenn Holger sich an Lync anmeldet, wird Lync versuchen sich mit dem Exchange Autodiscover Dienst zu verbinden. Dies wird fehlschlagen, da es keinen Host A Eintrag für autodiscover.bunkradt.de gibt. Lync wird dann versuchen den SRV Eintrag ._autodiscover._tcp.bunkradt.de zu finden und bekommt als Ziel autodiscover.bunkradt.com zurück. Lync überprüft dann autodiscover.bunkradt.com gegen die Liste der vertrauenswürdigen Domänen erfolgreich. Es wird also keine Warnmeldung wie oben gezeigt zum User erfolgen.
Wenn sie also die automatische Suche für Lync und Exchange über DNS konfigurieren, berücksichtigen sie am besten folgende Ratschläge:
Stellen Sie sicher, dass das Ziel eines SRV Eintrags, auf jeden Fall zu der Liste der Vertrauenswürdigen Domänen nach den obigen Regeln gehört
Stellen Sie sicher, dass jeder SRV Eintrag auf einen Host A Eintrag verweist. Die Verwendung von CNAME Einträgen als Ziel wird nicht durch Lync unterstützt. (RFC2782)
Stellen sie sicher, dass das Zertifikat für Lync und Exchange alle FQDN’s der im SRV eingetragenen Ziele enthält. Ansonsten kann Lync keine TLS Verbindung herstellen.
Eine der coolen Lync Funktionen ist die Möglichkeit mit Live Benutzern eine Audio/Vide Federation einzugehen. Aber Sie werden feststellen, dass dies nicht so einfach funktioniert. Als erstes muss Ihre Organisation den Publich IM Connectivity Provisoning Process mit Microsoft erfolgreich abgeschlossen haben. Danach sind zwei zusätzliche Änderungen nötig wenn Sie die Public IM Verbindung über die externe Access Policy für Benutzer aktiviert haben.
Als erstes ist ein versteckter Parameter, welcher die A/V Federation zu PIC aktiviert über die Lync Mangement Shell einzustellen. In meinem Beispiel habe ich die Globale Policy entsprechend angepasst.
Set-CsExternalAccessPolicy Global -EnablePublicCloudAccess $true -EnablePublicCloudAudioVideoAccess $true
Zweitens funktioniert Windows Live nicht mit SRTP Verschlüsselung für Audio/Video, aber Lync erfordert standardmäßig Verschlüsselung. Es muss also Lync von Verschlüsselung erforderlich auf Verschlüsselung unterstützt konfiguriert werden. Zusätzlich habe ich dann auch noch die maximal unterstütze Videoauflösung Global auf 720p erhöht, da diese der Windows Live Client auch unterstützt.
Set-CsMediaConfiguration Global -EncryptionLevel SupportEncryption -MaxVideoRateAllowed Hd720p15M
Die Einstellungen sollten nachca. 5 Minuten greifen. Nachdem Sie sich einmal am Lync Client ab- und wieder angemeldet haben, können Sie diese Einstellungen durch gleichzeitiges drücken der STRG Taste und rechts-click auf das Lync Symbol über Konfigurationsinformationen überprüfen. Es sollte jetzt bei PC-an-PC-AV Verschlüsselung jetzt AV-Verschlüsselung unterstützt angezeigt werden.
Der Windows Live Messenger unterstützt erst ab der Version 2011 A/V Federation.
<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> Lync 2010|Leave a comment
