Volevo fare un’installazione di test di System Center Service Manager per vederlo funzionare con il lab di SCOM per valutarne l’eventuale utilizzo in produzione.

Per questo, come sono solito fare, ho preso uno dei miei template e con Windows Server 2008R2 e fatto un bel linked clone.

A questo punto ho aperto la documentazione e, come immaginavo, compreso che il join al dominio era indispensabile. Niente di più facile, ho pensato.

Niente di più sbagliato

In pratica sembrava che il DNS non fosse raggiungibile visto che fallivano persino le richieste fatte da riga di comando con nslookup. Inoltre la connessione Internet risultava non disponibile…

Ovviamente le stesse richieste fatte dal sistema host funzionavano perfettamente.

Ho pensato che il template avesse qualche problema e ho reinstallato Windows Server 2008R2 da zero. Arrivato al fatidico momento stesso comportamento.

Pensando di essere completamente rinco a causa delle attività ormai primariamente di gestione, ho effettuato il troubleshooting “da manuale” avendo sempre in risposta un messaggio di timeout durante la richiesta. Semplicemente assurdo.

Soprattutto perché dai log dei DNS e dalla trace di rete le richieste sembrava che non uscissero neanche dalla macchina virtuale….

Era proprio così!

Memore dell’esperienza precedente con un servizio impiccione ho guardato tutti I servizi della mia macchina cercando di realizzare quale potesse frapporsi tra la VM e il mio DNS perfettamente funzionante.

Alla fine l’occhio mi è caduto su un servizio dal nome inquietante ShrewSoft DNS Proxy Daemon facente parte della suite che uso per accedere in VPN alla rete aziendale.

Appena fatto lo stop del servizio tutto ha ripreso a funzionare perfettamente!

Credo sia giunto il momento che Microsoft metta più di un lucchetto su certe funzionalità. Quello che si perde a fare il troubleshooting inizia ad essere preponderante rispetto alla possibilità di installare qualunque “porcata”.

