Il team di SCOM2007 R2 ha appena rilasciato il Management Pack relativo ad Operation Manager contenente una grande quantità di novità volte a migliorare il monitoraggio, la conoscenze e la documentazione dell’infrastruttura di Operation Manager.

Le principali novità sono:

• Report per capire le dinamiche dei dati accumulati nel datastore di OpsMan che si sostituiscono alle numerose query che potevano essere effettuate sul DB
• Monitoraggio dell’occupazione di CPU degli Agenti
• Controllo delle versioni dell’agente in modo da verificare la presenza delle versioni corrette sui server
• Controllo della corrispondenza dell’architettura degli agenti
• Performance View per controllare più efficacemente le performance del sistema di monitoraggio
• Operations Data Reporting ovvero la possibilità di inviare, in maniera del tutto anonima, i dati dei management pack a Microsoft come quelli della user experience

La R2 è la versione “funzionante” di un prodotto ambizioso, complesso e utilissimo come System Center Operation Manager 2007.Nonostante la R2 sia stato un enorme passo in avanti rispetto alla versione “1.0” (ovvero 2007) ha comunque qualche problemuccio residuo che non ne impedisce il corretto funzionamento ma, nella stragrande maggioranza dei casi, l’operatività.

Finalmente con questa CU1 vengono sistemate tutta una serie di problemini tra cui quello che maggiormente intaccava l’operatività e su cui, in attesa della patch, siamo intervenuti con tanti override.

In ogni caso l’installazione è abbastanza complessa e vi consiglio, as usual, di effettuarlo prima in un ambiente di test e quindi di procedere al backup dell’Operation Database.

Trovate tutte le informazioni e la procedura nel KB974144

SCOM 2007R2 continua a stupirmi sia per la facilità con cui si raggiungono certi obbiettivi sia per la sua relativa fragilità anche nell’ultimo rilascio.

E’ infatti la prima applicazione in cui su ben 4 chiamate al supporto si tramuta in non un caso “non decrementing” visto che si tratta di un bug.

In quest’ultima “avventura” sembra che ci sia qualche problema con i Roll-up monitor quando i submonitor cambiano molto spesso in un arco di tempo limitato.

Ciò si traduce nel roll-up ancora in Critical State mentre i sub-monitor sono in Healthy state.

Guardando gli state change dei sub-monitor ci si accorge che hanno cambiato il loro stato diverse volte in uno spazio di tempo abbastanza breve.

Questo causa il mancato aggiornamento dei Roll-up che rimane allarmato con relativo Alert in console.

A nulla serve anche aver configurato un override ai sub-monitor che fa l’auto-resolve del monitor responsabile, il problema permane.

La cosa è nota ed abbastanza seria tanto che l’engineer di supporto dice che  quanto riportato in questo post sui forum di Technet  e che la questione nella R2 è più profonda.

Fatto sta che dopo aver alzato alcuni valori con degli override, il problema si verifica molto meno visto che i cambi di stato sono quasi azzerati.

Aspettiamo la patch!

Mi è capitato diverse volte di imbattermi nelle limitazioni derivanti da aver creato diversi MP e non averli sigillati “sealed”. Il problema del procedimento di chiusura dei package non risiede tanto nel realizzarlo (è abbastanza semplice con la Authoring Console) ma nella scarsa praticità di questo meccanismo in ambienti molto dinamici e scarsamente standardizzati.

Nelle farm che gestisco i servizi sono abbastanza eterogei da non giustificare l’investimento necessario per ingegnerizzare un MP al punto tale da poter essere chiuso e quindi sottoposto solo ad eventuali override.

Però, come in ogni farm moderna, ci sono diversi servizi di base che sono fruiti da più servizi end-to-end e la probabilità che li si debbano presto utilizzare in una vista globale è altissima.

Inoltre, chi effettua fisicamente il monitoraggio 7×24 spesso non è lo stesso team che gestisce SCOM e quindi ha livelli di accesso necessariamente diversi con viste dedicate al proprio mestiere.

In questi casi è auspicabile creare delle viste specializzate che permettano di semplificare il monitoraggio e schematizzare le informazioni in modo che sia possibile a colpo d’occhio vedere lo stato di un servizio e di quelli da cui dipende.

Agendo in questo modo l’amministratore di SCOM incontra lo spauracchio dei Sealed MP in particolare se ha specializzato i suoi MP in modo da minimizzare le relazioni con altri Management Pack.

A me è successo di dover rendere disponibili delle viste su servizi per il nostro outsourcer per il quale avevo creato un apposito MP in cui concentrare tutto quello che gli poteva servire.

A questo punto non potevo definire una vista all’interno del MP per l’outsoucer visto che avrei creato dipendenze verso oggetti all’interno di altri MP custom…

