E si continua con la serie di magagne di Windows 2008: questa situazione tutto sommato non dovrebbe poi meravigliarsi, dato che è normale che un sistema operativo "nuovo" (è vero che ormai è vecchio di circa un anno, ma comunque le implementazioni sono decisamente poche) presenti qualche "imperfezione".
Windows 2008 introduce una nuova utility per la gestione dei backup al posto dell'ormai datata NTBACKUP (datata lo è di sicuro visto che anche in NT4 si chiamava NTBACKUP): il caro wbadmin. Anche il nome è cambiato diventando Windows Backup con funzionalità decisamente diverse, tra cui l'amatissima  feature di consentire solo i backup su disco (paraltro diverso da quelli dove si trova il sistema operativo).

PROBLEMA
Provando ad eseguire l'utility WBADMIN schedulata con un utente diverso da Administrator ma comunque membro del gruppo Backup Operators si ottiene il seguente messaggio di errore:

 

ERROR - Access denied. You must be a member of the Administrators group or
Backup Operators group to use Windows Server Backup and you must run WBADMIN
with elevated privileges. For example, open the Command Prompt with the Run as
administrator option and then type WBADMIN .


Va da se che in questo caso l'eventuale schedulazione non funziona! 
Allo stesso tempo nell'Event Viewer di Windows (nella parte System) si trova questo simpaticone:

 

dcom2008 1


Non solo: anche mettendo l'utente in oggetto amministratore (ovvero membro del gruppo Administrators) non si otteneva alcun beneficio. Solo facendo girare il WBADMIN come Administrator le cose funzionavano.

Facendo una breve ricerca per il registry (dentrro HKEY_CLASSES_ROOT\CLSID ) si scopre che quel valore corrisponde all'Application ID {C3B65D83-FB15-4e3f-BA04-097D1E2B5AC1} che, da una ulteriore ricerca dentro il "vecchio" DCOMCNFG (alias Component Services) porta al seguente oggetto COM:

 

dcom2008 2

Ergo, il messaggio di errore dice che l'utente utilizzato non ha il diritto di eseguire un oggetto COM che altro non è che il Block Level Backup Service.

SOLUZIONE
In un primo momento avevo pensato che ci fosse un qualche errore nei permessi dell'ggetto DCOM (cosa peraltro suggerita proprio dall'Event Viewer) e che quindi la soluzione potesse essere quella di cambiare i permessi dentro il Component Service. La mia idea però si è infranta contro la dura realtà che mi bloccava tutti i controlli relativi!

dcom2008 3


Di fronte a questa situazione ho giocato l'ultima carta: mi sono loggato con l'utente per vedere se non ottenevo qualche altra informazione (finora avevo sempre usato o l'Administrator di dominio dato che la macchina era un Domain Controller nuovo di pacca).
Loggandosi con l'utente in oggetti (ormai promosso ad Administrator) ho capito dove si annidava il problema, ovvero lo USER ACCESS CONTROL. 
Per chi fosse a digiuno, ricordo che lo UAC (già tristemente  famoso in Vista ) ha come compito principale quello di impedire, anche ad un utente "potente", di eseguire comandi potenzialmente pericolosi: ogni volta che si tenta di far partire un comando "amministrativo" (es. il WBADMIN citato), lo UAC richiede conferma all'utente. Naturalmente questa feature non si sposta molto bene i comandi eseguiti da eventuali batch che, ovviamente, non possono cliccare su YES quando lo UAC richiede la conferma!
Il problema non si verifica con l'utente Administrator dato che lo UAC di 2008 non influenza questo account "particolare".
La soluzione per far funzionare quindi il WBADMIN.EXE con un utente diverso da Administrator (anche se l'utente in questione è membro del gruppo Administrators) è quindi quella di DISATTIVARE L'UAC: dopo questa modifica wbadmin può essere eseguito anche con un semplice utente membro di Backup Operators.