Supporto Tecnico Enterprise

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

SQL Server - Algoritmo Proportional fill, Autogrow e loro effetto sulle dimensioni dei file di un filegroup

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

Algoritmo di Proportional fill

L'algoritmo di Proportional fill (Proportional fill and how to check whether it works, Using Files and Filegroups) è l'algoritmo utilizzato per allocare extent (Understanding Pages and Extents) all'interno dei datafile di un filegroup (Files and Filegroups Architecture) che contiene da due a più datafile.

Sql server alloca un quantità di extent , proporzionale allo spazio libero all'interno di ciascun datafile di un filegroup, mantenendo in questo modo la stessa percentuale di spazio utilizzato su ciascun file.

Il calcolo della proporzione da utilizzare per allocare lo spazio nei file viene effettuato con le seguenti modalità:

la percentuale di Proportional fill viene ricalcolata dopo aver allocato 8192 extent
il numero degli extent liberi del file con più spazio libero, viene diviso per il numero degli extent liberi degli altri file
il rapporto considera solo numeri interi

Tramite l'utilizzo dell'algoritmo del Proportional fill , i file all'interno di un filegroup si riempono contemporaneamente.

Nel caso di datafile con uguali dimensioni iniziali, dovremmo aspettarci un uguale utilizzo dello spazio su tali file man mano che il database cresce di dimensione.

L'algoritmo di Proportional fill considera solo interi, per cui si possono determinare uguali allocazioni anche con diverso spazio libero tra i file , ad esempio quando il rapporto tra lo spazio libero tra i file non è esattamente di 1 a 2 .
Avendo, all'interno di un filegroup, un datafile con 10 Gb di spazio libero e un datafile con 19,9 Gb di spazio libero , il rapporto tra lo spazio libero dei due datafile non è esattamente di 1 a 2, per cui il tasso di allocazione sui datafile sarà identico. In questa situazione, lo spazio verrà allocato nella stessa percentuale anche in file aventi una diversa quantità di spazio libero, con conseguente sbilanciamento dello spazio occupato tra di essi.

Siccome l'algoritmo è ricalcolato frequentemente, gli errori dovuti al considerare solo numeri interi, dovrebbero bilanciarsi, arrivando generalmente a situazioni in cui tutti i file hanno la stessa percentuale di spazio utilizzato e arrivano in contemporanea ad occupare tutto lo spazio libero.

Autogrow

Le impostazioni di autogrow dei file di un database controllano il comportamento di tali file nel momento in cui raggiungono la loro massima dimensione Database Properties (Files Page)

Ho spesso affrontato problemi di performance causati da una crescita per autogrow dei datafile o log file di un database. Il consiglio per evitare che l’autogrow venga scatenato durante l’attività sul database, causando problemi di performance, è di controllare periodicamente che ogni file abbia necessario spazio libero all'interno. In tal modo, lo spazio verrà allocato internamente al file e si eviterà la necessità di crescita automatica a causa del raggiungimento della massima dimensione.

L’autogrow dovrebbe essere utilizzato solo per evitare problemi causati da crescite inaspettate e non pianificate del database e non come sostituto di un’opportuna analisi sull’andamento delle dimensioni del database.

Attenzione è anche da riservare alla percentuale impostata di autogrow.

Consideriamo un database che ha raggiunto la dimensione massima e su cui l’applicazione tenta di inserite dati. All’inserimento di dati, siccome non è più presente spazio libero, l’autogrow viene attivato.

Se l’autogrow è impostato al 10% delle dimensioni del database e il database è di circa 30 GB, l’autogrow tenterà di aumentare le dimensioni del database di 3 GB. Tale espansione potrà richiedere molto tempo e terminare prima del timeout applicativo , determinando il fallimento dell’operazione di insert con un generico errore di timeout.

Di seguito alcuni articoli relativi alle considerazioni sulle impostazioni di autogrow

L'autogrow oltre a causare problemi di performance , può indirettamente causare uno sbilanciamento tra le dimensioni dei datafile di uno stesso filegroup, sebbene tali file siano stati impostati inizialmente alla stessa dimensione e con identiche configurazioni di autogrow.

Di seguito la spiegazione di come ciò possa avvenire

Autogrow e sbilanciamento dello spazio allocato tra i file di un filegroup nonostante il funzionamento del Proportional Fill

Sql server, allo startup, crea una lista dei datafile disponibili e calcola la percentuale di Proportional fill come sopra specificato.