Dopo aver provato l’ebrezza dell’utilizzo continuo di Internet fuori dalle mura domestiche con un contratto flat per iPad, in vista delle vacanze mi sono preso un chiavetta della 3 per il netbook.
L’esperienza di installazione ed utilizzo è stata decisamente diversa (ed in peggio) rispetto a quella della micro SIM sulla tavoletta di Apple. Dopo un’intera giornata di prove ho deciso, vista la relativa facilità e rapidità di ripristino del netbook di procedere ad una installazione from scratch (in considerazione del fatto che sul portatile l’installazione e l’utilizzo della chiavetta era filato tutto liscio.

Dopo la reinstallazione la chiavetta veniva correttamente riconosciuta non solo alla prima installazione ma i successivi inserimenti in una porta USB non portava alla mancata installazione di un fantomatico Huawei USB device ma al pieno riconoscimenti di tutti i componenti della chiavetta (memoria, modem, USB).

Bontà loro anche in ufficio si sono decisi a mandarmi, in sostituzione dell’orrenda e assetata di energia scheda cardbus Mobile Connect una nuova e fiammante Huawei k4505 Vodafone.

Peccato che anche in questo caso, dopo una prima installazione che sembrava essere andata liscia, si ripeteva il medesimo problema del driver Huawei Usb che installava una tra seriale e tutto li.
Trattandosi del PC dell’ufficio, su cui avevo appena installato anche Visual Studio 2010 Ultimate, la reinstallazione era un opzione remota.

Le ho veramente provate tutte con fido amico Google come alleato per cercare un compagno di sventura che avesse risolto l’enigma prima di me.
Per fortuna i forum uk di Vodafone hanno un bel thread sull’argomento e, sebbene la soluzione nel mio caso non fosse esplicitata all’interno di nessun messaggio un suggerimento è stato determinante.

La presenza di Vmware Workstation 7 sul mio notebook di lavoro e dell’ultimissima versione di Vmware Player sul netbook. Entrambe queste ultime versioni installano un servizio di USB redirector che non lega bene con queste chiavette Huawei.

Spento il servizio, rimossi i driver, reinstallato tutto da capo, ora la chiavetta funziona perfettamente. Se avessi scavato prima mi sarei risparmiato la reinstallazione del netbook con quasi un anno di patch di Windows 7 da installare.

In questo caso non posso parlare di un vero e proprio crash ma di un problema di visualizzazione che, all’improvviso, si è manifestato sule schermate.

Come testimoniato dalla foto, il perfettissimo software di apple si è incartato mescolando le icone sul desktop. Nonostante i molti tentativi di utilizzare gli accelerometri per tentare di forzare un redraw della schermata la situazione è rimasta quella che vedere in foto.

E’ stato necessario uno spegnimento totale per sistemare le cose.

Disclaimer: questo e i prossimi post non vogliono denigrare il prodotto, Il sistema operativo o la Apple, ma semplicemente riportare la realtà dell’utilizzo quotidiano di quello che comunque è un ottimo prodotto.

Questa mattina, come ormai prassi, ho lanciato l’applicazione del corriere della sera (appena aggiornata da App Store) e dopo qualche pagina sfogliata alla ricerca di succulente news ecco il clamoroso crash.

Non solo si è chiusa l’applicazione del Corriere ma l’intero sistema è andato in crash visualizzando la mela morsicata della sequenza di boot e successivamente il logon screen.

Ai prossimi crash…

Disclaimer: questo e i prossimi post non vogliono denigrare il prodotto, Il sistema operativo o la Apple, ma semplicemente riportare la realtà dell’utilizzo quotidiano di quello che comunque è un ottimo prodotto.

Durante il fine settimana, dopo 7 giorni densi di riprese e foto, mi sono trovato di fronte all’ennesimo problema con Photoshop Elements 8. Aprivo l’organizer e dopo qualche istante arrivava la finestra che mi invitava a mandare un crashdump ad Adobe.

Con oltre 16000 elementi tra foto e video potete capire il mio disappunto e la paura di dover ricorrere ad un backup mai testato (su questo magari un altro post…).

Alla fine ho trovato molto di più di quello che mi serviva scoprendo anche che le magagne di PSE 8 non sono poche e, soprattutto, sono note e ben documentate.

A questo indirizzo trovate una FAQ che è meglio di una bibbia e, se avete ormai tanta di quella roba in PSE che la sola idea di cambiare vi sembra una punizione divina, tenetela sempre a portata di mano.

Per me è stata fondamentale.  Grazie John.

Oggi mi è capitato un caso molto strano su cui da tempo tutti i componenti del team avevano sotto il naso una situazione che non si riuscivano a spiegare.

Una applicazione (in futuro sarà un servizio) in .NET utilizzava un servizio per processare dei dati. Vista la natura dell’elaborazione ci aspettavamo che utilizzando molti thread saremmo riusciti a lavorare un gran numero di documenti grazie a server particolarmente prestanti.

Purtroppo questo non avveniva e le macchine erano costantemente sotto il 25% di utilizzo nonostante avessimo aumentato il numero di thread dell’applicazione.

Solo grazie ad un problema uno dei componenti del team nota una singolare situazione. I thread sull’IIS in attesa di essere smistati dal servizio di elaborazione sullo stesso server sono un numero incongruente con le nostre previsioni. Anzi, un numero costante: 2

Dopo aver riprodotto in laboratorio il medesimo comportamento ci è sembrato plausibile ci fosse una limitazione da qualche parte.

IIS non poteva sicuramente essere visto che, fosse anche solo per esperienza diretta, lo abbiamo visto con diverse centinaia di thread aperti simultaneamente.

Qualche altra ricerca ci ha portato a scoprire una limitazione ben documentata:

Two-Connection Limit

The HTTP specification indicates that an HTTP client should make a maximum of two simultaneous TCP connections to any single server. This keeps a single browser from overloading a server with connection requests when it browses to a page with, say, 120 embedded thumbnail images. Instead of creating 120 TCP connections and sending an HTTP request on each, the browser will only create 2 connections and then start sending the 120 HTTP requests for the thumbnail images on those two pipes. The problem with this approach on the middle tier is that your middle tier may have 50 simultaneous users. If you have to make a MapPoint .NET Web service call for each of those users, then you will have 48 users sitting around waiting in line for one of those two pipes to free up.

 

Direttamente da una pagina di MSDN in cui sono riportate tante altre informazioni utili riguardo a considerazioni di performance riguardo i WebServices.

Una lettura consigliatissima

La soluzione di questo problema è una banale configurazione nella configurazione della vostra applicazione (MYAPP.config)o web (web.config) che includa:

<system.net>
  <connectionManagement>
     <add address="*" maxconnection="8"/>
  </connectionManagement>
</system.net>

Dove maxconnection >2 che è il default.

Non si finisce mai d’imparare.

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!

Seguo spesso il blog di Mark Russinovich che ritengo uno dei principali esperti di Windows al mondo.

Mai avrei pensato che lui potesse rivedere la sua posizione sul SID che per molto tempo è stato lo spauracchio della virtualizzazione di macchine Windows.

Ricordo ancora quanti finti problemi ci siamo fatti relativamente alla duplicazione pura e semplice di un PC Windows pensando sempre a problemi derivanti dal SID. Spesso questo ha causato il lancio proprio dell’utility NewSID che ora è stata, giustamente, ritirata dal mercato.

La cosa più significativa è che il tanto temuto problema di sicurezza spesso indicato come legato al SID è invece dovuto al SID dei well-know-principal che è sempre lo stesso.

Grazie Mark, ma potevi anche chiedertelo prima però ;-:

In seguito all’improvvisa dipartita del mio Thinkpad T60 (una prece con medaglia al merito) la mia azienda mi ha spedito un nuovissimo Thinkpad T400 con un favoloso ed estremamente capiente HD da ben 160GB (gasp!).

Poiché avevo aggiornato il precedente Thinkpad con un HD da 250GB, SATA 300 a 7200RPM ho deciso, conscio delle problematiche di rigetto del trapianto, di procedere visto che avevo appena finito di reinstallare Windows 7 RTM fresco fresco.

Ovviamente l’operazione di sostituzione dell’HD è di una facilità esemplare: Lenovo ha continuato nel solco di IBM (in realtà i progettisti degli attuali thinkpad sono gli stessi di prima) e l’hd è in una slitta che si estrae con un apposito flessibile dopo aver svitato una sola vite indicata da una inequivocabile icona sul fondo del computer.

Reinserito l’hd ho acceso con tanta speranza ma mister BSOD si è fatto vivo con un bell’errore 0X0000007B ovvero (BOOT_DEVICE_INACCESSIBLE).

Fiducioso della capacità di recupero di Windows 7 ho lasciato partire il Recovery senza nessun miglioramento nonostante il lungo frullare sull’HD.

A questo punto è scatta la ricerca su GOOGLE e support.microsoft.com.

Diversi articoli riportavano anche uno dei parametri dell’errore con finale 34 ed in quel caso parlavano di driver del disco in conflitto con la configurazione del computer.

E qui, come spesso accade durante l’hardcore troubleshooting mi è venuto in mente che avevo modificato manualmente settings nel BIOS del mio vecchio Thinkpad per attivare l’AHCI migliorando sensibilmente le performance di accesso al disco.

Reboot, modifica del valore, boot di Windows senza BSOD e, dopo il logon Windows 7 mostro da che pasta è fatto: si cerca tutti i driver ed aggiorna completamente la sua configurazione (salvo la Intel AMT).

Dal cambiamento dell’impostazione del BIOS, da Compatibility a AHCI, al pieno utilizzo della mia macchina sul nuovo hw circa 30’. Il trapianto è riuscito!

La morale è che, seppur a modo suo, il sistema operativo ci dice sempre dove sta l’inghippo.. tocca conoscere il ventoso

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.