Thebitstreamer

Ho utilizzato la festa della Repubblica per lavorare sui sistemi database che non possono essere manutenuti durante il normale orario di lavoro (a meno di non complicarsi la vita …)

Come da suggerimento ho effettuato il doveroso riallineamento a SP2 di SQL Server 2005 Enterprise Edition e immediatamente dopo ho applicato il Cumulative Update 7 di SQL Server.

Dopo questo tot di aggiornamenti la build di SQLServer dovrebbe essere la 3239.

Appena fatto sul primo cluster, però, tutte e 4 le istanze mostrano uno strano comportamento di SQL Server Agent.
Dopo alcuni restart la risorsa sul Cluster si mette in failed e scatta il panico.

A questo punto il dubbio mi assale: ho utilizzato la mia user.. vuoi che abbia fatto qualche casino con le permission durante gli aggiornamenti.

Infatti è buona norma, per essere sicuri che tutto si svolga al meglio, di utilizzare sempre la stessa identity con cui gira il servizio che si sta aggiornando. Almeno questa era la golden rule per Windows 2000 quando ho costruito la vecchia farm.

Dopo qualche ragionamento ho capito che non poteva essere così: finito il giro di Windows Update sui due nodi dell’altro Cluster, già SP2, ho installato la CU7. Stesso identico problema.

Attimi di panico, appena qualcuno, comunque presenti.

Poi inizio il classico metodo che i tempi moderni ci permettono:

1. Google (è il modo più efficace per cercare anche dentro la KB di Microsoft;
2. Direttamente la KB
3. Il sito premier (supporto gold di Microsoft)

Niente. Quando è così mi chiedo sempre se la domanda che ho fatto a Internet è quella giusta e, solitamente, ripensando e sistemando la query qualcosa viene sempre fuori.

Allora vado sull’Event Viewer è prendo il testo esatto della query:

“cannot start SQL Server Agent failover cluster”.

La risposta è l’articolo KB943525 che parla esattamente del problema che stavo vivendo. La certezza che si trattasse dello stesso caso è data dalla verifica sul file sqlagent.out che si trova nella cartella logfiles di ogni singola istanza creata sul server.

Questo quello che conteneva (tra le altre cose):

SQLServer Error: 22022, CryptUnprotectData() returned error -2146892987, ‘The requested operation cannot be completed. The computer must be trusted for delegation and the current user account must be configured to allow delegation.’ [SQLSTATE 42000]
ConnConnectAndSetCryptoForXpstar failed (0).

E’ un problema di sicurezza! (come la gran parte dei problemi in una complessa installazione di Windows fatta a regola d’arte…)

La soluzione è molto semplice nel mio caso: ho la necessità di utilizzare un account di dominio per SQL Server Agent.

In questo modo l’accesso alle risorse nel dominio di ogni cosa eseguita dall’agente di Sql Server può essere controllata ed identificata dalla sua user id.

Per fare questo l’identity del Sql Server Service deve essere Trusted for delegation selezionando l’apposito check nel tab account nel riguardo opzioni.

Senza effettuare nessun restart del servizio di SQL Server questa volta il Bring on-line della risorsa clusterizzata di SQL Server Agent service viene su che è una bellezza.

SQL Server non faceva fare il logon al servizio dell’Agent in quanto il suo account non era in grado di eseguire la sp_sqlagent_notify per un errore in una chiamata alle API della crittografia.

La delega di autenticazione è spiegata in questo link di Technet.

Tutto è bene quel che finisce bene. Inoltre ho imparato 3 cose:

• partire dalla ricerca dal testo dell’errore anche se generico
• SQLAgent ha un file che si chiama SQLAgent.out in cui scrive il suo bel log (fico!)
• la sicurezza di Windows è, e rimane, una cosa complessa ed assai poco sfruttata come funzionalità. Questa la rende la causa di molti comportamenti strani.