Dopo il verificarsi di un autogrow, Sql server conserva in memoria l'informazione di quale file nella lista sopra indicata è aumentato di dimensione per autogrow.

In caso di mancanza di spazio su un database, il file successivo viene preso in considerazione per eventuali allocazioni.

Al restart di Sql server, l'informazione relativa al file che ha subito l'autogrow, non viene mantenuta, per cui il primo file della lista viene nuovamente preso in considerazione in casi di mancanza di spazio , anche se l'autogrow si è appena verificato su di esso.

A causa di questo meccanismo può capitare che nonostante il Proportional fill, uno dei file di un filegroup , possa raggiungere dimensioni maggiori rispetto agli altri sebbene le configurazioni iniziali siano state identiche.

Soluzione

Al fine di evitare lo sbilanciamento delle dimensioni di file configurati inizialmente con le stesse dimensioni all'interno di un filegroup si suggerisce di :

aumentare manualmente e contemporaneamente la dimensione dei file di un filegroup
verificare lo spazio libero all'interno dei file e aumentarli prima che si verifichi l'autogrow
Per Sql server 2005, la seguente select , mostra lo spazio libero e allocato all'interno dei file

select
dbfiles.file_id,
[FILE_SIZE_MB] =
convert(decimal(12,2),round(dbfiles.size/128.000,2)),
[SPACE_USED_MB] =
convert(decimal(12,2),round(fileproperty(dbfiles.name,'SpaceUsed')/128.000,2)),
[FREE_SPACE_MB] =
convert(decimal(12,2),round((dbfiles.size-fileproperty(dbfiles.name,'SpaceUsed'))/128.000,2)) ,
NAME = left(dbfiles.NAME,15),
FILENAME = left(dbfiles.physical_name,30)
from
sys.database_files dbfiles
In Sql server 2008, è possibile utilizzare il trace flag -T1117 per attivare l' autogrow di tutti i file di un filegroup contemporaneamente, garantendo in questo modo che tutti i file rimangano alla stessa dimensione

Raffaella Canobbio
Senior Support Escalation Engineer
Microsoft Enterprise SQL 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

Exchange 2003 - Troubleshooting delle code e consegna dei messaggi

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

Una delle richieste che ci viene fatta più spesso è il troubleshooting dei messaggi che non vengono consegnati ai destinatari.

Questa tipologia di problematiche ha 3 ambiti:

Il messaggio non arriva da internet verso la nostra infrastruttura
Il messaggio raggiunge la nostra infrastruttura ma non viene consegnato alla casella di posta
Il messaggio non esce dall’infrastruttura

Vediamo insieme come comportarci nei vari casi.

Il messaggio non arriva da internet verso la nostra infrastruttura

In questo caso il 90% dei problemi è dovuto a problemi di rete. Se non vedete le mail arrivare al vostro server di Front-end o al vostro Edge, controllate le seguenti cose:

Verificate con IntroDNS il vostro MX record “intoDNS: checks DNS and mail servers health http://www.intodns.com/”
Ottenuto il record mx (ogni tanto c’è qualche confusione su chi prende le email per chi :) ) si parte con i tests:

E’ necessario capire se il record punta direttamente alla vostra infrastruttura Exchange, o se c’è uno smarthost che prende le email per voi.

Digitate da Command Prompt:
telnet mx_record 25 [invio]
Dovreste ottenere il banner del server smtp che accetta la connessione
Inviate un’email di prova con la seguente sequenza di comandi:
helo test
mail from:utente@dominio.com
rcpt to:utente@dominio.com
data
subject:test email
test email

Se il server è il vostro Exchange, e vi viene restituito un codice di errore (e la descrizione di cosa succede non è chiara) cercate su http://support.microsoft.com il codice ottenuto.

Se il server non è il vostro Exchange, e vi viene restituito un codice di errore che non sia esplicativo, è necessario contattare il gestore del servizio, o il produttore dell’appliance (nel caso utilizzaste dei moduli hw\sw antispam)

Nel caso di un appliance o software\servizio di terze parti, si possono prendere 2 strade:

