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

A seguito dell'installazione del SP1 di Windows 2003, gli aggiornamenti della sicurezza generano un eventid 13 ogni 8 ore che recita:
La registrazione automatica certificati per Sistema locale non è riuscita a registrare un certificato Controller di dominio (0x80070005). Accesso negato.



Nel caso specifico una delle due macchine controller di dominio è stand alone CA in quanto frontend per un sistema di messaggistica.
Il servizio certificati di Windows 2003 utilizza il protocollo DCOM per elargire servizi amministrativi.
L'avvento del SP1 introduce delle limitazioni negli accessi per il protocollo DCOM, è quindi necessario aggiornare a mano un gruppo di sicurezza (introdotto appunto dal Service Pack). Il gruppo in questione si chiama CERTSVC_DCOM_ACCESS e deve contenere i gruppi di sicurezza "Domain Users", "Domain Computers" e "Domain Controllers"; è probabile che questo ultimo gruppo debba essere aggiunto manualmente.



A questo punto è possibile aggiornare la configurazione di sicurezza DCOM tramite il servizio certificati, in particolare usando il comando:
certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG

poi, per attivare le modifiche:
net stop certsvc
net start certsvc

A questo punto avremo la registrazione di un evento 19:
La registrazione automatica certificati per Sistema locale ha ricevuto un certificato Controller di dominio dall'autorità di certificazione (nome CA) su (nomeserverCA)



Per la "release note" di Windows Server 2003 SP1 completa si veda:
http://support.microsoft.com/kb/889101/en-us

Un cliente mi evidenzia che da un numero non meglio determinato di giorni, uno dei due server controller di dominio (quello senza l'exchange installato, entrambi Global Catalog, DNS e DHCP server, entrambi con Windows 2003 R2 std SP1) logga gli eventi 1030 e 1058. In continuazione. Ogni 5 minuti.







Lanciare un "gpupdate /force" da un prompt dei comandi genera nuovamente la coppia di errori, segno che qualcosa non sta funzionando nella propagazione delle policy.
Loggato sul server che presenta problemi, ho cercato di raggiungere \\nomedominio\sysvol\nomedominio\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini riuscendoci correttamente (anche da un client e dall'altro server).

Premesso che Netlogon e il servizio DFS sono avviati e funzionanti, ho esaminato le impostazioni di rete non trovando nulla di significativo; ho comunque aggiunto, nella scheda "Avanzate" del protocollo TCP, il flag sulla casella di controllo "Registra nel DNS gli indirizzi di questa connessione".

Poi da prompt dei comandi "ipconfig /flushdns" e "ipconfig /regisgterdns".
Le voci DNS per i due domain controller risultavano corrette in tutte le istanze dei server DNS, come test ho verificato che da entrambi i server fosse possibile raggiungere l'altro sia via netbios name che via FQDN.
Il problema sembra essere legato al processo Winlogon che tenta di elaborare i criteri di gruppo prima del dovuto.
Dal regedit ho aggiunto una DWORD con nome WaitForNetwork e valore 1 nel ramo HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.
 
Poi ho ripulito manualmente la cache del servizio DFS. Per fare questo ho installato i support tools di Windows 2003 e lanciato dal prompt dei comandi "dfsutil /purgemupcache". Il problema è scomparso. Nell'eventviewer è stato loggato l'evento 1704 che indica la soluzione del problema di applicazione delle policy.

PS: Sembra che con il SP2 il problema non compaia più. Appena il cliente mi conferma il passaggio aggiornerò il post.

Per approfondire:
Technet
EventID.net