Firma di Outlook e OWA basata sulle informazioni utente in Active Directory (v 1.2)

Facebooktwittergoogle_plusredditlinkedin

Introduzione
Chi utilizza Exchange Server e conosce le regole di trasporto, sarà anche a conoscenza del fatto che in teoria esse possono essere utilizzate per implementare delle firme dinamiche nella propria organizzazione. Nonostante sia possibile tecnicamente, questa implementazione nasconde degli evidenti aspetti negativi. Se avete condotto anche solo un paio di test vi sarete resi conto che la firma dell’utente viene sempre collocata in fondo a "tutto" il testo, questo provoca un concatenarsi di firme al termine del messaggio email, in particolare nel caso di molti reply. L'unico sistema davvero efficace è settare la firma localmente, direttamente in Outlook e per ogni utente.
Quanto sopra è sostenibile se parliamo di pochi utenti, ma se nell'azienda per cui lavorate ne conta decine o addirittura centinaia dovrete acquistare prodotti di terze parti.
Fortunatamente esiste una valida alternativa, che come vedremo in questo articolo ci consentirà di generare e impostare in maniera automatica e dinamica le firme locali di Outlook e simultaneamente i file HTML necessari all’importazione delle firme in OWA (Outlook Web App)  tramite EMS (Exchange Management Shell). Un altro vantaggio non da poco è che la procedura è totalmente realizzabile utilizzando l’infrastruttura esistente e quindi totalmente free.
Lo script PowerShell che implementeremo andrà a creare una firma locale di Outlook  per ogni singolo utente avvalendosi dei dati utente presenti in Active Directory.
Il funzionamento è semplice. Ogni volta che si modificherà il file di Word contente un modello predefinito le firme verranno rigenerate dallo script a sua volta distribuito via GPO .
Tutti i file e gli script sono scaricabili dall’indirizzo fornito in fondo all’articolo.
Prerequisiti
Al fine di poter raggiungere il nostro obiettivo avremo bisogno che alcuni prerequisiti vengano soddisfatti:
PowerShell (Già presente in W7, installabile su WXP e distribuibile tramite WSUS)
Office 2003 o successivi (Sono necessari gli Assembly di interoperabilità primari installati di default, in caso contrario sono scaricabili da Microsoft download center
· Almeno un server che abbia il ruolo di Domain Controller
· Exchange Server 2007/10 (Facoltativo, lo script può essere facilmente adattato ad operare in sua assenza)
Installazione
Prima di cominciare verifichiamo che gli utenti AD contengano tutte le informazioni necessarie nei campi preposti. Potete osservare alcuni campi compilati nella figura 1
clip_image001
Figura 1
A questo punto creeremo un file "Modello" su cui basare la nostra firma aziendale e nel quale useremo le variabili dichiarate nello script . Di seguito troverete un esempio in cui le variabili sono evidenziate in blu.
DisplayName
Title
Nome Azienda
Via XXXXXXXX, XX
00000, XXXXXXX (XX)
Tel. TelePhoneNumber, Fax. facsimileTelephoneNumber
Web: XXXXXXXXXXXXX
Email: PostaEL
BlogIQ
Una volta decisi Logo, Font ecc, salvate il file in formato Word facendo attenzione al nome della vostra organizzazione o meglio al nome che è stato dichiarato nello script PowerShell ed in particolare nella variabile "$CompanyName".
$CompanyName = ‘NomeOrganizzazione’
$DomainName = ‘nomedominioAD.local’
Tenendo presente quanto sopra creiamo le cartelle necessarie sotto "NETLOGON" aggiungendo una nuova cartella denominata "sig_files" e poi una sottocartella corrispondente al nome attribuito in precedenza. Una volta terminato avremo un percorso simile a questo:
\nomedominioAD.localNETLOGONsig_filesNomeOrganizzazione
Non ci resta che copiare il file di Word creato in precedenza in questa posizione, come indicato in Figura2.
clip_image003
Figura 2
Le variabili AD utilizzate in questo script sono riassunte di seguito, a destra si trovano i riferimenti agli attributi dell’oggetto AD.
$ADDisplayName = $ADUser.DisplayName
$ADEmailAddress = $ADUser.mail
$ADTitle = $ADUser.title
$ADTelePhoneNumber = $ADUser.telephoneNumber
$ADdescription = $ADuser.description
$ADFax = $ADuser.facsimileTelephoneNumber
$ADMobile = $ADuser.mobile
$ADDepartment = $ADuser.department
Nel caso in cui ci sia la necessità di aggiungere altre variabili è possibile farlo da ADUC in modalità “Advanced Features” nelle proprietà dell’oggetto AD (utente) sotto “Attribute Editor”. Oltre a cambiate il valore è possibile leggerne il nome dell’attributo che molto spesso è poco intuibile. (Fig. 3)
clip_image004
Figura 3
E’ arrivato il momento di copiare il codice seguente e di salvare il file con estensione .ps1 (Es. Firma.ps1)








Il codice di cui sopra è basato su questo script di Jan Egil Ring ma dovete fare attenzione ad un paio di cose. Lo script originale contiene alcune linee di codice che sono state rimosse e che causavano il salvataggio nel formato errato del file firma che deve essere invece in formato testo. Nella versione 1.1 non sareste stati in grado di rispondere ai messaggi solo testo. Sono state aggiunte alcune variabili e soprattutto la parte che salva la firma in html “filtrato” per OWA. Fate attenzione al “filtrato”, se usate il tag “wdFormatHTML” come nello script originale (1.1) al posto di “wdFormatFilteredHTML” Winword genererà un file molto grande contenente una serie infinita di TAG relativi ad Office che nel nostro caso non sono necessari, Il file diventerebbe troppo grande (32k) per essere correttamente gestito in EMS (Exchange Management Shell) dato che ci viene imposto da Exchange Server un limite hard coded di 8k .

Nelle linee 51 – 52 definiamo il nome della nostra organizzazione e del dominio AD

51:  $CompanyName = ‘YourComapny’  
52:  $DomainName = ‘yourdomain.local



Da 68 a 81 troviamo le variabili AD che abbiamo definito e che abbiamo usato nel file di Word.

Mentre la linea 64 definisce il nome del vostro Exchange Server

$ExchPath = '\YOUR_EXCHANGE_SERVERSignatures'



Dalla 194 alla 196 lo script genera il file per htm in locale per OWA e poi lo copia nella cartella condivisa “Signatures” (Condivisa in precedenza sul server Exchange).

Ora il nostro script PowerShell è pronto per essere distribuito tramite GPO.

Il prossimo passo sarà quello di creare una nuova GPO di nome “Signature”.  (Fig. 4)

image

Figura 4

Per quanto riguarda i parametri da settare dobbiamo soffermarci qualche secondo sul fatto che dovremo “insegnare” a PowerShell ad eseguire il nostro script dato che non avrà nessuna firma digitale.

Sotto Policies –>Administrative Templates –>Windows Component –>  Windows PowerShell –>Turn on script esecution setteremo il parametro su “Enabled” e nelle opzioni “Allow all Scripts” (Fig. 5)

image

Figura 5.

A questo punto dovremo distribuire lo script vero e proprio, magari usando questa stessa GPO. (Fig. 6)

User Configuration –> Policies –> Windows Settings –> Scripts

image

Figura 6

Se nella vostra azienda avete ancora Windows XP allora sarà necessaria una seconda policy filtrata (fig. 7) con WMI (WXP) che chiameremo ad esempio “LegacySignature” dove andremo a definire un file batch che a sua volta eseguirà lo script PowerShell.  Di seguito la linea di codice da inserire nel file batch.




image

Figura 7

Installazione – parte Exchange Server

Partiamo dalla cosa più semplice. Accediamo al nostro Exchange Server, creiamo una nuova cartella di nome "Signatures" e condividiamola assegnando i permessi di scrittura per "Authenticated Users". La cartella dovrà essere accessibile tramite il percorso UNC \NOMESERVERSignatures.

Man mano che gli utenti faranno logon dalle macchine la nostra directory si popolerà dei vari file html che useremo per le firme OWA. (Fig. 8)

 image

Figura 8

Se nella vostra firma è stato inserito un logo dovremo affrontare un altro paio di problemini. I file htm generati  da Word contengono un collegamento all’immagine che punta ad una cartella locale con il risultato che OWA visualizzerà l’immagine con una bella X rossa. Inoltre l’immagine verrà collocata da Word in una cartella con nome %username%_file/nomeimmagine.xxx. Come si può immaginare la sostituzione del testo in questo caso non è così banale.

Risolveremo questo problema usando di nuovo PowerShell e avvalendoci delle espressioni regolari.

Il codice html dei vari file firma che troveremo nella cartella Signatures conterrà fra il resto del codice la linea  :

<td><img width=119 height=102 src="administrator_file/image001.gif"></td>


Quello che faremo sarà sostituire la parte src=”” con un link ad un sito web pubblico dove avremo precedentemente caricato la nostra foto del logo (image001.gif)


   <td><img width=119 height=102 src="http://www.publicwebsite.com/image001.gif"></td>



Ecco lo script Powershell (EMS) che permette di correggere tutti i file in un solo colpo e di importare le firme di ogni utente in OWA.




Noterete le variabili $Old (che contiene la Reg Ex) e $New . 

A questo punto l’unica cosa che resta da fare è automatizzare l’importazione con un operazione schedulata giornalmente. 

Nella parte Program/Script inseriremo:
C:WindowsSystem32WindowsPowerShellv1.0powershell.exe 



mentre nella parte Add Arguments :
-command ". 'C:Program FilesMicrosoftExchange ServerV14binRemoteExchange.ps1'; Connect-ExchangeServer -auto; c:SignaturesscriptOWASignature.ps1"    (Fig.9)
image
Figura 9
Da ora in poi ogni volta che andrete a modificare il file Word (della firma) automaticamente verranno aggiornate tutte le firme locali di Outlook e quelle di OWA.  

Tutti i file utilizzati in questo articolo sono scaricabili da questo link: http://sdrv.ms/Pi3mIW

VMFS 5: miglioramenti sul file sharing

Facebooktwittergoogle_plusredditlinkedin


Con vSphere 5.0, il numero massimo  di host che potevano condividere un file in read-only sulla VMFS era 8. Questo limite rappresentava una blocco alla scalabilità di ambienti VDI basati su VMware View, proprio a causa del tipo di deployment dei desktop che, in alcuni desktop pool, condividono lo stesso disco di base. Questo limite ha impattato anche nel deployment di vCloud Director per le vApp distribuite con il metodo “fast provisioning” che sfrutta il principio delle VM linked clones.
Con vSphere 5.1 questo limite è stato portato a 32, allineandosi al massimo numero di host supportati per cluster. Questo miglioramento si traduce in una maggiore scalabilità sia per View che per vCloud Director.
In merito a View va ricordato che:
  • con View 5.0 il limite degli host è 8 sia indipendentemente che il datastore sia VMFS o NFS;
  • con View 5.1 il limite degli host è stato spostato a 32 ma solo con l’uso di datastore NFS;
  • il prossimo rilascio di View porterà a 32 il numero degli host anche per i datastore VMFS.
Per maggiori informazioni è possibile consultare il white paper “What’s New in VMware vSphere 5.1 – Storage”.

vSphere Data Protection

Facebooktwittergoogle_plusredditlinkedin


vSphere Data Protection (VDP) è la nuova soluzione per il backup introdotta da VMware con vSphere 5.1; questo prodotto sostituisce vSphere Data Recovery (VDR) presente nelle precedenti versioni. VDP è basato su EMC Avamar e fornisce numerose funzionalità e molte ottimizzazioni per il backup ed il recovery di VM.
vSphere Data Protection viene distribuito come virtual appliance costituito da 4 vCPU e 4 GB di RAM. Rispetto al predecessore nel quale era necessario aggiungere lo storage quale destinazione dei job di backup, vSphere Data Protection è disponibile in 3 configurazioni in base alla dimensione di spazio utilizzabile per il backup:
  • 500 GB;
  • 1 TB;
  • 2 TB
La pianificazione iniziale è essenziale in quanto non è possibile aggiungere ulteriore storage dopo il deployment dell’appliance. Ovviamente i requisiti di spazio per il backup si basano su diversi indicatori quali: il numero di VM che si desidera proteggere, la quantità di dati, il periodo di retention o conservazione del dato e la percentuale di cambiamento dei dati.
La creazione dei job di backup è una operazione fattibile attraverso il vSphere Web Client dalla scheda Backup di VDP. Nel job è possibile selezionare singole VM o contenitori di VM quali datacenter, cluster, host, resource pool e cartelle. Scegliendo un contenitore tutte le VM in esso contenute verranno protette, di conseguenza le nuove VM verranno aggiunte automaticamente al backup, quelle rimosse non verranno più protette. I backup possono essere pianificati giornalmente, settimanalmente o mensilmente.
Il prodotto prevede diverse metodologie di restore:
  • Full image restore
  • CDP restore
  • File Level Restore (FLR)
Quando è richiesto il ripristino completo di una VM, vSphere Data Protection valuta automaticamente quale metodo utilizzare per l’operazione di restore optando per quello più rapido. Quando viene utilizzata la tecnologia Change Block Tracking per il processo di restore delle VM, il software determina, grazie alle “vSphere API for Data Protection”, quale blocco è stato modificato rispetto all’ultimo restore point e rispristina solo quei blocchi.
Per evitare di sovrascrivere VM esistenti è possibile assegnare alla VM un nuovo nome e datastore di destinazione, in questo ultimo caso il restore sarà di tipo “full image”.
Oltre al restore completo è possibile recuperare singoli file o cartelle contenute nelle VM, cosiddetto File Level Restore, attraverso un tool web-based chiamato vSphere Data Protection Restore Client. Questo sistema permette agli utenti di recuperare in autonomia i propri file.
Per quanto riguarda la reportistica, VDP permette all’amministratore di configurare il sistema per inviare via mail i rapporti contenenti i dettagli dell’appliance, dei job di backup e delle VM che sono state salvate. I rapporti possono essere schedulati ad una specifica ora, per qualsiasi giorno o tutti i giorni della settimana.
VDP dispone anche di un meccanismo di “checkpoint e rollback”. Il checkpoint è un backup del sistema che assiste nel caso ci fosse una corruzione dei dati, ad esempio in caso di crash dell’appliance VDP eseguirà il rollback all’ultimo checkpoint valido. Qualsiasi backup eseguito dopo il checkpoint sarà perso ma si eviteranno dati corrotti.
Per maggiori informazioni è possibile:

Space-Efficient Sparse Virtual Disks

Facebooktwittergoogle_plusredditlinkedin


I dischi thin indirizzano una delle maggiori cause di inefficienza nell’uso dello spazio, allocando blocchi di storage al file system delle guest OS solo quando questi sono necessari, piuttosto che preallocarli all’atto della creazione della VM. Questo meccanismo, tuttavia, risolve una parte del problema in quanto se lo spazio viene allocato in scrittura non viene rilasciato quando i dati vengono eliminati nel file system della VM; questo comporta un graduale aumento dello storage vanificando il beneficio del disco thin.
Con il rilascio di vSphere 5.1, VMware ha introdotto una nuova tipologia di virtual disk, il “space-efficient sparse virtual disk (SE sparse disk)”. Una delle maggiori features consiste nell’abilità di recuperare lo spazio precedentemente allocato nel guest OS. Un secondo beneficio sta nella capacità di impostare una dimensione del blocco del disco virtuale in base ai requisiti dell’applicazione. Alcune applicazioni in esecuzione delle VM lavorano meglio con una dimensione grande del blocco, altre invece con blocchi piccoli; in passato questa impostazione non era regolabile.
Come avviene il recupero dello spazio? Il recupero dello spazio precedentemente occupato è suddiviso in 2 fasi:
  • l’eliminazione profonda, wipe operations, che libera un’area contigua di spazio nel VMDK della VM;
  • la riduzione (shrink), che scollega (unmap) l’area liberata dal VMDK e consente allo spazio di ritornare libero.
La fase di wipe è inizializzata dalle VMware Tools che eseguono una scansione del file system del guest OS e marca i blocchi inutilizzati come liberi. Successivamente viene lanciato, sempre nella VM, il comando SCSI UNMAP che comunica nel layer SCSI virtuale nel VMkernel di marcare i blocchi storage come liberi.
La fase di Shrink è differenziata in base al tipo di storage:
  • per gli storage con accesso a blocchi il VMkernel lancia il comando SCSI UNMAP verso lo storage array;
  • per gli storage NFS, ESX esegue una RPC call per troncare il file
Nell’esecuzione di questi task il VMkernel si preoccupa anche di spostare i blocchi alla fine del VMDK all’inizio, per evitare che il troncamento venga operato in una zona contenete dei dati.
Per poter beneficiare di questa funzionalità è richiesto che le VM abbiano il virtual Hardware versione 9, le precedenti edizioni non supportano questo formato disco.
Inizialmente, con vSphere 5.1, l’uso del formato SE sparse è limitato a VMware View. View Composer è in grado di creare VM linked clone durante la distribuzione di VM. Le VM linked clones usano snapshot, aperte in lettura e scrittura, che puntano ad un disco padre. View beneficerà immediatamente sia della funzionalità di crescita granulare del blocco del disco indirizzando problemi legati all’allineamento sperimentati su alcuni storage, sia del recupero dello spazio eliminato.
Per maggiori informazioni è possibile consultare il white paper “What’s New in VMware vSphere 5.1 – Storage”.

Supporto per VM con 64 vCPU

Facebooktwittergoogle_plusredditlinkedin


vSphere 5.1 raddoppia la capacità elaborativa delle VM, consentendo di allocare fino a 64 vCPU, disponendo dell’edizione Enterprise Plus. Con l’edizione Enterprise è invece possibile allocare fino a 32 vCPU, per tutte le altre il limite è 8 vCPU.
Questo miglioramento, insieme alla possibilità di assegnare alla singola VM fino ad 1 TB di RAM, dimostra da un lato la capacità dell’hypervisor di poter sostenere VM con enormi carichi di lavoro in grado di soddisfare la maggior parte delle applicazioni aziendali ora in commercio, dall'altro la facoltà della piattaforma di poter proteggere e spostare “VM mostruose” all’interno del datacenter virtuale.
L’allocazione delle 64 vCPU è fattibile creando VM con il nuovo virtual HW, arrivato con vSphere 5.1 alla versione 9; le precedenti versione 8, 7, e 4 sono ancora supportate dalla nuova piattaforma.

Il Nuovo vSphere Web Client

Facebooktwittergoogle_plusredditlinkedin


La vSphere Web Client è stata introdotta con vCenter 5 e permette di utilizzare un web browser per interfacciarsi con il sistema di gestione di vSphere.
La proliferazione dei prodotti e delle tecnologie collegate alla virtualizzazione ed al cloud ha determinato la necessità di uno strumento di gestione che lato client potesse:
  • avere la capacità di essere fruibile da ambienti eterogenei;
  • uno strumento estensibile ed aperto alle personalizzazioni;
  • capacità di gestire un grande numero di oggetti presenti nei datacenter distribuiti anche geograficamente
Con vSphere 5.1 il client via web diventa la GUI di riferimento, sorpassando le funzionalità offerte dal tradizionale vSphere Client che si installa su sistemi Windows. Tra le funzionalità chiave:
  • Inventory Lists: permettono di sfogliare rapidamente un inventario composto da molti oggetti, sfruttando la logica di mettere in relazione l’oggetto selezionato con tutti gli altri elementi che interagiscono con lui. Il vantaggio principale è quello di evitare di spostarsi tra i diversi inventari  per avere un’informazione dettagliata di un oggetto;
  • Personalizzazione della GUI: non tutti gli utenti usano le interfacce grafiche per le stesse ragioni, in questa ottica il vSphere Client rappresenta un problema a causa della sua rigida GUI, al contrario il vSphere Web Client consente all’utente di personalizzare il proprio ambiente spostando o eleminando gli elementi;
  • Common Action: questa funzionalità viene risolve il problema dei task ripetitivi che vengono svolti cercando di eliminare il tempo e la frustrazione che deriva, il vSphere Web Client fornisce menù con comandi contestuali per eseguire rapidamente i task comuni;
  • Work-in-Progress Workflows: questa funzionalità permette di mettere in pausa dei task indirizzando il problema nell’eseguire i task in modo seriale. Grazie a questo miglioramento è possibile dare più priorità anche ai comandi lanciati in un secondo momento;
  • Advanced Search: le ricerche avanzate permetto di trovare più facilmente gli oggetti all’interno del datacenter, soprattutto quando gli ambienti scalano oppure quando si è in presenza di ambienti cloud;
  • Estensibilità: il nuovo client via Web offre la possibilità a terze parti di integrare le proprie funzionalità, evitando quindi di dover passare da più interfacce per eseguire task che convergono sulla infrastruttura virtuale.
L’architettura del vSphere Web Client è composta da tre layer:
  • il client applicazione multipiattaforma che viene eseguita in un browser web in grado di supportare Adobe Flex
  • l’application server, servizio basato su Virgo e tc Server. SI tratta di una applicazione Java progettata e sviluppata con Spring
  • vCenter e i servizi associati ad esso. vCenter è il servizio principale che fornisce i dati all’application server
Per utilizzare il vSphere Web Client è necessario installare il vSphere Web Client server, quale applicazione su un sistema Windows oppure avviando il servizio già presente sul vCenter Server Appliance.
Per maggiori informazioni è possibile consultare il documento sulle novità introdotte da vCenter Server 5.1

Il Nuovo vSphere Web Client

Facebooktwittergoogle_plusredditlinkedin


La vSphere Web Client è stata introdotta con vCenter 5 e permette di utilizzare un web browser per interfacciarsi con il sistema di gestione di vSphere.
La proliferazione dei prodotti e delle tecnologie collegate alla virtualizzazione ed al cloud ha determinato la necessità di uno strumento di gestione che lato client potesse:
  • avere la capacità di essere fruibile da ambienti eterogenei;
  • uno strumento estensibile ed aperto alle personalizzazioni;
  • capacità di gestire un grande numero di oggetti presenti nei datacenter distribuiti anche geograficamente
Con vSphere 5.1 il client via web diventa la GUI di riferimento, sorpassando le funzionalità offerte dal tradizionale vSphere Client che si installa su sistemi Windows. Tra le funzionalità chiave:
  • Inventory Lists: permettono di sfogliare rapidamente un inventario composto da molti oggetti, sfruttando la logica di mettere in relazione l’oggetto selezionato con tutti gli altri elementi che interagiscono con lui. Il vantaggio principale è quello di evitare di spostarsi tra i diversi inventari  per avere un’informazione dettagliata di un oggetto;
  • Personalizzazione della GUI: non tutti gli utenti usano le interfacce grafiche per le stesse ragioni, in questa ottica il vSphere Client rappresenta un problema a causa della sua rigida GUI, al contrario il vSphere Web Client consente all’utente di personalizzare il proprio ambiente spostando o eleminando gli elementi;
  • Common Action: questa funzionalità viene risolve il problema dei task ripetitivi che vengono svolti cercando di eliminare il tempo e la frustrazione che deriva, il vSphere Web Client fornisce menù con comandi contestuali per eseguire rapidamente i task comuni;
  • Work-in-Progress Workflows: questa funzionalità permette di mettere in pausa dei task indirizzando il problema nell’eseguire i task in modo seriale. Grazie a questo miglioramento è possibile dare più priorità anche ai comandi lanciati in un secondo momento;
  • Advanced Search: le ricerche avanzate permetto di trovare più facilmente gli oggetti all’interno del datacenter, soprattutto quando gli ambienti scalano oppure quando si è in presenza di ambienti cloud;
  • Estensibilità: il nuovo client via Web offre la possibilità a terze parti di integrare le proprie funzionalità, evitando quindi di dover passare da più interfacce per eseguire task che convergono sulla infrastruttura virtuale.
L’architettura del vSphere Web Client è composta da tre layer:
  • il client applicazione multipiattaforma che viene eseguita in un browser web in grado di supportare Adobe Flex
  • l’application server, servizio basato su Virgo e tc Server. SI tratta di una applicazione Java progettata e sviluppata con Spring
  • vCenter e i servizi associati ad esso. vCenter è il servizio principale che fornisce i dati all’application server
Per utilizzare il vSphere Web Client è necessario installare il vSphere Web Client server, quale applicazione su un sistema Windows oppure avviando il servizio già presente sul vCenter Server Appliance.
Per maggiori informazioni è possibile consultare il documento sulle novità introdotte da vCenter Server 5.1

Le novità di Windows Server 2012 – parte 1 – : i nuovi limiti di Hyper-V

Facebooktwittergoogle_plusredditlinkedin

Link per tornare all’indice degli articoli della serie “Le novità di Windows Server 2012” : http://ivansalvade.it/2012/09/06/le-novita-di-windows-server-2012-indice-generale-degli-articoli/ —————————————————————————————————————————————————————————————————————————– Hyper-V 3.0 in Windows Server 2012 implementa nuovi limiti (per host e per macchina virtuale), molti dei quali ampiamente superiori alla precedente release. Eccoli riassunti nelle seguenti tabelle : Limiti per host Hyper-V

Fig. 1 : limiti per singolo Host Hyper-V Limiti per macchina virtuale

Fig. 2 : [...]

Blog italiani (e in italiano) nel mondo IT/ICT