Curiosando sulla Console ho notato la presenza del comando Copy all’interno del menu contestuale sull’albero di navigazione del pannello Monitoring.

Notoriamente il copia e incolla è la funzione alla base del successo di Windows e saggiamente Microsoft l’ha inserita praticamente ovunque. Ho quindi copiato la vista definita nel mio MP Custom e l’ho incollato all’interno della cartellina dell’MP per l’outsoucer: voilà!

L’odioso messaggio non appare e la vista è disponibile esattamente come definita nell’MP sorgente. Lo sto usando da un pò e sembra un meccanismo affidabile anche se non conosco esattamente cosa avviene “dietro le quinte” (chi lo sa si faccia avanti!)

Ovviamente non esiste nessun collegamento con la vista originale e quindi, se cambiate quella , dovete copiarla nuovamente o effettuare le stesse modifiche in tutte le copie.

Dal blog ufficiale di SCOM2007 ho scoperto che oggi è stato rilasciato la nuova versione del Management Pack dedicato al failover clustering (meglio noto come MSCS) su Windows.

Potete trovare tutte le info e il download qui.

Per chi è già passato a SCOM2007R2 l’aggiornamento è possibile all’interno della console di SCOM.

Una delle funzionalità maggiormente utili di SCOM consiste nella possibilità di registrare un percorso o un’insieme di URL che poi saranno monitorate dal watcher node prescelto. La funzionalità, che ha fatto la sua prima apparizione nel Web site e webservices management pack di MOM2005 permette quindi di verificare la disponibilità e le performance di una singola URL, di un intero percorso di navigazione (transazione) inclusi link, risorse e tutto quanto è possibile misurare nelle applicazioni web

Ovviamente in SCOM questa funzionalità è parte integrante delle funzionalità di base e i risultati riporti all’interno del Data warehouse si integrano e vengono utilizzati per generare report di performance molto utili per determinare e tenere sotto controllo la user experience delle web application.

Purtroppo anche questa funzionalità condivide con l’intero prodotto una sostanziale mancanza di documentazione tecnica dei dettaglio e quindi si può finire nei guai come sono finito io perché, senza saperlo, si possono generare quantità di dati fuori controllo e che pregiudicano la funzionalità stessa.

Nel mio caso il problema consiste nell’interruzione del flusso dati da watcher node al RMS che si materializza nell’interruzione dei grafici con i tempi di risposta rilevati dall’agente sul watcher node.

Un workaround consiste nel restart dell’agente di SCOM sul watcher node e al simultaneo aumento dei Private Bytes e Handles attraverso un bel override. Purtroppo, come quasi tutti i workaround, questo strategemma alza solo la soglia oltre la quale la rilevazione dei dati viene interrotta.

Dopo diversi tentativi, tra i quali aumenti di risorse a disposizione dei server, raddoppio dei server da dedicare ai watcher node, abbiamo anche accelerato l’upgrade alla R2 che, stando alle dichiarazioni di Microsoft, ha aumentato notevolmente la sua efficienza.

Purtroppo il watcher node continuava a fermarsi anche se con un numero di applicazioni maggiori confermadoci che c’era qualcosa di sbagliato nelle web application visto che alcune create ex-novo funzionavano correttamente.

Sul Watcher node apparivano errori con Event ID 4503 con sorgente HealthService e l’esecuzione di query tipo la seguente sul DB non dava risultati:

SELECT PerformanceSourceInternalID,countername,InstanceName

from PerformanceCounterView

WHERE InstanceName Like '<%MYWEBAPPNAME>%'

Il problema risiedeva nell’inclusione di link e risorse nelle analisi da fare nel percorso da riprodurre come testimoniato anche dal log ETL dell’agente che riportava errori nei workflow:

0              00000000             [1]2916.2452::08/26/2009-15:00:14.497 [HealthServiceRuntime]  Verbose CSinkPort::CompleteShutdown(SinkPort_cpp715)Shutdown called on already shutdown sink port.

0              00000000             [1]2916.2452::08/26/2009-15:00:14.497 [HealthServiceCommon]  Verbose CFileUtility::_RemoveDirectory(FileUtility_cpp408)GetFileAttributes on path "\\?\C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 4\5390\" failed with code 2(ERROR_FILE_NOT_FOUND) indicating the path does not exist, will report success.

0              00000000             [1]3768.448::08/26/2009-15:00:14.497 [ConfigurationManager]  Warning CConfigurationManager::WorkflowFailed(ConfigurationManager_cpp2568)Workflow ‘WebApplication_56c259f98ca945e0b5c70975ebb34289.Request2.Resources.StatusCode.Monitor’ from management pack ’32ec7a6d-4498-abaa-1a19-6b8023f427ee’ failed with code WINERROR=80FF0032.

