Supporto Tecnico Enterprise

Meccanismi di risoluzione DNS quando molteplici DNS server sono configurati su un client

Supporto Tecnico Enterprise Italia — Fri, 17 May 2013 22:00:00 GMT

Ciao a tutti!

Un pò di tempo fa avevamo parlato di DNS client in questo post, approfondendo i vari meccanismi di gestione della client cache e dei vari meccanismi di risoluzione record tramite suffissi quando era necessario andare ad interrogare un server DNS. Le cose però come sempre nel mondo reale sono un pò più complesse :)

Sicuramente infatti vi sarete trovati almeno una volta a configurare due o più server DNS da far utilizzare al vostro client dalle proprietà della scheda di rete o da uno scope DHCP:

Ma vi siete mai chiesti come funziona il meccanismo con cui i diversi server vengono utilizzati? è importante sapere che più server aggiungiamo alla lista, più aumentiamo le probabilità che la nostra query sia risolta. Ma dobbiamo tenere presente anche che se aggiungiamo più server, cambierà anche la modalità con la quale effettuiamo le query. Ma andiamo subito a vedere in dettaglio i vari scenari.

Qual è il comportamento di default di un client DNS quando è configurato un solo DNS server ?

Il comportamento è il seguente (testato su Windows XP, Windows 7 e Windows 8 con una sola scheda di rete)

Tempo (secondi dall’inizio della query)	Azione eseguita
0	Client effettua una query verso il server DNS
1	Se nessuna risposta è stata ricevuta dopo 1 secondo, il client effettua una nuova query verso il server DNS
2	Se nessuna risposta è stata ricevuta dopo 1 ulteriore secondo, il client effettua una nuova query verso il server DNS
4	Se nessuna risposta è stata ricevuta dopo 2 ulteriori secondi, il client effettua una nuova query verso il server DNS
8	Se nessuna risposta è stata ricevuta dopo 4 ulteriori secondi, il client effettua una nuova query verso il server DNS
10	Se nessuna risposta è stata ricevuta dopo 2 ulteriori secondi, il client smette di effettuare query

Nota bene: ogni risposta di “Name Error” o “Server Failure” ricevuta da parte del server determinerà lo stop del processo: il client non riproverà a fare la query se ha ricevuto una risposta negativa ma solo se non ha ottenuto alcuna risposta.

In questo semplice scenario, il client esegue 5 query verso il singolo DNS server prima di stopparsi.

Esempio:

Ipconfig sul client

IPv4 Address. . . . . . . . . . . : 10.0.0.31(Preferred)

DNS Servers . . . . . . . . . . . : 10.0.0.1

Estratto di una trace di rete (Network Monitor)

Qual è il comportamento di default di un client DNS Windows XP quando sono configurati 2 DNS server ?

Il comportamento è il seguente (testato su client Windows XP con una sola scheda di rete)

Tempo (secondi dall’inizio della query)	Azione eseguita
0	Client effettua una query verso il primo server della lista
1	Se nessuna risposta è stata ricevuta dopo 1 secondo, il client effettua una nuova query verso il secondo server DNS e in contemporanea ritenta una query verso il server primario
3	Se nessuna risposta è stata ricevuta dopo 2 ulteriori secondi, il client effettua una nuova query verso il server DNS primario
7	Se nessuna risposta è stata ricevuta dopo 4 ulteriori secondi, il client effettua una nuova query verso il server DNS primario
9	Se nessuna risposta è stata ricevuta dopo 2 ulteriori secondi, il client smette di effettuare query

In questo scenario, il client cerca di contattare prevalentemente il server primario, mentre utilizza il secondario una sola volta.

Esempio:

Ipconfig sul client

IPv4 Address. . . . . . . . . . . : 10.0.0.31(Preferred)

DNS Servers . . . . . . . . . . . : 10.0.0.1
10.0.0.2

Estratto di una trace di rete (Network Monitor)

Qual è il comportamento di default di un client DNS Windows 7 o Windows 8 quando sono configurati 2 DNS server ?

Il comportamento è il seguente (testato su client Windows 7 e Windows 8 con una sola scheda di rete)

Tempo (secondi dall’inizio della query)	Azione eseguita
0	Client effettua una query verso il primo server della lista
1	Se nessuna risposta è stata ricevuta dopo 1 secondo, il client effettua una nuova query verso il secondo server DNS
2	Se nessuna risposta è stata ricevuta dopo 1 ulteriore secondo, il client effettua una nuova query verso il secondo server DNS
4	Se nessuna risposta è stata ricevuta dopo 2 ulteriori secondi, il client effettua una nuova query verso tutti i server della lista in contemporanea
8	Se nessuna risposta è stata ricevuta dopo 4 ulteriori secondi, il client effettua una nuova query verso tutti i server della lista in contemporanea
10	Se nessuna risposta è stata ricevuta dopo 2 ulteriori secondi, il client smette di effettuare query

Il client tenta di utilizzare nuovi server solo se gli altri sono irraggiungibili.

Esempio:

Ipconfig sul client

IPv4 Address. . . . . . . . . . . : 10.0.0.31(Preferred)

DNS Servers . . . . . . . . . . . : 10.0.0.1
10.0.0.2

Estratto di una trace di rete (Network Monitor)

Qual è il comportamento di default di un client DNS quando sono configurati 3 o più DNS server ?

Quanti e quali di loro sono utilizzati?

Il comportamento è il seguente (testato su client Windows XP, Windows 7 e Windows 8 con una sola scheda di rete)

Tempo (secondi dall’inizio della query)	Azione eseguita
0	Client effettua una query verso il primo server della lista
1	Se nessuna risposta è stata ricevuta dopo 1 secondo, il client effettua una nuova query verso il secondo server DNS
2	Se nessuna risposta è stata ricevuta dopo 1 secondo, il client effettua una nuova query verso il terzo server DNS
4	Se nessuna risposta è stata ricevuta dopo 2 ulteriori secondi, il client effettua una nuova query verso tutti i server della lista in contemporanea
8	Se nessuna risposta è stata ricevuta dopo 4 ulteriori secondi, il client effettua una nuova query verso tutti i server della lista in contemporanea
10	Se nessuna risposta è stata ricevuta dopo 2 ulteriori secondi, il client smette di effettuare query

Il client tenta di utilizzare nuovi server solo se gli altri sono irraggiungibili.

Se quindi ci aspettiamo di ottenere la risposta da un server in quarta posizione, abbiamo un ritardo annunciato di almeno 4 secondi dopo la query originale. Questo può causare problemi nel caso in cui l’applicazione che ha invocato la query abbia un timeout inferiore a questo valore. L’unico modo per risolvere il problema è impostare il server DNS corretto in una delle prime 3 posizioni.

Esempio:

Windows 8 Client configurato con cinque server DNS, che effettua una query per Microsoft.com

Ipconfig sul client

IPv4 Address. . . . . . . . . . . : 10.0.0.31(Preferred)

DNS Servers . . . . . . . . . . . : 10.0.0.1
                                            10.0.0.2
                                            10.0.0.3
                                            10.0.0.4
                                            10.0.0.5

Estratto di una trace di rete (Network Monitor)

Info aggiuntive:

Se sul client ci sono due schede di rete, entrambe configurate con DNs server differenti il meccanismo è leggermente diverso ed è descritto in questo blog post:

http://blogs.technet.com/b/networking/archive/2009/06/26/dns-client-resolver-behavior.aspx

Grazie a tutti e alla prossima!

Stefano Gagliardi
Sr. Support Engineer
Microsoft Enterprise Platform Support

DNS forwarders e Conditional forwarders

Supporto Tecnico Enterprise Italia — Fri, 17 May 2013 22:00:00 GMT

Ciao a tutti!

Nel precedente post abbiamo parlato di come funzionano i meccanismi di risoluzione DNS quando molteplici server DNS sono configurati su di un client. Oggi andremo a vedere come funziona invece quando molteplici forwarders o conditional forwarders sono configurati su di un DNS server.

Partiamo da una brevissima descrizione teorica:

Quando un client chiede ad un server DNS di risolvere un nome per una zona a lui sconosciuta, il server si deve organizzare per andare a recuperare la risposta da un ulteriore server DNS. Per questo fine possiamo utilizzare i Forwarders.

Un Forwarder non è altro che un server DNS al quale il nostro server di riferimento inoltra la query del client (passi 1-2 in figura). Il forwarder stesso poi può conoscere la risposta alla query, o può doverla richiedere ad altri in modo ricorsivo (passi 3-4). Quello che è importante è che alla fine del processo il Forwarder sia in grado di restituire la risposta al nostro server (5) che la inoltrerà al client (6).

I Conditional Forwarders funzionano in modo del tutto analogo, ma sono specifici delle zone per cui si effettuano le query. Il server quindi può indirizzare, in base a quale sia la richiesta del client, la query verso uno (o più) conditional forwarders specifici.

Ovviamente, così come per i client, anche in questi casi è bene configurare più di un singolo forwarder/conditional forwarder per evitare problemi di risoluzione in caso di problemi di connettività o di server down.

Qual è il comportamento di default di un server DNS quando due o più DNS server sono configurati come Forwarders?

è bene tenere in considerazione due importanti variabili:

- RecursionTimeout
”quanto tempo il DNS server rimane in attesa di risposte da altri server prima di terminare la ricerca”

Il parametro è salvato nel registro sotto:

HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\RecursionTimeout

e configurabile tramite il comando:

dnscmd /config /RecursionTimeout <valore>

Il valore di default è:

15 secondi su Windows Server 2003
8 secondi su Windows Server 2008, 2008R2 e 2012

Il RecursionTimeout è definito a livello server ed è indipendente dalla specifica zona per cui si sta effettuando la query

- ForwardingTimeout
”quanto tempo il DNS server rimane in attesa di uno specifico Forwarder”

Il parametro è salvato nel registro sotto:

HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\ForwardingTimeout

e configurabile tramite il comando:

dnscmd /config /ForwardingTimeout <valore>

Il valore di default è:

5 secondi su Windows Server 2003
3 secondi su Windows Server 2008, 2008R2 e 2012

Il ForwardingTimeout è definito a livello server ed è indipendente dalla specifica zona per cui si sta effettuando la query

Questo parametro è quello che possiamo vedere dalla interfaccia grafica dei Forwarders:

Quando il server DNS riceve una query per un record in una zona per cui non è autoritativo e necessita di usare i forwarders, il comportamento è il seguente:

Tempo (secondi dall’inizio della query)	Azione eseguita
0	Client effettua una query verso il server DNS. Server DNS inoltra la query immediatamente verso il primo forwarder.
<forwarding_timeout>	Dopo <forwarding_timeout> secondi, se il primo forwarder non ha risposto, il server DNS inoltra la query verso il secondo forwarder
2 * <forwarding_timeout> +1	Dopo <forwarding_timeout> +1 ulteriori secondi, se il secondo forwarder non ha risposto, il server DNS inoltra la query verso il terzo forwarder
...	...
N * <forwarding_timeout> +(N-1)	Dopo <forwarding_timeout> +1 ulteriori secondi, se l’N-esimo forwarder non ha risposto, il server DNS inoltra la query verso il N+1 esimo forwarder

Nota: in aggiunta al ritardo configurato può esserci un ulteriore ritardo di 0.5 secondi

L’algoritmo si ferma quando il tempo trascorso supera il valore di RecursionTimeout.
Se scade il RecursionTimeout il DNS server risponde al client con un messaggio di “Server Failure”. Questo messaggio non è inviato immediatamente dopo la scadenza del timeout, ma solo quando arriverà il momento di contattare il forwarder successivo.

Se il server finisce di contattare tutti i forwarders prima che sia scaduto il RecursionTimeout senza ottenere risposte, proverà ad usare i Root Hints.

Questo significa che, con default settings, un DNS Windows Server 2008 R2 sarà in grado di contattare al massimo 3 forwarders. Non ci sarà tempo sufficiente per arrivare ad usare il quarto. Infatti in base ai valori di default il server:

Contatterà il primo forwarder dopo 0 secondi
Contatterà il secondo forwarder dopo 3.5 secondi
Contatterà il terzo forwarder dopo 3.5 + 4 = 7.5 secondi
Dopo 8 secondi scadrà RecursionTimeout
Dopo 3.5 + 4 + 4 = 11.5 secondi (quando sarebbe stato tempo di contattare il quarto forwarder) il server risponderà “server failure” al client.

Esempio:

DNS server con IP address 10.10.10.10 e configurato con 5 forwarders (10.0.0.1-10.0.0.5).

Client ha IP address 10.0.0.8

In una cattura di rete vedremmo il seguente comportamento (notare 10.0.0.4 e 10.0.0.5 mai interrogati):

Qual è il comportamento di default di un server DNS quando due o più DNS server sono configurati come Conditional Forwarders?

Similmente al caso dei Forwarders, abbiamo due variabili in gioco. C’è ancora RecursionTimeout (a livello server) ma in questo caso utilizziamo ForwarderTimeout anzichè ForwardingTimeout. Oltre alla sottile differenza nel nome, la grande differenza è che ForwarderTimeout opera a livello di zona ed ha diversi valori di default.

- RecursionTimeout
”quanto tempo il DNS server rimane in attesa di risposte da altri server prima di terminare la ricerca”

Il parametro è salvato nel registro sotto:

HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\RecursionTimeout

e configurabile tramite il comando:

dnscmd /config /RecursionTimeout <valore>

Il valore di default è:

15 secondi su Windows Server 2003
8 secondi su Windows Server 2008, 2008R2 e 2012

Il RecursionTimeout è definito a livello server ed è indipendente dalla specifica zona per cui si sta effettuando la query

- ForwarderTimeout
”quanto tempo il DNS server rimane in attesa di uno specifico Conditional Forwarder”

Poichè i Conditional Forwarders sono configurati per specifiche zone DNS, anche ForwarderTimeout è zone-dependent.

Il parametro è salvato nel registro sotto:

HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\DNS Server\Zones\ <nome_zona>\ForwarderTimeout

Il valore di default è 5 secondi su Windows Server 2003, 2008, 2008R2 e 2012

Questo parametro è quello che possiamo vedere dalla interfaccia grafica dei Conditional Forwarders:

Quando il server DNS riceve una query per un record in una zona per cui non è autoritativo e necessita di usare i conditional forwarders, il comportamento è il seguente:

