Come da oggetto, dopo aver installato automaticamente gli ultimi aggiornamenti sul server, tutti i client Outlook 2007 (sia in cached mode che non, questi ultimi se erano configurati per scaricarsi la OAB) continuano a chiedere le credenziali per accedere al servizio remote.sitodelcliente.com che è l'HOST DNS che punta all'indirizzo pubblico nattato sul CAS Exchange 2007. Anche inserendo le credenziali corrette Outlook continua a fare la medesima richiesta. Premendo annulla, annulla, annulla per un po' la richiesta scompare, per tornare alla carica dopo qualche minuto o quando si forza l'invio/ricezione.
Questo comportamento è riscontrato sia per gli utenti connessi in LAN che per quelli con OutlookAnyware configurato ma con macchina in rete LAN; al contrario chi ha il portatile configurato con OutlookAnyware e si trova fuori dall'azienda non riscontra il problema.
Dopo aver ricreato la OAB, rifatta la directory virtuale dell'IIS della OAB e aver verificato che tutti i servizi web di SBS fanno riferimento come uri pubblico a remote.sitodelcliente.com (quello indicato nel certificato di protezione), scopro navigando su social.technet.microsoft.com che il problema nasce da una impostazione che sul mio SBS 2008 non era configurata correttamente.

Si tratta di aprire la configurazione del sito "SBS Web Applications"  


Sotto l'application Autodiscover, scegliere  “Autenticazione”, tasto destro su "Autenticazione Windows" e poi "Impostazioni Avanzate". Il flag "Abilita autenticazione in modalità kernel" deve essere abilitato 

 
La stessa configurazione va replicata sulle directory RPC, EWS e OAB

Oggi dopo una installazione in modalità "ripristino di emergenza" di Exchange 2003 (<unità>:\Setup\I386\Setup.exe /DisasterRecovery) il supervisore di sistema non si avviava più.
Nel registro eventi venivano loggati gli errori eventid 9022 e 1005. L'errore è relativo a un problema di permessi dell'account server sul contenitore Exchange in Active Directory.
Per risolvere il problema è stato sufficiente lanciare lo snap-in ADSI Editor (adsiedit.msc, è necessario installare i support tools di Windows Server 2000/2003) e navigare l'albero in configurazione, configurazione (CN=Configuration, DC=nomedominio, DC=estensione) e poi Servizi, Microsoft Exchange, CN=nomedominio, Gruppi Amministrativi, nomeprimogruppoamministrativo (Primo Gruppo Amministrativo nell'esempio qui sotto), Server e poi nomemacchina.



Nelle proprietà del server, nella scheda protezione è sufficiente verificare che l'oggetto server nell'elenco degli account abbia come diritti controllo completo.



Chiudendo ADSI Edit e avviando i servizi l'errore sparisce e dal Gestore SIstema di Exchange è possibile aprire il gruppo di archiviazione e montare i db.

Per salvare le informazioni, Exchange utilizza la tecnica dei log transazionali, in pratica una mail che arriva viene prima inserita in un log transazionale e solo in un secondo momento travasata nel db.
Questa metodologia porta due vantaggi, il primo, prestazionale, è quello di poter scrivere direttamente in un log invece di dover aspettare che l'attività sul database venga interrotta per permettere l'inserimento dell'informazione; il secondo è invece di tipo strutturale, ci permette infatti (Volume Shadow Copy Services a parte) di effettuare un backup del db senza dover interrompere il servizio di Exchange.
Quando arriva una mail, ad esempio, viene effettuata una scrittura nel file E00.log che viene creato vuoto di dimensione fissa pari a 5MB. Se la transazione legata alla mail si completa correttamente, l'informazione viene copiata nel DB appena possibile, rispettivamente in Priv1.stm e Priv1.edb se si tratta delle caselle postali degli utenti o in Pub1.stm e Pub1.edb se si tratta delle cartelle condivise. Il file E00.chk tiene traccia di quali transazioni sono già state copiate.
Con il passare del tempo e compatibilmente con il traffico mail generato dall'azienda, il file E00.log andrà riempiendosi e, superata la dimensione fissata, verrà archiviato (con un nome del tipo E0000XXX.log) mentre un nuovo E00.log sarà creato della stessa dimensione.
All'esecuzione di un backup completo i file di log segnati come completamente travasati nel db verranno cancellati (operazione fattibile semplicemente utilizzando ntbackup e scegliendo di eseguire un backup del Gruppo di Archiviazione di Exchange come mostrato in figura).

Così facendo un vantaggio indotto è che, in caso di corruzione del database, questo possa essere ricostruito partendo dall'ultimo backup completo e riapplicando tutte le transazioni memorizzante nei file di log archiviati (per questo motivo è fortemente consigliato mantenere DB e file di log su dischi differenti in modo da evitare di perderli entrambi con una rottura hardware).

Il circular logging è una modalità operativa che autorizza il motore di Exchange a sovrascrivere le porzioni di file di log inutilizzate perchè già travasate nel db. La diretta conseguenza è che avremo pochissimi file di log (4 o 5 in media, a seconda delle dimensioni delle mail che arrivano e del traffico) risparmiando notevolmente in termini di spazio disco. Il rovescio della medaglia è che in caso di rottura sarà possibile soltanto ricostruire il database all'ultimo backup completo eseguito, perdendo molto probailmente almeno in parte le attività intercorse dal backup al momento della rottura.

Per attivare il Circular Logging è sufficiente aprire il Gestore di Sistema di Exchange, navigare in Gruppi Amministrativi -> Primo Gruppo Amministrativo -> Server -> nomeserver e scegliere lo storage group cui si desidera attivare/disattivare la registrazione circolare; nelle proprietà compare il checkbox relativo:

Per completare l'elenco dei file di log utilizzati da Exchange, Res1.log e Res2.log sono due file di 5MB ciascuno, riservati, che il sistema crea per salvaguardarsi in caso di limitato spazio disco che provocherebbe un arresto del servizio Exchange.