Supporto Tecnico Enterprise : Marco Pulita

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

itentblg — Sun, 03 May 2009 23: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
Support Engineer
Microsoft Enterprise Platform Support

Editing dei file del registro direttamente dal file WIM

itentblg — Mon, 16 Feb 2009 00:00:00 GMT

WIM Files

Le recenti versioni dei sistemi operativi Microsoft (Vista e Windows Server 2008) vengono fornite su media che contengono un nuovo formato di immagine di disco chiamato WIM.

I WIM File sono dei file compressi che contengono immagini di disco che a differenza delle normali immagini sector based sono file based. Questo significa che il WIM File è un contenitore di file che in aggiunta fornisce dei descrittori di come gli oggetti contenuti in esso devono essere copiati e configurati su disco. Grazie a questa strutturazione è possibile avere all’interno delle immagini nel WIM un unico file che se necessario può essere “istanziato” più volte invece che copiato. E’ chiaro che questo meccanismo, in aggiunta alla compressione delle immagini porta a ridurre considerevolmente la dimensione del file WIM che potrà quindi contenere più immagini di disco.

Intestazione WIM : definisce il contenuto del file con estensione wim, inclusi la posizione di memoria delle risorse principali (metadati, tabella di ricerca, dati XML) e vari attributi del file (versione, dimensioni, tipo di compressione).

Risorsa file : una serie di pacchetti contenenti i dati acquisiti, ad esempio i file di origine.

Risorsa metadati: contiene informazioni sui file acquisiti, inclusi la struttura di directory e gli attributi del file. In un file con estensione wim esiste una risorsa metadati per ogni immagine.

Tabella di ricerca: contiene la posizione di memoria dei file di risorse nel file con estensione wim.

Dati XML: contiene ulteriori informazioni sull'immagine.

Tabella di integrità: contiene informazioni sull'hash di protezione utilizzato per verificare l'integrità di un'immagine nel corso di un'operazione di applicazione.

File default HIVE in XP e variazione con vista Vista/Windows Server 2008

Nella versione precedente di Windows XP la configurazione di default del registry era importata utilizzando i file HIVE*.inf contenuti nella cartella del media di installazione. La modifica di questi file consentiva di fatto di generare una configurazione personalizzata del registry prima ancora del setup.

Nei file .WIM è contenuta un’immagine completa di un’installazione del sistema e di conseguenza non esistono più tali file.

Contenuto del media d’installazione

Sfogliando il media di installazione di Vista o Windows Server 2008 si possono individuare due file .WIM.

Boot.wim: contiene Windows PE; un sistema operativo minimale basato su kernel Vista. Consente di eseguire il setup, eseguire operazioni di risoluzione di problemi ed infine eseguire il ripristino automatico in caso di software OEM.
Install.wim: contiene le immagini di installazione del sistema operativo.

IMAGEX e modifica del REGISTRY

Con il formato .WIM viene introdotto il tool Imagex, necessario per lavorare con le immagini file based. Questo tool consente in particolare di scompattare in una cartella su disco le immagini contenute nel file .WIM consentendo così di lavorare OFFLINE sulla futura installazione del sistema. Per quanto riguarda in particolare la modifica del registry, la procedura consisterà nello scompattare l’immagine, caricare nel registry della propria macchina il file del registry che si vuole modificare contenuto nell’immagine, apportare le modifiche e salvare l’immagine includendo il nuovo file modificato. Vediamo nel dettaglio la procedura.

Prima di tutto eseguiamo il mount del file install.wim in read/write nella cartella c:\mount\ dopo aver copiato il file install.wim su disco, con il seguente comando:

imagex /mountrw install.wim 1 c:\mount

Ora nella cartella c:\mount\ vi è il contenuto del disco che si ha con una normale installazione di Windows (Vista Server 2008). Nella folder c:\mount\windows\system32\config\ sono contenuti i file del registry, tra cui ad esempio il file DEFAULT (setting di default a livello utente).

Il passo successivo consiste nel caricare l’hive DEFAULT nel registry della propria macchina ad esempio in HKLM\esempio ed editarlo con i setting necessari. Possiamo usare il seguente comando:

reg load HKLM\esempio c:\mount\windows\system32\config\DEFAULT

Terminata la modifica scarichiamo il file HIVE appena editato con il seguente comando:

reg unload HKLM\esempio
La procedura termina con l’unmount e il salvataggio dell’immagine tramite il seguente comando:

imagex /unmount /commit c:\mount

Marco Pulita
Support Engineer
Microsoft Enterprise Platforms Support

SoftGrid - Introduzione a Microsoft Application Virtualization

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

SoftGrid fornisce la possibilità di virtualizzare e distribuire agli utenti applicazioni senza la necessità che queste siano installate sulla macchina.
Un’applicazione virtualizzata è pacchettizzata e predisposta per l’esecuzione in un ambiente virtualizzato che contiene le informazioni necessarie all’esecuzione senza che vi sia la necessità di eseguire il setup.

SoftGrid fornisce quindi la possibilità di trasformare le classiche applicazioni da installare e le applicazioni Terminal Server da applicazioni che richiedono una gestione locale ad applicazioni che possono essere gestite, configurate e deployate in tempo reale e in modo centralizzato.

L’uso di applicazioni virtualizzate riduce significativamente i costi di gestione del parco applicativo.
I costi dell’help desk per le applicazioni possono essere ridotti di più del 30% e le problematiche che portano l’utente a non lavorare ridotte di più dell’80%.

Virtualizzare le applicazioni consente di ottenere i seguenti benefici:

Centralizzazione
Protezione del codice sorgente (l’applicazione viene inglobata in un ambiente protetto)
Possibilità di più versioni differenti
Autenticazione e controllo licenze real time sfruttando Active Directory

L’architettura di SoftGrid oltre ai client si compone di altre tre componenti importanti; il Management Server, lo Streaming Server ed il Sequencer.

Management Server

Si occupa della gestione delle applicazioni e dei diritti assegnati agli utenti. Il tool usato per le operazioni di gestione è la App-V Management Console tramite cui è possibile importare le applicazioni rendendole disponibili agli utenti. L’importazione avviene leggendo le informazioni contenuti nei file .OSD o .SPRJ precedentemente creati durante la fase di sequencing. Durante l’importazione è inoltre possibile assegnare l’icona (file .ICO) da utilizzare per l’applicazione.

Il Management server si occupa inoltre dell’archiviazione delle applicazioni nella Content directory. Lo streaming delle applicazioni può avvenire sfruttando lo stesso Management Server o utilizzando ulteriori Streaming Server.

Streaming Server

E’ utile in scenari con estensione molto elevata del parco macchine. Sostanzialmente è un repository delle applicazioni che scarica il Management Server dal lavoro di Streaming riducendo così anche il carico di rete fornendo la possibilità di bilanciarlo su più server.

Sequencer

Il Sequencer è un tool che impacchetta le applicazioni in modo da renderle disponibili in tempo reale e isolate nell’ambiente virtuale. Tramite l’operazione di Sequencing l’applicazione viene anche protetta a livello di codice sorgente perché “impacchettata” in un ambiente eseguibile con SoftGrid.
Il Sequencing di un’applicazione porta alla creazione di quattro file:

SFT File: Contiene una o più applicazioni virtualizzate preparate in blocchi che possono essere inviati in streaming ai client.
SPRJ File: E’ un file in formato XML che contiene il progetto del Sequencer.
OSD File: E’ un file in formato XML che contiene le informazioni necessarie allo streaming e all’esecuzione dell’applicazione.
ICO File: Contiene i file delle icone dell’applicazione che vengono integrate nell’applicazione e appariranno sul desktop dei client. Lanciando l’applicazione dall’icona si punta direttamente al file OSF che inizia lo streaming e l’esecuzione.
XML Manifest: contiene le informazioni di configurazione dell’applicazione

Requisiti di Sistema (App-V 4.5)

Per poter utilizzare SoftGrid sono necessarie per la parte server le seguenti caratteristiche hardware/software minime.

Processore minimo 1Ghz P3
512 MB di Ram
Almeno 200MB su disco (esclusa la parte relativa alla content directory)
Almeno Windows 2003 SP1
Almeno SQL Server 2000 SP3a
Active Directory

