Nell’interazione tra Live Communications Server 2005 e Office Communications Server 2007 è capitato ad alcuni clienti di incappare in un problema legato alla “presence” degli utenti OCS; sostanzialmente gli utenti LCS2005 vedevano la presenza di quelli attestati su OCS sempre “Unknown” con relativo pallino color grigio.

Inoltre gli utenti LCS non riuscivano ad iniziare una sessione di IM con quelli OCS ma era possibile il contrario.

La prima cosa da fare per capire la causa di comportamenti simili è riprodurli abilitando i log sia sui client che sui server in modo da poter ricostruire ciascun passaggio.

Di seguito vediamo le azioni da svolgere.

Abilitazione Log

  • Su LCS 2005:
    Trovate una descrizione su come abilitare i log in LCS 2005 SP1 nella Reference Guide da pag 37 in poi e reperibile qui:
    Live Communications Server 2005 with SP1: All Technical Documents
    Nel Tab logging abbiamo impostato il “Logging Level” a 4 per avere il maggior dettaglio possibile.
  • Su OCS 2007:
    Con OCS è stato introdotto un tool di logging molto comodo: Replacement of Flat File Logging Functionality
    Come descritto al link abbiamo abilitato il logging per il componente SIPStack.
  • Su MOC 2007:
    Basta andare in ToolsàOptionsàGeneral e abilitare la voce “Turn on logging in Communicator”.
    Le trace saranno disponibili nel folder %USERPROFILE%\Tracing con il nome: Communicator-uccapi-X.uccapilog
    Per aprirlo è necessario il tool Snooper reperibile nel Resource Kit.
  • Su MOC 2005:
    Si tratta di impostare le seguenti chiavi di registry:
    HKCU\Software\Microsoft\Tracing\Communicator EnableFileTracing=1
    HKCU\Software\Microsoft\Tracing\LCAPI EnableFileTracing=1
    HKCU\Software\Microsoft\Tracing\LCIMSP EnableFileTracing=1
    HKCU\Software\Microsoft\Tracing\LCMSGSC EnableFileTracing=1
    HKCU\Software\Microsoft\Tracing\lcmedia_rtp EnableFileTracing=1

Le trace saranno disponibili nel folder %USERPROFILE%\Tracing
How to enable diagnostic logging for Office Communicator and for Windows Messenger

Riprodurre il problema

Per riprodurre abbiamo semplicemente eseguito il login su un MOC 2005 che aveva nella sua lista di contatti alcuni utenti 2007 e constatato dopo qualche minuto che la presenza risultava sempre sconosciuta.

Ricordatevi di disabilitare i log dopo il test se non vi serve mantenerli attivi per ulteriori test.

ANALISI

Per iniziare l’analisi è certamente essenziale avere ben chiaro l’ambiente del cliente, personalmente cerco sempre di farmi uno schema della parte di infrastruttura che mi interessa, con gli indirizzi IP, i nomi macchina e tutto quello che possa tornarmi utile ai fini dell’analisi.

A tal proposito se voleste raccogliere i dati di una macchina in particolare, potete utilizzare l’"MPS Report" che è parte del Microsoft Product Support's Reporting Tools:

http://www.microsoft.com/downloads/details.aspx?FamilyID=00ad0eac-720f-4441-9ef6-ea9f657b5c2f&DisplayLang=en

Il programma genera un file NomeMacchina_MPSReports.CAB salvato nella cartella: "C:\WINDOWS\MPSReports\PFE\Report\Cab" contenente numerosissime informazioni sullo stato del server e sulla relativa configurazione.

 

Dall’analisi dei dati raccolti avevamo notato il seguente errore:

$$begin_record

LogType: connection

Date: 2009/02/22 11:31:52

Severity: 1

Text: The connection matched by IP address had the wrong peer name

Peer-IP: 10.0.0.1:5061

Peer-Name: server_name.contoso.local

Transport: M-TLS

$$end_record

Effettivamente il mismatch c’era in quanto il “Peer Name” corrispondeva all’ FQDN del server fisico OCS, mentre l’indirizzo IP era quello del Pool.

Questo mismatch portava di conseguenza ad un 504 Server Time-Out alla richiesta di sottoscrizione iniziale:

$$begin_record

LogType: diagnostic

Date: 2009/02/22 11:31:52

Severity: information

Text: Response successfully routed

SIP-Start-Line: SIP/2.0 504 Server time-out

SIP-Call-ID: 949157e5a19d4d8b91a5541ecb7f2e1

SIP-CSeq: 1 SUBSCRIBE

Peer: 191.168.1.122:4918

$$end_record

SOLUZIONE

In questo caso lato OCS avevamo una Enterprise Edition con un singolo Front End e senza bilanciatore Hardware: questo tipo di configurazione, supportata in OCS, era bloccata in LCS 2005 SP1 e un apposito controllo verificava che due FQDN non si risolvessero con lo stesso indirizzo IP.

Nella guida alla migrazione è riportato infatti quanto segue:

Supporting a Pool with a Single Enterprise Edition Server :

If you deploy Office Communications Server 2007 Enterprise pool with a single Enterprise Edition server without a load balancer, to support coexistence you must use a separate IP address for the Enterprise server and the Enterprise pool.

To do so, the following steps are required:

  • Add a second IP address on the Enterprise Edition server
  • Point the DNS record for the Enterprise pool to the second IP address

This requirement exists because Live Communications Server 2005 SP1 servers cannot successfully communicate if the Enterprise Edition server and the Enterprise pool have the same IP address.

After your deployment is moved completely to Office Communications Server, you can remove the new IP and use a single IP address for the pool (and the pools DNS record) and the Enterprise Edition server.

Per risolvere il problema abbiamo quindi aggiunto un secondo IP sulla macchina di Front End OCS e fatto puntare l’ FQDN del Pool a questo nuovo indirizzo, e una volta riavviati i servizi il problema è sparito.

Esiste un articolo di KB di riferimento per questa problematica ormai nota:
Presence information appears as "Presence Unknown" when Live Communications Server 2005 users view the presence information of Communications Server 2007 users

 

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support