Supporto Tecnico Enterprise : Windows Team

Windows Server 2008 R2 Core – Come abilitare BitLocker da riga di comando

itentblg — Mon, 02 Nov 2009 00:00:00 GMT

BitLocker è una tecnologia semplice da configurare ed affidabile che permette la cifratura (encryption) di dischi a livello di settori. E’ disponibile a partire da Windows Vista e Windows Server 2008. Dettagli ed informazioni su questa tecnologia sono disponibili a questo link su Microsoft TechNet: http://technet.microsoft.com/en-us/windows/aa905065.aspx (http://technet.microsoft.com/it-it/windows/aa905065.aspx in italiano).

In Microsoft si considera tecnicamente possibile ed importante arrivare alla cifratura del proprio parco macchine desktop e laptop come uno standard aziendale. E’ evidente il vantaggio in termini di riduzione dei rischi di perdita di informazioni riservate associati a furti, dismissioni di hardware o altre situazioni di accesso fisico ai dischi non autorizzato. Si tratta inoltre di un importante impegno verso i propri clienti quando si detengano loro informazioni personali o riservate.

In base a queste considerazioni ho quindi iniziato da un po’ di tempo a cifrare tutti i dischi delle mie macchine, incluse le installazioni server. Si tratta di un’operazione abbastanza semplice, la documentazione disponbile (es. “Help and Support” nel menu principale) mi è stata sufficiente ad arrivare all’obiettivo. La mia macchina preferita è un Windows Server 2008 R2 Server Core con ruolo di file server personale ed Hyper-V per il mio laboratorio. In questo ultimo caso ho dovuto documentarmi in modo un po’ più approfondito, come spesso accade con la Server Core, non essendo sempre disponibili tutti gli strumenti amministrativi come nel caso dell’edizione Full.

Ho quindi voluto condividere sul nostro Blog i passi che ho seguito, che sono illustrati nel seguito.

Per installare la feature “Bitlocker” si deve eseguire il seguente comando:

start /w ocsetup BitLocker

nota: “L” maiuscola perché le feature sono riconosciute in modo “case sensitive”, il seguente riferimento contiene una lista delle feature che possono essere abilitate tramite ocsetup: http://technet.microsoft.com/en-us/magazine/dd673656.aspx.

Per l’encription del drive di boot e/o di sistema, nella modalità che detiene la chiave nel sottosistema TPM, si renderà necessario iniziaizzare il sottosistema stesso. Per ottenere questo scopo ci sono due alternative:

Console amministrativa “TPM management”. Essa è in grado di operare remotamente, tuttavia nella sua normale configurazione locale non è immediatamente disponibile un’opzione per connettersi ad un’altro computer. Per arrivare allo scopo si può eseguire una mmc vuota (start/run/mmc) ed aggiungere manualmente (File, Add/ Remove Snap-in) una console di tipo “TPM management”, in questa fase sarà quindi possibile selezionare se operare localmente o remotamente, specificando il nome del computer remoto.
Utility manage-bde con l’opzione -tpm. Useremo questa utility anche nel seguito. I dettagli delle opzioni di questa utility, compresa l’opzione -tpm sono elencate nella seguente pagina di documentazione su Microsoft TechNet: http://technet.microsoft.com/en-us/library/dd875513(WS.10).aspx.

Nota: il sottosistema TPM può necessitare di essere abilitato ed eventualmente inizializzato anche a livello di BIOS. Questa operazione deve essere fatta prima dell’inizializzazone a livello di sistema operativo. Non entrerò nei dettagli di questa parte perché è specifica dei singoli BIOS forniti dagli OEM (Original Equipment Manufacturer).

Per iniziare la cifratura dei dischi si userà ancora il comando manage-bde.exe da command prompt. Esso può essere eseguito sia localmente, sul Server Core, che remotamente; per questa seconda modalità l’opzione -cn (abbreviazione di -ComputerName) permette di specificare la macchina remota sulla quale il comando verrà applicato. Il comando più comune e semplice per la cifratura sarà il seguente:

manage-bde.exe -on X: -rp [-cn <computername>]

dove X: è il volume sul drive che si intende cifrare (tipicamente si inizierà da C:).

E’ importante notare che il parametro associato a -rp, NumericalPassword, è opzionale. Lasciandolo non specificato ne viene generata una automaticamente. Lasciare che la password sia generata automaticamente è comodo per il fatto che la stessa è soggetta a certi vincoli e quindi non è possibile scegliere una qualsiasi sequenza di cifre. E’ raccomandabile salvarla e stamparla e porla in luogo sicuro secondo le stesse modalità che la documentazione per il caso comune (non Server Core) illustra.

Operando remotamente è opportuno lavorare in un command prompt non elevato, in questa situazione infatti, se ci si dimenticasse di specificare -cn (-ComputerName), si eviterà l’encryption non desiderata su una macchina che non era la destinazione del comando. Al contrario l’elevazione locale non serve per operare come amministraztore sul server di destinazione.

Sempre con l’utility manage-bde si potrà monitorare il procedere dell’encryption:

manage-bde -status [-cn <computername>]

l’output in questo caso sarà una serie di informazioni per ciascun disco nel sistema, una di esse è il progredire dell’encription in termini percentuali.

Per sbloccare manualmente un drive, dopo un reboot senza aver configurato l’autounlock, e per impostare quest’utima modalità saranno necessari rispettivamente i seguenti due comandi:

manage-bde -unlock X: -rp ******-******-******-******-******-******-******-******

manage-bde -autounlock -enable X:

Nota: ******-******-******-******-******-******-******-****** rappresenta la password numerica che era stata messa in output dal comando manage-bde -on mostrato precedentemente.

L’obiettivo di questo post è di illustrare come eseguire certi passi, che nella versione Full del sistema operativo sono abbastanza agevoli, da command line e/o remotamente sulla Server Core. Relativamente ai meccanismi specifici di Bitlocker raccomando di documentarsi, p.es. facendo rifetimento ai link indicati, e di capirne dettagliatamente i meccanismi su cui si basa. Raccomando inoltre di mantenere sempre una copia delle password numeriche o di altro tipo per riacquisire l’accesso ai dati cifrati in caso di problemi. E’ infatti importante sapere che per ogni problema che portasse alla perdita delle chiavi a disposizione del sistema (memorizzate nel TPM, su file o dispositivi di storage esterni), solo la disponibilità delle password e/o chiavi permette di sbloccare i propri dispositivi e riaquistare l’accesso ai dati memorizzati su di essi.

Fabio Lavatelli
Escalation Engineer
Microsoft Enterprise Platform Support

Printer Server – Installare stampante locale senza interazione dell’utente

itentblg — Sun, 25 Oct 2009 23:00:00 GMT

In questo post vediamo come installare i driver delle stampanti locali tramite script in maniera automatizzata e sui vari client senza la necessità dell’interazione con l’utente.

Le stampanti “Plug & Play” collegate localmente richiedono le credenziali di amministratore per poter essere installate come indicato nel seguente articolo:

KB 326473
You Are Prompted for Administrator Credentials When You Try to Install a Plug and Play Printer
http://support.microsoft.com/default.aspx?scid=kb;en-us;326473

Quindi, nel momento in cui si collega la stampante al computer, è visualizzato il wizard d’installazione che richiede l’inserimento delle credenziali di amministratore.

Il wizard è avviato automaticamente dal Sistema Operativo in quanto il driver richiede “Client-side Installations” come indicato nel seguente articolo MSDN:

Device Installation Types
http://msdn.microsoft.com/en-us/library/ms791105.aspx

Devcon tool permette di interagire direttamente con il Device Manager e quindi evitare che l’utente riceva la schermata di installazione dei driver.
Maggiori informazioni sono disponibili sul TechNet:

Devcon Overview
http://technet.microsoft.com/en-us/library/cc737393(WS.10).aspx

Per quanto riguarda le stampanti, è possibile creare uno script di logon che esegua il rescan delle periferiche collegate al computer:

devcon.exe /rescan

A questo punto, la nuova stampante collegata localmente al PC sarà aggiunta dal Plug & Play nel Device Manager e tramite il seguente comando si eseguirà l’aggiornamento del driver:

devcon update %InfFile% %HardwareID%

Se il driver della stampante che vogliamo installare è inbox, ovvero presente nel CD di installazione del Sistema Operativo, è possibile far puntare %InfFile% a C:\WINDOWS\inf\ntprint.inf che contiene tutta la lista delle stampanti riconosciute da Windows.

Un altro comando utile per identificare tutte le stampanti installate nel computer è il seguente:

devcon.exe listclass printers

Inoltre, è anche possibile rimuovere la periferica tramite questo comando:

devcon.exe /remove %HardwareID%

Se non si conosce a priori l’Hardware ID della periferica installata nel computer, ma si conosce la lista delle stampanti presenti in azienda, è possibile creare l’installazione di tutti i driver conosciuti, in quanto devcon fallisce in caso non sia presente la periferica corrispondente all’Hardware ID specificato.
Questo semplifica la scrittura dello script d’installazione perché non richiede a priori la ricerca del tipo di periferica, anche se è possibile gestire i return code come indicato in questa sezione:

Devcon Remarks
http://technet.microsoft.com/en-us/library/cc779075(WS.10).aspx

Il download dell’applicazione è disponibile a questo indirizzo:

KB 311272
The DevCon command-line utility functions as an alternative to Device Manager
http://support.microsoft.com/kb/311272

Infine, una guida utile per controllare tramite Group Policy quali periferiche possono essere installate in Windows Vista e Windows Server 2008:

Device Management and Installation Step-by-Step Guide: Controlling Device Driver Installation and Usage with Group Policy
http://technet.microsoft.com/en-us/library/cc731387(WS.10).aspx

Daniele Maso
Senior Support Engineer
Microsoft Enterprise Platform Support

Windows Server 2008 - Impossibile installare il Service Pack 2

itentblg — Mon, 12 Oct 2009 02:00:00 GMT

Può capitare che la Service Pack 2 per Windows Server 2008 fallisca la sua installazione per via di una corruzione del deposito degli update, o per la mancanza di alcuni file ritenuti essenziali ai fini dell’installazione. Un effetto collaterale di questa corruzione può essere rappresentato dall’impossibilità di aprire e gesitre i ruoli nella finestra “Server Manager”.

