Di recente mi sono imbattuto in un caso piuttosto strano nonostante lo scenario fosse relativamente semplice. Un piccolo cliente dislocato su due sedi e servito da una VPN tra firewall, due siti AD (DC W2003) ed un server Exchange per sito. Per esigenze particolari si è reso necessario virtualizzare un DC anche se vi ricordo che non è una procedura supportata e che in linea di massima non è una buona idea, sicuramente la via meno problematica e supportata è quella di estendere AD nella VM e successivamente fare l’abbassamento di livello del DC fisico.
Starete tutti pensando “ti sta bene, non si virtualizzano i DC” e invece il problema in oggetto non dipende dalla conversione P2V in sé…
DCDIAG non presenta anomalie, NETDIAG è assolutamente OK le repliche tra i siti funzionano correttamente mentre sul DC “virtualizzato” con cadenza regolare si presenta l’errore seguente:
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 18/03/2013
Time: 17.19.02
User: NT AUTHORITY\SYSTEM
Computer: SERVER2
Description:
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.
Dopo ulteriori ricerche decido di applicare la KB 326152 naturalmente senza successo. Verifico NetBIOS, DNS tutto Ok. Accedo anche a \\mydomain.com\sysvol\mydomain.local.
Di nuovo sembrano non esserci problemi particolari nonostante l’errore 1054. Questa volta provo ad attivare il debug dell’ambiente utente nella speranza di trovare qualche indizio nel log. ( KB 221833 ). Purtroppo %Systemroot%\Debug\UserMode\Userenv.log mi indica soltanto che le policy vengono applicate. Niente di fatto,
Anche il comando “setlogon server” restituisce correttamente il nome del DC, dato che ho il prompt dei comandi sotto mano provo un ping sul nome di dominio e noto una risposta di –1994ms. MENO? Si avete letto bene, un tempo negativo.
Pinging domain.local [192.168.1.10] with 32 bytes of data:
Reply from 192.168.1.10: bytes=32 time=-1994ms TTL=128
Reply from 192.168.1.10: bytes=32 time=-1994ms TTL=128
Reply from 192.168.1.10: bytes=32 time=-1994ms TTL=128
Reply from 192.168.1.10: bytes=32 time=-1994ms TTL=128
Ping statistics for 192.168.1.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = -1994ms, Maximum = -1994ms, Average = 1073739830ms
Mi rimetto nelle mani di Google per ulteriori ricerche ma trovo solo alcuni articoli che trattano un problema simile, passo oltre dato che sembra riguardare solo le CPU AMD Opteron.
Ripenso ai passaggi fatti e mi ricordo di aver aggiunto un processore alla mia VM giusto prima del power on, la macchina fisica aveva un solo processore. Cerco di approfondire le problematiche VM e multiprocessore ed apprendo che la funzione Win32 QueryPerformanceCounter per impostazione predefinita utilizza un’unità di tempo chiamata TSC che essenzialmente conta i cicli di CPU. A quanto pare la lettura del valore TSC può essere diversa per ogni CPU “virtuale”, questo spiegherebbe la negatività temporale (virtuale naturalmente).
Il colpevole sembrerebbe proprio la time source di default.
Il caso si è risolto indicando a “QueryPerformanceCounter” che da dovrà basarsi su PM timer che è una fonte tempo globale, anziché su TSC.
Come? semplicemente aggiungendo il flag /usepmtimer al file boot.ini
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Standard" /noexecute=optout /fastdetect /usepmtimer