Nel seguente Post tratterò alcune tematiche relative alla configurazione e al troubleshooting per la parte di Mobility. Non saranno trattati gli steps riguardanti l’installazione, poiché descritti da un ottima documentazione presente sul sito TechNet.
Maggiori informazioni riguardo al Deployment sono disponibili al link:

Deployment Process for Mobility
http://technet.microsoft.com/en-us/library/hh690023.aspx

E’ bene introdurre il Workflow generale utilizzato per questa nuova feature introdotta in Lync.

clip_image002

Da questo diagramma si denota subito un’importante informazione: anche i client connessi tramite WiFi si devono connettere al servizio MCX esposto dall’External Web site sulla porta 4443.
Questo significa che i client interni devono essere in grado di navigare in internet e “rientrare” nella rete passando dal server TMG/Reverse Proxy.
Se questo non dovesse essere permesso dalla propria infrastruttura di rete, è possibile creare un nuovo listener sull’interfaccia interna del TMG e far puntare l’FQDN relativo al “External Web Services” a tale indirizzo IP.

Altra importante informazione che si evince dal seguente schema è relativa al server Edge: Tale server non è necessario per la funzionalità base della parte Mobility, ma è utilizzato per la Push Notification che verrà trattata in seguito.

Dalla mia esperienza al supporto ho notato che la maggior parte dei problemi sono causati da errate configurazioni lato Reverse Proxy (aka TMG).
Ho quindi voluto fare un breve riassunto di quelli che sono i principali errori di configurazione.

TMG

In un ambiente “correttamente funzionante” la parte di Mobility prevede solo l’aggiunta dell’FQND lyncdiscover.dominio.it all’interno degli indirizzi accettati, e l’assegnazione del nuovo certificato contenetene il nuovo indirizo.
Per quanto riguarda l’implementazione è possibile rifarsi alla seguente documentazione.

Configuring the Reverse Proxy for Mobility
http://technet.microsoft.com/en-us/library/hh690011.aspx

In molti casi le configurazioni delle regole riguardanti la parte dei Web Services di Lync sono errate ancor prima di implementare questa nuova funzionalità.

Volevo quindi mostrare quelli che sono gli errori più comuni sulla configurazione sulla regola di pubblicazione dei servizi di Lync.

Bridging
Tutto il traffico verso che arriva al listener deve essere ridiretto sul Pool interno sulla porta 4443 e non 443.
La porta 4443 è associata all’External Web Site sull’IIS del Front End.

clip_image004

Public Name
In alcuni casi, i sistemisti, dimenticato di aggiungere il lyncdiscover.dominio.it all’intero dei Public Name.
In questo scenario tutte le richieste verso Lyncdiscover.dominio.it vengono semplicemente ignorate.

clip_image005

To/Web Farm
Altro comune errore è quello di non flaggare “Forward the original host header instead of the site name” o di non impostare “TMG server “ per la parte di “Requests appear to come from”.
Nel caso della screenshoot I server interni sono bilanciati da un WebFarm, se così non fosse il tab si chiamerebbe To al posto di Web Farm.

clip_image007


Authentication Delegation
Questo è l’errore che più comunemente è commesso dai clienti.
La causa principale è perché le due possibili opzioni sono molto simili e se non si presta particolare attenzioni può sfuggire la differenza.
Il valore corretto è “No delegation, but client may authenticate directly” e non “No delegation, and client cannot authenticate directly”.

clip_image008

DNS and Pool Configuration

All’intero della configurazioni di ogni Pool è presente un campo chiamato External Web Services. Questo campo è utilizzato dai client Esterni per alcune funzionalità quali: Download ABS, Respose Group, Web Query, ecc..
Tale indirizzo è utilizzato anche dai Mobile durante la fase di sign-in.

Nell’esempio sottostante l’indirizzo utilizzato dai client è ws.domain.it. 

clip_image010

Questo implica che:

ü FQDN deve essere pubblicato sul DNS pubblico,

ü Il certificato sul listener in TMG deve contenere tale indirizzo nei SAN

ü L’ indirizzo deve essere contenuto nei Public Name nella regola di pubblicazione.

Troubleshooting Autodiscover

Il servizio di Autodiscover, come per Exchange, si occupa di fornire gli indirizzi utilizzati dal client Mobile per eseguire il sign-in.
Se tale servizio non dovesse funzionare, o restituire i dati errati, i devices non riusciranno a loggarsi.

Queste sono le richieste effettuate dal client al fine di indivudare il servizion di autodiscover

1. http://lyncdiscoverinternal.<sipdomain>/
2. https://lyncdiscoverinternal.<sipdomain>/
3. http://lyncdiscover.<sipdomain>/
4. https://lyncdiscover.<sipdomain>/

Le richieste 1,2 e 3,4 sono effettuate in parallelo.

Prendiamo come esempio l’ambiente descritto nella precedente screenshot.
La prime richieste effettuate dal client sono indirizzate a http://lyncdiscoverinternal.dominio.it e https://lyncdiscoverinternal.dominio.it

