Virtualizzazione

Introduzione a Microsoft Application Virtualization

Anthony Kinney

Questo articolo si basa su una versione non definitiva di App-V. Tutte le informazioni riportate sono soggette a modifica.

Panoramica:

• Architettura di App-V
• Gestione di applicazioni virtuali
• Utilizzo del sequencer di App-V
• Integrazione di App-V con Configuration Manager

Indice

Architettura di App-V
Funzionamento dell'infrastruttura completa di App-V
Aggiornamento di applicazioni virtuali
Sequenziazione
Versione 4.5

Microsoft Application Virtualization (o App-V) è un programma a cui sono particolarmente legato. App-V era in precedenza noto come SoftGrid e il sottoscritto è stato assunto in Microsoft grazie all'acquisizione di Softricity, l'azienda produttrice di SoftGrid. Ora sono lieto di avere l'opportunità di scrivere questo articolo per TechNet Magazine, poiché dal periodo dell'acquisizione sono avvenuti diversi cambiamenti.

L'approccio migliore ad App-V consiste nel descrivere dapprima le difficoltà che i professionisti IT devono affrontare in termini di gestione aziendale. Oggi i desktop aziendali sono sommersi di applicazioni. Prima di poter installare un'applicazione, è necessario eseguire interminabili test di regressione al fine di garantire che questa possa coesistere con le altre applicazioni installate sul sistema, senza danneggiarne la capacità di esecuzione. Quindi, prima di diventare effettivamente produttiva, l'applicazione deve essere sottoposta a una serie di processi di distribuzione. Inoltre, poiché un'applicazione è disponibile di fatto solo quando è installata, gli utenti sono legati a computer specifici. Questo complica ulteriormente progetti già di per sé critici e complessi, quali migrazioni di sistemi operativi e applicazioni, aggiornamenti della protezione e pianificazione dei ripristini di emergenza.

In questo ambito, App-V rappresenta una svolta. Grazie ad App-V, infatti, l'amministrazione di desktop si trasforma in un processo semplice e automatizzato, anziché richiedere una serie complicata di passaggi che implicano notevoli sforzi in termini di tempo e risorse. È quindi possibile distribuire, applicare patch, aggiornare e terminare le applicazioni con maggior facilità, ottenendo risultati migliori.

Con App-V, gli utenti possono utilizzare qualsiasi desktop per accedere alle proprie applicazioni. Queste sono distribuite su richiesta, ma vengono eseguite come se fossero realmente installate localmente. In tal modo non è necessario installarne i componenti o alterare il dispositivo host.

Questo utilizzo della virtualizzazione potrebbe modificare radicalmente il modo in cui i professionisti IT gestiscono i desktop. L'assenza di modifiche al dispositivo host e l'esecuzione di applicazioni virtualizzate introduce numerosi vantaggi, tra i quali:

• Minor numero di conflitti tra applicazioni
• Aggiornamenti delle applicazioni più semplici e rapidi
• Possibilità di eseguire contemporaneamente più versioni della stessa applicazione
• Applicazioni flessibili che seguono gli utenti in linea e non
• Minore quantità di test di regressione tra applicazioni

Architettura di App-V

Esaminiamo ora le operazioni svolte "dietro le quinte" dalla piattaforma App-V. La piattaforma è costituita da alcuni componenti principali: un sequencer, un database, dei client, un server di gestione, un server di streaming e una console di gestione (vedere la Figura 1).

Figura 1 Layout di un ambiente App-V (fare clic sull'immagine per ingrandirla)

Il nucleo del sistema App-V è il client App-V. Esistono due tipi di client che è possibile utilizzare: il client Terminal Server e il client Desktop. In entrambi i casi il client deve essere installato su ciascun desktop e terminal server su cui si intende distribuire le applicazioni virtuali. Il client occupa una quantità relativamente ridotta di spazio su disco: installa un driver e dispone di un componente di runtime utente visibile, che viene visualizzato sotto forma di indicatore nell'area di notifica.

Il client acquisisce un elenco di applicazioni virtuali dal server di gestione di App-V e visualizza quelle disponibili. Si occupa quindi dell'avvio di tali applicazioni (quando avviate dall'utente) e gestisce la cache sul lato client. Il client gestisce inoltre la creazione dell'ambiente di runtime virtuale e garantisce che ciascun ambiente venga eseguito autonomamente. L'ambiente virtuale comprende diversi componenti, tra cui un registro di sistema, un file system e un gestore di servizi, tutti virtuali.