Tempo (secondi dall’inizio della query)	Azione eseguita
0	Client effettua una query verso il server DNS. Server DNS inoltra la query immediatamente verso il primo conditional forwarder.
<forwarder_timeout>	Dopo <forwarder_timeout> secondi, se il primo conditional forwarder non ha risposto, il server DNS inoltra la query verso il secondo conditional forwarder
2 * <forwarder_timeout> +1	Dopo <forwarder_timeout> +1 ulteriori secondi, se il secondo conditional forwarder non ha risposto, il server DNS inoltra la query verso il terzo conditional forwarder
...	...
N * <forwarder_timeout> +(N-1)	Dopo <forwarder_timeout> +1 ulteriori secondi, se l’N-esimo conditional forwarder non ha risposto, il server DNS inoltra la query verso il N+1 esimo conditional forwarder

Nota: in aggiunta al ritardo configurato può esserci un ulteriore ritardo di 0.5 secondi

Questo significa che, con default settings, un DNS Windows Server 2008 R2 sarà in grado di contattare al massimo 2 conditional forwarders. Non ci sarà tempo sufficiente per arrivare ad usare il terzo. Infatti in base ai valori di default il server:

Contatterà il primo conditional forwarder dopo 0 secondi
Contatterà il secondo conditional forwarder dopo 5.5 secondi
Dopo 8 secondi scadrà RecursionTimeout
Dopo 5.5 + 6 = 11.5 secondi (quando sarebbe stato tempo di contattare il terzo conditional forwarder) il server risponderà “server failure” al client.

Esempio:

DNS server con IP address 10.10.10.10 e configurato con 5 conditional forwarders (10.0.0.1-10.0.0.5) per la zona Microsoft.com

Client ha IP address 10.0.0.8 ed effettua una query per Microsoft.com

In una cattura di rete vedremmo il seguente comportamento (notare 10.0.0.3, 10.0.0.4 e 10.0.0.5 mai interrogati):

Per ulteriori informazioni:

Teoria

Understanding Forwarders
http://technet.microsoft.com/en-us/library/cc782142(v=ws.10).aspx

Configurazione

Forwarding Timeout
http://technet.microsoft.com/en-us/library/cc940784.aspx
Recursion Timeout
http://technet.microsoft.com/en-us/library/cc940788.aspx

Best Practice

The Recursion Timeout must be greater than the Forwarding Timeout
http://technet.microsoft.com/en-us/library/ff807363(v=ws.10).aspx
The Forwarding Timeout value should be 2 to 10 seconds
http://technet.microsoft.com/en-us/library/ff807396(v=WS.10).aspx

Grazie a tutti e alla prossima!

Stefano Gagliardi
Sr. Support Engineer
Microsoft Enterprise Platform Support

System Center Advisor - Obiettivi e utilizzo

Supporto Tecnico Enterprise — Mon, 25 Mar 2013 14:47:35 GMT

Ciao a tutti,

il Product Team ha deciso di rilasciare System Center Advisor gratis e utilizzabile liberamente tramite registrazione.

La disponibilità della piattaforma con interfaccia grafica in inglese è valida attualmente nelle principali nazioni del mondo.

Funzionamento dell’infrastruttura

La seguente immagine illustra i blocchi di funzionamento di System Center Advisor:

User = l’utente o il team di persone registrate e autorizzate ad accedere alla dashboard per analizzare i risultati
Cloud = consiste sia nella parte di interfaccia grafica accessibile tramite la dashboard web, che il backend in cui i dati raccolti sono processati ed analizzati
Server = composta da 2 parti: un gateway per la comunicazione sicura verso il cloud e gli agent installati nei server per collezionare i dati

Con l’ultimo aggiornamento di Marzo 2013, sono stati aggiunti Windows Server 2012 e Microsoft Hyper-V Server 2012.

Di seguito l’elenco completo delle piattaforme supportate:

Consiglio di seguire questa pagina con gli aggiornamenti della piattaforma in quanto è in continua espansione e includerà a breve nuovi prodotti.

Registrazione degli utenti

Per iniziare è necessario registrare un nuovo account:

L’utente di System Center Advisor è associato all’account Microsoft (ex - Windows Live ID):

Accettate le condizioni del servizio, l’account è attivo ed è possibile iniziare subito la distribuzione dell’agent:

Configurazione del servizio - Gateway

Dopo la registrazione degli utenti che gestirà il servizio, procediamo con la configurazione del servizio.

La seguente schermata illustra i 2 componenti fondamentali da installare: Gateway e Agent.

I requisiti di sistema necessari per un corretto funzionamento del programma sono i seguenti:

Windows Server 2008 o successivo
Microsoft .NET Framework 3.5 SP1
Internet Explorer 7 / Firefox 3.5 e successivi
Microsoft Silverlight

Il programma d’installazione è di 62 Mb e include entrambi i componenti gateway e agent:

Una volta scaricato il programma e il certificato, procediamo con l’installazione del Gateway ovvero il computer che raccoglierà i log dei server e li invierà nel cloud tramite connessione criptata.

Attivando l’opzione Gateway, un messaggio avvisa che per poter comunicare correttamente, è necessario avere la porta 80 aperta tra i server monitorati e nel gateway verso internet.

Terminata l’installazione, si procede con la configurazione del Gateway.

Il primo passo consiste nell’impostare il proxy e importare il certificato scaricato precedentemente:

Dopo queste impostazioni, il gateway procede alla configurazione dei componenti:

Configurazione del servizio - Agent

Ora, si continua con la configurazione degli Agent sui server da monitorare.

Nel caso di infrastrutture complesse, sono disponibili le procedure per l’installazione tramite command line oppure altre diverse tipologie di deployment.

L’installazione via grafica è simile al Gateway e ha gli stessi prerequisiti:

Durante l’installazione dell’Agent si nota che il componente è “Sytems Center 2012 – Operations Manager Agent” che è il motore utilizzato per raccogliere le informazioni dai server:

Terminata installazione, si procede ad impostazione il server che svolge la funzione di gateway:

Terminata la configurazione del client, si dovrebbe ricevere la seguente schermata:

Per poter visualizzare i risultati, potete collegarvi al sito web System Center Advisor in cui saranno convogliate tutte le informazioni provenienti dai server monitorati:

Il prossimo post illustrerà i dettagli della Dashboard e la parte di raccolta dei log lato server.

Per qualsiasi altra domanda, potete utilizzare i commenti sotto all’articolo.

Grazie e Buona giornata!

Daniele Maso
Senior Support Engineer
Microsoft Enterprise Platform Support

Windows 7 SP1 e Windows server 2008 R2 SP1 – Rilasciato un aggiornamento cumulativo raccomandato KB2775511

Supporto Tecnico Enterprise Italia — Mon, 18 Mar 2013 23:00:00 GMT

Ciao a tutti!

Lo scorso 13 marzo 2013 Microsoft ha rilasciato un aggiornamento cumulativo per i due sistemi operativi Windows 7 e Windows server 2008 R2 che risolve diversi problemi noti e migliora le performance durante la fase di boot e logon.

La KB in questione è consultabile e scaricabile all’indirizzo http://support.microsoft.com/kb/2775511.

Le hotfix contenute nella KB migliorano le performance e l’affidabilità generale di computer basati su Windows 7 SP1 e Windows server 2008 R2; in particolare gli ambiti principali su cui l’aggiornamento apporta modifiche sono:

Componenti di Windows Client Remote File System, tra cui:
- Web-based Distributed Authoring and Versioning (WebDAV)
- DFSN client
- Folder Redirection
- Offline Files and Folders (CSC)
- SMB client
- Redirected Drive Buffering Subsystem (RDB)
- Multiple UNC Provider (MUP)
Componenti del servizio SMB e del protocollo TCP.
Processamento delle Group Policy e preferenze delle Group Policy
Componenti WMI

Tutto ciò porta a un miglioramento delle performance, in particolare dei seguenti aspetti:

Migliore performance di rete
Minore uso di banda di rete e carico sui servizi offerti da Domain Controller
Minore utilizzo di CPU e migliore performance per la verifica del repository WMI

A chi è destinato questo aggiornamento?

L’enterprise hotfix rollup è destinato principalmente:

a coloro che vogliono migliorare l’affidabilità e le performance di client e server, basati sui sistemi operativi sopra citati, joinati ad un dominio;
a coloro i quali creano immagini per il deployment in ambito aziendale.

L’aggiornamento richiede di avere già installato il Service Pack 1 dei sistemi operativi Windows 7 e Windows server 2008 R2.

La KB2775511 è un Service Pack?

No, questo aggiornamento non è un Service Pack, ma questa KB è raccomandata da Microsoft e dovrebbe essere inserita nei piani di manutenzione e patching degli ambienti enterprise gestiti.

La KB2775511 contiene 90 aggiornamenti precedentemente rilasciati dopo il Service Pack 1 ed è adatta sia ad ambienti client che server.

E’ consigliata la distribuzione sia sui client che sui server della propria organizzazione, dato che in questo modo si riesce ad ottenere il massimo dei benefici offerti.

Consiglio, ovviamente, di effettuare il deployment di tale aggiornamento in un ambiente di test durante un periodo di monitoraggio appropriato, pratica che dovrebbe essere comune in ambienti enterprise, prima di effettuare l’aggiornamento di ambienti in produzione.

Note post-installazione dell’aggiornamento

L’installer del rollup package non abilita due aggiornamenti contenuti nello stesso.