Il record Lyncdiscoverinternal non è mai pubblicato sul DNS pubblico, e in questo modo il client si rende subito conto se all’interno o all’esterno dell’azienda.
Supponiamo che il client non sia all’interno dell’azienda, quindi le prime due interrogazioni falliranno e saranno poi effettuate le richieste a http://lyncdiscover.dominio.it e https://lyncdiscover.dominio.it

Dalla query sopra vengono restituiti due indirizzi:

ü https://ws.dominio.it/Autodiscover/AutodiscoverService.svc/root/domain

ü https://ws.dominio.it/Autodiscover/AutodiscoverService.svc/root/user

Il primo è utilizzato fornirà tutte le informazioni dell’infrastruttura, mentre il secondo sarà utilizzato per la parte di autenticazione.

clip_image012

Come si può notare, l’indirizzo utilizzato è quello impostato per gli External web Service all’interno della topologia di Lync.

La seguente screenshot è relative alla query eseguita all’indirizzo https://ws.dominio.it/Autodiscover/AutodiscoverService.svc/root/user.
Tale query restituisce un errore HTTP 401, dato questa parte prevede autenticazione.

clip_image014

Infine, l’ultima screenshot riguarda la query per l’indirizzo https://ws.dominio.it/Autodiscover/AutodiscoverService.svc/root/domain.
La risposta a questa richiesta restituisce le informazioni che il client userà per eseguire il sign-in.
Importante notale che l’FQDN del servizio MCX corrisponde sempre al External Web Services quello impostato nella topologia di Lync.

clip_image016

Provando a navigare sull’indirizzo del servizio MCX restituito dal processo di Autodiscover, questa dovrebbe essere la pagina visualizzata.
clip_image018

Questi sono i risultati che dovreste avere su un’infrastruttura correttamente configurata.
Se i risultati restituiti sono differenti, con molta probabilità, ci sono degli errori a livello di configurazione lato TMG o Lync.

E’ presente anche un tool pubblico che esegue il test del servizio di Autodiscover.
Tale tool è presente all’indirizzo:

Microsoft Lync Server Remote Connectivity Test with AutoDiscover
https://www.testocsconnectivity.com/

Troubleshooting Mobile

Oltre al troubleshooting lato server, è possibile analizzare dei log anche lato mobile.
Tutti i devices hanno una parte di logging, abilitabile tramite il menu delle opzioni, che colleziona tutte le informazioni necessarie al troubleshooting.

Piccola precisazione sul logging sui Devices Windows Phone.
Una volta abilitato il logging su Lync Mobile tutte le informazioni sono salvate dentro una immagine con il simbolo di Lync. Basterà aprirla con Notepad per visualizzare i logs generati dall’applicazione.

Il problema più comune che si può commettere lato mobile, è un errato inserimento delle credenziali.
In accordo con la tabella seguente si posso avere differenti due differenti scenari

Utente è ospitato da

Indirizzo SIP e UPN

Campi obbligatori

Server Lync in sede

Indirizzo SIP e UPN sono uguali

Indirizzo di accesso:Indirizzo SIP
Nome utente: vuoto
Password: Password

Server Lync in sede

Indirizzo SIP e UPN sono diversi

Indirizzo di accesso:Indirizzo SIP
Nome utente:UPN o di dominio\nome utente
Password: Password

La stessa tabella vale anche per la parte di O365.

Ricolleghiamoci all’infrastruttura sopra descritta, dove il domino interno è uc.local, e il SIP DOMAIN @dominio.it.
In questo scenario rientriamo nella seconda opzione descritta della tabella, dove indirizzo SIP e UPN sono diversi.

Come si evince dallo schema è necessario esplicitare il Nome utente nel formato UPN o di dominio\nome utente.
Questo significa che bisogna andare nelle Opzioni di Lync Mobile e inserire il proprio dominio interno e nome utente.
Se si omette questa configurazione il client Mobile non riuscirà a loggarsi.

Push Notification:

Ultimo importante aspetto che è bene trattare quando si parla di Mobility, è la “Push Notification”.
La Push Notification non è altro che un meccanismo per permettere di inviare i messaggi agli utenti anche quando l’applicazione è in Background o Suspended Mode.

Il maccanismo di Push Notification è gestito da un Server Lync Push Notification Service il quale si appoggia ad altri due server Microsoft Push Notification Service e Apple Push Notification Service, che si occupano della consegna dei messaggi ai rispettivi dispositivi mobili.

clip_image019

Andorid NON utilizza Push Notification, poiché, quest’ultimo è un “sistema operativo Multitasking”, contrariamente a Apple e Windows Phone.

Semplificando, la Push Notification non è altro che una normale Federation con un “Public IM Provider” come può essere MSN o AOL.
Questo significa che il certificato installato sul server Edge NON può essere rilasciato da una CA privata non Trust per Microsoft.
Quindi se s’implementa Lync Mobile con dispositivi Apple o Windows Phone è necessario utilizzare un certificato pubblico, altrimenti tale funzionalità non sarà disponibile.

Alla Prossima

Stefano Ceruti
Support Engineer
Microsoft Enterprise Exchange Support