Problema

In Office Communicator R2 versione 3.5.6907.37 e 56 la GAL non risulta essere aggiornata.

Ecco i passi tramite i quali si può riprodurre il problema:

Giorno 1:

  1. Create un un nuovo utente, ad esempio user1@contoso.com e abilitatelo per OCS;
  2. Da una postazione installate il client Communicator versione 3.5.6907.56 ed eseguite il Sign In con lo user appena creato, poi assicuratevi che la GAL (GalContacts.db) sia stata creata localmente in:
    C:\Users\Nome_utente\AppData\Local\Microsoft\Communicator\sip_user1@contoso.com
  3. Adesso in Active Directory aggiungete un altro utente, ad esempio user2@contoso.com e abilitate anch’esso per OCS;
  4. Sul server aprite un prompt dei comandi, spostatevi nella cartella contenente il tool abserver.exe, che nella versione R2 è di default il seguente:
    C:\Program Files\ Microsoft Office Communications Server R2\Server\core
  5. Eseguite questi due comandi:
    abserver.exe –regenUR
    aspettate qualche minuto...
    abserver.exe -syncNow
  6. Assicuratevi che il Full File (F1) di quel giorno e i delta file siano stati aggiornati; potete farlo controllando negli eventi l’ Event ID 21007 che dovrebbe riportare l’inserimento di almeno un nuovo contatto e nel folder contenente gli Address Book Files (nella standard edition R2 in <drive>:\%ProgramFiles%\Office Communications Server 2007 R2\Web Components\Address Book Files\Files.);
  7. Adesso tornate in AD e aggiungete un nuovo utente, user3@contoso.com e abilitatelo per OCS ma NON ripetete i passi precedenti 5 e 6;

Giorno 2:

  1. All’ 1:30 (orario impostabile via WMI) l’ ABS Server creerà un nuovo Full File (F2) e i delta file dal precedente Full File F1;
  2. Fate Sign In nuovamente con lo user1;
  3. Ricontrollate localmente la GAL e noterete che non è stata aggiornata e che nemmeno l’eventuale delta file (GalContactsDelta.db creato quando le entry nella GAL sono > di 50k) è stato creato;
  4. Se adesso uscite dal Communicator, cancellate la GAL locale e rifate signIn noterete che il file viene ricreato e risulta aggiornato correttamente. Se lascerete che gli ABS file si aggiornino automaticamente senza forzare nuovamente a mano una sincronizzazione, anche i giorni successivi non riscontrerete più il problema.

Nota: Per evitare il delay del download dell’ AB, impostate/create sul client la seguente chiave (dword) a 0: HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator
GaldownloadInitialDelay –> 0

Spiegazione

Durante lo sviluppo del prodotto si è cercato di prestare molta attenzione alla quantità di banda necessaria al download della GAL da parte dei client, sopratutto per l’impatto che realtà con svariate migliaia di client attivi avrebbero potuto accusare sulla rete.

In tale ottica sono stati introdotti diversi miglioramenti tra cui i più rilevanti sono:

  • L’introduzione dei Compact Delta file in aggiunta ai tradizionali delta file.
    Con i compact file si è cercato di contenere al massimo le dimensioni dei delta file, ad esempio inserendo solo le proprietà di un oggetto che sono effettivamente state modificate (mentre un delta file contiene l’intero oggetto) oltre che una serie di ottimizzazioni atte appunto a ridurne le dimensioni;
  • Dalla versione .37 in poi il MOC utilizza questi nuovi compact delta file invece dei tradizionali (che vengono comunque generati dal server per retro compatibilità con le versioni precedenti);
  • Un’altra modifica riguarda la logica in base alla quale l’ABS crea i delta file stessi, che si basa sostanzialmente sul numero di modifiche e sulla dimensione rispetto al Full file;
  • Per ridurre il numero di download contemporanei della GAL ed evitare il congestionamento della rete (immaginate al mattino quando tutti si loggano circa alla stessa ora) il client, invece di scaricare la GAL immediatamente all’avvio, attende un intervallo di tempo random in una finestra di 60 minuti (configurabile con la chiave sopra citata: GaldownloadInitialDelay);

La nuova logica prevede che:

  • Se un compact file è stato scaricato con successo allora un delta file non verrà scaricato durante lo stesso tentativo di aggiornamento;
  • Un meccanismo di fallback per cui il client verifica a ritroso la presenza di un compact file (preferibilmente) o eventualmente di un delta file prima di procedere con il download dell’intera GAL;
  • Il Full sarà scaricato se e solo se il db locale non è stato aggiornato da almeno7 giorni “e” un delta file (compact o meno) più recente non è disponibile;
  • Nelle versioni precedenti, qualsiasi fallimento nel parsing del delta file o durante la creazione/aggiornamento del DB locale obbligava il client a scaricare il Full file mentre dalla versione .37 in poi queste condizioni di errore non causano il download del Full file.
    Questa condizione può essere infatti dovuta ad una condizione temporanea, ad esempio se dovesse essere finito lo spazio disco oppure se il client non ha i permessi in scrittura o ancora se il file scaricato si è corrotto. In tutte queste situazioni il processo esce e riprova nuovamente in seguito.

Tornando al nostro problema perché la GAL non si aggiorna con queste due versioni?

Dobbiamo sapere che:

  • Nel GalContact.db è immagazzinato l’hash del Full file dal quale il db locale è stato generato;
  • I delta file contengono un campo che identifica l’Hash del Full file dal quale sono stati generati:
    BaseFileHash (2 bytes): A 16-bit unsigned number that is a hash of the contents of the base file that was used to calculate this delta file.
    http://msdn.microsoft.com/en-us/library/dd943207.aspx

Quando negli step sopra abbiamo manualmente rigenerato il primo giorno gli ABS file tramite abserver.exe, il processo ha aggiornato oltre che gli ABS file di quel giorno anche il relativo Hash.

Al giorno 2, quando i client scaricano il nuovo delta, si troveranno ad avere l’hash del Full file dal quale il db locale è stato creato diverso da quello da cui è stato generato il delta file appena scaricato, e considerano di conseguenza che il delta sia corrotto.

Il risultato è che la GAL non riesce più a sincronizzarsi in quanto, secondo quanto spiegato prima, il Full modificato non sarà mai scaricato essendo i delta file disponibili.

Soluzione

La soluzione è la cancellazione sul client del file GalContacs.db locale in modo da crearne uno nuovo.

Il problema è stato parzialmente risolto anche con l’aggiornamento rilasciato in questi giorni:
Description of the Communicator 2007 R2 cumulative update: January 2010

il quale contiene una fix relativa al seguente articolo:
Communicator 2007 R2 users experience network bandwidth issues

Se leggete bene la Kb vedrete che l’origine del problema è diversa (il move degli utenti da un pool all’altro) ma la condizione che si viene a creare è praticamente la stessa ovvero gli hash non coincidono più.

Con questa fix il client gestisce il mismatch e scarica comunque un delta file e non il Full.

Un successivo aggiornamento sarà rilasciato nel prossimo Cumulative Update per gestire ulteriormente al meglio questa condizione.

 

Alcuni link di riferimento:

 

Alessandro Pasero
Support Escalation Engineer
Microsoft Enterprise Exchange Support