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.

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