Nell’articolo della KB (http://support.microsoft.com/kb/2775511) sotto la sezione “Registry information” sono riportate le istruzioni per abilitarli con alcune note a margine.

Consiglio di leggere attentamente il contenuto dell’articolo per intero in modo che tutto sia chiaro prima di procedere con la distribuzione e/o installazione.

Come ottenere la KB2775511

L’aggiornamento può essere scaricato semplicemente dal Microsoft Update Catalog e può essere distribuito tramite WSUS e SCCM, oltre che essere installato manualmente come singola hotfix.

L’update non è proposta in automatico da Windows Update.

Download manuale da Microsoft Update Catalog

Di seguito i semplici passi per scaricare la KB dal Microsoft Update Catalog manualmente:

Aprire il web browser e inserire l’URL http://catalog.update.microsoft.com/
Cliccare su “Install” se viene richiesta l’installazione dell’add-on “Microsoft Update Catalog”
Nella casella di ricerca inserire la stringa “2775511” e cliccare su “Ricerca”
Nell’elenco delle versioni della KB, cliccare su “Aggiungi” per selezionare i singoli aggiornamenti o “Aggiungi tutto”
Cliccare su “visualizza carrello”
Cliccare su “Download”
Selezionare il percorso dove salvare i file e cliccare su “Continua”
Attendere la conclusione del download

…
Nel path specificato in precedenza troveremo i file delle hotfix selezionate

Importare la hotfix in System Center Configuration Manager 2012 e WSUS

Alcune screenshot sotto riportate sono tratte da http://blogs.technet.com/b/michaelgriswold/archive/2013/03/13/kb2775511-deployment-for-the-sccm-admin.aspx

Sul central site/CAS Software Update Point, aprire l’admin console Windows Server Update Services
Nel panel di sinistra, aprire la voce “Updates” e nel menu contestuale, cliccare su “Import Updates…”; questo aprirà una pagina web del Microsoft Update Catalog
Nella pagina cercare la stringa “2775511” e, una volta identificate le hotfix desiderate, selezionare la checkbox “Import directly into Windows Server Update Services”
Cliccando su “Import”, inizierà il download
Verificare che SCCM abbia l’impostazione “Updates” attivata per la sincronizzazione
Una volta che il download è completato, si può sincronizzare SCCM e, a questo punto, sarà possibile vedere gli aggiornamenti per il deployment come qualsiasi altro update.

…

Link utili

Consiglio la lettura dei seguenti articoli, relativamente all’argomento trattato in questo post.

An enterprise hotfix rollup is available for Windows 7 SP1 and Windows Server 2008 R2 SP1
http://support.microsoft.com/kb/2775511
Slow Boot Slow Login (SBSL) Hotfix Rollup for Windows 7 and Server 2008 R2 Available Today!
http://blogs.technet.com/b/askpfeplat/archive/2013/03/12/slow-boot-slow-login-sbsl-hotfix-rollup-for-windows-7-and-server-2008-r2-available-today.aspx
KB2775511 deployment for the SCCM Admin
http://blogs.technet.com/b/michaelgriswold/archive/2013/03/13/kb2775511-deployment-for-the-sccm-admin.aspx

Avvertenza

Il sottoscritto non si assume alcuna responsabilità derivante dall’esecuzione di attività descritte nel presente articolo.
Il contenuto dell’articolo è puramente indicativo e le azioni descritte devono essere vagliate caso per caso.

Buona giornata!

Alessandro Caniglia
Support Engineer
Microsoft Enterprise Platform Support

TMG 2010–Accesso Ftp access denied 550

Supporto Tecnico Enterprise Italia — Mon, 04 Mar 2013 23:00:00 GMT

Ciao a tutti!

In questo articolo vedremo come risolvere un particolare problema legato all’accesso ad un server FTP remoto dietro TMG 2010.

Immaginate il seguente scenario: un PC all’interno di una rete aziendale vuole accedere a un server FTP remoto attraverso TMG 2010 utilizzando un client-FTP come – ad esempio - Filezilla

La configurazione di questo server FTP (autenticazione, cifratura, ecc..) non ci interessa per questo tipo di situazione.

Sul server TMG, abbiamo creato una regola d’accesso che consente il transito del protocollo FTP dall’interno all’esterno in modalità “Read-only” (quindi solo in lettura):

Quando tentiamo la connessione verso il server FTP usando – ad esempio – Filezilla, potremmo ritrovarci col seguente errore:

I problemi di connettività a server FTP attraverso ISA/TMG possono essere causati da svariati diversi aspetti.

Nel seguente articolo troviamo I principali metodi di risoluzione delle problematiche piu comuni:

http://technet.microsoft.com/en-us/library/bb794745.aspx

Tuttavia, il problema oggetto di questo articolo è di natura differente rispetto a quanto riportato nell’articolo technet, e dipende da una ben precisa proprietà “by-design” del filtro FTP di TMG.

Nello specifico, nel nostro caso osserviamo che la connessione fallisce riportando un errore “550-Access Denied” in seguito all’invio di un comando MLSD da parte del client.

Che scopo ha il comando MLSD?

Il seguente articolo IETF ce ne chiarisce l’utilità:

http://tools.ietf.org/html/draft-ietf-ftpext-mlst-16#section-7

Citando testualmente:

The MLST and MLSD commands are intended to standardize the file and directory information returned by the Server-FTP process. These commands differ from the LIST command in that the format of the replies is strictly defined although extensible.

Vediamo quindi che tale comando è utilizzato con l’intento di “formattare” le informazioni relative a files e directories pubblicate dal server FTP, inviateci dall’FTP stesso.

Il filtro FTP di TMG, di sua natura, non considera il comando MLSD come comando di “Read” (al contrario di quanto avviene col comando LIST): una risoluzione banale del problema consisterebbe, pertanto, nel garantire priviliegi di scrittura sul server FTP andando a modificare la modalità di lavoro del filtro FTP di TMG a livello di regola d’accesso:

I client FTP che utilizzano il comando LIST non riporteranno questa problematica, in quanto il LIST è consentito dal filtro.

Ora, garantire privilegi di scrittura sul server FTP spesso non risulta desiderabile, nè consigliato, dipendentemente dall’utilizzo considerato.

Esiste un workaround che ci permette di mantenere il filtro FTP in “Read-Only” risolvendo questa problematica: è infatti possibile inserire tramite script il comando MLDS nella lista dei comandi consentiti dal filtro FTP di TMG configurato in “Read-Only” mode.

Il seguente articolo MSDN ci spiega come configurare vari add-ins:

http://msdn.microsoft.com/en-us/library/dd435753.aspx

Nello specifico del nostro caso:

FTP Access Filter

FTP Access Filter is an application filter that is installed with Forefront TMG. It enables FTP protocols. When running in read-only mode, FTP Access Filter blocks all commands in the control channel except the following commands: ABOR, ACCT, CDUP, CWD /0, FEAT, HELP, LANG, LIST, MODE, NLST, NOOP, PASS, PASV, PORT, PWD /0, QUIT, REIN, REST, RETR, SITE, STRU, SYST, TYPE, USER, XDUP, XCWD, XPWD, SMNT. This should block any writing to the server side. The default list of allowed commands can be replaced by a customized list that is written to the collection of vendor parameters sets (FPCVendorParametersSets) associated with the filter. The Firewall service must restarted for the new settings to take effect.

L’esempio di script presente nell’articolo può essere utilizzato per customizzare la lista dei comandi consentiti dal filtro.

Il valore di vpSet.Value("AllowReadCommands") = "xxxxxxx" andrà configurato con tutti i comandi che desideriamo il filtro FTP di TMG consideri come acconsentiti.

In questo modo sarà possibile mantenere il filtro FTP in “Read-Only”, e al contempo la nostra connessione FileZilla sarà in grado di funzionare perfettamente.

Nella speranza che questo possa tornarvi utile....arrivederci al prossimo topic!!

Daniele Gaiulli – MS Support Engineer

Windows 8, Windows 7, Windows Vista, Windows XP – strumento per la risoluzione di problemi durante la disinstallazione di programmi

Supporto Tecnico Enterprise Italia — Tue, 19 Feb 2013 23:00:00 GMT

Buongiorno!

Qualche giorno fa mi è capitato di riscontrare un problema durante la disinstallazione di una applicazione che non andava a buon fine.

Il primo passo da fare in questi casi è cercare di comprendere la possibile causa dell’errore, leggendo gli ulteriori dettagli visualizzati dal popup.

Se non riusciamo a trovare la strada corretta, Microsoft Fix it ci viene in aiuto.

Tra i tool messi a disposizione nella famiglia Microsoft Fix it (ne parlerò in un altro post del blog in futuro), ce n’è uno adatto alla nostra esigenza:

Program Install and Uninstall troubleshooter

E’ consigliato l’uso di questo strumento solo se la disinstallazione/installazione del programma fallisce usando “Aggiungi/Rimuovi Programmi” di Windows.

Il tool è scaricabile da http://support.microsoft.com/mats/Program_Install_and_Uninstall/en o dal seguente link localizzato in lingua italiana http://support.microsoft.com/mats/program_install_and_uninstall/it .

Può essere lanciato direttamente dalla pagina web, cliccando su “Esegui adesso”.

Una volta accettata la richiesta dell’UAC e accettato i termini di licenza, lo strumento effettuerà un rapido controllo e una installazione, come visibile in figura:

Terminato il processo di installazione, saranno visualizzate due possibili scelte:

Cliccando sulla scelta raccomandata, verrà chiesto se il problema riscontrato riguarda l’installazione o la disinstallazione.

Scelta la voce “Uninstalling”, verrà visualizzato un elenco di applicazioni attualmente installate sulla macchina:

Selezionate l’applicazione che non si riesce a disinstallare e cliccate su Next.

Vi verrà chiesta conferma della disinstallazione:

Una volta avviata la procedura, accettando la disinstallazione del componente, il tool provvederà ad effettuare una serie di operazioni il cui esito viene mostrato come in figura seguente:

E’ anche possibile visualizzare in dettaglio le operazioni effettuate, cliccando su “View report details”.

Prima di terminare l’esecuzione del tool, viene richiesto un feedback per aiutare Microsoft a migliorare lo strumento grazie alla collaborazione degli utenti.

Quali operazioni effettua Program Install and Uninstall troubleshooter?

Come elencato nella pagina da cui è possibile scaricare lo strumento, esso effettua le seguenti tipologie di attività:

Rimuove chiavi di registro incorrette su sistemi operativi a 64 bit.
Corregge le chiavi di registro di Windows che controllano l’aggiornamento (patching) che sono corrotte.
Risolve problemi che prevengono la corretta installazione di nuovi programmi.
Risolve problemi che provocano il fallimento della completa disinstallazione/installazione di programmi o di aggiornamenti.

Un esempio pratico di utilizzo: l’errore 1603 impedisce l’aggiornamento del client Skype

Personalmente ho riscontrato un problema effettuando un aggiornamento della versione del client Skype su un PC basato su Windows 7.

Durante la fase di aggiornamento, l’iter si bloccava visualizzando un errore irreversibile.

Il contenuto dell’errore visualizzato si riferiva a un problema che non permetteva di completare il processo di disinstallazione/aggiornamento del client Skype.

L’ID visualizzato 1603, comune a diversi scenari relativi a installazione/disinstallazione di applicazioni, ed esso cita:

error 1603: A fatal error occurred during installation

I dettagli a disposizione suggerivano che il problema fosse legato alla mancanza del file .msi di installazione della versione attualmente installata del client Skype, che non era reperibile tra i percorsi in cui l’unistaller lo cercava.

Lo stesso errore veniva visualizzato provando a disinstallare Skype da Aggiungi/Rimuovi Programmi.

Utilizzando lo strumento della famiglia Fix it descritto sopra, sono stato in grado di rimuovere correttamente il vecchio client di Skype e quindi di installare la nuova versione.

Link utili:

Program Install and Uninstall troubleshooter
http://support.microsoft.com/mats/program_install_and_uninstall
Microsoft Fix it center
http://support.microsoft.com/find-solutions/
La KB834484 discute di possibili cause che provocano l’errore 1603 durante la fase di installazione.
Per maggiori informazioni, consultare l’articolo a questo link: http://support.microsoft.com/kb/834484/

Avvertenza

Buona giornata!

Alessandro Caniglia
Support Engineer
Microsoft Enterprise Platform Support

“The Back-End Service Model“

Supporto Tecnico Enterprise Italia — Thu, 14 Feb 2013 23:00:00 GMT

Salve a tutti!

Spero abbiate scaricato in tanti l’applicazione di esempio e l’abbiate provata. Non è nulla di eccezionale, ma vuole mostrare la strada per creare una applicazione client-server, dove il server è un servizio che gira in Sessione 0 e il client è una applicazione user mode. Questo è il cosiddetto “Back-End Service Model“.

Come funziona il servizio.

Il servizio è un banalissimo servizio Windows realizzato in VB.Net. All’avvio, crea una pipe con un nome random, e salva il nome in una chiave di registry predefinita, cosicchè quando i client verranno avviati, potranno andare a leggere il nome della pipe nel registry e potranno collegarsi a quella. Questa è solo una misura di sicurezza per evitare attacchi DOS (Denial of Service), a cui la vostra applicazione potrebbe essere soggetta, dato che avere un servizio che gira come Local System e che esegue qualunque comando/applicazione, potrebbe consentire un veloce EOP (“escalation of privilege”) ad un qualunque malaware che vi prenda di mira. Ovviamente potete migliorare moltissimo questa fase, creando un protocollo di handshaking complicato e cryptato a piacimento.

Tenete sempre presente che qualora andaste a portare in produzione un’applicazione del genere, il rischio esiste, quindi dovete fare tutto il possibile per mitigare questa possibilità.

Il thread principale del servizio in ascolto sulla pipe, quando riceve una chiamata da un client, ottiene il nome dello user e crea un nuovo thread che altro non fa che aprire una nuova pipe su cui da ora in poi andranno avanti le comunicazioni. La vecchia comunicazione viene interrotta e il server può rimettesi in ascolto per una nuova connessione. Al client viene inviato il nome della nuova pipe creata.

Il client a questo punto tenterà di connettersi alla nuova pipe e se ci riesce il servizio gli invia indietro una stringa di controllo “START:” che significa che il client è connesso e può iniziare ad inviare comandi.

Come vedete il resto del thread è molto semplicemente una grande Select Case dove si analizza il contenuto del comando ricevuto e si agisce di conseguenza, richiamando la funzione specifica.

Oltre a questo, prima dell’avvio del pipe server, ho aggiunto la creazione di una form, che serve per gestire gli eventi relativi alle sesisoni.

La WTSRegisterSessionNotificationEx e la WTSUnRegisterSessionNotificationEx prevedono espressamente di utilizzare un window handle per gestire i messaggi di tipo WM_WTSSESSION_CHANGE, che sono elencati in questa enumerazione:

Public Enum WTS_SESSIONCHANGE_EVENT
    WTS_CONSOLE_CONNECT = 1
    WTS_CONSOLE_DISCONNECT
    WTS_REMOTE_CONNECT
    WTS_REMOTE_DISCONNECT
    WTS_SESSION_LOGON
    WTS_SESSION_LOGOFF
    WTS_SESSION_LOCK
    WTS_SESSION_UNLOCK
    WTS_SESSION_REMOTE_CONTROL
End Enum

In questo modo, potremo sapere sempre quando accade un evento di quelli sopra elencati, ed eventualmente mantenere una lista in memoria dove, avremo elencati numero sessione e ultimo evento ricevuto, così da poter sapere sempre in che stato si trova la sessione.. Locked o unlocked, collegata alla console o ad una sessione remota, ecc.. questo è l’unico modo per tenere traccia del fatto che una sesisone sia lockata o meno ad esempio.

Per evitare che la finestra si chiudesse immediatamente dato che siamo in Sessione 0 e il sistema si rende conto che questa finestra non serve a nulla, ho implementato un trucchetto, creando un thread di attesa.. bruttissima come soluzione, ma funzionale..

Conclusioni.

Quindi, riassumendo, abbiamo visto come il servizio può essere migliorato e di molto.. ad esempio implementando della sicurezza intorno alla creazione della pipe e/o cifrando il protocollo di comunicazione. Anche la creazione di una lista che mi dica sempre lo stato delle sessioni può essere una bella cosa.

Alla prossima!

Mario Raccagni
Senior Support Engineer
Platform Development Support Team

An authentication error occurred while communicating with the web server

Supporto Tecnico Enterprise Italia — Thu, 14 Feb 2013 23:00:00 GMT

Dopo l’installazione della Service Pack 2 di .NET 2.0 (o della SP1 di .NET 3.5) tentando il debugging remoto di un’applicazione web per la quale utilizzare gli host headers, potreste incappare in questo errore:

Unable to start debugging on the web server. An authentication error occurred while communicating with the web server

Il motivo è una modifica di sicurezza introdotta proprio da queste Service Pack: il comportamento di default è ora quello di utilizzare l’host name specificato nell’URL, in un SPN nel pacchetto di autenticazione NTLM; in altre parole facendo una richiesta all’indirizzo http://myserver/myapp, l’SPN “HTTP/myserver” viene aggiunto alle informazioni di autenticazione. Questa è una buona cosa dal punto di vista della sicurezza, ma con alcune conseguenze sgradite…

Il processo di autenticazione NTLM prevede un meccanismo di challenge che parte dalla macchina di destinazione (il server web) ed ha come destinatario il client che ha fatto la richiesta iniziale; quando Windows riceve un challenge che lui stesso ha generato, l’autenticazione fallisce a meno che la connessione non sia di tipo loopback. Quando un sito ha un host header configurato, l’host name non è ne il nome della macchia, ne l’indirizzo IP di loop back, ne l’indirizzo IP della macchia, quindi l’autenticazione è destinata a fallire.

Esistono due possibili soluzioni a questo problema:

L’approccio raccomandato consiste nel mappare l’host header con il look pack address nel registro di sistema, ecco come fare:
- Cliccate su Start > Run, digitate regedit e cliccate OK
- Nell’editor del registro di sistema selezionate la chiave “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0”
- Create un nuovo valore di tipo Multi-String e chiamatelo BackConnectionHostNames
- Modificatene il valore digitando l’host name (potete inserire anche più di un nome) del sito o dei siti che si trovano sul server
- Riavviate IIS
La seconda soluzione, però meno sicura della precedente, consiste nel disabilitare il loop back check come descritto in http://support.microsoft.com/kb/896861

Per maggiori dettagli vi rimando al post reporting-services-http-401-unauthorized-host-headers-require-your-attention.aspx (in inglese).

Carlo Cardella
Senior Support Engineer
EMEA IIS and Web Developer Support

AppInit_DLL, novità in Windows 7 e 2008 R2

Supporto Tecnico Enterprise Italia — Thu, 14 Feb 2013 23:00:00 GMT

Salve a tutti.

AppInit_DLL è una delle infrastrutture disponibili nel sistema operativo per estendere le funzionalità di un programma, aggiungendo, o meglio, “iniettando” una dll all’interno di un processo. La AppInit_DLL fornisce in modo semplice ed efficace la possibilità di caricare una dll custom all’interno di tutti i processi, e di rimpiazzare per mezzo di hook, le chiamate API di sistema, aggiungendo funzionalità, o anche solo per scopi di logging e/o tracing applicativo. Tipico esempio di questa funzionalità, gli antivirus.

Come gli antivirus, anche i virus e i malware, hanno sfruttato questo principio, di per se molto semplice ed efficace. Per questo motivo, a partire da Windows Vista l’infrastruttura AppINit_DLL è disabilitata per default. Questo comportamento rimane invariato per Windows 7 e 2008 R2. Ma cosa cambia quando questa viene attivata?

La configurazione della infrastruttura AppInit_DLL è controllata e regolata attraverso le chiavi di registry disponibili sotto:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT \CurrentVersion\Windows\

La seguente tabella mostra i possibili valori delle chiavi, e il loro significato:

Valore	Descrizione	Valori di esempio
LoadAppInit_DLLs (REG_DWORD)	Valore che abilita/disabilita a livello globale AppInit_DLL	0x0 – AppInit_DLL è disabilitata. 0x1 – AppInit_DLL è abilitata.
AppInit_DLLs (REG_SZ)	Lista di dll da caricare, delimitata da spazi o virgole. Il percorso completo deve essere specificato usando lo short file name.	C:\PROGRA~1\Test\Test.dll
RequireSignedAppInit_DLLs (REG_DWORD)	Richiede DLL firmate digitalmente.	0x0 – Carica ogni DLL. 0x1 – Carica solo DLL firmate digitalmente.

Le AppInit_DLL non vengono caricate all’interno dei processi protetti da DRM (Digital Right Management), e questo come è facile intuire non si può modificare/configurare. Inoltre, non verranno caricate in questi processi, considerati processi critici del Sistema:

· Windows Defender.

· Windows Software Licensing service.

· Microsoft Hyper-V (vmms.exe and vmwp.exe).

Durante un Upgrade da Vista a Windows 7, le dll che sono elencate nella chiave ApInit_DLL, non vengono migrate nel registry di Windows 7. Inoltre, durante Upgrade da sistemi operativi precedenti a Vista, le dll elencate non vengono nemmeno copiate nelle cartelle di sistema di Windows.

Per default, Windows 7, per motivi di compatibilità, continuerà a caricare tutte le dll elencate in AppInit_DLL, indipendentemente dal fatto che queste siano firmate digitalmente o meno. Questo perchè per default, RequireSignedAppInit_DLLs è impostato a 0.

Su Windows 2008 R2 invece, RequireSignedAppInit_DLLs è impostato a 1 per default, e quindi solo le librerie firmate digitalmente verranno caricate. Bisogna anche considerare la bitness delle DLL, visto che 2008 R2 è solo a 64 bit. Non si può caricare una dll a 32 bit in un processo a 64 bit e viceversa..

Microsoft raccomanda a tutti gl sviluppatori di estensioni che usano l’infrastruttura AppInit_DLL di iniziare a firmare digitalmente le librerie, perchè in futuro diventerà obbligatorio.

Developer Best Practices

Cosa devono fare gli sviluppatori per assicurarsi che le loro estensioni funzionino al meglio e siano caricate in Windows 7 (e sistemi successivi):

Firmare digitalmente le DLL.
Versioni successive di Windows caricheranno solo DLL firmate digitalmente, e non sarà disponibile una chiave di registry per configurare questo comportamento. Sarà obbligatorio.
Caricare le DLL solo nel processo richiesto e non in tutti i processi indistintamente.
L’infrastruttura AppInit_DLL carica le dll elencate nella chiave di registry in tutti i processi al loro avvio. Se la DLL è pensata per funzonare solo all’interno di un determinato processo, allora bisogna chiamare dall’interno della DLLMain, la GetModuleFileName, per recuperare il nome del processo che ci sta caricando. Se non è quello che ci interessa, bisogna semplicemente ritornare e non proseguire nel caricamento.
Durante la fase di inizializzazione, chiamare solo API esportate da Kernel32.dll.
Ricordando il fatto che questa infrastruttura consente di caricare DLL in “TUTTI” i processi, anche durante l’avvio del sistema operativo stesso, durante la fase di inizializzazione, ci si potrebbe trovare in una fase talmente embrionale del caricamento del sistema operativo, che molte funzionalità non saranno ancora disponibili. Per questo motivo è buona norma chiamare solo API contenute in Kernel32.dll, che sarà probabilmente l’unica dll già caricata in memoria nel processo in cui stiamo venendo caricati. Nulla impedisce di inizializzare un altro thread, la cui prima operazione è una sleep di qualche secondo, dando così modo alla dll di essere caricata senza problemi in qualunque processo senza causare problemi di loader lock durante l’inizializzazione, che come sempre deve essere il più atomica possibile.

Per tutti gli aspetti legati alla firma digitale e al testing nel sistema operativo vi rimando al documento ufficiale:

http://www.microsoft.com/whdc/driver/install/AppInit-Win7.mspx

Siamo così arrivati in prossimità delle festività natalizie. E’ stata una bella corsa. I Vostri feedback ci diranno se interessante o meno. Per il momento grazie per averci seguito e mi raccomando non abbiate paura di fare domande, di dare feedback, di interagire con noi. Siamo qui per aiutarvi possibilmente.

A nome del Supporto Tecnico agli Sviluppatori di Microsoft Italia, auguro a tutti un Buon Natale e un Felice Anno nuovo!

Alla prossima!

Mario Raccagni
Senior Support Engineer
Platform Development Support Team

ASP.NET application: alta CPU per un difetto di sincronizzazione accedendo ad una variabile globale.

Supporto Tecnico Enterprise Italia — Thu, 14 Feb 2013 23:00:00 GMT

Salve a tutti.

Vediamo oggi un interessante caso di alta CPU.
Siamo di fronte ad una applicazione ASP.NET 2.0 che, pur funzionando bene solitamente, di tanto in tanto rallenta improvvisamente e la CPU si innalza al di sopra del 80% di utilizzo.

Come al solito generiamo dei log con Performance Monitor che ci mostrino l’andamento della CPU usata dal processo durante la giornata. I seguenti counters ci aiuteranno a capire se la CPU è in qualche modo correlata al carico in termini di utenti connessi (Requests Current), o con le Collection del Garbage Collector (%Time in GC), o ancora all’ammontare di bytes allocati nell’unità di tempo (Allocated Bytes/Sec), o ancora a vedere in quanto tempo mediamente vengono servite le richieste (Request Execution Time), e tanto altro.

•    Performance Object : Process     -  Counters : Private Bites, %Privilaged Time, %User Time, %Processor Time, ID Process - Instances : any existing inentinfo.exe, w3wp.exe, aspnet_wp.exe and dllhost.exe  
•    Performance Object : Processor   -  Counters : Processor Time - Instances : _Total
•    Performance Object : Memory      -  Counters : Committed Bytes
•    Performance Object : ASP.NET vX.X-  Counters : All Counter  (where vX.X is the version you are running on)
•    Performance Object : ASP.NET Apps vx.x-  Counters : All Counter (where vX.X is the version you are running on)

Con i Debugging Tools for Windows, eseguiamo il seguente comando quando la CPU risulta essere sotto stress:

cscript adplus.vbs -quiet -hang -r 3 30 -p <PID> usando il PID del processo in questione

Questo comando genererà 3 memory dump alla distanza di 30 secondi l’uno, che andremo poi ad analizzare.

Come prima cosa eseguiremo il comando !runaway su tutti e 3 i dump. Questo comando ci dice quanti secondi CPU hanno usato i singoli thread a partire da quanto il processo è stato avviato. Per avere un dato significativo dobbiamo confrontare l’output del comando sui 3 dump e calcolare la differenza per capire quanti secondi sono stati spesi dai thread tra un dunmp e l’altro. Andremo ad analizzare i thread che hanno lavorato per più secondi.

Un esempio di output:

0:000> !runaway
 User Mode Time
  Thread       Time
  98:2fec      0 days 0:41:05.515
  85:2cf0      0 days 0:40:58.109
  93:904       0 days 0:39:08.484
 103:1fd8      0 days 0:35:22.171
  31:29a4      0 days 0:32:48.312
 109:2924      0 days 0:31:10.515
  23:16e0      0 days 0:29:10.953
 113:79c       0 days 0:27:26.687
  99:1424      0 days 0:17:58.750
  94:1fa0      0 days 0:17:55.734
 122:1898      0 days 0:13:23.593
 123:26b4      0 days 0:12:54.312
 117:ca4       0 days 0:12:44.343
 114:23b4      0 days 0:12:12.406
 100:2904      0 days 0:11:19.750
  91:f24       0 days 0:09:45.593
 125:f34       0 days 0:09:43.187
  29:1088      0 days 0:09:35.406
  37:22d0      0 days 0:09:34.515
  83:1410      0 days 0:09:32.890

Nel caso che stiamo rivedendo, usando il comando SOS.ClrStack, vediamo il callstack managed (ossia .NET) dei thread più occupati:

0:98> !clrstack
OS Thread Id: 0x27dc (124)
ESP       EIP     
2f77ed24 795b3c5c System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[System.__Canon, mscorlib]].FindEntry(Int32)
2f77ed3c 795b3835 System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[System.__Canon, mscorlib]].ContainsKey(Int32)
2f77ed40 209f1932 MyApp.MyFunc1()
2f77ed58 209f1815 MyApp.MyFunc2()
2f77ed70 209f163e MyApp.MyFunc3(Boolean)
2f77ed80 209f1453 ASP.site_master.__BuildControlform1()
2f77ed90 209f0a7b ASP.site_master.__BuildControlTree(ASP.site_master)
2f77eda0 209f098c ASP.site_master.FrameworkInitialize()
2f77eda8 661565a0 System.Web.UI.UserControl.InitializeAsUserControlInternal()
2f77edb0 66345fd9 System.Web.UI.MasterPage.CreateMaster(System.Web.UI.TemplateControl, System.Web.HttpContext, System.Web.VirtualPath, System.Collections.IDictionary)
2f77ee04 66147cd1 System.Web.UI.Page.get_Master()
2f77ee0c 6614a137 System.Web.UI.Page.ApplyMasterPage()
2f77ee1c 6614de3e System.Web.UI.Page.ProcessRequestMain(Boolean, Boolean)
2f77f018 6614d8c3 System.Web.UI.Page.ProcessRequest(Boolean, Boolean)
2f77f050 6614d80f System.Web.UI.Page.ProcessRequest()
2f77f088 6614d72f System.Web.UI.Page.ProcessRequestWithNoAssert(System.Web.HttpContext)
2f77f090 6614d6c2 System.Web.UI.Page.ProcessRequest(System.Web.HttpContext)
2f77f0a4 209f7545 ASP.MyPage_aspx.ProcessRequest(System.Web.HttpContext)
2f77f0a8 65fe6bfb System.Web.HttpApplication+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
2f77f0dc 65fe3f51 System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)
2f77f11c 65fe7733 System.Web.HttpApplication+ApplicationStepManager.ResumeSteps(System.Exception)
2f77f16c 65fccbfe System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(System.Web.HttpContext, System.AsyncCallback, System.Object)
2f77f188 65fd19c5 System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest)
2f77f1bc 65fd16b2 System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest)
2f77f1c8 65fcfa6d System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr, Int32)
2f77f3d8 79f047fd [ContextTransitionFrame: 2f77f3d8] 
2f77f40c 79f047fd [GCFrame: 2f77f40c] 
2f77f568 79f047fd [ComMethodFrame: 2f77f568]