In App-V 4.5 sono disponibili tre opzioni per la distribuzione delle infrastrutture: infrastruttura completa, infrastruttura leggera e modalità autonoma. Quando si distribuisce un'infrastruttura completa, il back-end include il server di gestione e il server di streaming di App-V (quest'ultimo è un nuovo componente che sarà illustrato a breve). Il server di gestione di App-V ospita e distribuisce le applicazioni virtuali centralizzate, oltre ad aggiornarle quando vengono applicate patch o aggiornamenti.

Per supportare il database App-V, che contiene configurazioni e impostazioni per le applicazioni virtuali, il server di gestione è basato su SQL Server. Come strumento di gestione centrale per eseguire il provisioning e il controllo delle autorizzazioni per le applicazioni virtuali occorre utilizzare i gruppi di Active Directory.

Per gestire impostazioni e configurazione, la piattaforma di App-V fornisce un servizio Web Microsoft .NET Framework che è possibile caricare sullo stesso server, se l'IIS è installato. Questo servizio Web collega la console di gestione di App-V, uno snap-in MMC (Microsoft Management Console) e il database di App-V. Gli amministratori possono utilizzare la console per pubblicare e gestire applicazioni virtuali, assegnare gruppi Active Directory e controllare le impostazioni dei server, nonché eseguire generare sull'utilizzo di applicazioni virtualizzate (vedere la Figura 2).