La risoluzione di questa situazione, è abbastanza semplice, si tratta di individuare I file corrotti e sostituirli o eventualmente aggiungerli al deposito nel caso mancassero.

I passi da seguire per la risoluzione sono I seguenti:

Individuare I file oggetto del problema con “System Update Readiness Tool”
Recuperare I file originali
Copiare i file nel deposito degli update

Vediamo in maggiore dettaglio ogni passo.

Individuare

Il tool da utilizzare è scaricabile a questo indirizzo http://support.microsoft.com/kb/947821

Una volta scaricato ed eseguito, esso produrrà un file di log (CheckSUR.log) all’interno della cartella “%SYSTEMROOT%\Logs\CBS\”; questo log è di primaria importanza per il resto della soluzione in quanto contiene l’elenco dei file mancanti e/o corrotti, che dovranno essere sostituiti nei prossimi passi.

Un esempio del log prodotto è il seguente:

=================================
Checking System Update Readiness.
Binary Version 6.0.6001.22375
Package Version 5.0
2009-10-01 11:24
Checking Deployment Packages
Checking Package Manifests and catalogs.
Checking package watchlist.
Checking component watchlist.
Checking packages.
(f) CBS MUM Missing 0x00000002 servicing\packages\Package_80_for_KB967723~31bf3856ad364e35~amd64~~6.0.1.7.mum
(f) CBS MUM Missing 0x00000002 servicing\packages\Package_for_KB967723_server_0~31bf3856ad364e35~amd64~~6.0.1.7.mum
(f) CBS MUM Missing 0x00000002 servicing\packages\Package_for_KB967723_server~31bf3856ad364e35~amd64~~6.0.1.7.mum
(f) CBS MUM Missing 0x00000002 servicing\packages\Package_for_KB967723~31bf3856ad364e35~amd64~~6.0.1.7.mum
Checking component store
Summary:
Seconds executed: 401
Found 4 errors
CBS MUM Missing Total Count: 4
=================================

Recuperare

Il nome del file che sta causando il problema, contiene il numero della KB a cui appartiene, quindi è sufficiente scaricare l’aggiornamento corrispondente per avere una copia corretta del file. Rinominando l’eseguibile da .msu a .cab è possibile accedere ai file mum senza dover installare il pacchetto (installazione che molto probabilmente fallirebbe).

Ogni file .mum, può avere associato un file di catalogo (.cat) con lo stesso nome; sebbene questi tipi di file non siano menzionati nel log del passo precedente, essi vanno sempre copiati assieme ai file .mum.

Bisogna eseguire l’operazione per ogni KB elencata all’interno del log precedente, in modo che al termine di questo passaggio si disponga di tutti I file .mum e .cat necessari per procedere con il punto successivo

Copiare

Questa è la parte che richiede un pò più di lavoro, ma è comunque abbastanza semplice. Si tratta di copiare tutti I file raccolti all’interno della cartella %windir%\servicing\package sostituendo quelli eventualmente già presenti.

Questa cartella di sistema è però bloccata e l’utente, seppur amministratore, non ha i diritti di scrittura, per poter procedere bisogna prendere l’ownership di tale cartella. Una volta presa l’ownership è possibile aggiungere l’utente corrente ed assegnargli i permessi necessari per la copia dei file al suo interno.

Copiati i file, rieseguire nuovamente il punto 1 ed ispezionare il file di log, se nel log non risultano errori è possibile procedere con l’installazione della Service Pack 2.

Nel caso invece in cui compaiano altri file mancanti (possbili nuove dipendenze) ripetere tutta la procedura dall’inizio, fino a che nel log del tool di Readiness verrano riportati errori.

Una nota finale, per non incorrere in futuri problemi legati all’installazione degli aggiornamenti, ricordatevi di riassegnare l’ownership della cartella %windir%\servicing\package al servizio di update (utente NT SERVICE\TrustedInstaller).

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platform Support

Kerberos delegation – Capire e configurare correttamente

itentblg — Mon, 28 Sep 2009 02:00:00 GMT

Sempre più spesso sono coinvolto nella risoluzione di problemi di configurazione di Kerberos in infrastrutture con più server dove le credenziali devono essere “delegate” dai front-end server ai back-end server.

Ho pensato di scrivere questo post dove riportare tutti i punti per configurare i parametri usati da kerberos per funzionare correttamente.

Come funziona

La configurazione su mi trovo a lavorare sempre più spesso prevede uno o più server IIS e un back-end server con un SQL server o un File server. Per comprendere meglio i passi di configurazione è utile spiegare come funziona il meccanismo che permette di arrivare al server di back-end con le credenziali del client.

Il client passa le credenziali al Domain Controller/KDC che ritorna il TGT al client
Il client usa il TGT per richiedere il Service Ticket per connettersi al server IIS
Il client si connette al server IIS passandogli il TGT e il service Ticket
Il Server IIS usa il TGT passato dal client per richiedere il service ticket per accedere al Server SQL
Il Server IIS si connette a Server SQL usando le credenziali dell’utente loggato al client

Configurazione

Per permettere ad una sistema come quello rappresentato nell’immagine sopra di lavorare correttamente è necessario configurare diversi parametri nei diversi software utilizzati (IIS, IE, AD..)

Internet Explorer

Configurare FQDN del sito che verrà utilizzato nel “Local Intranet Zone” di Internet Explorer. Nel nostro esempio useremo l’FQDN blogs.technet.com

Abilitare l’opzione “Enable Windows Integrated Authentication” sotto “Internet Options->Advanced->Security-> Advanced”

Abilitare l’opzione “Automatic logon with current username and password" o "Automatic Logon only in Intranet Zone" sotto “Internet Options->Advanced->Security-> Custom level”

IIS

Eseguire il seguente comando per verificare la configurazione di IIS e assicurarsi che l’output mostri “Negotiate, NTLM”.

<system drive>\inetpub\adminscripts\cscript adsutil.vbs get w3svc/ WebSite /root/NTAuthenticationProviders

Bisogna sostituire WebSite con il numero del sito in IIS che sarà usato.

Configurare IIS con la sola “Windows Integrated Authentication”

Se si usano più IIS server è necessario configurare l’AppPool di entrambi i server IIS con un utente di dominio creato appositamente ( esempio: AppPoolUser). Nel caso di un solo server IIS si può lasciare l’utente Local System.

Active Directory

L’account AppPoolUser deve essere configurato con l’opzione per permettere la “delega”.

Bisogna precisare la differenza tra “Kerberos Delegation” (immagine sopra a sx) e “Contrained Delegation” (immagine sopra a dx). La“Kerberos Delegation” permette al primo server (front-end) di richiedere a nome del client il ticker kerberos per accedere al secondo server (back-end). La “Constrained Delegation” a differenza della “Kerberos Delegation” non è supportata su tutti i sistemi e per funzionare richiede che il “domain functional level” sia impostato a 2003. Con la “Constrained Delegation” l’amministratore può configurare un utente per richiedere il ticker kerberos solo per specifici servizi. Nell’esempio sopra abbiamo specificato solo il server SQLServer con la porta 1433 e il service principal name MSSQLSvc.

L’account AppPoolUser deve essere aggiunto al gruppo IIS_WPG group su ogni IIS server.
Registrare l’SPN per l’FQDN blogs.techenet.com all’account AppPoolUser

Setspn –A http/<FQDN> <Domain user account>

Setspn –A http/<Netbios Name> <Domain user account>

Verificare che SQL abbia registrato durante l’installazione l’SPN nell’oggetto computer del server SQLServer

Setspn –L <Domain user account>

Configurare i seguenti diritti per l’account AppPoolUser su tutti i server IIS tramite le Local Policy o tramite una GPO

Troubleshooting

Se avete seguito i passi sopra il sistema dovrebbe usare Kerberos senza problemi. Nel caso ci fossero problemi vi suggerisco di scaricare questa applicazione ASP.NET dal sito:

http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/delegconfig-delegation-configuration-reporting-tool.aspx

Dopo aver scaricato l’applicazione create un nuovo sito usando i file scaricati. A questo punto puntando sul nuovo sito avrete un report completo con indicato gli errori e la procedura per risolverli. Vi riporto un esempio di report nel caso tutto sia configurato correttamente:

Se l’uso dell’applicazione Delegconfig non è sufficiente vi riporto una lista di azioni da fare per identificare la causa del problema:

Pulire la cache kerberos con il tool Klist.exe o Kerbtray.exe sul client e su tutti i server. In questo modo tutti i ticket kerberos verranno richiesti al KDC utilizzando la nuova configurazione
Aumentare il livello del log di Kerberos (KB262177). Con l’attivazione di questo log verranno generati degli eventi in caso di errori nel registro degli eventi di sistema.
Collezionare una trace di rete sul client, il front-end e il back-end e analizzare il traffico kerberos sulla porta 88. Con l’analisi della trace di rete siete in grado di capire se ci sono problemi nella configurazione degli SPN. Gli errori kerberos tipici sono:

KDC_ERR_S_PRINCIPAL_UNKNOWN= Non è stato registrato l’spn
KDC_ERR_PRINCIPAL_NOT_UNIQUE= Ci sono più oggetti che hanno registrato lo stesso SPN. Per identificare gli oggetti si possono usare diversi tool. Avendo un server Windows 2008 si può sfruttare una nuova funzionalità del tool SetSpn:

http://blogs.msdn.com/saurabh_singh/archive/2009/01/09/new-features-in-setspn-exe-on-windows-server-2008.aspx

Altrimenti bisogna utilizzare il tool LDIFDE con la seguente sintassi:Syntax:

ldifde -f <filename> -d "<dc=domain-netbiosname,dc=primary-domain>" -l serviceprincipalname -r "(serviceprincipalname=<serviceprincipalname-to-check-for-duplicates>)" -p subtree

For example, if the domain name is test.abcd.com and the site URL is http//test.abcd.com command should be as shown below:

ldifde –f C:\log.txt -d "dc=test, dc=abcd, dc=com"-l serviceprincipalname –r "(serviceprinicpalname=http/test.abcd.com)" -p subtree

Se non volete usare il tool LDIFDE potete usare lo script contenuto nell’articolo 929650

Articoli utili

Kerberos on IIS, http://support.microsoft.com/kb/326985 , is a good resource that goes discusses using IIS for the front end server.
Kerberos on 2000 server clusters, http://support.microsoft.com/kb/235529
Kerberos in SQL Server, http://support.microsoft.com/kb/319723
Kerberos with network load balancing, http://support.microsoft.com/kb/325608
Kerberos with SMS 2003, http://support.microsoft.com/kb/326985

