Lync 2013 configurare IIS ARR
In questo post volevo trattare alcuni aspetti legati alla configurazione di IIS Application Request Routing (ARR). Dato TMG non verrà più sviluppato e conseguentemente venduto, il Product Group di Lync suggerisce l’utilizzo di IIS Application Request Routing (ARR) per la pubblicazione dei servizi di Lync 2013.
Dato che esiste già un articolo che spiega come configurare il prodotto per Lync, mi limiterò a darvi delle indicazioni su come controllare una configurazione esistente e fornivi quelle che sono le indicazioni per il troubleshooting.
Il seguente post spiega nel dettaglio come configurare IIS per la pubblicazione di Lync 2013/2010.
Using IIS ARR as a Reverse Proxy for Lync Server 2013
Supponiamo però di avere a che fare con una infrastruttura già implementata e necessitiamo di conoscere quelle che sono le configurazioni delle farms.
Purtroppo, essendo l’interfaccia grafica piuttosto limitata, non permette di verificare tutte le configurazioni delle farm, specialmente le impostazioni riguardanti il redirect delle porte.
Affiche il reverse proxy sia configurato correttamente per Lync 2010/2013 ,questo deve ridirigere il traffico HTTP e HTTPS che arriva sull’interfaccia esterna su porta 443 (80 per HTTP), al front end su porta 4443 (8080 HTTP).
Per poter verificare quella che è la configurazione delle farm, è possibile analizzare il file applicationHost.config che si trova in C:\Windows\System32\inetsrv\config.
All’interno del file sono presenti tutte le configurazioni di IIS, tra cui quelle relative alla parte the ARR.
Uno degli errori più comuni durante la configurazione, risiede nel fatto che non viene impostato l’inoltro su porte 4443 e 8080.
Il seguente esempio riporta la configurazione di una farm estratta dall’ applicationHost.config
<webFarm name="webexternal.lync.it" enabled="true">
<server address="fe.lync.local" enabled="true" />
<applicationRequestRouting httpPort="8080" httpsPort="4443" />
</server>
<applicationRequestRouting>
<protocol timeout="00:15:00">
<cache enabled="false" />
</protocol>
</applicationRequestRouting>
</webFarm>
Dalle righe qui sopra si può facilmente identificare il nome della far, l’indirizzo a cui vengono inoltrate le richieste, le porte utilizzate per l’inoltro, etc..
In questo modo è possibile verificare nel dettaglio quelle che sono le configurazioni impostate precedentemente da interfaccia grafica.
Malgrado l’articolo non riporta nessuna indicazione riguardo al posizionamento delle regole, la mia esperienza suggerisce di impostare come prima regola quella relativa all’indirizzo esterno dei WebServer, successivamente la parte di Lyncdiscover e per finire meet e dialin.
Veniamo ora a quelle che sono le indicazioni per eseguire il troubleshooting. Essendo IIS ARR un “plugin” installato su IIS, il troubleshooting è il medesimo che si utilizza per Internet Information Services.
I log di IIS in C:\inetpub\logs\Logsfile (default directory) permettono di verificare quelle che sono le richieste servite da IIS e verificare il codice restituito (200 OK, 401 Unauthorized, 404 Not Found, etc..).
Altro strumento per identificare eventuali problematiche è il Failed Requests Tracing. Questo fornisce una serie di informazioni dettagliate riguardo ad ogni singola richieste servita da IIS (moduli invocati, dettaglio della richiesta web, etc..).
Maggiori informazioni riguardo a questo strumento sono presenti al seguente link:
Troubleshooting Failed Requests Using Tracing in IIS 7
A contorno di questi due metodi, Netowork Monitor o Wireshark rimangono utili strumenti per verificare il traffico di rete ed individuare facilmente errori su sessioni TLS o configurazioni firewall.
HTH
Senior Support Engineer
Stefano Ceruti