Figura 2 Console di gestione (fare clic sull'immagine per ingrandirla)

L'infrastruttura leggera include il server di streaming di App-V, che consente l'esecuzione di funzionalità di streaming, quali l'aggiornamento a pacchetti/attivo. Questa opzione non richiede Active Directory o SQL Server, non dispone di un servizio di configurazione desktop, né di funzionalità di controllo licenze e misurazione. Questo tipo di infrastruttura consente, tuttavia, l'aggiunta di funzionalità di streaming a System Center Configuration Manager (SCCM) e ad altre soluzioni per la distribuzione del software aziendale (ESD) di terze parti.

In modalità autonoma il sequencer di App-V può creare un file MSI che automatizza l'aggiunta dell'applicazione virtuale (vedere la Figura 3). Il file MSI contiene metadati che consentono a qualsiasi sistema ESD di riconoscerlo e di controllare l'applicazione virtualizzata. A tal fine, il client deve passare alla modalità autonoma, che consente unicamente aggiornamenti basati su MSI delle applicazioni virtuali, mentre lo streaming non è consentito. Questa modalità permette alle aziende di utilizzare le funzionalità di isolamento di App-V.

Figura 3 Sequencer di App-V (fare clic sull'immagine per ingrandirla)

I file MSI sono molto flessibili, possono essere eseguiti in modalità del tutto autonoma con un unico client App-V e non necessitano di componenti server. Ciò significa che possono essere distribuiti manualmente, tramite un disco, o mediante qualsiasi strumento di distribuzione tradizionale.

In App-V 4.5, vengono ora supportati HTTP e HTTPS come protocolli per lo streaming. Questo garantisce prestazioni migliori a livello di streaming con un protocollo utilizzato su larga scala, in particolare per lo streaming in ambienti WAN protetti e Internet.

Funzionamento dell'infrastruttura completa di App-V

L'utente accede a un dispositivo su cui è installato uno dei client (client Desktop o Servizi terminal di App-V) e quest'ultimo invia al server una richiesta dell'elenco di applicazioni assegnate all'utente corrente. Il server comunica con Active Directory per determinare a quali gruppi appartiene l'utente, quindi restituisce l'elenco di applicazioni al client. Il client avvia la creazione di annunci per le applicazioni virtuali assegnate al determinato utente.

In questo processo di pubblicazione, vengono eseguite diverse operazioni:

• Copia dei file di configurazione
• Creazione delle icone desktop
• Creazione dei collegamenti di invio
• Creazione delle cartelle del menu di avvio
• Configurazione dei tipi di file

Questo processo è molto rapido e, ancor più importante, garantisce che l'ambiente abbia esattamente lo stesso aspetto previsto dall'utente, senza alcuna modifica a livello di visualizzazione. Le applicazioni virtuali si comportano come se fossero installate a livello locale ma, naturalmente, non alterano il computer host. Le icone, anziché fare riferimento a file eseguibili che risiedono nella directory dei programmi, fanno riferimento al client App-V, che per la configurazione si basa su un file di avvio (un file OSD).

È importante sottolineare che questo processo ha un impatto minimo sulla rete poiché, a differenza delle distribuzioni software tradizionali, non vi sono elementi installati. I vantaggi che ne derivano sono enormi, in particolare in ambienti di utenti mobili, poiché le applicazioni sono disponibili all'utente, ma non vengono realmente distribuite fino all'avvio. Questo metodo di annuncio è ciò che consente ad App-V di disporre di applicazioni su richiesta e mobili.

Quando l'utente avvia un'applicazione virtuale, il client legge un file di configurazione OSD, che è stato memorizzato sul computer locale. Questo comunica al client il protocollo da utilizzare durante la comunicazione con il server di gestione di App-V, nonché il server su cui l'applicazione risiede.

Il server corrispondente risponde al client trasmettendo la soglia di avvio iniziale, che in genere corrisponde al 20-40% dell'applicazione completa. Quando l'intera soglia di avvio è stata trasmessa (anche in questo caso, circa il 20-40% dell'applicazione), l'applicazione virtuale è pronta per l'esecuzione.

Lo streaming è uno degli elementi principali del cambiamento paradigmatico introdotto con App-V, poiché consente di inviare una parte sufficiente di un'applicazione, in modo che questa possa essere eseguita senza perdere preziosa larghezza di banda della rete. Tutti i dati trasferiti al client risiedono in un file della cache locale sul dispositivo e tutti i successivi avvii dell'applicazione avverranno tramite la cache locale, eliminando eventuale traffico di rete aggiuntivo.

Al termine della trasmissione dell'applicazione, il client crea un ambiente isolato che evita che l'applicazione modifichi il computer locale (in altre parole, l'applicazione non ha footprint sul client). Il client, tuttavia, consente all'applicazione virtuale di accedere al file system locale quando si salvano e si modificano file e le permette inoltre di interagire con i servizi locali (ad esempio, la stampa), a condizione che l'utente disponga di privilegi adeguati sul sistema locale. Tuttavia, qualsiasi modifica eseguita da un'applicazione virtuale al registro di sistema e ai file del sistema locale viene reindirizzata all'ambiente virtualizzato, in modo che il dispositivo host rimanga inalterato.

Quando l'applicazione è in esecuzione, qualsiasi funzionalità che non sia stata utilizzata in precedenza viene fornita in base alle esigenze e memorizzata nella cache per utilizzo futuro. Il vantaggio offerto da questa operazione è che, all'avvio iniziale, vengono caricati solo i componenti di cui l'utente necessita, mentre le funzionalità superflue non consumano risorse di rete (nella nuova versione sono presenti alcuni miglioramenti a livello di memorizzazione nella cache sul lato client, che consentono un utilizzo più efficiente della cache e la possibilità di streaming in background).

Si consideri ad esempio Microsoft Office Word. Quasi tutti gli utenti utilizzano il correttore ortografico (senza il quale neppure questo articolo avrebbe potuto essere scritto), che quindi farà parte dell'avvio iniziale. Per quanto riguarda invece la funzionalità della Guida di Word, questa non viene utilizzata da altrettanti utenti, pertanto non viene fornita nell'avvio iniziale, ma inviata a ciascun utente al primo utilizzo.

Quando l'utente ha terminato e chiude l'applicazione, il client rimuove l'ambiente virtuale e memorizza tutte le impostazioni utente in una posizione specifica per l'utente: in tal modo, l'ambiente viene conservato e sarà ricostruito all'avvio seguente. La percentuale dell'applicazione virtuale trasmessa resta nella cache locale ed è disponibile per il successivo avvio. Se un altro utente accede allo stesso sistema host e avvia la stessa applicazione virtuale, questo potrà utilizzare l'applicazione già memorizzata nella cache.

Per rimuovere gli annunci delle applicazioni virtuali, è sufficiente rimuovere l'utente dal gruppo Active Directory appropriato. Inoltre, per disinstallare completamente l'applicazione virtuale da un desktop, è possibile eliminare semplicemente i dati della cache. Poiché l'applicazione non è mai stata realmente installata a livello locale, non vengono visualizzati messaggi con cui si richiede all'utente se desidera rimuovere i componenti condivisi.

Anche se un'applicazione virtuale è memorizzata in una cache, ciò non significa che tutti gli utenti possano accedervi. A differenza delle applicazioni installate a livello locale, in cui gli utenti possono semplicemente ricercare file eseguibili per i quali non dispongono di diritti, in questo caso non esistono rappresentazioni visive o fisiche dell'esistenza dell'applicazione virtuale, a meno che all'utente non siano stati concessi diritti espliciti mediante i gruppi Active Directory.

Aggiornamento di applicazioni virtuali

L'aggiornamento viene eseguito tramite il sequencer. Dopo l'aggiornamento di un'applicazione, questa viene collocata sul server di gestione di App-V accanto alla versione precedente. All'avvio seguente, il server notifica quindi al client che è stata apportata una modifica. Se la versione precedente è ancora in uso, l'utente continua ad aver accesso a tale versione finché l'applicazione virtuale non viene chiusa. All'avvio seguente, i delta che costituiscono l'aggiornamento vengono trasmessi al client e caricati nella cache, consentendo l'aggiornamento dell'applicazione.

Si supponga di avere 1.000 utenti che eseguono Word 2000. Un amministratore deve aggiornare Word 2000 (word2K.sft) a Word 2000 SP3, quindi copia il file word2K.sft nella postazione di sequenziazione e, nel sequencer, seleziona l'opzione di apertura per l'aggiornamento del pacchetto. Selezionando tale opzione, l'amministratore inizia a operare dallo stato dell'ultimo pacchetto. Può copiare DLL, effettuare aggiornamenti oppure eseguire patch all'interno dell'applicazione virtuale per aggiornarla a Word 2000 SP3, quindi salvare il pacchetto aggiornato.

Il sequencer assegna automaticamente un nuovo nome file, word2K_2.sft, per evitare nomi di file duplicati e per indicare la versione della sequenza. Il nuovo pacchetto viene collocato nella stessa directory del vecchio sul server di gestione di App-V, in modo che Word 2000 (word2K.sft) e Word 2000 SP3 (word2K_2.sft) risiedano nella stessa directory. L'amministratore utilizza quindi la console di gestione di App-V per collegare questi due file SFT.

Sul lato client, gli utenti con una sessione attiva di Word 2000 senza SP3 continuano a lavorare normalmente. Gli utenti che avviano una nuova sessione dell'applicazione dopo che l'amministratore ha eseguito questo collegamento riceveranno un messaggio che informa della modifica. Il client inizia quindi a trasferire solo le modifiche delta tra word2K.sft e word2K_2.sft, aggiornando automaticamente l'applicazione a Word 2000 SP3.

Grazie alla natura dinamica delle applicazioni virtuali, anche eseguire il rollback è piuttosto semplice. È sufficiente tornare alla console di gestione di App-V e rimuovere la versione aggiunta di recente. Ne consegue che, al riavvio, il client esegue il rollback alla versione precedente. Affinché non si verifichino sovrapposizioni di dati dei pacchetti, il client elimina automaticamente i dati dalla cache e trasmette nuovamente il file SFT corretto. Si tratta di un compromesso accettabile, se si considerano le operazioni necessarie per eseguire il rollback dell'aggiornamento di un'applicazione che è stata fisicamente installata utilizzando strumenti di distribuzione software più tradizionali.

Per comprendere i vantaggi di App-V, è necessario creare pacchetti di applicazioni virtuali. Qui entra in gioco il sequencer di App-V. Qualsiasi informazione ed esperienza nella creazione di script e pacchetti per strumenti di distribuzione software tradizionali faciliterà il passaggio alla sequenziazione (si noti che questa operazione richiederebbe di per sé un intero articolo).

La maggior parte delle soluzioni di distribuzione software si basano su script che acquisiscono la modalità di installazione di un'applicazione, per poi duplicare il processo su altri computer, eliminando l'esigenza di spostarsi di computer in computer per installare o aggiornare le applicazioni. Una volta installata l'applicazione, i comuni strumenti di distribuzione software ignorano il pacchetto. È quindi necessario installare eventuali dipendenze sulle quali l'applicazione potrebbe basarsi, eseguire altri script o effettuare operazioni manuali per configurare l'applicazione in base alle proprie esigenze.

La svolta fondamentale in App-V è che il processo di sequenziazione genera l'immagine di un'applicazione già installata, completa di relative dipendenze e configurazioni. Questa può essere "eseguita" dal client di App-V senza alterare il dispositivo sul quale avviene l'esecuzione.

Il sequencer genera una serie di file, il più importante dei quali è il file SFT, che contiene tutte le risorse e le dipendenze dell'applicazione, nonché le informazioni di configurazione. In alcuni casi potrebbe inoltre contenere più applicazioni: in effetti, le dimensioni del file possono diventare notevoli. Sono disponibili alcune opzioni di compressione, ma è essenziale una conoscenza approfondita delle prestazioni della propria rete e dei propri dispositivi. Il file icona (.ico) che il sequencer crea è utilizzato per annunciare l'applicazione virtuale, in modo che operi come se fosse installata a livello locale.

Anche il file OSD è molto importante e le relative opzioni sono infinite. Per impostazione predefinita, questo è un file basato su XML utilizzato per comunicare al client App-V come avviare l'applicazione virtuale. Il file può inoltre essere modificato per configurare e controllare la modalità di avvio ed esecuzione dell'applicazione virtuale. Per acquisire familiarità con le proprietà e i valori disponibili grazie al file OSD, è consigliata la lettura della guida per gli amministratori relativa alla sequenziazione e del documento sulle procedure consigliate in ambito di sequenziazione.

Infine, il nuovo file manifest.xml contiene informazioni di configurazione basate su pacchetti e può essere utilizzato per l'integrazione con soluzioni ESD di terze parti e distribuzioni MSI. Il sequencer può inoltre generare un file MSI per il pacchetto di applicazioni virtuali, che è possibile utilizzare per caricare le applicazioni su client autonomi (senza server) e attraverso un sistema ESD.

Il sequencer è uno strumento basato su una procedura, il packager, che guida l'utente attraverso il processo di installazione e di trasformazione di un'applicazione in un'applicazione virtuale (vedere la Figura 4). Il primo passaggio consente di configurare le proprietà predefinite per il pacchetto. Tali proprietà, memorizzate nel file OSD, comprendono nome del pacchetto e commenti. Alcune delle impostazioni avanzate consentono di specificare il server da cui eseguire il trasferimento, la directory dei contenuti e i sistemi operativi che il pacchetto deve supportare.

Figura 4 Procedura guidata di sequenziazione (fare clic sull'immagine per ingrandirla)

Il secondo passaggio consiste nell'installare, configurare e verificare l'applicazione. Durante l'installazione, il sequencer acquisisce tutte le modifiche apportate al sistema locale, compresi file system, Registro di sistema e sistema. La procedura guidata include inoltre alcune utilità che consentono, ad esempio, l'integrazione con Windows Update.

Il passaggio successivo prevede la configurazione delle associazioni dei tipi di file e la definizione della posizione dei collegamenti. Le posizioni standard includono il menu Start, il desktop e la barra di avvio rapido, ma è anche possibile creare posizioni personalizzate.

Quindi è necessario avviare l'applicazione e configurare la soglia per il lancio iniziale. In questo passaggio App-V determina la porzione iniziale dell'applicazione che deve essere fornita al client per consentirne l'avvio.

Per configurare questo codice iniziale (in genere indicato come Feature Block 1 o FB1), è sufficiente avviare l'applicazione e utilizzare le funzionalità in genere necessarie agli utenti. Ad esempio, avviare Word, quindi il correttore ortografico. Le DLL, i file o le chiavi di registro richiamate dall'applicazione durante questa fase vengono automaticamente designate come parte dell'FB1. I file, le impostazioni o i componenti non utilizzati in questa fase vengono aggiunti all'FB2. In seguito, quando l'applicazione viene utilizzata, il client riceve una mappa del file SFT, che indica i punti in cui inizia e termina l'FB1 e se sono presenti altri file nell'FB2, in modo che il client possa recuperarli quando sono necessari per l'applicazione.

Il passaggio finale del processo di sequenziazione consiste nell'accertarsi che tutto sia configurato correttamente. Nel sequencer viene visualizzata la finestra di dialogo illustrata nella Figura 5, che rappresenta l'SFT e consente di eseguire aggiunte finali o apportare modifiche al pacchetto.

Figura 5 Conferma e modifica di un pacchetto finale (fare clic sull'immagine per ingrandirla)

Versione 4.5

Dopo due anni di lavoro, nei prossimi mesi sarà rilasciato App-V 4.5. Si tratta della prima versione del prodotto a essere rilasciata da Microsoft e promette di aumentare la virtualizzazione delle applicazioni grazie all'introduzione di diversi miglioramenti di rilievo, quali interazione dinamica di applicazioni virtuali, scalabilità estesa e maggiore aderenza ai requisiti di protezione e internalizzazione Microsoft.

L'interazione dinamica di applicazioni virtuali consente alle applicazioni virtualizzate di interagire tra loro. Tale interazione è definita DSC (Dynamic Suite Composition) e non esclude la possibilità di aggiungere più applicazioni allo stesso pacchetto, costituendo invece un nuovo metodo per integrare dipendenze, middleware e plug-in condivisi tra applicazioni virtuali.

Gli amministratori possono specificare quali applicazioni virtualizzate possono interagire tra loro. Ad esempio, si supponga di disporre di cinque applicazioni Web che richiedono la stessa versione Java. In App-V 4.1, sarebbe necessario aggiungere questa versione Java a ciascuno dei cinque pacchetti separatamente. Si supponga inoltre che la versione Java richieda una patch, l'amministratore dovrebbe applicarla a tutti e cinque i pacchetti. Con DSC, Java può essere incorporato un'unica volta in un pacchetto, il quale può essere configurato per l'utilizzo da parte di tutte e cinque le applicazioni Web. Di conseguenza, per applicare la patch a Java, l'amministratore deve eseguire tale operazione sul pacchetto un'unica volta.

Lo stesso scenario è applicabile al middleware e ai plug-in. Quando Microsoft sarà prossima al rilascio e avrà finalizzato eventuali aggiunte, realizzerò un blog in cui verranno descritti altri casi di utilizzo.

I miglioramenti a livello di scalabilità comprendono sia l'infrastruttura di streaming, sia quella di back-end. I componenti di back-end sono stati modificati in modo da supportare in modo più efficiente scenari di clustering e failover, mentre lo streaming è più adatto a WAN e LAN. I miglioramenti sono stati possibili grazie a diverse aggiunte fondamentali.

Innanzitutto il nuovo componente "Streaming Server", che consente la trasmissione senza l'esigenza di un'infrastruttura di back-end di Active Directory e SQL Server. L'utente può usufruire dei notevoli vantaggi della distribuzione su richiesta e dell'aggiornamento centralizzato dei pacchetti, senza dover soddisfare i notevoli requisiti del back-end. Questo componente sarà largamente utilizzato in scenari che prevedono la presenza di filiali, nonché per l'integrazione di soluzioni ESD di terze parti.

Anche il client App-V è stato migliorato. Ad esempio, ora vengono memorizzate localmente tutte le informazioni relative all'utilizzo: in tal modo è possibile tenerne traccia, che il sistema client sia in rete o meno. Inoltre, la cache del client è stata espansa e migliorata per garantire prestazioni ottimali in scenari in cui lo spazio su disco è limitato. Infine, è stato aggiunto il supporto per la sequenziazione di applicazioni non in inglese, l'esecuzione di App-V su sistemi operativi non in inglese e la localizzazione in diverse altre lingue.

Integrazione di App-V con Configuration Manager

Sono stati progettati numerosi miglioramenti e nuove funzionalità in App-V 4.5 per l'integrazione della soluzione in SCCM 2007 R2. Come detto in precedenza, la virtualizzazione e lo streaming offrono possibilità di distribuzione delle applicazioni che i tradizionali strumenti di distribuzione software non offrono. App-V non sostituirà tali strumenti, tuttavia può completarli ed estenderli.

L'integrazione consentirebbe di ottenere tutte le funzioni di scalabilità, report, riconoscimento di dispositivi e WAN di SCCM e tutte le caratteristiche di streaming e isolamento di App-V. Di seguito sono indicate alcune delle aree che traggono vantaggio dall'integrazione delle due tecnologie.

Distribuzione di applicazioni: l'integrazione di SCCM R2 supporta tutte le funzionalità di distribuzione su richiesta, applicazioni mobili, soglie di avvio iniziale e distribuzione di applicazioni senza modificare i PC client.

Aggiornamenti: i punti di distribuzione (DP) SCCM consentono di distribuire modifiche delta di applicazioni virtuali quando i pacchetti vengono aggiornati. Questo introduce, a livello centralizzato, la possibilità di riportare le applicazioni virtualizzate alla versione precedente con un semplice clic.

Gestione: la versione R2 ha introdotto una nuova procedura guidata di annuncio delle applicazioni, che consente agli amministratori di distribuire applicazioni virtualizzate, nonché pacchetti software tradizionali e annunci da un'unica console.

Assemblaggio: non è necessario assemblare nuovamente le applicazioni quando si integra App-V con SCCM. La sequenziazione iniziale di un'applicazione deve essere eseguita utilizzando la sequenza App-V al di fuori di SCCM, ma gli amministratori possono aggiornare i pacchetti esistenti utilizzando SCCM.

Licenze: è possibile tenere traccia di licenze e misurazioni delle applicazioni virtuali utilizzando gli strumenti esistenti in SCCM.

BITS: SCCM offre un nuovo metodo per la distribuzione di applicazioni virtualizzate ad App-V tramite l'utilizzo del protocollo BITS standard del settore. Nonostante i DP SCCM possano eseguire la trasmissione, esistono casi in cui questo non è il metodo ideale per la distribuzione di applicazioni virtualizzate. Quando si esegue la distribuzione tramite SCCM, sono disponibili due opzioni. È possibile utilizzare funzionalità di streaming standard oppure funzionalità per la qualità del servizio (QoS) di BITS per eseguire la distribuzione in modo maggiormente controllato. Questo è inoltre utile in scenari nei quali si desidera caricare la cache prima che gli utenti lancino l'applicazione virtuale.

Distribuzioni a computer: SCCM offre la possibilità di distribuire applicazioni virtualizzate a computer specifici, nonché di continuare a supportare l'approccio basato sugli utenti della piattaforma App-V. Questo è vantaggioso quando si distribuiscono applicazioni virtuali a computer portatili, chioschi e computer di laboratorio. Risulta inoltre utile per fornire assistenza nel controllo delle licenze, nei casi in cui queste sono fornite ai dispositivi, non in base ai nomi degli utenti.

Scalabilità: l'esigenza di distribuire due strumenti separati che condividono una grande quantità di elementi è una questione di interesse comune. Integrando i vantaggi di SCCM, vale a dire scalabilità e WAN, con quelli di App-V, ossia isolamento e streaming, è possibile utilizzare l'SCCM esistente, che fornisce un unico strumento per occuparsi sia di gestione, sia di distribuzione, senza aggiungere ulteriore complessità.

Anthony Kinney è Technical Sales Professional responsabile del Microsoft Desktop Optimization Pack. Anthony è stato assunto da Microsoft nel 2006, con l'acquisizione di Softricity. Durante il periodo di lavoro presso Softricity, ha scritto e progettato il primo programma di formazione per SoftGrid (ora App-V). È possibile contattarlo all'indirizzo Anthony.kinney@microsoft.com.