Collegarsi sull’appliance\server-servizio e verificare se ci sono dei diagnostic loggings che indicano in che stato è il messaggio
Verificare sui logs smtp del server di Front-end\Edge se ci sono delle sessioni smtp in ingresso dall’appliance\server-servizio (vedi http://blogs.technet.com/itasupport/archive/2008/10/10/smtp-analisi-del-protocol-logging.aspx per come abilitare\analizzare il log smtp) (per il server edge, è necessario abilitare il logging dalle proprietà del receive connector –> verbose logging)
L’apppliance deve in ogni caso comunicare con il server front-end\edge tramite una sessione SMTP, quindi si può provare a ripetere il tests della sessione telnet, questa volta dal server Exchange verso l’appliance\server-servizio e viceversa (ove possibile) per verificare eventuali problemi con apparati di rete.

Nel caso in cui il record MX sia il server Exchange:

Aprire l’Exchange System Manger e posizionarsi sul server –> Queue (Ex 2003) o il Queue Viewer (Ex 2007\2010). Se il messaggio è stato ricevuto, lo troveremo in una di queste code.
Se il messaggio non è presente nelle code, utilizzare il Message tracking per verificare se il messaggio è stato stato inviato ad un altro server o se sia stato generato un Non Delivery Report.
Utilizzate il log del protocollo SMTP per verificare la corretta sequenza di ricezione del messaggio.

Il messaggio raggiunge la nostra infrastruttura o è già nell’infrastuttura stessa ma non viene consegnato alla casella di posta

Dal punto precedente è necessario a quindi capire su quale server il messaggio è fermo. Una volta individuato il server con il message tracking, è necessario controllare le code di Exchange sul server incriminato per capire lo stato del messaggio:

Se il messaggio è pendente nella coda Awaiting Directory lookup

Indagare\verificare la connettività con l’infrastruttura Active Directory (connettività di rete verso i domain controller e global catalog (porte tcp 389 e 3268)
Verificare che i domain controllers e global catalogs non abbiamo problemi di performances

Aumentare il diagnostic logging del server per il componente Categorizer (proprietà del server –> diagnostic logging –> MsExchangeTransport Ex 2003 o Manager Diagnostic logging –> MsExchangeTransport –> categorizer Ex2007Sp2) a Maximum e verificare nell’application log eventuali avvisi\errori.

Se il messaggio è pendente nella coda Remote delivery

verificare la connettività di rete con il server\connettore riportato nel nome della coda (verificare anche la risoluzione nomi dns)

Se il messaggio è pendente nella coda Failed Message retry

il messaggio potrebbe essere corrotto o sono installati event sync di terze parti che possono interferire con la consegna del messaggio (antivirus o antispam). Provare a disabilitarli.

Se il messaggio non compare nelle code

Usare il message tracking per determinare a che punto del message flowing il messaggio è sparito. Se l’ultimo evento è la categorizzazione del messaggio, potrebbero essere coinvolti Event Sync di terze parti, come al punto precedente (gli Event Sync si agganciano alla fase di PostCategorize del messaggio).

From:Exchange Message Flow
http://technet.microsoft.com/en-us/library/bb123864(EXCHG.65).aspx

In generale in questo caso potete utilizzare i seguenti articoli per il troubleshooting delle code di Exchange:

Troubleshooting Mail Flow and SMTP
http://technet.microsoft.com/en-us/library/aa996805(EXCHG.65).aspx
Managing Queues
http://technet.microsoft.com/en-us/library/bb125022.aspx

E’ interessante notare che uno dei problemi che si presenta maggiormente è l’accodamento dei messaggi sul server di Back End, in particolare nelle code: Local Delivery e Awaiting directory lookup.

In questo caso ci sono 3 grandi famiglie di problematiche:

Performance del server: In particolare il systema dischi, in questo caso è necessario verificare i contatori logical discs –> average read\sec e average write\sec. Entrambi devono essere sotto i 0.02s
Antivirus: Se gli scanning threads sono pochi o i controlli vanno per le lunghe, si può generare il problema.Un dump del processo store.exe in genere rileva la problematica.
Varie: Qui si raccolgono alcuni problemi, anche relativi a Store event Syncs, che possono essere analizzati tramite la verifica di un dump del processo Store.exe

Performance del server

Per i problemi di performance utilizziamo il seguente articolo come base di partenza:

Troubleshooting Microsoft Exchange Server Performance
http://technet.microsoft.com/en-us/library/aa997270(EXCHG.65).aspx

Prendiamo ad esempio la parte relativa ai dischi. Vi riporto un esempio reale:

In questo caso vi era l’accodamento dei messaggi nella Local Delivery queue.

Come potete osservare il valore delle letture per buona parte dei dichi è scarso, in quanto è superiore ai 20ms(0.02s), mentre il valore delle scritture è assolutamente intollerabile da parte del sistema in quanto è praticamente sempre oltre gli 50ms(0.05s). Al superamento della soglia dei 20ms comincerete ad avere degli accodamenti sporadici di emails, a seconda del traffico e del message rate sperimentato.

Oltre i 50ms le code cominceranno a crescere fintanto che il problema sui dischi non sarà risolto. Considerate la vostra infrastruttura dischi come la colonna portante del vostro server Exchange. In questo caso la problematica era dovuta ad un alimentatore rotto sulla SAN!!!

Antivirus e varie

Se sospettate un problema con l’antivirus o uno Store Sync (la modalità di gestione dei sync, è sincrona (da non confondere sincrona con sync, in quanto la voce “sync” indica l’oggetto che si aggancia ad una funzione specifica e viene attivato solo nel caso specifico), ciò significa che nel processo vengono generati un certo numero di threads, detti Worker Threads che si occupano di eseguire la funzioni specifiche. La dll del sync object passerà la chiamata al worker thread libero e aspetterà la restituzione del controllo, prima di far continuare il processo padre.

Detto in temini semplici: se il processo dello store.exe ha 100 email da processare e l’antivirus ha 3 threads, ciò singnifica che verrano processate parallelamente 3 email per volta. Il primo thread che finisce, viene marcato come libero e può processare la mail successiva nella coda dello store.exe. Se per qualche ragione tutti e 3 i processi dell’antivirus si bloccano, da un dump in hang mode del processo store.exe, avrete un sacco di threads in questo stato:

ChildEBP RetAddr
4a7bf2d4 7c59a0a2 NTDLL!NtWaitForSingleObject+0xb
4a7bf2fc 7c57b40f KERNEL32!WaitForSingleObjectEx+0x71
4a7bf30c 00648dd6 KERNEL32!WaitForSingleObject+0xf
4a7bf394 00426a4f store!EcCheckVirusScanStamp+0x687 <---- in questo momento viene passato la chiamata all’antivirus e il thread di elaborazione della mail resta in attesa del completamento.

4a7bf3c4 00415d4d store!OMSG::EcCheckVirusScanStatus+0x130

Se vi ritrovate con un centinaio di thread in questo stato, allora il problema è esattamente li! :)

Nel caso di Syncs che non siano l’antivirus, nello stack trovere, nei primi frames di molti threads il riferimento alle funzioni chiamate. (ps. un analisi di questo tipo prevede di verificare lo stato del processo ad alcuni minuti di distanza, non è sufficiente una sola cattura del dump dump di processo in hang mode).

Il messaggio non esce dall’infrastruttura

In questo caso è necessario verificare dove il messaggio si blocca e avere ben presente l’infrastruttura di routing configurata (send connectors e smtp connectors).

Prima cosa verificare sempre se i messaggi raggiungo il server che fà da bridgehead per i connettori, e testare la connettività verso quel server (telnet alla porta 25).

Se il messaggio è fermo sul bridgehead server, verificare il log del protocollo smtp per eventuali errori, provare a fare a fare un telnet verso lo smart host configurato sul connettore smtp, o verso il record mx di un dominio esterno (se utilizzate la risoluzione dns).

Utilizzate un tool di cattura del traffico di rete (network monitor o equivalente) se sospettate problemi con device di rete:

Microsoft Network Monitor 3.3
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f

Fare una cattura utilizzando il filtro “.protocol.smtp” se volete verificare la sessione smtp

Verificate sempre se la problematica è simmetrica (ovvero otre a non uscire, la posta non entra).

Verificate con il message tracking, in quale parte della delivery il messaggio si blocca (per esempio advanced queue o mta transfer).

Riepilogo

La guida presentata vuole essere semplicemente uno scheletro generico che può essere utilizzato per indirizzare il troubleshoting della problematica. Le modalità di approccio al problema possono essere varie e dipendono molto dall’esperienza passata di chi esegue il troubleshooting.

Francesco Poli
Support Escalation Engineer
Microsoft Enterprise Exchange 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

Exchange 2007 – Supportabilità in base Sistema Operativo e Active Directory

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

Dopo l’uscita del Service Pack 2 di Exchange Server 2007, è stato rilasciato il seguente articolo relativo alla supportabilità del prodotto:

Exchange Server Supportability Matrix: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee338574.aspx

L'articolo fa riferimento a diverse configurazioni riguardo a: Active Directory, Sistema Operativo, Clients, .Net Framework, etc.

Questo post ha l'intento di evidenziare alcune informazioni importanti:

Exchange Server 2003 non è supportato in ambiente dove il "domain/forest functional level" di Active Directory è stato alzato oltre il livello Windows Server 2003.
Comunque, Exchange Server 2003 SP2 può essere installato in ambiente dove vi siano Windows Server 2008 Active Directory Servers.
Exchange Server 2007 RTM non è supportato su Windows Server 2008 R2.
Exchange Server 2007 SP1 RU9 e SP2 sono supportati su Windows Server 2008 R2.
Exchange 2007 SP1 RU9 e SP2 sono supportati in ambienti dove il "domain/forest functional level" di Active Directory è stato alzato al livello Windows Server 2008 R2.
Exchange 2007 SP2 è supportato con PowerShell 2.0

Sistemi Operativi supportati

Operating System Platform	Exchange 2007 SP2	Exchange 2007 SP1	Exchange 2007 RTM	Exchange 2003 SP2	Exchange 2000 SP3
Windows 2000 SP4	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X	X
Windows XP Professional SP2	X*	X*	X*	X**	X**
Windows XP Professional SP3	X*	X*	X*	X**	X**
Windows Vista RTM	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X***	NOT SUPPORTED
Windows Vista SP1	X*	X*	NOT SUPPORTED	X***	NOT SUPPORTED
Windows Vista SP2	X*	X*		X***	NOT SUPPORTED
Windows Server 2003 SP2	X	X	X	X	NOT SUPPORTED
Windows Server 2003 R2 SP2	X	X	X	X	NOT SUPPORTED
Windows Server 2008	X	X	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Windows Server 2008 SP2	X	X	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED

* Solo per Exchange Management Tools

** Solo per Exchange 2000/2003 System Manager

*** Solo con Exchange 2003 System Manager per Windows Vista

Active Directory Server e Ambiente supportati

Operating System Environment	Exchange 2007 SP2	Exchange 2007 SP1	Exchange 2007 RTM	Exchange 2003 SP2	Exchange 2000 SP3
Windows 2000 Server SP4 Active Directory Servers	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X	X
Windows Server 2003 SP1 Active Directory Servers	X	X	X	X	X
Windows Server 2003 SP2 Active Directory Servers	X	X	X	X	X
Windows Server 2008 Active Directory Servers	X	X	X	X	NOT SUPPORTED
Windows Server 2008 SP2 Active Directory Servers	X	X	X	X	NOT SUPPORTED
Windows Server 2008 R2 Active Directory Servers	X	X*	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Windows Server 2008 Read Only Active Directory Servers	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Windows Server 2008 R2 Read Only Active Directory Servers	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED

Active Directory Environment	Exchange 2007 SP2	Exchange 2007 SP1	Exchange 2007 RTM	Exchange 2003 SP2	Exchange 2000 SP3
Windows 2000 Mixed Domain Functional Level	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X	X
Windows 2000 Native Functional Level	X	X	X	X	X
Windows Server 2003 Interim Domain Functional Level	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X	X
Windows Server 2003 Domain Functional Level	X	X	X	X	X
Windows Server 2008 Domain Functional Level	X	X	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Windows Server 2008 R2 Domain Functional Level	X	X*	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Windows 2000 Forest Functional Level	X	X	X	X	X
Windows Server 2003 Interim Forest Functional Level	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED	X	X
Windows Server 2003 Forest Functional Level	X	X	X	X	X
Windows Server 2008 Forest Functional Level	X	X	X	NOT SUPPORTED	NOT SUPPORTED
Windows Server 2008 R2 Forest Functional Level	X	X*	NOT SUPPORTED	NOT SUPPORTED	NOT SUPPORTED

* Necessario installare RU9 per Exchange Server 2007 SP1 disponibile al seguente indirizzo:
Description of Update Rollup 9 for Exchange Server 2007 Service Pack 1: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221166.aspx

Paulo Canuto
Senior Support Engineer
Microsoft Enterprise Exchange Support

Blog - Supporto Tecnico agli Sviluppatori

itentblg — Thu, 17 Sep 2009 02:00:00 GMT

Dopo un anno dal lancio del nostro blog “Supporto Tecnico Enterprise”, abbiamo il piacere di dare il benvenuto ai nostri colleghi del supporto allo sviluppo che hanno deciso di creare: "Supporto Tecnico agli Sviluppatori"

I nostri amici Andrea, Carlo Cardella, Carlo Colombo, Carmelo, Raffaele hanno già da tempo un blog personale in inglese, ma tramite questo nuovo blog vogliono dedicarsi in modo specifico agli sviluppatori italiani, affiancandosi e collaborando con i colleghi del team di MSDN Italia condividendo la loro enorme esperienza di troubleshooting e di sviluppo avanzato di applicazioni basate sulle tecnologie Microsoft.

Benvenuti!

Davide Felicetti

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

Exchange 2007 – Rilasciato il Service Pack 2

itentblg — Tue, 25 Aug 2009 02:00:00 GMT

È appena uscito il Service Pack 2 di Exchange Server 2007.

In questo articolo, intendo evidenziare alcune nuove funzionalità e considerazioni riguardo l’installazione o aggiornamento del Service Pack 2.

Installazione di Exchange Server 2010

Se Exchange Server 2007 (RTM o SP1) è già istallato e si vuole aggiornare ad Exchange Server 2010, o aggiungere un nuovo Exchange server 2010 nella infrastruttura, bisogna prima aggiornare Exchange Server 2007 alla SP2

Installazione di Exchange Server 2007 SP2

Per effettuare l’installazione di Exchange Server 2007 SP2, bisogna avere installato Windows Installer 4.5:
Windows Installer 4.5
http://www.microsoft.com/downloads/details.aspx?FamilyID=5a58b56f-60b6-4412-95b9-54d056d6f9f4&displaylang=en
Non è supportato installare Exchange Server 2007 SP2 su un server con Windows Server 2003 e dopo fare l’aggiornamento ad un Windows Server 2008 oppure, aggiornare il sistema operativo da Windows Server 2003 a Windows Server 2008 e successivamente aggiornare Exchange Server 2007 a SP2.
Per installare Exchange Server 2007 SP2 su un sistema operativo Windows Server 2008, bisogna prima installare il sistema operativo (senza Exchange) e dopo installare Exchange Server 2007 SP2.
Non è possibile disinstallare Service Pack 2. Per fare ciò, occorre disinstallare Exchange server e successivamente installare una versione precedente.
Nel caso in cui ci siano software di terze parti installati sul server, è necessario fermare tutti i servizi delle terze parti, prima di proseguire con l’installazione di Exchange Server 2007 SP2.

Aggiornamento a Exchange Server 2007 SP2

Tutti i ruoli del Exchange Server 2007 vengono aggiornati durante il processo di aggiornamento al Exchange Server 2007 SP2. Non è possibile aggiornare solo alcuni ruoli.
Il ruolo Mailbox, deve essere aggiornato per ultimo, ovvero, si devono aggiornare tutti gli altri ruoli prima e l’ordine consigliata è:
1. Client Access Server
2. Unified Messaging Servers
3. Hub Transport Servers
4. Edge Transport Servers
5. Mailbox Servers
Inoltre, è consigliato aggiornare i Client Access Server dall'esterno verso l’interno ovvero, configurare prima quelli accessibili da Internet seguiti di quelli interni, senza collegamento internet.
Nel caso in cui la versione di Exchange Server 2007 sia RTM e Microsoft Forefront Security for Exchange Server (FF) sia installato sul server, dobbiamo tenere in considerazione che:
1. La versione originale (RTM) di Forefront Security for Exchange Server è incompatibile con la versione di Exchange Server 2007 SP2. Bisogna o aggiornare Forefront Security for Exchange Server oppure rimuoverlo prima di aggiornare al Service Pack 2 di Exchange Server 2007
2. Se la versione di Forefront Security for Exchange Server è la più aggiornata, bisogna stoppare tutti i servizi di Forefront Security for Exchange Server prima della installazione del Service Pack 2 di Exchange Server 2007

Nuove caratteristiche

VSS Backup
Con la Service Pack 2 di Exchange Server 2007, abbiamo un VSS (Volume Shadow Copy Service ) plug-in per Windows Server Backup per il backup di Exchange. Il plug-in esiste in forma di un file denominato WSBExchange.exe e viene automaticamente installato su tutti i Mailbox server.
Bisogna installare la feature “Windows Server Backup” di Windows Server 2008

Durante il processo di Backup, non si evidenziano differenze con o senza SP2 comunque, durante il processo di Restore, abbiamo la possibilità di selezionare l’applicazione desiderata (in questo caso Exchange) come si può visualizzare nelle seguenti schermate:

Prima del Service Pack 2 del Exchange Server 2007:

Dopo aver istallato Service Pack 2 del Exchange Server 2007:

Using Windows Server Backup to Back Up and Restore Exchange Data: Exchange 2007 Help
http://technet.microsoft.com /en-us/library/ee221172.aspx

How to Perform a Backup of Exchange Using Windows Server Backup: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221177.aspx

How to Restore a Backup of Exchange Using Windows Server Backup: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221167.aspx
Auditing
Una delle funzionalità abbastanza richiesta dagli amministratori di Sistemi di posta, è l’auditing. Con la SP2, ci sono nuovi eventi e log che aiuteranno gli amministratori a monitorare i server Exchange. Avendo un luogo specifico dove accedere ai log di auditing, questa funzionalità è stata veramente agevolata.

L’auditing viene implementato al livello del processo Microsoft Exchange Store.exe visto che è tramite questo processo che si accede alle mail nelle mailbox.

Dopo aver configurato il livello di logging, bisogna riavviare il servizio Microsoft Exchange Information Store

Se il sistema operativo è il Windows Server 2008, il file evtx si trova sotto la cartella “\Exchange Server\Logs\AuditLogs” e si può accedere tramite Event Viewer, sotto “Applications and Services Logs\Exchange Auditings”

Understanding Mailbox Access Auditing with Exchange Server 2007 Service Pack 2: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221156.aspx

Validazione automatica del’Active Directory Schema
L’aggiornamento e validazione automatica dello schema del Active Directory, consente futuri aggiornamenti di installarsi dinamicamente e di anche prevedere potenziali conflitti sempre che una nuova proprietà venga aggiunta allo schema di Active Directory.

Understanding Dynamic Schema Updates and Validation in Exchange 2007 SP2: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221169.aspx
Configurazione della Quota dei Public Folder
La gestione/configurazione delle quota dei Public Folder è stata migliorata, potenziando il cmdlet con ulteriori parametri.

Set-PublicFolder
- IssueWarnigQuota – SP2
  - Questo parametro ci consente di configurare il valore per cui, un messaggio è inviato al owner della PublicFloder informando che il public folder è quasi al massimo delle sue capacità .
- ProhibitPostQuota –SP2
  - Superando questa quota, un messaggio è inviato al’utente che invia un post alla Public Folder, informando che la public folder è al massimo della sua capacità. Da questo momento in poi, gli utenti non sono in grado di inviare più messaggi al public folder
- I seguenti due parametri sono stati rimossi nella SP2
  - PostStorageQuota
  - StorageQuota
Diagnostic Logging
Dal Exchange Server 2007 Service Pack 2, abbiamo la possibilità di abilitare il diagnostic logging dalla console di Exchange, Exchange Management Console (ESM). Per questo proposito, basterà cliccare con il tasto destro del mouse sopra il server e troviamo la voce: “Manage Diagnostic Logging Properties”

Selezionando questa opzione, abbiamo la seguente finestra di configurazione:

Informazioni addizionali

E’ disponibile un documento con l’elenco dettagliato delle novità introdotte nel Service Pack 2:

What's New in Exchange Server 2007 SP2: Exchange 2007 Help
http://technet.microsoft.com/en-us/library/ee221150.aspx

Il pacchetto di installazione è disponibile al seguente indirizzo:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4c4bd2a3-5e50-42b0-8bbb-2cc9afe3216a

Paulo Canuto
Senior Support Engineer
Microsoft Enterprise Exchange 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

Exchange 2010 – Rilasciata la RELEASE CANDIDATE

itentblg — Wed, 19 Aug 2009 02:00:00 GMT

La Release Candidate di Exchange 2010 è stata rilasciata ieri al pubblico dal sito download Microsoft:

Microsoft Exchange Server 2010 Release Candidate

Brief Description

Microsoft Exchange Server 2010 helps you achieve new levels of reliability and performance by delivering features that help to simplify your administration, protect your communications, and delight your customers by meeting their demands for greater business mobility.
http://www.microsoft.com/downloads/details.aspx?FamilyID=c6d27da1-ba2c-4570-a491-c0d7b39ede8b&displaylang=en

Il rilascio della Release Candidate significa che il prodotto ha raggiunto un livello di stabilità tale per cui la build è considerata il punto di partenza per la successiva versione definitiva RTM.

Tutte le build successive saranno delle minor version, senza grossi cambiamenti in termini di funzionalità del prodotto e d’interfacce di gestione.

Attualmente, è disponibile solamente la versione in lingua Inglese.

Francesco Poli
Support Escalation Engineer
Microsoft Enterprise Exchange Support

OCS 2007 - Problema di integrazione con Outlook: Impossibile recuperare le informazioni del calendario

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

Come sappiamo Office Communicator è altamente integrato con Outlook ed Exchange mettendo a disposizione una serie di feature come la presence, la conversation histroy, la missed-call history, ecc

Il Communicator ottiene inoltre da Outlook e/o da Exchange una serie di informazioni, tra cui quelle relative all’ Out of Office e al calendario, per poter aggiornare conseguentemente la presenza dell’utente. Le informazioni vengono ottenute sia via MAPI che tramite i Web Services di Exchange.

Una spiegazione di come funziona questo meccanismo è data sul blog ufficiale del team che si occupa dello sviluppo del Communicator:
Office Communicator Team Blog : Communicator and Exchange – Special considerations for deploying Communicator in an Exchange environment

PROBLEMA

Per un nuovo utente era stato preparato un nuovo account ed una macchina di lavoro che prevedeva Outlook 2003 e Office Communicator 2007; nell’infrastruttura il server era un Exchange 2003 EE.

All’avvio del Communicator, successivo all’avvio di Outlook, è stato notato il seguente messaggio di errore:

che sulla versione in lingua Inglese corrisponde a:

“Cannot retrieve your Outlook calendar information. Communicator will automatically continue to retry. If this problem persists, contact your system administrator.”

Un messaggio di errore del Communicator che indicava l’impossibilità di scaricare le informazioni del calendario e che persisteva durante l’utilizzo del Communicator.

ANALISI

Come abbiamo detto sopra, il Communicator scarica le informazioni del calendario da Exchange, per i client Outlook 2007 con Exchange 2007 tramite gli Exchange Web Services oppure via MAPI.

Il tempo di polling del Communicator è modificabile via policy:

MapiPollInterval	Frequency of loading calendar data from MAPI.
WebServicePollInterval	Frequency of loading calendar data from the Web services provider.

Se l’utente non sta’ però pubblicando queste informazioni il Communicator non potrà aggiornare lo stato a sua volta, abbiamo quindi per prima cosa controllato se fossero state cambiate le impostazioni di default di Outlook:

Abbiamo poi verificato sul client Communicator che le impostazioni nel Personal Information Manager fossero settate su Outlook (in Tools -> Options):

Siccome risultava tutto configurato correttamente abbiamo abilitato i log del Communicator, da Tools –> Options -> General –> Logging

Dopo aver flaggato la voce: “Turn on logging in Communicator” e nessessario uscire e ri-loggarsi affinché le modifiche vengano accettate; verranno creati due file nella directory %userprofile%\Tracing: Communicator-uccapi-X.uccapilog e Communicator.etl.

Mentre il file .uccapilog è leggibile con Snooper, un tool del resource kit, ma anche semplicemente con il NotePad, il file ETL deve essere necessariamente mandato al supporto tecnico Microsoft per essere convertito in testo e interpretato.

La voce “Turn on Windows Event logging for Communicator” serve invece ad abilitare il Windows Event logging.

Maggiori informazioni sono reperibili sul blog ufficale di OCS: OCS Client Logging Capabilities (MOC)

Abbiamo quindi chiesto al cliente di abilitare i log, loggarsi nuovamente, aspettare che si riproducesse il problema e mandarci il file Communicator.etl.

Dal file etl risultava che il task incaricato del caricamento delle informazioni del calendario , restituiva il codice di errore 0x8004010F ovvero MAPI_E_NOT_FOUND.

SOLUZIONE

Abbiamo semplicemente inserito un evento nel calendario vuoto e l’errore è scomparso, non si tratta quindi di un vero problema, ma semplicemente del fatto che le informazioni non sono effettivamente presenti; il messaggio infatti non viene più riscontrato dopo che un appuntamento è stato creato almeno una volta.

Questo comportamento è presente solo con Outlook 2003 + Exchange 2003 di cui tra l’altro è ormai terminato il supporto mainstream:

come visto risolverlo è comunque molto semplice, in quanto al primo elemento inserito nel calendario l’errore lato Communicator sparice.

Rimando inoltre al seguente articolo di KB che descrive il motivo del possibile ritardo nell’aggiornare lo stato lato Communicator nella stessa configurazione: Communicator 2007 does not update the free/busy information as scheduled

Alessandro Pasero
Senior Support Engineer
Microsoft Enterprise Exchange Support