0              00000000             [1]3768.448::08/26/2009-15:00:14.497 [ConfigurationManager]  Warning CConfigurationManager::WorkflowFailed(ConfigurationManager_cpp2581)Module ’3′ for workflow ‘WebApplication_56c259f98ca945e0b5c70975ebb34289.Request2.Resources.StatusCode.Monitor’ reported error event 3221229975.

0              00000000             [1]3768.448::08/26/2009-15:00:14.497 [HealthServiceCommon]  Warning EventLogUtil::LogEvent(EventLogUtil_cpp275)Logging warning event with args <MANAGEMENTGROUP>, 1, 1

I link e le risorse sono inclusi nella rilevazione di disponibilità e performance attraverso i checkbox:

- Enable health evaluation and performance collection for Resources

- Enable health evaluation and performance collection Internal Links

In questo modo ogni risorza (immagine, JS o similari) e ogni link, di ogni pagina del vostro percorso deve essere elaborata dall’agente.  Potete immaginare come, vista la ricchezza tipica di una pagina web contemporanea, queste opzioni facessero schizzare verso livelli intollerabili per il servizio dell’agente che veniva resettato e quindi falliva il completamento dei workflow con l conseguente stop della rilevazione dati.

Al momento, con quelle due opzioni disabilitate, riesco a monitorare tutte le applicazioni web dell’azienda anche con un solo watcher node e senza particolari problemi di performance. Ovviamente sono opportuni override atti a consentire un limite di memoria ed handle utilizzati più alti di quelli che normalmente vengono impostati per semplici agent.

Dopo tanto averlo testato in laboratorio è venuto il tempo di aggiornare anche la produzione a System Center Operation Manager R2 per stabilizzare la piattaforma e utilizzare le nuove feature di R2.

Avevamo schedulato 3 giorni con la consapevolezza che nel 3° avremmo potuto fare del fine-tuning se tutto filava liscio. Purtroppo, come questo in questi casi, Murphy era in agguato e questo racconto serve perché nessuno debba vivere la mia inquietante esperienza.

Dopo aver preso visione della Upgrade Guide abbiamo eseguito tutti i passi abbastanza speditamente nonostante le dimensioni del database fossero comunque abbastanza rilevanti.

Migrato RMS era l’ora di aggiornare il Reporting Service, tutto sembrava andare per il meglio fino a quando, nell’eseguire il passo “Removing backup files” l’installer eseguiva il rollback e laconicamente diceva di essere stato interrotto. Da chi?

Prima cosa da fare è guardare immediatamente il file di log (ammesso che ci si capisca qualcosa). Appoggiandomi al servizio di supporto MS siamo riusciti a capire che fondamentalmente le personalizzazione dei ruoli standard di SRS non sono graditi all’installer che, trovando il valore della tabella TaskMask nel database ReportServer alterata, semplicemente effettua il rollback dell’installazione.

Per risolvere il problema è stato necessario, dall’interfaccia di gestione del Reporting Service, ripristinare i diritti originari e quindi ottenere una bitmask uguale all’originale.

Detta in questo modo sembra facile ma qualsiasi manovra avventata in quella situazione (RMS migrato, SRS no) poteva distruggere il datawarehouse e quindi perdendo tutti i preziosi dati storici per i vostri report.

Una situazione veramente ingarbugliata…. per fortuna risolta senza grossi danni.

Per la nostra particolare topologia delle foreste Active Directory la configurazione di SCOM richiede l’installazione di alcuni gateway.

Per i gateway è indispensabile utilizzare i certificati per la mutua autenticazione e dunque prerequisito fondamentale e quello di avere una CA.

In un mondo ideale (secondo Microsoft) ogni azienda che utilizza un’infrastruttura di rete con Active Directory mediamente complessa dovrebbe avere una CA centralizzata che emetta i certificati.

Anzi, a dirla tutta, se la foresta è  una, è possibile fare l’autoenrollement in modo da gestire automaticamente le fasi di emissione, revoca e rinnovo dei certificati.

Purtroppo il mondo reale è molto diverso dal mondo ideale e la stragrande maggioranza delle infrastrutture che ho visto hanno delle StandAlone CA.

Questo significa che la gestione dei certificati è completamente manuale, non solo per la parte di configurazione per SCOM (per il quale è indispensabile utilizzare MomCertImport), ma che per l’emissione del certificato.

In particolare questa fase, in se abbastanza semplice, è complicata dagli strumenti che tra patch, modifiche ed aggiornamenti spesso non rispecchiano le procedure che si trovano su Technet.