Le funzioni dell’applicazione (che ho rinominato in MyApp.MyFunc) stanno lavorando con un oggetto Dictionary cercando un elemento:

System.Collections.Generic.Dictionary`2[[System.Int32, mscorlib],[System.__Canon, mscorlib]].FindEntry(Int32)

Già di per sé, se il Dictionary contenesse un numero molto elevato di Items, questa operazione potrebbe richiedere molta CPU. Nel nostro caso però l’oggetto sembrava avere solo pochi elementi.

Usando il comando !dso (sempre della SOS extension), è possibile vedere l’indirizzo del Dictionary (e di tutti gli altri oggetti usati dal thread, che però rimuovo dall’output sottostante):

0:022> !dso
OS Thread Id: 0x2c30 (22)
ESP/REG  Object   Name
esi      1728e9fc System.Collections.Generic.Dictionary`2

A questo punto possiamo vedere, tramite il comando !GCRoot, se questo oggetto è dichiarato come variabile locale del thread (avremo solo rooting che partono dal trhead local storage), oppure se è una varabile ‘strongly rooted’ che dunque sopravvive al thread ed ha application life scope.

Effettivamente il nostro Dictionary risulta essere strongly rooted, ed è inserito in una array di Objects. Tali array sono usate dal runtime per tenere traccia delle variabili statiche.