Documenti utili

Kerberos RFC - http://www.ietf.org/rfc/rfc1510.txt
Microsoft Kerberos Tech Ref - http://technet2.microsoft.com/windowsserver/en/library/b748fb3f-dbf0-4b01-9b22-be14a8b4ae101033.mspx?mfr=true
Kerberos Double Hop webcast - http://support.microsoft.com/kb/887682
Constrained Delegation -http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/constdel.mspx
Protocol Transition - http://technet2.microsoft.com/windowsserver/en/library/4c8b5ac7-368b-45b9-91d7-1ae7c5e0da311033.mspx?mfr=true
How the Kerberos Version 5 Authentication Protocol Works - http://technet2.microsoft.com/windowsserver/en/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f281033.mspx

Windows Update - Tipologie di aggiornamenti: QFE/LDR e GDR

itentblg — Mon, 14 Sep 2009 02:00:00 GMT

Spesso quando, prima dell'installazione di un pacchetto di aggiornamento, ci si sofferma a leggere l'elenco dei file che verranno aggiornati per la propria versione di sistema operativo, ci si trova davanti ad un elenco di questo tipo:

Come è possibile notare dalla figura, per ciascun file che è sostituito esiste sia una versione GDR, che una versione QFE identificabili dalla colonna “Service branch”.

Questo è dovuto al fatto che esistono due differenti tipologie di aggiornamenti, tipicamente definite come branch dagli sviluppatori Microsoft, che sono le General Distribution (GDR) e le Quick Fix Engineering (QFE).

GDR (General Distribution) - Un binario identificato come GDR, contiene solo gli aggiornamenti di sicurezza che sono stati eseguiti sul file, includendo i cambiamenti necessari per l'update in rilascio e quelli relativi alla precedenti security hotfix che aggiornavano lo stesso file. Questo tipo di aggiornamenti vengono rilasciati attraverso Windows Update.

QFE (Quick Fix Engineering) - Un binario identificato come QFE contiene sia gli aggiornamenti di sicurezza e sia gli aggiornamenti funzionali, includendo tutti i cambiamenti per l'update in rilascio e tutti quelli relativi alle precedenti security hotfix e bug hotfix. Con Windows Vista e Windows Server 2008, le QFE sono state rinominate in LDR (Limited Distribution Release).

Per chiarire ulteriormente la differenza, possiamo fare riferimento al seguente schema:

Se, dunque, per un ipotetico binario pippo.sys abbiamo installato la versione GDR – Security Hotfix #3, le correzioni introdotte con l’Hotfix #2 non saranno presenti.

Alla luce di quanto appena detto, la seguente domanda sarebbe più che lecita:

“ho trovato l’articolo KB XYZ (QFE – Hotfix #2) che rispecchia esattamente il problema che io sto riscontrando, ma il numero di build indicato per I file che l’update andrà ad installare è più vecchio di quello attualmente installato sulla mia macchina attraverso l’hotfix relativa all’articolo KB ABC (GDR – Security Hotfix #3). Come mai il mio problema risulta ancora presente anche dopo l’installazione della KB ABC?”

Il problema è ancora presente perché il security update (GDR) introdotto attraverso l’articolo KB ABC, sebbene più recente in termini di build, non include la correzione rilasciata con l’articolo KB XYZ che appartiene alla branch delle QFE.

Come identificare la versione di un binario installato

Windows XP o Windows Server 2003

Supponiamo di voler identificare a quale branch appartiene il nostro solito file pippo.sys, possiamo seguire la seguente procedura:

Fare clic sul pulsante Start, scegliere Search.
Nella casella Nome del file o parte del nome digitare il nome del file (pippo.sys nel nostro esempio), quindi scegliere Search.
Nel riquadro dei risultati della ricerca, fare clic con il pulsante destro del mouse sul file, quindi scegliere Properties.
Nella scheda Version, fare clic su File Version nell'area Other version information

Otterremo una finestra di questo tipo:

Dalle seguenti due tabelle possiamo identificare a quale branch appartiene il binario e quale sarà la versione installata in automatico da Windows Update

Windows Server 2003

Version	Description
srv03_rtm.mmmmmm-nnnn	Questo formato indica che il file proviene dalla versione originale del prodotto e che non è stato aggiornato da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver, un feature pack o un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
srv03_spx_gdr.mmmmmm-nnnn	Questo formato indica che il file proviene da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver o un feature pack e che non è stato aggiornato da un hotfix. Si tratta della build basata su SPx. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
srv03_spx_rtm.mmmmmm-nnnn	Questo formato indica che il file proviene da SPx e non è stato aggiornato da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver, un feature pack o un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
srv03_spx_qfe.mmmmmm-nnnn	Questo formato indica che il file proviene da un hotfix. Si tratta della build basata su SPx. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione hotfix che include anche la correzione GDR.

Windows XP

Version	Description
xpclient.mmmmmm-nnnn	Questo formato indica che il file proviene dalla versione originale del prodotto e che non è stato aggiornato da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver, un feature pack o un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
xpsp_spx_gdr.mmmmmm-nnnn	Questo formato indica che il file proviene da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver o un feature pack e che non è stato aggiornato da un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
xpspx.mmmmmm-nnnn	Questo formato indica che il file proviene da un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione hotfix che include anche la correzione GDR.
xpspxrtm.mmmmmm-nnnn	Questo formato indica che il file proviene da SPx e non è stato aggiornato da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver, un feature pack o un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
xpclnt_qfe.mmmmmm-nnnn	Questo formato indica che il file proviene da un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione hotfix che include anche la correzione GDR.
xpsp.mmmmmm-nnnn	Questo formato indica che il file proviene da un hotfix pre-SP3. Per poter installare questo file è necessario disporre del Service Pack 2. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione hotfix che include anche la correzione GDR.

Nell’esempio riportato sopra, la versione è: srv01_sp2_rtm-070216-1710 ovvero il file è stato installato con il service pack 2. Un eventuale aggiornamento sostituirà il binario con la relativa versione GDR.

Windows Vista o Windows Server 2008

Analogamente a quanto visto in precedenza, supponiamo di voler determinare la versione del driver Win32k.sys:

Fare clic sul pulsante Start e dal Search immettere il nome del file (Win32k.sys nel nostro caso)
Nel riquadro dei risultati della ricerca, fare clic con il pulsante destro del mouse sul file, quindi scegliere Properties.
Identificare la voce File Version, nella scheda Details

Otterremo un risultato di questo tipo:

Per identificare la versione, possiamo fare riferimento alla seguente tabella:

Version	Product	Level	Service Branch
6.0.600 0 . 16 xxx	Windows Vista	RTM	GDR
6.0.600 0 . 20 xxx	Windows Vista	RTM	LDR
6.0.600 1 . 18 xxx	Windows Vista and Windows Server 2008	SP1	GDR
6.0.600 1 . 22 xxx	Windows Vista and Windows Server 2008	SP1	LDR
6.0.600 2 . 18 xxx	Windows Vista and Windows Server 2008	SP2	GDR
6.0.600 2 . 22 xxx	Windows Vista and Windows Server 2008	SP2	LDR

Nel nostro esempio la versione è 6.0.6000.22416. Questo è dunque un file di Windows Vista ed appartiene alla branch GDR.

Come forzare l'installazione di una versione QFE/LDR

Windows XP o Windows Server 2003

Attraverso lo switch /B possiamo specificare la branch da cui l’update verrà installato, che sostituisce la scelta predefinita che sarebbe stata effettuata dall’update.exe
Questo significa che se di default il programma di update installerebbe il binario dal branch GDR, noi possiamo forzare l’installazione della relativa QFE.
Esempio, per una hotfix relativa al service pack 2 possiamo digitare:

WindowsServer2003.WindowsXP-KB999999-x64-ENU.exe /b:SP2QFE

Questo farà in modo che venga installata la versione QFE dell’hotfix specificata.
Lo switch /B non può essere utilizzato per installare la versione GDR di un binario che appartiene già al ramo QFE.
L’unico modo per tornare alla branch GDR, partendo da una QFE, è quello di rimuovere tutti gli update QFE o installare l’ultimo service pack disponibile.

Windows Vista o Windows Server 2008

Possiamo seguire I seguenti passi per forzare l’installazione di una LDR in Windows Vista e Windows Server 2008:

C:\> Expand -f:* <path del file .msu relativo all’update> <folder che conterrà l’espansione del file msu>
C:\> Expand -f:* <path del file KB#.cab contenuto nella cartella di espansione del file msu> <folder che conterrà l’espansione del cab>
C:\> pkgmgr /ip /m:<folder che conterrà l’espansione del cab> \update-bf.mum

Riferimenti utili

Branching out
http://blogs.technet.com/mrsnrub/archive/2009/05/18/branching-out.aspx
What is the difference between general distribution and limited distribution releases?
http://blogs.msdn.com/windowsvistanow/archive/2008/03/11/what-is-the-difference-between-general-distribution-and-limited-distribution-releases.aspx
Description of the contents of Windows XP Service Pack 2 and Windows Server 2003 software update packages
http://support.microsoft.com/kb/824994

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

Windows Server 2008 - Impossibile raggiungere la seconda scheda di rete se non è specificato il default gateway

itentblg — Mon, 07 Sep 2009 02:00:00 GMT

Una configurazione molto comune per un server è avere più di una scheda di rete, ed essere collegato a più reti simultaneamente nonostante il server non funga da forwarder/router. Un server con questa caratteristica viene etichettato come multihomed.

Un server multihomed è caratterizzato da un’elevata connettività di rete, in quanto può essere connesso simultaneamente a più reti, siano esse Intranet e/o Internet. Questa connessione multipla introduce alcune problematiche di sicurezza, che normalmente non sono presenti in un ambiente con una sola connessione. I servizi che girano in un server multihomed potrebbero essere vulnerabili ad attacchi provenienti dalle diverse reti connesse.

Per ovviare a questo problema l’RFC 1122 (sez 3.3.4.2) specifica due modelli comportamentali per gli host multihomed:

Strong ES Model
Weak ES Model

Nel primo modello l’host scarta un pacchetto in ingresso se il suo indirizzo di destinazione non corrisponde a quello dell’interfaccia in cui è stato ricevuto ed invia un pacchetto IP solamente attraverso l’interfaccia che corrisponde all’IP sorgente del pacchetto. Il modello weak invece è più permissivo, e permette di compiere le azioni inibite dal modello precedente.

Una differenza sostanziale tra I due modelli è nella scelta della scheda su cui inviare un pacchetto, il modello weak tiene conto solamente dell’IP di destinazione mentre il modello strong utilizza anche l’IP sorgente come parametro per la scelta della scheda da utilizzare. Da notare che il modello strong preferisce l’utilizzo di un default gateway per ogni scheda.

In Windows Server 2008 di default è abilitato il modello strong, che aumenta il livello di sicurezza della macchina. In alcune configurazioni particolari la seconda scheda di rete, senza gateway, riceve correttamente i pacchetti ma non invia le risposte per via delle restrizioni di sicurezza introdotte dal modello strong.

Per ovviare a questo inconveniente ci sono due modi:

Aggiungere un default gateway sulle NIC che ne sono prive
Passare dal modello strong al modello weak

Il primo punto è di facile implementazione, mentre per mettere in pratica il secondo punto bisogna utilizzare i seguenti comandi:

netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enabled
netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enabled

Per maggiori informazioni, e una dettagliata descrizione degli algoritmi utilizzati nei vari modelli potete fate riferimento al seguente articolo.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

Windows Update - Panoramica dei log d’installazione degli aggiornamenti

itentblg — Mon, 31 Aug 2009 02:00:00 GMT

Come abbiamo visto nell’articolo precedente, nei nuovi sistemi operativi il processo di aggiornamento di una macchina è basato su di una tecnica transazionale, che garantisce la corretta installazione di tutti gli aggiornamenti scaricati.

Come accennato, gli eventi di sistema sono la prima fonte di informazione nel caso ci siano problemi durante l’installazione degli aggiornamenti. Le informazioni contenute nella descrizione degli eventi sono però ad alto livello, ovvero a livello di pacchetto.

Con questo articolo vi illustro dove reperire ulteriori informazioni riguardo un’installazione fallita.

I principali posti da cui recuperare le informazioni relative all’installazione dei componenti, oltre agli eventi di sistema, sono:

%windir%\WindowsUpdate.log
%Windir%\logs\CBS.log

Mentre nel caso di errori di installazione al reboot della macchina:

%WinDir%\WinSxS\pending.xml
%WinDir%\WinSxS\poqexec.log

Seguendo l’ordine sopra descritto, si può tracciare una completa attività del processo di aggiornamento, in ordine crescente di dettagli.

Nel log di WindowUpdate troviamo tutta l’interazione con il server di aggiornamento, sia esso WSUS oppure il sito web Microsoft, ed inoltre troviamo lo stato finale dell’installazione come riportato dal servizio CBS. Nel caso di errori specifici all’installazione la sola consultazione di questo file non è sufficiente.

Nel secondo log della lista - CBS.log - troviamo tutte le operazioni effettuate dai componenti CBS, quindi la creazione delle transazioni e la valutazione delle regole di applicabilità. Il log non è “user-friendly” però a volte uno sguardo sommario può dare qualche indicazione in più sull’errore occorso durante l’installazione e fare puntare il dito verso una determinata risorsa (file, registro, permesso, ect.)

Gli ultimi due file sono strettamente legati tra loro, e servono per individuare l’errore quando l’installazione subisce problemi in fase di riavvio della macchina.

Addentriamoci ulteriormente nell’architettura CBS.

Possiamo pensare ad un pacchetto di aggiornamento come una serie/lista di operazioni da effettuare sul sistema; questa lista di operazioni, da eseguire con un ordine ben definito da regole di precedenza e di dipendenza, viene suddivisa in due code differenti:

Coda delle operazioni primitive (Primitive Operations Queue)
Coda delle operazioni avanzate (Advanced Installer Queue)

La prima coda contiene tutte quelle operazioni considerate “facili”, come ad esempio le operazioni sui file o sul registro di sistema; mentre la seconda coda viene riempita con tutte le operazioni che non possono essere modellate come operazioni primitive: ad esempio una modifica alle regole del firewall, l’installazione di una licenza..etc..

Per lo scopo di questo articolo, per semplificare le cose, consideriamo solamente la coda delle operazioni primitive.

Una volta costruita la coda, essa viene passata ad un componente che si occupa di eseguire tutte le operazioni elencate all’interno di una transazione kernel. È frequente che tra tutte queste operazioni alcune non possano essere eseguite durante la sessione di installazione, per i più svariati motivi, primo fra tutti l’accesso a file/risorse attualmente in uso.

Tutte queste operazioni “bloccano” la transazione richiedendo la propria esecuzione in fase di avvio della macchina. Davanti ad una simile richiesta il sistema operativo genera un file XML con il contenuto della coda primitiva (POQ) da eseguire durante il prossimo reboot. Il file generato è pending.xml ed è situato dentro la cartella %windir%\winsxs.

Esempio di file pending.xml:

<PendingTransaction Version="1.0" Identifier="58d5f3e1ca77c80164000000280f4c15">
<POQ>

<BeginTransaction id="TI4.29915082:3359338114:4/Package_for_KB937287" />
<MoveFile source="\SystemRoot\WinSxS\Temp\PendingRenames\b3053de0ca77c80161000000280f4c15 " destination="\SystemRoot\WinSxS\FileMaps\$$_servicing_fc2045b9046cc796.cdf-ms" />
<CreateFile path="\SystemRoot\WinSxS\FileMaps\$$_servicing_version_6.0.6001.18000 " fileAttribute="0x00000000" />
<DeleteFile path="\??\C:\Windows\System32\test.exe" />

</POQ>

Se al prossimo riavvio dovesse capitare un problema, il file verrà rinominato in pending.xml.bad e verrà generato il file poqexec.log all’interno della stessa cartella. Quest’ultimo file è come se contenesse l’indice degli errori occorsi all’interno del file pending.xml.bad. Controllando questo file il più delle volte riusciamo a trovare la specifica operazione primitiva che ha causato la fallita installazione.

Riporto un esempio concreto del file poqexec.log:

1c91429dcbd5e25: 0, 0, 0, 0, StartTime ;
1c91429e0a9e5b1: 0, 0, 0, 0, EndTime ;
1c92edb3b79b5c1: 0, 0, 0, 0, StartTime ;
1c92edb43e8bf82: 0, 0, 0, 0, EndTime ;
1c935d353ff8079: 0, 0, 0, 0, StartTime ;
1c935d3554f2373: 0, 0, 0, 0, EndTime ;
1c948b2d25268d5: 0, 0, 0, 0, StartTime ;
1c948b2d25268d5: 65b, c0190036, 16, 0, DeleteFile ;\??\C:\Windows\System32\test.exe
1c948b2d2787f05: 0, 0, 0, 0, EndTime ;

In caso di errori persistenti, come suggerisce l’articolo KB 949358 è possibile eliminare il file pending.xml per evitare che al successivo riavvio la macchina tenti di eseguire le sempre stesse operazioni che portano al problema.

Ogni errore ha una sua soluzione specifica, ma controllando tutti questi file, possiamo avere maggiori dettagli sugli errori occorsi, ed a volte possiamo anche trovare un work-around per la risoluzione del problema.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

Windows Update - TrustedInstaller e l’installazione transazionale

itentblg — Mon, 24 Aug 2009 02:00:00 GMT

Da Windows Vista in avanti è stata rivista gran parte dell’architettura di aggiornamento del sistema operativo. Si è passati da un’installazione “stand-alone” dei singoli aggiornamenti ad un sistema transazionale. Questa tecnica transazionale è molto più robusta e sicura della precedente, in quanto garantisce che il sistema si trovi sempre in uno stato consistente.

In parole più semplici, gli aggiornamenti vengono raggruppati in transazioni, e viene fatto un commit delle operazioni solamente se tutti gli aggiornamenti in una transazione non presentano errori nella propria di installazione. Al contrario se anche un solo aggiornamento fallisce la sua installazione, allora tutta la transazione viene annullata e nessun componente viene aggiornato.

Questa nuova architettura prende il nome di Component-Based Servicing (CBS) , e si basa sul concetto di componente. Un component è un’unità di “cambiamento dello stato del sistema” (file, registry key, settings, risorsa, etc.). Esso possiede un identità ed è trattato come un oggetto atomico. I componenti sono organizzati in deployment che a loro volta sono contenuti all’interno di package, unità di distribuzione. Un componente, così come un deployment ed un pacchetto, può avere delle dipendenze da soddisfare prima della propria installazione.

I principali componenti di questo nuovo sistema sono i seguenti:

Windows Modules Installer (TrustedInstaller.exe, CBS): è il servizio principale che lavora a livello di pacchetto/update ed analizza l’applicabilità di un aggiornamento
Component Servicing Infrastructure (CSI): infrastuttura di base che lavora a livello di deployment e a livello di componente, gestisce l’accesso e l’interazione con lo store dei componenti
Component Store: è formato dalla cartella %WinDir%\WinSxS e da un ramo particolare del registro. Esso è il ripostiglio di tutti i componenti e del loro manifesto (file XML che ne descrive le proprietà e le dipendenze)

In linea generale un pacchetto di aggiornamento viene passato al servizio CBS, che ne valuta l’applicabilità e lo scompatta nei vari deployment. A questo punto ogni deployment viene passato al livello CSI che si occupa di verificare la presenza dei vari componenti, ne controlla le dipendenze ed il loro stato. Infine il componente viene installato sul sistema. Tutte queste operazioni vengono eseguite all’interno di una transazione kernel che ne garantisce la corretta esecuzione.

Negli eventi di sistema vengono loggate tutte le operazioni effettuate, quindi un sguardo agli eventi è sempre il passo base per qualsiasi problema nell’installazione dei componenti. Questi eventi sono autoesplicativi, quindi ometto la loro descrizione. Il provider di tali eventi è Microsoft-Windows-Servicing.

Dopo questa panoramica, che è necessaria per capire la nuova architettura, nel prossimo articolo vi illustrerò dove recuperare maggiori informazioni in caso di errori durante l’installazione di un componente.

Gianluca Bertelli
Support Engineer
Microsoft Enterprise Platforms Support

Cluster Service – Il Poison Packet

itentblg — Mon, 27 Jul 2009 02:00:00 GMT

In questo post cerchiamo di capire come si comporta il Cluster Service in caso di problemi di comunicazione tra i nodi e quando utilizza il poison packet.

Per semplicità consideriamo un cluster a 2 nodi, ma lo stesso identico scenario è applicabile anche a configurazioni con un numero di nodi maggiori.

Problema

Lo scenario tipico si ha quando il nodo 2, che non detiene il quorum, è stato rimosso dal cluster e il cluster service è arrestato.
Inoltre, se si tenta di avviare il cluster service manualmente, dopo pochi minuti si arresta automaticamente.
Ovviamente in una configurazione a 2 nodi questo limita l’high availability, in quanto un failover non sarebbe possibile con 1 nodo solo disponibile.

Raccolta e Analisi dei Dati

Il primo punto da verificare sono gli Eventi di sistema in quanto riportano tutti gli eventi generati dal Cluster Service, ClusDisk e ClusNet.

In particolare, eventi tipici sintomatici del problema sono i seguenti:

Warning       ClusSvc   1123   The node lost communication with cluster node 'Node2' on network 'Public'.             Nodo1
Warning       ClusSvc   1123   The node lost communication with cluster node 'Node2' on network 'Private'.            Nodo1
Information   ClusSvc   1122   The node (re)established communication with cluster node 'Node2' on network 'Public'. Nodo1
Information   ClusSvc   1122   The node (re)established communication with cluster node 'Node2' on network 'Private'. Nodo1

Seguito dal seguente evento:

Error ClusNet 1118 Cluster service was terminated as requested by Node 1. Node2

L’ultimo evento indicato permette di capire che i 2 nodi sono riusciti a comunicare: infatti il Nodo 1 richiede esplicitamente al Nodo 2 di arrestare il Cluster Service.

Analizziamo il cluster.log presente in C:\Windows\Cluster del nodo 2, e non negli altri nodi, in quando i file cluster.log contengono gli eventi specifici del nodo e quindi sono diversi gli uni dagli altri.
Notiamo i seguenti eventi in corrispondenza dell’ora indicata calcolata in GTM (fuso orario di Londra):

00001728.0000077c::2009/07/20-14:42:13.623 INFO [CS] Cluster Service started - Cluster Node Version 4.3790

00001728.00000a4c::2009/07/20-14:49:21.406 INFO [ClMsg] Received poison event.
00001728.00000a4c::2009/07/20-14:49:21.406 ERR [RGP] Node 2: REGROUP ERROR: poison packet received from node 1

La prima riga indica l’avvio del Cluster Service: questo avviene indipendentemente dalla volontà del cluster perché è il Service Control Manager del Sistema Operativo a riavviare il servizio ad intervalli regolari in base alle impostazioni.
Dopo soli 7 minuti il tentativo di regroup al cluster fallisce perché il Cluster Message notifica la ricezione del Poison Packet e questo termina ogni attività del Cluster Service istantaneamente.

Soluzione

In questo esempio, la sovrapposizione dei problemi di visibilità tra i due nodi e l’evento del Poison Packet indica evidenti problemi di comunicazione.

Questo comportamento avviene nel momento in cui un nodo del cluster fallisce un aggiornamento tramite GUM, in quel momento il nodo che detiene il Quorum invia il Poison Packet e blocca il nodo finchè l’aggiornamento non è eseguito correttamente.

Il seguente articolo illustra un caso particolare in cui un fallimento della comunicazione RPC genera il Poison Packet:

KB 326330 - The Cluster Service Detects RPC Errors 1726 and 1722

Per quanto riguarda gli errori di comunicazione, possono influire molto nella sincronizzazione dei nodi, e per questo consiglio la lettura di questo articolo:

KB 892422 - Overview of event ID 1123 and event ID 1122 logging in Windows 2000-based and Windows Server 2003-based server clusters

Quando il nodo 1, che ha incarico il quorum, non riceve un aggiornamento dall’altro per più di 6 volte il tempo di hearbeat (1.2 secondi) su tutte le schede di rete, lo considera offline e gli invia il Poison Packet.
Questa procedura serve per tutelare il corretto funzionamento di tutto il cluster, in quanto la parte con meno voti (in questo caso il Nodo 2) non deve interferire con la parte maggioritaria (Nodo 1 + Quorum) e tutti i servizi continuano a essere erogati correttamente.

Daniele Maso
Senior Support Engineer
Microsoft Enterprise Platforms Support

Windows 7 & Windows Server 2008 R2 – Rilasciata la RTM ufficiale!

itentblg — Wed, 22 Jul 2009 02:00:00 GMT

Breve post dedicato all’importante rilascio della versione RTM (Release To Manufacturing) di Windows 7 e Windows Server 2008 R2.

L’annuncio ufficiale è stato pubblicato oggi ed è disponibile sul sito Microsoft.com

Tutti gli approfondimenti e le novità del nuovo Sistema Operativo client Windows 7 sono presenti nella sezione dedicata del sito Microsoft Italia.

Tutte le principali novità introdotte dal nuovo Windows Server 2008 R2 sono illustrate in un articolo di TechNet e confrontate con Windows Server 2008

Verificate inoltre le nuove versioni di Windows Server 2008 R2 in base alle necessità.

Vi consiglio di leggere i 3 post di MClips e TechNet Italia:

E’ importanti verificare le date di rilascio al pubblico:

RTM: OEM
6 agosto: TechNet Plus Direct, MSDN e Microsoft Connect
7 agosto: Volume License con Software Assurance
16 agosto: Microsoft Partner Network Portal
23 agosto: Microsoft Action Pack Subscribers
1 settembre: Volume License senza Software Assurance
1 ottobre: disponibilità di tutte le altre lingue
22 ottobre: clienti finali e pc con preinstallato Windows 7

Buona installazione a tutti!

Daniele Maso
Senior Support Engineer
Microsoft Enterprise Platform Support

DPM 2007 – Script per impostare una tape come free

itentblg — Mon, 13 Jul 2009 02:00:00 GMT

L'obiettivo di questo articolo è quello di fornire uno script, per marcare una tape come free, prima che la relativa data di retention sia trascorsa.

DPM non consente, infatti, di effettuare questa operazione da interfaccia grafica. Tuttavia, potrebbe essere necessario in particolari scenari, esempio durante una fase di test, recuperare un tape marcandolo come free.

A tal fine, prendiamo in considerazione il seguente script che andrà salvato con estensione .ps1:

----------------------------- Start of Script --------------------------------

param ([string] $DPMServerName, [string] $LibraryName, [string[]] $TapeLocationList)

if(("-?","-help") -contains $args[0])
{
    Write-Host "Usage: ForceFree-Tape.ps1 [[-DPMServerName] <Name of the DPM server>] [-LibraryName] <Name of the library> [-TapeLocationList] <Array of tape locations>"
    Write-Host "Example: Force-FreeTape.ps1 -LibraryName "My library" -TapeLocationList Slot-1, Slot-7"
    exit 0
}

if (!$DPMServerName)
{
    $DPMServerName = Read-Host "DPM server name: "

    if (!$DPMServerName)
    {
        Write-Error "Dpm server name not specified."
        exit 1
    }
}

if (!$LibraryName)
{
    $LibraryName = Read-Host "Library name: "

    if (!$LibraryName)
    {
        Write-Error "Library name not specified."
        exit 1
    }
}

if (!$TapeLocationList)
{
    $TapeLocationList = Read-Host "Tape location: "

    if (!$TapeLocationList)
    {
        Write-Error "Tape location not specified."
        exit 1
    }
}

if (!(Connect-DPMServer $DPMServerName))
{
    Write-Error "Failed to connect To DPM server $DPMServerName"
    exit 1
}

$library = Get-DPMLibrary $DPMServerName | where {$_.UserFriendlyName -eq $LibraryName}

if (!$library)
{
    Write-Error "Failed to find library with user friendly name $LibraryName"
    exit 1
}

foreach ($media in @(Get-Tape -DPMLibrary $library))
{
    if ($TapeLocationList -contains $media.Location)
    {
        if ($media -is [Microsoft.Internal.EnterpriseStorage.Dls.UI.ObjectModel.LibraryManagement.ArchiveMedia])
        {
            foreach ($rp in @(Get-RecoveryPoint -Tape $media))
            {
                Get-RecoveryPoint -Datasource $rp.Datasource | Out-Null

                Write-Verbose "Removing recovery point created at $($rp.RepresentedPointInTime) for tape in $($media.Location)."
                Remove-RecoveryPoint -RecoveryPoint $rp -ForceDeletion -Confirm:$false
            }

            Write-Verbose "Setting tape in $($media.Location) as free."
            Set-Tape -Tape $media -Free
        }
        else
        {
            Write-Error "The tape in $($media.Location) is a cleaner tape."
        }
    }
}

----------------------------- End of Script --------------------------------

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

DPM 2007 - Drive visualizzati come Standalone drive

itentblg — Mon, 06 Jul 2009 02:00:00 GMT

Lo scopo di questo post è quello di fornire le informazioni per risolvere una potenziale problematica relativa ai drive di una library esposti da Data Protection Manager 2007.

Potrebbe capitare che, in seguito all'installazione di una library sul nostro server DPM 2007, i relativi drive siano visualizzati come Standalone Drives:

La prima cosa che dobbiamo verificare è il modo in cui sono visualizzati i drive e la library in Device manager:

Questo è un tipico caso in cui i driver della library non sono installati correttamente e dunque la library è visualizzata come "Unknown Medium Changer" e potenzialmente anche i drive non sono riconosciuti correttamente.

Occorrerà dunque richiedere al vendor i driver corretti, portandosi in una situazione coerente come quella riportata nella seguente figura:

Se anche dopo aver installato l'hardware in maniera corretta ed aver effettuato un rescan dalla console DPM, o se questo fosse stato già installato correttamente in precedenza, si continuano a visualizzare i drive come standalone, verificare se la library che si sta utilizzando è tra quelle certificate per DPM.
A tal fine sarà possibile utilizzare il seguente link:

System Center Data Protection Manager 2007 Tested Hardware
http://technet.microsoft.com/it-it/dpm/cc678583(en-us).aspx

Se il problema ancora persiste, una volta accertato che la nostra library è tra quelle testate per Data Protection Manager 2007, possiamo effettuare un remapping dei drive.

Per eseguire questa procedura, accertarsi che:

Il servizio DPMLA dovrà essere arrestato
Occorrerà rimuovere tutte le tape dai vari drive

Eseguire i seguenti task:

Effettuare un backup del file <DPM Installation path>\Config\DPMLA.xml ed eliminarlo
Rigenerarlo attraverso il tool: <DPM Installation path>\Bin\DriveMappingTool.exe
Aprire la console DPM ed eseguire un rescan

L'esecuzione del tool fallirà se eseguito per un drive standalone, restituendo il seguente errore:

La procedura sopra esposta è documentata al seguente link:

Remapping Tape Drives
http://technet.microsoft.com/en-us/library/bb795782.aspx

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

Memoria Paged e NonPaged Pool – Come risolvere un memory leak

itentblg — Mon, 18 May 2009 02:00:00 GMT

In questo post vedremo come risolvere un leak di memoria e identificare il driver responsabile.
Vi consiglio di leggere il post Memoria Paged e NonPaged Pool – Come identificare un memory leak per verificare che effettivamente siamo in presenza di un leak di memoria.

Utilizzare il PoolMon

L’allocazione di una quantità di byte in una delle memorie Pool utilizza un sistema di tagging. Un TAG è un identificativo di quattro byte associato ad ogni porzione di memoria Pool allocata.

Il TAG viene specificato da un driver, durante l’allocazione della memoria, attraverso la routine ExAllocatePoolWithTag. I seguenti tre parametri, devono essere specificati durante la chiamata a questa routine:

PoolType: Il tipo di memoria Pool da allocare (Paged o NonPaged)
NumberofBytes: Il numero di byte da allocare con la richiesta
TAG: il Pool TAG, rappresentato attraverso quattro caratteri ASCII

L’obiettivo dei Pool TAG è quello di fornire un meccanismo, che attraverso degli identificatore potenzialmente univoci, consenta di stabilire quali driver stanno allocando la memoria. Inoltre, durante la fase di sviluppo di un driver, i TAG sono utili per poter differenziare le diverse tipologie di allocazione, rendendo più selettiva un’eventuale investigazione attraverso il tool Driver Verifier.

Identificare il TAG e byte allocati

Per poter verificare quanti byte sono allocati da un determinato TAG occorrerà utilizzare il tool poolmon.exe, che è possibile recuperare dalla cartella \Support\Tools del CD d’installazione del Sistema Operativo.

Questo tool consente di ottenere un report di tutti i TAG della Paged e Non Paged Pool con i relativi byte allocati.
In Windows Server 2003 il Pool tagging è già abilitato, mentre in Windows Server 2000 e Windows XP è necessario abilitarlo attraverso il tool Gflags.exe presente sempre nella cartella \Support\Tools del supporto di installazione, o modificando le opportune chiavi di registro.

Per maggiori informazioni sull'utilizzo di questo tool potete consultare l’articolo How to use Memory Pool Monitor (Poolmon.exe) to troubleshoot kernel mode memory leaks

La seguente immagine illustra un esempio di output relativo al poolmon:

FIG 1 - Output del tool Poolmon.exe

I campi fondamentali per la nostra analisi sono evidenziati in rosso:

Tag: Rappresenta il TAG che identifica l'allocazione.
Type: Specifica se la memoria è stata allocata in Paged (Paged) o Nonpaged (Nonp) pool.
Bytes: Quantità di memoria allocata, in bytes, per il corrispondente TAG

Possiamo, dunque, utilizzare i seguenti passi per raccogliere l'output del poolmon in una finestra temporale di nostro interesse:

Copiare il file "PoolMon.exe" in "C:\PoolMon", inserendo nella stessa cartella il tool sleep.exe
Aprire una console dei comandi da "Start" --> "All programs" --> "Accessories" --> "Command Prompt"
Spostare il prompt in C:\PoolMon
Per avere una lettura dei dati ogni 15 minuti (per 2 giorni circa), digitare il seguente comando:
for /l %i in (1,1,200) do ( poolmon -n log-%i.txt && sleep 900000 )
Nella cartella "C:\PoolMon" verranno creati i vari file di log.

Il tool sleep.exe utilizzato è fornito in allegato al presente post.

Determinare la frequenza di campionamento

Sleep.exe richiede un parametro che indica il periodo d'attesa in millisecondi tra due esecuzioni del ciclo for.
Nell’esempio di script riportato sopra, abbiamo il parametro 900’000 che è ottenuto moltiplicando: 15 minuti * 60 secondi * 1000 millisecondi per ottenere una pausa tra una lettura e l’altra di 15 minuti.

Considerando i 200 cicli impostati ogni 15 minuti, abbiamo un campionamento di circa 2 giorni calcolato da: 15 minuti/campione * 200 campioni = 3000 minuti totali / 60 = 50 ore totali / 24 = 2,08 giorni.

Possiamo modificare il numero di cicli e la frequenza di campionamento in base alla rapidità del leak che abbiamo identificato.

Al termine del periodo di monitoring, avremo dunque 200 file di testo, che iniziano con log1.txt fino a log200.txt nel nostro esempio.

Copiando questi dati in un foglio Excel ed ordinandoli in base al tipo (Nonp o Paged) e in ordine decrescente rispetto ai byte allocati, saremo in grado di determinare la variazione di allocazione dei TAG in funzione del tempo, identificando quali, in particolare, stanno occupando di più.

FIG 2 - Schermata di Excel per l'ordinamento dei TAG.

Analizzare i log

Avremo risultati di questo tipo:

NonPaged Pool

NonPaged - Log 1	NonPaged - Log 10	NonPaged - Log 20

Paged Pool

Paged - Log 1	Paged - Log 10	Paged - Log 20

Come possiamo notare è evidente un notevole incremento del TAG Pipo per la Nonpaged pool.
Analizzando anche i restanti log abbiamo infatti il seguente andamento:

FIG 3 - Andamento della Nonpaged pool allocata dal TAG Pipo.

Come è possibile notare è presente un leak sul TAG Pipo. Ora che abbiamo identificato il TAG che sta alla base del memory leak, come possiamo identificarne il driver corrispondente?

Identificare il driver

L’elenco di tutti i TAG utilizzati per le allocazioni nella memoria Pool sono disponibili nel file Pooltag.txt
Questo file contiene l’identificativo di tutti i componenti Kernel-mode e driver rilasciati con i Sistemi Operativi Windows.

E’ disponibile per il download e l’installazione all’interno dei Debugging Tools for Windows:

Un esempio del contenuto del file Pooltag.txt è riportato di seguito:

8042 - i8042prt.sys - PS/2 kb and mouse
AdSv - vmsrvc.sys   - Virtual Machines Additions Service
ARPC - atmarpc.sys - ATM ARP Client
ATMU - atmuni.sys   - ATM UNI Call Manager
ACPI - acpi.sys     - ACPI
Afd? - afd.sys      - AFD objects
AfdA - afd.sys      - Afd EA buffer

Se il TAG che causa il leak di memoria non è contenuti nell’elenco, vi consiglio di effettuare una ricerca nella nostra Knowledge Base, in modo da verificare la presenza di eventuali problemi conosciuti e installare la relativa hotfix.

Se invece, come nel caso del nostro esempio, il TAG non è Microsoft non sarà presente nell'elenco.
In questo caso possiamo utilizzare il comando findstr, valido per ciascuna versione di Windows, che potrà essere eseguito come indicato di seguito:

Aprire una console dei comandi da "Start" --> "All programs" --> "Accessories" --> "Command Prompt"
Spostarsi nella cartella %systemroot%\system32\drivers
Digitare il comando
findstr /m /l <tag> *.sys
Verificare l'output restituito dal comando

In questo screenshot è evidenziata la ricerca per il TAG Pipo:

Come possiamo notare è restituito il driver corrispondente al TAG specificato “Pipo”.

In questo caso occorrerà verificare un'eventuale versione aggiornata del driver Pippo.sys, o eventualmente contattare il fornitore del software segnalando la problematica.

Conclusione

Alla luce di quanto visto fino ad ora, se stiamo evidenziando un leak di memoria sul nostro sistema potremo identificarne la potenziale causa attraverso i seguenti passi:

Monitorare i byte allocati da ciascun TAG durante una finestra temporale adeguata al nostro leak, attraverso il tool poolmon.exe
Evidenziare eventuali allocazioni che variano proporzionalmente al tempo in costante crescita
Stabilire su che tipo di pool è presente il leak (Paged o Nonpaged)
Stabilire il driver associato al TAG che sta causando il leak
Ricercare eventuali problemi noti, o analizzare la problematica con il fornitore del driver

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

Microsoft Support Lifecycle – Periodo di supporto per Sistemi Operativi Windows Server

itentblg — Mon, 04 May 2009 02:00:00 GMT

In questo post cerco di chiarire i periodi di supporto per i 3 sistemi operativi server rilasciati:

Windows 2000 Server
Windows Server 2003
Windows Server 2008

Fasi del ciclo di vita del supporto

La politica “Microsoft Support Lifecycle” fornisce indicazioni coerenti e precise sulla disponibilità del supporto per i singoli prodotti al momento del rilascio.
Entrata in vigore il 15 ottobre 2002, questa politica si applica alla maggior parte dei prodotti attualmente disponibili tramite i canali Retail o Volume Licensing, oltre che alle versioni future.
A partire dal 1 giugno 2004 è stato applicato un nuovo approccio al ciclo di vita del supporto, come illustrato nella seguente immagine:

L’immagine seguente illustra il tipo di supporto fornito in base alle 2 fasi del ciclo di vita:

Supporto Mainstream

Mainstream Support è la prima fase del ciclo di di vita del supporto di un prodotto.

Per la politica di supporto dei service pack, il supporto Mainstream include:

Richiesta di supporto (Richiesta di supporto gratuita, richiesta di supporto a pagamento, supporto a pagamento orario, supporto in garanzia)
Supporto per gli aggiornamenti di protezione
Possibilità di richiedere hotfix non di protezione

Supporto Extended

Il supporto Extended segue la fase di supporto Mainstream per i prodotti business e di sviluppo.

Per la politica di supporto dei service pack, il supporto Extended include:

Supporto a pagamento
Aggiornamenti di protezione gratuiti
Hotfix non relative alla protezione richiedono un contratto "Extended Hotfix" a pagamento (verrà applicato un costo per ogni fix)

Nota:

Microsoft non accetterà richieste di supporto in garanzia, modifiche del prodotto o nuove funzioni durante la fase di supporto Extended
Supporto Extended non è disponibile per i prodotti Consumer, Hardware, Multimedia e Microsoft Dynamics products

Politica per il supporto dei Service Pack

I service pack sono cumulativi, ovvero ogni nuovo service pack contiene tutte le correzioni incluse nei precedenti, oltre a nuovi hotfix.
In questo modo gli utenti non devono installare una versione precedente di un service pack prima di procedere all'installazione di quella più aggiornata. Un Security Rollup Package (SRP) offre un rollup cumulativo di aggiornamenti della protezione disponibili dall'ultimo SRP.

Quando è rilasciato un nuovo service pack, Microsoft offre 12 mesi di supporto per la versione precedente. Il supporto può essere esteso a 24 mesi per quei service pack per il cui testing e deployment Microsoft ritiene che i clienti possano aver bisogno di altro tempo.

Microsoft annuncerà l'estensione del supporto per un service pack precedente al momento del rilascio della versione aggiornata.

Quando il supporto per un prodotto è ritirato, non viene più fornito supporto per i relativi service pack. La politica Support Lifecycle ha la priorità su quella per il supporto dei service pack.

Windows 2000 Server

Di seguito è riportata un’immagine che illustra le principali date del supporto a Windows 2000 Server:

Ad oggi abbiamo:

Supporto Mainstream = terminato il 31 Marzo 2005
Supporto Extended = finirà il 13 Luglio 2010

Il Sistema Operativo per poter ricevere supporto necessità obbligatoriamente l’installazione del Service Pack 4 e richiede l’acquisto dell’estensione.

Maggiori informazioni riguardo al supporto di Windows 2000 Server e Windows 2000 Advanced Server.

Windows Server 2003 e R2

Di seguito è riportata un’immagine che illustra le principali date del supporto a Windows Server 2003:

Ad oggi abbiamo:

Supporto Mainstream = finirà il 13 Luglio 2010
Supporto Extended = finirà il 14 Luglio 2015

Il supporto specifico per i Service Pack:

Service Pack 0 = terminato il 10 Aprile 2007
Service Pack 1 = terminato il 14 Aprile 2009
Service Pack 2 = fino al termine del Supporto Mainstream

Il Sistema Operativo per poter ricevere supporto necessità obbligatoriamente l’installazione Da notare che è necessario installare il Service Pack 2 per poter ottenere supporto, in quanto SP1 non è più supportato.

Maggiori informazioni riguardo al supporto di Windows Server 2003 e di Windows Server 2003 R2.

Windows Server 2008

Di seguito è riportata un’immagine che illustra le principali date del supporto a Windows Server 2008:

Ad oggi abbiamo:

Supporto Mainstream = finirà il 9 Luglio 2013
Supporto Extended = finirà il 10 Luglio 2018

Il supporto specifico per i Service Pack:

Service Pack 1 = fino al 29 Aprile 2011 (integrato nella versione RTM dell’OS)
Service Pack 2 = fino al termine del Supporto Mainstream

Maggiori informazioni riguardo al supporto di Windows Server 2008.

Maggiori informazioni sono disponibili

Marco Pulita
Microsoft Enterprise Platform Support

Restricted Group - Problemi con l’applicazione delle Group Policy

itentblg — Mon, 27 Apr 2009 02:00:00 GMT

In questo post approfondiremo i possibili problemi che si possono verificare nell’applicazione dei Restricted Group tramite Group Policy.

Problema

Quando si presenta il problema durante il boot la configurazione del Restricted Group non è applicata completamente ed è creato un evento SceCli 1001:

Event ID     : 1001
Category     : None
Source       : SceCli
Type         : Error
Generated    : 11/10/2008 5:27:44 AM
Written      : 11/10/2008 5:27:44 AM
Machine      : W010010312
Message      : Security policy cannot be propagated. Impossibile eliminare la cache dei criteri di gruppo.

Considerando come funziona l’applicazione dei Restricted Group, leggi il precedente post, ho ipotizzato che il problema fosse causato da un lock sul file tmpgptfl.inf. Per avere una conferma alla mia ipotesi ho abilitato l’audit sui tutti i file e cartelle sotto la cartella C:\Windows\Security\Templates avendo una conferma alla mia idea. Infatti l’evento 560 mostra che il processo con PID 2972 “tocca” il file tenendolo “bloccato”.

Event ID     : 560
Source       : Security
Type         : Audit Success
Generated    : 11/10/2008 5:27:44 AM
Written      : 11/10/2008 5:27:44 AM
Machine      : MBXP
Message      : Object Open:
   Object Server:   Security
   Object Type:   File
   Object Name:   C:\WINNT\security\templates\policies\tmpgptfl.inf
   Handle ID:   -2147478420
   Operation ID:   {0,207111}
   Process ID:   2972
   Image File Name:
   Primary User Name:   MBXP$
   Primary Domain:   DISNEY
   Primary Logon ID:   (0x0,0x3E7)
   Client User Name:   -
   Client Domain:   -
   Client Logon ID:   -
   Accesses:   %%4416
                     %%4423
Privileges:   -
   Restricted Sid Count:   0
   Access Mask:   Security8

Il PID è elevato (2972) e non è sicuramente quello del processo Winlogon. Aprendo task manager scopro che il processo con il PID 2972 è ALG.exe ovvero Application Layer Gateway Service. Questo processo non dovrebbe andare a leggere questi file e quindi è inspiegabile come mai questi file siano letti e soprattutto messi in lock rendendoli illeggibili dal processo Winlogon per l’applicazione delle policy.

Con process monitor, configurandolo per collezionare i dati durante il boot, il sistema ha tracciato l’accesso ai file sotto la cartella “C:\WINNT\security\templates\policies”.

Il log di Process Monitor mostra che il processo ALG.exe accede ad un notevole numero di file e cartelle. Tra le cartelle che sono aperte dal processo ALG.exe c’è anche la cartella C:\WINNT\SECURITY\TEMPLATES\POLICIES e tutti i file contenuti in essa e quindi anche il file TMPGPTFL.INF.

Qui sotto la sequenza del process monitor log:

13:34:41.1974394 alg.exe 3384 QueryDirectory C:\WINNT\security SUCCESS 0: ., 1: .., 2: Database, 3: logs, 4: templates...
13:34:41.2118214 alg.exe 3384 CreateFile C:\WINNT\security\TEMPLATES SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened...
13:34:41.2317561 alg.exe 3384 CreateFile C:\WINNT\security\templates\policies SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
13:34:41.2379169 alg.exe 3384 QueryDirectory C:\WINNT\security\templates\policies SUCCESS 0: ., 1: .., 2: gpt00000.dom, 3: gpt00001.inf, 4: gpt00002.inf, 5: tmpgptfl.inf
13:34:41.2380052 alg.exe 3384 QueryDirectory C:\WINNT\security\templates\policies NO MORE FILES
13:34:41.2380490 alg.exe 3384 CloseFile C:\WINNT\security\templates\policies SUCCESS
13:34:42.6791166 alg.exe 3384 CreateFile C:\WINNT\security\templates\policies\tmpgptfl.inf SUCCESS Desired Access: Read Data/List Directory, Read Attributes, Disposition: Open, Options: Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
13:34:42.6817174 alg.exe 3384 QueryStandardInformationFile C:\WINNT\security\templates\policies\tmpgptfl.inf SUCCESS AllocationSize: 144, EndOfFile: 142, NumberOfLinks: 1, DeletePending: False, Directory: False
13:34:42.7097160 alg.exe 3384 CreateFile C:\WINNT\security\templates\policies\gpt00000.dom SUCCESS Desired Access: Read Data/List Directory, Read Attributes, Disposition: Open, Options: Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
13:34:42.7177564 alg.exe 3384 QueryStandardInformationFile C:\WINNT\security\templates\policies\gpt00000.dom SUCCESS AllocationSize: 2,048, EndOfFile: 1,822, NumberOfLinks: 1, DeletePending: False, Directory: False
13:34:42.7609479 alg.exe 3384 CreateFile C:\WINNT\security\templates\policies\gpt00001.inf SUCCESS Desired Access: Read Data/List Directory, Read Attributes, Disposition: Open, Options: Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
13:34:42.7613351 alg.exe 3384 QueryStandardInformationFile C:\WINNT\security\templates\policies\gpt00001.inf SUCCESS AllocationSize: 5,120, EndOfFile: 4,638, NumberOfLinks: 1, DeletePending: False, Directory: False
13:34:42.7811776 alg.exe 3384 CreateFile C:\WINNT\security\templates\policies\gpt00002.inf SUCCESS Desired Access: Read Data/List Directory, Read Attributes, Disposition: Open, Options: Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
13:34:42.7953439 alg.exe 3384 QueryStandardInformationFile C:\WINNT\security\templates\policies\gpt00002.inf SUCCESS AllocationSize: 1,536, EndOfFile: 1,282, NumberOfLinks: 1, DeletePending: False, Directory: False
13:34:44.6352280 alg.exe 3384 CloseFile C:\WINNT\security\templates\policies\tmpgptfl.inf SUCCESS
13:34:44.6376565 alg.exe 3384 CloseFile C:\WINNT\security\templates\policies\gpt00000.dom SUCCESS
13:34:44.6379161 alg.exe 3384 CloseFile C:\WINNT\security\templates\policies\gpt00001.inf SUCCESS
13:34:44.6381773 alg.exe 3384 CloseFile C:\WINNT\security\templates\policies\gpt00002.inf SUCCESS

Ho preso il call stack da process monitor per la createfile del processo ALG.exe sul file TMPGPTFL.INF . Qui sotto il call stack preso da process monitor:

13:34:40.5168152 alg.exe 3384 CreateFile C:\ SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
-----------------------------------------------------------------------------------------------------
0 fltMgr.sys   fltMgr.sys + 0x1944     0xf84b1944 C:\WINNT\System32\Drivers\fltMgr.sys
1 fltMgr.sys   fltMgr.sys + 0x3352     0xf84b3352 C:\WINNT\System32\Drivers\fltMgr.sys
2 fltMgr.sys   fltMgr.sys + 0xfccb     0xf84bfccb C:\WINNT\System32\Drivers\fltMgr.sys
3 fltMgr.sys   fltMgr.sys + 0x10142    0xf84c0142 C:\WINNT\System32\Drivers\fltMgr.sys
4 ntkrnlpa.exe ntkrnlpa.exe + 0x17003 0x804ee003 C:\WINNT\system32\ntkrnlpa.exe
5 ntkrnlpa.exe ntkrnlpa.exe + 0x17003 0x804ee003 C:\WINNT\system32\ntkrnlpa.exe
6 ntkrnlpa.exe ntkrnlpa.exe + 0xdc996 0x805b3996 C:\WINNT\system32\ntkrnlpa.exe
7 ntkrnlpa.exe ntkrnlpa.exe + 0xd8e77 0x805afe77 C:\WINNT\system32\ntkrnlpa.exe
8 ntkrnlpa.exe ntkrnlpa.exe + 0x93431 0x8056a431 C:\WINNT\system32\ntkrnlpa.exe
9 ntkrnlpa.exe ntkrnlpa.exe + 0x93da8 0x8056ada8 C:\WINNT\system32\ntkrnlpa.exe
10 ntkrnlpa.exe ntkrnlpa.exe + 0x9647a 0x8056d47a C:\WINNT\system32\ntkrnlpa.exe
11 ntkrnlpa.exe ntkrnlpa.exe + 0x65a48 0x8053ca48 C:\WINNT\system32\ntkrnlpa.exe
12 ntkrnlpa.exe ntkrnlpa.exe + 0x26755 0x804fd755 C:\WINNT\system32\ntkrnlpa.exe
13 ntkrnlpa.exe ntkrnlpa.exe + 0x13e1cc 0x806151cc C:\WINNT\system32\ntkrnlpa.exe
14 ntkrnlpa.exe ntkrnlpa.exe + 0x13eb9d 0x80615b9d C:\WINNT\system32\ntkrnlpa.exe
15 ntkrnlpa.exe ntkrnlpa.exe + 0x13efd4 0x80615fd4 C:\WINNT\system32\ntkrnlpa.exe
16 ntkrnlpa.exe ntkrnlpa.exe + 0xedca7 0x805c4ca7 C:\WINNT\system32\ntkrnlpa.exe
17 ntkrnlpa.exe ntkrnlpa.exe + 0x6a1e2 0x805411e2 C:\WINNT\system32\ntkrnlpa.exe

Process Monitor, non avendo configurato i simboli, non mostra il call stack decodificato, procedendo alla decodifica degli indirizzi che vediamo sul call stack,tramite i simboli di debugging, ho ottenuto quanto segue:

1:34:41.2317561 PM alg.exe 3384       CreateFile            C:\WINNT\security\templates\policies   SUCCESS              Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
-----------------------------------------------------------------------------------------------------
0 fltMgr.sys   fltMgr!FltpPerformPreCallbacks+0x2d4 0xf84b1944 C:\WINNT\System32\Drivers\fltMgr.sys
1 fltMgr.sys   fltMgr!FltpPassThroughInternal+0x32 0xf84b3352 C:\WINNT\System32\Drivers\fltMgr.sys
2 fltMgr.sys   fltMgr!FltpPassThrough+0x1df         0xf84b3c15 C:\WINNT\System32\Drivers\fltMgr.sys
3 fltMgr.sys   fltMgr!FltpDispatch+0xf3             0xf84b3ffb C:\WINNT\System32\Drivers\fltMgr.sys
4 ntkrnlpa.exe nt!IopfCallDriver+0x31               0x804ee003 C:\WINNT\system32\ntkrnlpa.exe
5 ntkrnlpa.exe nt!IopfCallDriver+0x31               0x804ee003 C:\WINNT\system32\ntkrnlpa.exe
6 ntkrnlpa.exe nt!NtQueryDirectoryFile+0x5d         0x8056e29f C:\WINNT\system32\ntkrnlpa.exe
7 ntkrnlpa.exe nt!KiFastCallEntry+0xf8              0x8053ca48 C:\WINNT\system32\ntkrnlpa.exe
8 ntkrnlpa.exe nt!ZwQueryDirectoryObject            0x804fdfc5 C:\WINNT\system32\ntkrnlpa.exe
9 ntkrnlpa.exe nt!CcPfPrefetchMetadata+0x76         0x806151cc C:\WINNT\system32\ntkrnlpa.exe
10 ntkrnlpa.exe nt!CcPfPrefetchScenario+0x6d         0x80615b9d C:\WINNT\system32\ntkrnlpa.exe
11 ntkrnlpa.exe nt!CcPfBeginAppLaunch+0x158          0x80615fd4 C:\WINNT\system32\ntkrnlpa.exe
12 ntkrnlpa.exe nt!PspUserThreadStartup+0xeb         0x805c4ca7 C:\WINNT\system32\ntkrnlpa.exe
13 ntkrnlpa.exe nt!KiThreadStartup+0x16              0x805411e2 C:\WINNT\system32\ntkrnlpa.exe

Analizzando le funzioni riportare sopra si identifica che il sistema di prefetching ha generato la scansione dei file e delle cartelle. Quando il processo ALG parte e crea il primo thread è eseguito in kernel mode il codice che esegue il prefetching.

Riporto il log che mostra questa sequenza:

13:34:40.1881511 alg.exe 3384 Process Start SUCCESS Parent PID: 1100
13:34:40.1966276 alg.exe 3384 Load Image C:\WINNT\system32\alg.exe SUCCESS Image Base: 0x1000000, Image Size: 0xd000
13:34:40.1967013 alg.exe 3384 Load Image C:\WINNT\System32\ntdll.dll SUCCESS Image Base: 0x7c910000, Image Size: 0xb6000
13:34:40.2724867 alg.exe 3384 CreateFile C:\WINNT\Prefetch\ALG.EXE-231187DC.pf SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: None, AllocationSize: n/a, OpenResult: Opened
13:34:40.2725487 alg.exe 3384 QueryStandardInformationFile C:\WINNT\Prefetch\ALG.EXE-231187DC.pf SUCCESS AllocationSize: 54,784, EndOfFile: 54,568, NumberOfLinks: 1, DeletePending: False, Directory: False
13:34:40.2725791 alg.exe 3384 ReadFile C:\WINNT\Prefetch\ALG.EXE-231187DC.pf SUCCESS Offset: 0, Length: 54,568
13:34:40.2728658 alg.exe 3384 CloseFile C:\WINNT\Prefetch\ALG.EXE-231187DC.pf SUCCESS
13:34:40.5168152 alg.exe 3384 CreateFile C:\ SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened

Come potete vedere nel log il processo ALG.exe legge il file alg.exe.<hashcode>.pf per determinare quali cartelle e file caricarsi in memoria durante il prefetching. In questo caso specifico ho riscontrato una dimensione notevole del file alg.exe.<hashcode>.pf (54K) che rivela come il file contenga notevoli cartelle e file da caricare e sicuramente anche il path C:\WINNT\SECURITY\TEMPLATES\POLICIES.

Per comprendere come mai il file alg.exe.<hashcode>.pf contenga cosi tante cartelle e file ho effettuato un test notando che eseguendo un processo qualsiasi, nel nostro caso la calcolatrice, durante la scansione dell’Antivirus, il file Calc.exe.<hashcode>.pg generato è di 60k mentre normalmente è di 10-15k.

Causa

Durante l’aggiornamento del file alg.exe.<hashcode>.pf, l’antivirus o qualsiasi altra applicazione esegue la scansione del sistema accedendo tutti i file e generando un file *.pf di grosse dimensione. Quando il servizio ALG.exe è avviato leggerà, durante il prefetching, il file alg.exe.<hashcode>.pf che contiene tutti i file e cartelle di sistema e anche il file C:\WINNT\security\templates\policies\tmpgptfl.inf

Soluzione

Individuare il software che fa la scansione di tutti i file anche se molto probabilmente si tratta dell’Antivirus. Configurare questa applicazione per non accedere ai file sotto C:\WINNT\SECURITY\TEMPLATES\POLICIES. Nel nostro caso troviamo prima dell’evento 1001 un evento generato dal processo ntrtscan.exe (Trend Micro OfficeScan Real-time Scan Service) che conferma che la causa è l’antivirus.

Description:         Trend Micro OfficeScan Real-time Scan Service (32-bit)
Company:             Trend Micro Inc.
Name:   ntrtscan.exe
Version: 8.00.0000.1189
Path:       C:\Programmi\Trend Micro\OfficeScan Client\ntrtscan.exe
Command Line: "C:\Programmi\Trend Micro\OfficeScan Client\ntrtscan.exe"
PID:        800
Parent PID:           1100
Session ID:           0
User:      NT AUTHORITY\SYSTEM
Auth ID: 00000000:000003e7
Architecture:         32-bit
Virtualized:            n/a
Integrity: n/a
Started: 12/16/2008 1:33:57 PM
Ended:   (Running)
Modules:
NTRtScan.exe     0x400000             0xd8000                C:\Programmi\Trend Micro\OfficeScan Client\NTRtScan.exe
Date & Time:        12/16/2008 1:34:42 PM
Event Class:        Registry
Operation:            RegSetValue
Result: SUCCESS
Path:      HKLM\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion\Misc.\LastScannedFileName
TID:        868
Duration:              0.0000277
Type:      REG_SZ
Length: 101
Data:      C:\WINNT\SECURITY\TEMPLATES\POLICIES\TMPGPTFL.INF

L’evento sopra mostra che l’antivirus verifica i file TMPGPTFL.INF infatti il servizio ha impostato la chiave LastScannedFileName con il valore C:\WINNT\SECURITY\TEMPLATES\POLICIES\TMPGPTFL.INF.

Per verificare velocemente se siete in questa condizione potete provare a disabilitare il prefetching in modo da evitare il comportamento descritto sopra.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters
Name: EnablePrefetcher
Type: REG_DWORD
Value: 0

The EnablePrefetcher key has the following values:

0 = Disabled
1 = Application launch prefetching enabled
2 = Boot prefetching enabled
3 = Application launch and boot enabled

To disable Prefetch, set the value to 0.

Se il problema si risolve con il prefetching disabilitato avete una conferma alla analisi.

In caso affermativo dovrete lavorare con il supporto dell’Applicativo per configurare e applicare l’exclusion dell’antivirus per la cartella C:\WINNT\SECURITY\TEMPLATES\POLICIES

Matteo Belloni
Support Escalation Engineer
Microsoft Enterprise Platform Support