Infatti nel punto 6C della procedura di Technet noterete che non è più disponibile il check “Store certificate in the local computer certificate store” per problematiche di sicurezza legate a Internet Explorer questa possibilità viene preclusa.

Dunque necessario aggiungere alcuni passi prima e, soprattutto, dopo.

• E’ necessario prima mettere la URL del proprio CertSrv nei Trusted Site di ogni server che deve ricevere il certificato.
• Nei trusted sites è necessario autorizzare gli ActiveX altrimenti la pagine di richiesta e ritiro del certificato non funzionerà propriamente.
• Una volta scaricato il certificato è necessario andare nel tab contenuti di Internet Explorer, sezione Certificati, per esportare in formato PKS il certificato che IE inserisce, in mancanza dell’opzione citata precedentemente, direttamente nel keyring dell’utente e non del computer.
• Esportare il certificato e la chiave privata  in un file.
• Costruire una console di management (MMC) con la console per i certificati macchina
• In questa console importare il file PKS all’interno del Personal folder del computer

A questo punto si può procedere con MomCertImport e, infine, riavviare OpsMgr service vedendo finalmente sparire il grigiore dalla propria console.

E’ sconsigliabile spostare di gateway i server (nella nostra configurazione abbiamo la ridondanza per i gateway delle macchine di produzione monitorate) se i certificati sono stati emessi tutti nello stesso momento come accade di solito durante l’installazione.

Nello spostamento gli agenti perdono il join al management Group e, dopo aver faticosamente ripristinato i gateway vi toccherà fare l’uninstall e il successivo reinstall degli agenti per riavviare la comunicazione tra quest’ultimi ed il nuovo gateway.

Mettetevi un reminder di quando stanno per scadere i certificati!!

Ebbene si, se avete appena installato SCOM 2007 o lo state per farlo ricordatevi la prima fondamentale norma di sicurezza per poter agevolmente aggiornare i vostri MP senza ricorrere a tool avanzati.

Vi capiterà sicuramente di dover aggiornare un MP oppure, come è successo a me, di volerne eliminare uno che genera un numero ingiustificato di allarmi.

In particolare io sto litigando, da alcuni giorni, con il Management Pack di IBM per il monitoraggio dell’hardware che ha un’installazione particolarmente complessa.

Proprio in occasione dell’uscita della versione 2.1 voluto disinstallarlo per provarlo meglio nell’ambiente di laboratorio che, nel frattempo mi ero (ri)costruito.

Il problema è che, sebbene ci sia stato attento, qualche Override è finito nel Default MP insieme ad un certo numero di viste ed era pertanto impossibile rimuovere i due MP di IBM dai quali il default dipendeva.

Ho quindi Googlato come sempre e BigG mi ha portato sul blog che non può mancare nel blogrol di ogni utilizzatori di SCOM 2007: il Kevin Holman’s OpsMgr Blog.

Grazie a questo suo magnifico post non solo sono riuscito a disinstallare gli MP di IBM ma ho anche imparato come sono strutturati i Management Pack ad esportarli in formato XML, editarli e quindi reimportarli (ovviamente quelli non SEALED)

La morale è che per SCOM 2007 è necessario mantenere un archivio degli MP come se fossero file sorgente con il vostro source control preferito.

Come da consiglio del mio amico Daniele ho provveduto a costruire un laboratorio SCOM dove provare patch e MP prima di portarle in produzione.

Poichè la versione bacata della KB957123 QFE ha, di fatto, distrutto il mio RMS ho ripristinato la macchina virtuale di backup che mi ero creato e relativo DB (OperationManager e OperationManagerDW).

Alla sua ripartenza ho trovato il seguente errore:

The SQL Server Service Broker for the current Opsmgr database is

not enabled

Il problema è di facile soluzione poiché il SQL Server Service Broker è una funzionalità di SQL Server che permette lo scambio di messaggi in maniera transazionale (come le code di MSMQ di tipo transazionale) con delle semplici estensioni del DML si SQL Server.

Ho perfezionato la procedura trovata qui  per gli ambienti con più management server come il mio.

1. Sull’RMS mettere in stop i servizi OpsMgr HealthService, Config, SDK
2. Sugli altri MS mettere in stop il servizio HealthService
3. Con SQL Server Management Studio aprire una query window sul database OperationManager ed eseguite in sequenza le query:

ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE

ALTER DATABASE OperationsManager SET ENABLE_BROKER

ALTER DATABASE OperationsManager SET MULTI_USER

In tutto l’esecuzione di queste query non richiede che qualche secondo. Se dura di più c’è sicuramente qualcuno che sta utilizzando il database e non permette l’alterazione dei suoi parametri.

Riattivate i servizi messi in stop ai punti precedenti e vedrete, dopo qualche tempo, che un bel pallino verde apparirà vicino al vostro RMS.