0:022> !gcroot 1728e9fc 
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
........
.cutting.
........
DOMAIN(09671470):HANDLE(Pinned):e5411ec:Root:  20120410(System.Object[])-> 1728e9fc(System.Collections.Generic.Dictionary`2

Dunque il nostro Dictionary è una variabile statica e come tale è accessibile da diversi thread contemporaneamente.

A questo punto, il dubbio che ci è sorto, è che l’accesso al Dictionary non fosse sincronizzato opportunamente. Analizzando le funzioni che vi accedevano l’ipotesi è stata confermata.

In pratica quello che succedeva era che, mentre un thread lavorava con il Dizionario cercando un elemento, un altro thread accedeva anch’esso allo stesso Dizionario e ne cambiava il numero e la posizione degli elementi. Così facendo si creavano situazioni instabili e la ricerca di un elemento poteva andare avanti all’infinito usando tanta CPU.

D’altra parte la documentazione avverte sul fatto che la Classe dictionary non è threadsafe e chi la usa in ambiente multythreaded deve preoccuparsi della sincronizzazione:

http://msdn.microsoft.com/en-us/library/xfhwa508(VS.80).aspx

A Dictionary can support multiple readers concurrently, as long as the collection is not modified. Even so, enumerating through a collection is intrinsically not a thread-safe procedure. In the rare case where an enumeration contends with write accesses, the collection must be locked during the entire enumeration. To allow the collection to be accessed by multiple threads for reading and writing, you must implement your own synchronization.

E’ stato sufficiente sincronizzare gli accessi, racchiudendoli in un blocco Lock{}, per risolvere il problema.

Alla prossima

Stefano Pronti
Senior Support Engineer
EMEA IIS and Web Developer Support Team