Marco Pulita
Support Engineer
Microsoft Enterprise Platforms Support

Internet Explorer – Frequente richiesta delle credenziali con applicazioni SSL

itentblg — Wed, 22 Oct 2008 23:00:00 GMT

Uno dei principali motivi per i quali Microsoft Internet Explorer può richiedere l’inserimento delle credenziali quando siamo di fronte ad una connessione HTTPS è relativo ad un abort in fase di handshake.

Vediamo in dettaglio come funzionano i due tipi di handshake SSL.

FULL HANDSHAKE

Durante il full handshake il client e il server si scambiano i relativi certificati per la cifratura dei dati trasmessi via web. Con il full handshake viene creato un ID di sessione relativo al processo di autenticazione appena concluso. L’ID di sessione consente al client e al server di riconoscere come sicura la connessione.

Terminato l’handshake inizia la trasmissione dei dati crittografati per l’invio sul web.

Periodicamente, durante la connessione, possono essere inviati dei pacchetti dati di tipo “close notify” con level settato a warning. Questi pacchetti consentono, quando ad esempio il trasferimento dei dati è terminato, la chiusura concordata della connessione, mantenendola comunque valida. In questo caso l’ID di sessione generato nella fase di handshake viene mantenuto nella cache SSL e può essere riutilizzato per le connessioni seguenti.

SHORT HANDSHAKE

Per ristabilire una connessione mantenendo il session ID presente in cache non è più necessario lo scambio dei certificati; è quindi possibile utilizzare uno short handshake.

Durante lo short handshake non vi è scambio di certificati, vengono scambiate solo le chiavi per la cifratura dei dati e successivamente viene avviato il trasferimento dei dati.

CONNECTION ABORT

Si ha un abort della connessione, caratterizzato dall’invio di un pacchetto TCP di reset, sostanzialmente quando si naviga su un altro link.

Questa casistica si può verificare ad esempio:

Cliccando direttamente su un altro link
Richiedendo il reload della pagina ad esempio con F5 (di fatto si naviga sullo stesso link ma la connessione è effettuata come se fosse su una nuova pagina)
Attivando qualche javascript che chiede un reload.

L’abort termina il caricamento della pagina e richiede la nuova pagina al server.

In genere questa condizione non causa il purge (cancellazione) della cache e quindi l’ID di sessione rimane valido per le successive connessioni.

Esiste però un caso particolare che richiede, alla successiva connessione, un full handshake e quindi la rinegoziazione dei certificati.

Per garantire la sicurezza delle informazioni trasmesse il Secure Channel di Windows, che fornisce supporto all’SSL, è stato disegnato in modo da eseguire il purge della cache SSL nel momento in cui si ha un abort durante un handshake.

Come conseguenza di quanto appena descritto la successiva connessione richiederà non più uno short handshake, bensì un full handshake; potrebbe essere quindi necessario specificare le proprie credenziali se l’applicazione lo prevede.

Per ovviare a questo problema è buona norma bloccare l’”uso” della pagina prima che questa sia stata completamente scaricata.

Uno tra i metodi utilizzabili consiste nel creare un livello trasparente e disabilitarlo al termine del caricamento della pagina. Di seguito riporto un esempio.

<html>
    <head>
       <SCRIPT TYPE="text/javascript" LANGUAGE="javascript">
          function waitLoading()
           {
            if (document.getElementById)
             document.getElementById('protectloading').style.visibility='visible';
            else //IE4
             document.all.protectloading.style.visibility = 'visible';
           }
       </SCRIPT>
    </head>

<body onLoad="waitLoading();">
      <div id="protectloading" style='position:absolute;
           left:0px; top:0px; background-color:white;
           layer-background-color:white;
           height:100%; width:100%; visibility:hidden;">

<!—CODICE PAGINA -->

</div>
</body>
</html>

Maggiori informazioni:

KB 257591 - Description of the Secure Sockets Layer (SSL) Handshake

Marco Pulita
Support Engineer
Microsoft Enterprise Platforms Support