Quando avete un problema su una soluzione software complessa che pochi o nessuno ha incontrato già su internet potete postulare il seguente assioma:

Assioma del problema software sconosciuto

Dato un problema su un software molto diffuso, che ha ampia diffusione su internet,  per il quale non si provano sufficienti riscontri sui più diffusi motori di ricerca, potete dedurre che una delle seguenti teorie è vera:

1. Avete fatto una ca***a mondiale nella sua installazione/configurazione/uso;
2. L’errore che si presente non si riferisce a nulla di pubblico già a conoscenza dell’azienda produttrice;
3. Siete di fronte ad un bug non documentato

Il primo caso si spiega da solo oppure potete rinfrescarvi la memoria con un semplice post di esempio.

Il secondo è un problema sul software già a conoscenza della casa produttrice che viene lasciato li perchè non ci sono giustificazioni economiche per procedere alla realizzazione (ed al successivo test) della patch visto che in particolarissime condizioni si verifiche.

Il terzo, ed ultimo, è quello che si verifica quando avete la fortuna di poter accedere ad un supporto che può scalare fino al team di sviluppo quando il problema è bello tosto e si hanno dei bei dump.

Ed  è proprio quello che è successo a me con SQL Server Reporting Service 2005 di cui mi andava misteriosamente in hang l’applicazione Web (ReportManager/Reports). Dopo controlli alla correttezza dell’installazione, alla configurazione e al suo utilizzo, si è passati a frebbrili controlli nella VisualKB di Microsoft (la KB interna con i call log) ed infine ai dump dei processi con il mitico ADPLUS.

Alla fine di questo calvario i due memory dump fanno il giro di tutta una serie di team all’interno di Microsoft fino a giungere al product team di IIS che, immancabilmente, viene fuori con una motivazione ed una soluzione.

Non so se sono sotto NDA quindi, ad ogni buon conto, mi terrò sul vago.

Sembra che l’interpretazione di Microsoft riguardo il licensing sui processori multicore (processor= socket, sostanzialmente) non sia solamente implementato male ma sia stata interpretata male.

Quindi ReportingService e ASP.NET non si parlano nello stesso “canale” e tutto si blocca poiché il primo applica la limitazione tipica dell’edizione standard sui Logical Processor (ovvero i Core) mentre la seconda li sfrutta tutti.

Non capita tutti i giorni che gente come Doug Stewart ti dice che sei incappato in un “double bug”.

L’assioma funziona.

PS: per ora, a meno di una patch che però ricade nel punto 2 dell’assioma, tocca utilizzare la Processor Affinity Mask delle Advanced Properties di Internet Information Server per agirare il problema

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.