Il Failover Cluster è un gruppo di computer che interagiscono tra di loro per migliorare la disponibilità e la scalabilità dei ruoli cluster. Se in uno o più nodi del cluster si verifica un errore, il servizio verrà garantito dagli altri nodi (processo di failover). I ruoli cluster, inoltre, vengono monitorati in modo proattivo per verificare che funzionino correttamente. Se non funzionano, vengono riavviati o spostati in un altro nodo.

Novità del clustering di failover in Windows Server 2019

• Set di cluster – Consentono di aumentare il numero di server oltre i limiti correnti di un cluster. Questa operazione viene eseguita mediante il raggruppamento di più cluster in un set di cluster. Maggiori papprofondimenti sono disponibili leggendo il mio articolo Introduzione ai Cluster Sets in Windows Server 2019
• Azure-aware cluster – I cluster di failover rileva ora automaticamente quando è in esecuzione nelle macchine virtuali IaaS di Azure e ottimizza la configurazione per garantire il failover proattivo e la registrazione degli eventi di manutenzione pianificata di Azure per ottenere i massimi livelli di disponibilità.
• Migrazione del cluster tra domini (cross-domain)– I cluster di failover si possono ora spostare in modo dinamico da un dominio di Active Directory ad un altro, semplificando il consolidamento dei domini.
• USB witness – È ora possibile usare un semplice dispositivo USB collegato a uno switch di rete come witness nella determinazione del quorum per un cluster.
• Miglioramenti all’infrastruttura di cluster – La cache CSV è ora abilitata per impostazione predefinita per migliorare le prestazioni delle macchine virtuali.
• Cluster Aware Updating supporta Storage Spaces Direct – Cluster Aware Updating (CAU) è ora integrato e compatibile con Storage Spaces Direct e convalida e garantisce il completamento della risincronizzazione dei dati su ciascun nodo. In più controlla gli aggiornamenti solo se necessario e riavvia i nodi in modo intelligente. In questo modo orchestra i riavvii di tutti i server del cluster per la manutenzione pianificata.
• Cluster hardening – Le comunicazioni interne a un cluster tramite Server Message Block (SMB) per Cluster Shared Volumes e Storage Spaces Direct ora sfruttano i certificati per rendere la piattaforma più sicura. In questo modo i cluster di failover possono funzionare senza dipendenze su NTLM e abilitare le baseline di sicurezza.
• Eliminazione dell’autenticazione NTLM – Il cluster di failover non utilizza più l’autenticazione NTLM, ma usa in maniera esclusiva l’autenticazione Kerberos e l’autenticazione basata su certificati. Non sono necessarie modifiche da parte per sfruttare i vantaggi di questo miglioramento della sicurezza.
  

Schema di funzionamento di un cluster

Per realizzare questa guida ho creato un domain controller (DC1.demo.lab) e due server che verranno poi clusterizzati (FS1.demo.lab e FS2.demo.lab). Ho anche creato una macchina che farà da ISCSI target (ISCSI1.demo.lab) ed ospiterà lo storage condiviso dei due nodi del cluster.

Anche se utilizzerò Windows Server 2019, la stessa procedura è valida se utilizzate Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012.

Nella figura sotto è mostrato lo schema del laboratorio realizzato:

Figura 1: Schema del laboratorio realizzato

Prerequisiti per la creazione di un Failover Cluster

Prima di iniziare a configurare il cluster, verificate i prerequisiti seguenti:

• Assicuratevi che tutti i server da aggiungere come nodi del cluster eseguano la stessa versione di Windows Server.
• Esaminate i requisiti hardware per assicurarvi che la configurazione in uso sia supportata. Per altre informazioni seguite la guida Requisiti hardware per il clustering di failover e opzioni di archiviazione.
• Assicuratevi che tutti inodi del cluster possano accedere ad uno storage condiviso.
• Assicuratevi che tutti i server da aggiungere come nodi del cluster siano aggiunti allo stesso dominio Active Directory.
• Assicuratevi che l’account da usare per la creazione del cluster sia un utente di dominio che dispone di diritti di amministratore su tutti i server da aggiungere come nodi del cluster.

NOTA: Per essere supportato da Microsoft, tutto l’hardware deve essere certificato per la versione di Windows Server in esecuzione e la soluzione completa del cluster di failover deve superare tutti i test della Convalida guidata configurazione. Per altre informazioni sulla convalida del cluster di failover, vedere Convalidare l’hardware per un cluster di failover.

Check-list delle attività da eseguire

La creazione di un Failover Cluster richiede l’esecuzione delle seguenti attività:

• Verificare i prerequisiti
• Installare la funzionalità Clustering di failover in tutti i server da aggiungere come nodi del cluster
• Eseguire la convalida guidata del cluster per la verifica della configurazione
• Eseguire la Creazione guidata cluster per creare il cluster di failover
• Creare ruoli del cluster per ospitare i carichi di lavoro del cluster

Configurazione dello storage condiviso

Ad ogni nodo del cluster deve essere collegato storage condiviso, cioè visibile da tutti i nodi. È possibile presentare lo storage ai diversi nodi tramite ISCSI, SAN Fiber Channel, Shared SAS oppure tramite gli Storage Spaces. Ho già avuto modo di parlarvi degli Storage Spaces nell’articolo Implementare Storage Spaces Direct in Windows Server 2016 con Microsoft Azure e nell’articolo Storage Spaces Tiering in Windows Server 2016

In questa guida mi servirò di un ISCSI Target installato sulla macchina ISCSI1.demo.lab che pubblica due dischi: un disco di quorum da 10 GB e un disco dati da 500GB. La configurazione dell’ISCSI Target esula dai contenuti di questa guida. Per approfondimenti vi rimando alla lettura dell’articolo Configure Windows 2012 R2 as iSCSI target

Sui due nodi del cluster, FS1.demo.lab ed FS2.demo.lab, ho collegato i dischi ISCSI utilizzando l’ISCSI Initiator, come mostrato in figura:

Figura 2: Configurazione dell’ISCSI Initiator sui due nodi del cluster

Dopo aver collegato i dischi tramite l’ISCSI Initiator, ho provveduto sulla macchina FS1.demo.lab ad inizializzare i dischi e a formattarli, come mostrato nelle figure sotto:

Figura 3: Inizializzazione dei dischi ISCSI sulla macchina FS2.demo.lab

Figura 4: Formattazione dei due dischi ISCSI sulla macchina FS1.demo.lab

Poiché si tratta di dischi ISCSI, sulla macchina FS2.demo.lab i due dischi risulteranno formattati ma saranno visti offline. Windows infatti non supporta la clusterizzazione dei dischi NTFS. Provvederemo più tardi ad utilizzare la funzionalità di Cluster Shared Volume per permettere ad entrambi i nodi di poter scrivere contemporaneamente sullo stesso disco.

Configurazione della rete

I due nodi sono collegati tramite due schede di rete: una di management ed una dedicata all’heartbeat. Vi consiglio la lettura dell’articolo Configuring Windows Failover Cluster Networks per approfondire tutti i requisiti di rete necessari per il corretto funzionamento del Cluster.

Installazione e configurazione del Cluster

Per configurare uno Scale-out File Server è necessario che su entrambi i nodi venga installata la funzionalità di File Server e di Failover Clustering. Potete servirvi del Server Manager per installare le funzionalità su entrambi i nodi, oppure potete utilizzare il comando PowerShell

$servers = "fs1.demo.lab", "fs2.demo.lab"
foreach ($server in $servers)
{
    Install-WindowsFeature -computername $server –Name Failover-Clustering –IncludeManagementTools
}

Figura 5: Aggiunta del secondo nodo al Server Manager di FS1.demo.lab per poterlo gestire

Figura 6: Aggiunta della funzionalità di Failover Clustering

Effettuate l’installazione del ruolo di File Server e della funzionalità di Failover Clustering anche sul secondo nodo.

Figura 7: Installazione del ruolo di File Server e della funzionalità di Failover Clustering anche sul secondo nodo

Terminata l’installazione della funzionalità, utilizzate la console del Failover Cluster Manager per testare la configurazione dei due nodi e per creare il nuovo cluster. Vi consiglio di verificare i prerequisiti elencati alla pagina Creare un cluster di failover

Lanciate quindi il wizard per la validazione del cluster, in modo tale da essere sicuri che tutti i prerequisiti siano stati rispettati.

Figura 8: Validazione dei nodi del cluster

Figura 9: Validazione effettuata

In alternativa potete utilizzare il comando PowerShell

Test-Cluster –Node fs1.demo.lab,fs2.demo.lab

Terminata la validazione potete creare il nuovo cluster. Cliccate su Create the cluster now using the validates nodes e seguite il wizard di creazione. Indicate il nome del cluster (nel mio caso CLUSTER1) e l’indirizzo IP da assegnargli, come mostrato nelle figure sotto. Io ho anche scelto di aggiungere al cluster tutti i dischi condivisi che sono stati agganciati ai nodi, utilizzando Add all eligible storage to the cluster.

Figura 10: indicazione del nome e dell’indirizzo IP del cluster

Figura 11: Aggiunta dello storage condiviso da tutti i nodi del cluster

Figura 12: Creazione del cluster completata

La creazione del cluster può essere eseguita anche utilizzando il comando PowerShell

New-Cluster –Name CLUSTER1 –Node fs1.demo.lab,fs2.demo.lab –StaticAddress 10.10.10.69

Verificate la creazione del cluster dalla console del Failover Cluster Manager e verificate che i dischi condivisi siano stati aggiunti. Come si vede dalla figura sotto, il disco da 10GB viene utilizzato per il quorum, mentre quello da 500GB è disponibile per i dati e può essere trasformato in un Cluster Shared Volume (CSV). I CSV permettono a tutti i nodi di un cluster di failover di poter accedere contemporaneamente sia in lettura che in scrittura ad un disco formattato NTFS o ReFS. NTFS ed ReFS non sono infatti file system clusterizzabili. Per approfondimenti vi rimando alla lettura dell’articolo Utilizzare volumi condivisi del Cluster in un cluster di failover

Cliccate col tasto destro sul disco da utilizzare e scegliete la voce Add to Cluster Shared Volume.

Figura 13: Aggiunta del disco condiviso al Cluster Shared Volume

Il processo è praticamente istantaneo e permette di trasformare il disco in un mount point. Adesso tutti i nodi del cluster potranno accedere al disco utilizzando il percorso predefinito C:\ClusterStorage\Volume1 e potranno leggere e scrivere contemporaneamente nello storage condiviso.

Figura 14: il disco è stato trasformato in un Cluster Shared Volume

Verificate anche la configurazione delle schede di rete per controllare che ognuna delle schede sia utilizzata nel modo corretto per il management, lo scambio dati e per l’heartbeat.

Figura 15: Configurazione delle reti del cluster

Il cluster è ora configurato.

A questo punto non vi resta che aggiungere al cluster i ruoli di Windows Server oppure le applicazioni che volete rendere disponibili. I ruoli supportati sono:

• Namespace Server
• DFS Namespace Server
• Distributed Transaction Coordinator (DTC)
• File Server
• Generic Application
• Generic Script
• Generic Service
• Hyper-V Replica Broker
• iSCSI Target Server
• iSNS Server
• Message Queuing
• Other Server
• Virtual Machine
• WINS Server

Conclusioni

La funzionalità di Failover Clustering permette di rendere altamente disponibili le nostre applicazioni o le macchine virtuali e diminuisce drasticamente le interruzioni di servizio (downtime). Già da Windows Server 2012 R2 Microsoft supporta failover cluster fino a 64 nodi fisici ed una scalabilità fino a 8.000 macchine virtuali in esecuzione contemporaneamente. Ogni nodo fisico con Hyper-V è in grado di eseguire fino a 1024 macchine virtuali.

Abbiamo visto nel precedente articolo Azure Cloud Shell – Amministrazione di Microsoft Azure con una shell accessibile tramite browser che Azure Cloud Shell ci permette di gestire e sviluppare le risorse in Microsoft Azure senza la necessità di installare e aggiornare i tool di gestione.

La comodità offerta da Azure Cloud Shell è davvero notevole e la semplicità di attivazione, sia tramite browser che tramite app sullo smartphone, ci permette di poterla utilizzare praticamente ovunque.

La shell viene eseguita in un Linux Container basato su Ubuntu 16.04 LTS e include gli strumenti più usati dell’interfaccia della riga di comando, tra cui gli interpreti della shell Linux, i moduli di PowerShell, gli strumenti per amministrare Azure, gli editor di testo, il controllo del codice sorgente, gli strumenti per la compilazione, gli strumenti per i contenitori, gli strumenti per i database e altro ancora. Cloud Shell include anche il supporto per alcuni linguaggi di programmazione più diffusi, ad esempio Node.js, .NET e Python.

Nella tabella sotto sono riportati gli strumenti e i linguaggi disponibili nella Cloud Shell:

Strumenti

Linguaggi supportati

È possibile lanciare Azure Cloud Shell direttamente dal portale di Azure, utilizzando il simbolo presente in alto, oppure dal link https://shell.azure.com

Figura 1: Azure Cloud Shell eseguita dal portale di Azure

Figura 2: Azure Cloud shell eseguita dallo smartphone tramite l’app Azure

Alla pagina https://azure.microsoft.com/it-it/features/azure-portal/mobile-app/ trovate maggiori informazioni sull’app per dispositivi mobili di Azure

Azure Cloud Shell utilizza una condivisione di File di Azure per salvare in modo permanente i file. Quando lanciate per la prima volta Azure Cloud Shell verrà richiesta la creazione di una condivisione di file in Azure Files (sarà necessario indicare quale storage account utilizzare per mantenere i file) e questa condifisione verrà ricollegata automaticamente tutte le volte che rilancerete la Azure Cloud Shell. La risorsa di archiviazione viene resa persistente come un file .img nella condivisione file di Azure e sarà montata come $HOME\clouddrive.

Sarà anche possibile caricare script all’interno della file share creata, in modo tale da poterli riutilizzare tutte le volte che saranno necessari

Figura 3: È possibile caricare script all’interno della Azure File Share

Per caricare file all’interno della directory clouddrive è anche possibile utilizzare il portale di Azure accedendo direttamente allo storage account associato alla Azure Cloud Shell cliccando sul link Manage file share mostrato nella figura precedente.

Nell’esempio sotto ho caricato un file chiamato CreaUnaNuovaVMWindows.ps1 all’interno della sottocartella Scripts. È possibile caricare script, template ARM e altri file da riutilizzare.

Figura 4: I file possono essere caricati anche direttamente nella file share dello storage account associato ad Azure Cloud Shell

Per verificare qual è il mount point del vostro clouddrive potete lanciare il comando Get-CloudDrive, come mostrato in figura 5 e successivamente potete spostare il prompt nella posizione indicata. Nel mio caso il mount point è /home/nicola/clouddrive

Figura 5: Dall’interno di Azure Cloud Shell è possibile navigare nel clouddrive e accedere ai propri script

Creazione e modifica dei file utilizzando gli editor disponibili in Azure Cloud Shell

Azure Cloud Shell permette di utilizzare un editor di file progettato in base allo strumento open source Monaco Editor, un web-standard editor che è anche alla base di Visual Studio Code. Eseguendo semplicemente il comando code in Azure Cloud Shell, oppure cliccando sul pulsante presente nella barra degli strumenti, è possibile modificare i propri script ed i propri file direttamente nella finestra di Cloud Shell. I file creati e modificati verranno salvati nel vostro clouddrive.

Figura 6: Modifica dello script PowerShell precedentemente caricato nel clouddrive utilizzando code

Per tutti i “nostalgici” c’è anche la possibilità di utilizzare gli editor nano, vi ed emacs, visto che come ho accennato prima la shell viene eseguita in un Linux Container basato su Ubuntu 16.04 LTS.

Figura 7: Utilizzo degli editor nano, vi ed emacs in Azure Cloud Shell

Conclusioni

Azure Cloud Shell è uno strumento interattivo, potente, versatile e soprattutto comodo per poter amministrare le nostre risorse in Cloud. Da un browser, da un tablet o da uno smartphone abbiamo la possibilità di collegarci facilmente alla Shell ed operare ovunque ci troviamo, senza la necessità di installare nulla. La Shell è gestita e aggiornata da Microsoft, in modo tale da poter avere sempre i nostri strumenti aggiornati e gli editor presenti ci permettono di modificare con enorme semplicità i nostri script ed i nostri file di configurazione.

La funzionalità di Shadowing delle sessioni remote è presente da diverso tempo in RDS, sebbene abbia vissuto fasi alterne nel tempo, come è possibile leggere in questo Post di Ermanno Goletto. Per chi non la conoscesse, si tratta della possibilità di accedere, in modalità visualizzazione o controllo, ad una sessione RDP attiva su un session Host.

In una infrastruttura RDS è possibile sfruttare questa funzione per fornire assistenza e supporto agli utenti, interagendo con le loro attività.

Di default è attiva ed è utilizzabile direttamente da Server Manager nel contesto di gestione della Farm RDS, è sufficiente individuare la Collection, ed identificare la sessione a cui connettersi

Server Manager\Remote Desktop Services\Collections\Desktop1

Identificata la sessione, con il dato DX selezionare Shadow

Figura 1 selzione della sessione connessa

Si apre a questo punto una maschera in cui viene richiesto di specificare la modalità di connessione, ossia se in sola visualizzazione o in controllo e quindi in piena interazione con l’utente, è anche possibile specificare se richiedere all’utente il consenso alla connessione.

Figura 2 modalità di connessione

A questo punto proseguendo con OK all’utente connesso viene proposto un messaggio che lo informa della richiesta di accesso

Figura 3 prompt di conferma della richiesta di accesso

Non appena ottenuta la conferma la sessione può essere controllata o visualizzata da remoto

Questo comportamento, come detto prima, è di default e l’accesso è possibile in quanto il permesso di Shadowing sulle connessioni RDP è concesso agli utenti Amministratori.

Gestione dei permessi di Shadowing

Nel caso sia necessario garantire questa funzionalità ad utenti non amministratori è necessario che il permesso venga esplicitato per i vari utenti, direttamente sulla connessione RDP dei singoli Session Host

Per una gestione più semplice è preferibile creare un gruppo all’interno di AD ed assegnare il permesso di Shadowing a questo gruppo, successivamente verranno definiti come membri i vari utenti che dovranno operare in modalità Shadow sulle sessioni RDS

La modifica dei permessi di default avviene con un comando che opera direttamente tramite WMI sulle proprietà della connessione RDP dei Session Host. Tramite GPO invece è possibile modificare la modalità di accesso alle sessioni RDS.

Impostazioni tramite Wmic (WMI)

Supponendo di aver creato sul dominio ICTPOWER il gruppo UtentiRdsShadowing il comando per assegnarne i permessi è il seguente

wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName=”RDP-Tcp”) CALL AddAccount “ictpower\UtentiRdsShadowing”,2

più in dettaglio vediamo che viene identificato il nome della connessione RDP con TerminalName RDP-Tcp e con AddAccount viene definito il gruppo ictpower\UtentiRdsShadowing il parametro al termine del comando prevede 3 valori:

• 0 = WINSTATION_GUEST_ACCESS
• 1 = WINSTATION_USER_ACCESS
• 2 = WINSTATION_ALL_ACCESS

Per verificare le impostazioni correnti è possibile utilizzare il comando

wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting

il cui output sarà simile a questo

Caption DenyAdminPermissionForCustomization Description InstallDate Name PolicySourceDenyAdminPermissionForCustomization Status StringSecurityDescriptor TerminalName

O:SYG:SYD:(A;;CC;;;IU)(A;;0xf03bf;;;SY)(A;;CCSWLOSDRCWDWO;;;LS)(A;;CCLO;;;NS)(A;;0xf03bf;;;BA)(A;;CCWPCR;;;RD)S:NO_ACCESS_CONTROL Console

O:SYG:SYD:(A;;0xf03bf;;;S-1-5-21-263436683-1377918197-1349984968-1110)(A;;CC;;;IU)(A;;0xf03bf;;;SY)(A;;CCSWLOSDRCWDWO;;;LS)(A;;CCLO;;;NS)(A;;0xf03bf;;;BA)(A;;CCWPCR;;;RD)S:(AU;FA;CCWPCR;;;WD) RDP-Tcp

In grassetto nell’ultima riga è riportato il SID del gruppo ictpower\UtentiRdsShadowing, per poter risalire al nome del gruppo dato il SID il comando è sufficiente utilizzare il Cmd-Let

Get-ADGroup -Identity S-1-5-21-263436683-1377918197-1349984968-1110

Se fosse necessario ricondurre le impostazioni ad un valore di default è possibile utilizzare il comando seguente

wmic /namespace:\\root\CIMV2\TerminalServices PATH WIN32_TSPermissionsSetting WHERE (TerminalName="RDP-Tcp") CALL RestoreDefaults

dopo la variazione dei permessi di accesso tramite il comando VMIC è necessario riavviare il servizio RDS con il comando

net stop "Remote Desktop Services" && net start "Remote Desktop Services"

Impostazioni tramite Group Policy (GPO)

Le impostazioni per mezzo delle GPO definiscono la modalità con cui gli utenti che richiedono di effettuare lo shadow potranno accedere alla Sessione

La Group Policy è configurabile in Computer/Policies/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connection

Figura 4 impostazione delle modalità di shadowing

Si può definire l’accesso in controllo completo con o senza autorizzazione utente, l’accesso in sola modalità visualizzazione con o senza autorizzazione esplicita dell’utente ed una ulteriore impostazione che nega qualunque tipo di accesso allo shadow delle sessioni, chiaramente questa configurazione è indipendente dai permessi di accesso impostati con WMIC che devono comunque essere dichiarati.

La Group Policy vista in figura 4 è configurabile a livello Macchina e quindi per qualunque utente che ha una connessione sul Session Host, nel caso fosse necessario definire regole diverse di controllo delle sessioni RDS in base agli utenti collegati, è possibile attivare una Group Policy nel contesto utente e come tale applicata solamente a determinati account.

La Group Policy è configurabile in User/Policies/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connection

Figura 5 impostazioni modalità di shadowing nel contesto utente

La GPO deve essere assegnata alla OU dove risiede l’utente che deve essere controllato e non all’utente che effettua il controllo sulla sessione RDS, per il resto le impostazioni sono identiche a quelle viste per il contesto macchina.

Utilizzo di Script in Powershell e del client RDS per la gestione delle attività di Shadowing

Fino a questo punto abbiamo visto le impostazioni dell’ambiente RDS e la modalità di accesso allo Shadowing avviene a partire dal Server Manager e dalle funzioni disponibili nella sua interfaccia.

Essendo a conoscenza dell’Id della sessione RDS su un determinato Session Host, è possibile eseguire il client RDP in modo che effettui il mirroring della sessione voluta.

Supponendo di eseguire l’accesso alla sessione 10 sul server RDSH01 in modalità di controllo, dovremo eseguire il comando MSTSC con le impostazioni seguenti:

Mstsc.exe /v: /shadow:10 /control

Nel caso in cui non sia necessario eseguire il controllo ma solo la visualizzazione della sessione è sufficiente omettere l’opzione /control

L’individuazione dell’id della sessione non è propriamente immediato, soprattutto nel caso in cui l’accesso alla Farm RDS avviene con un unico utente comune a più connessioni, l’elenco all’interno del Server Manager presenta in questo caso molteplici connessioni tutte originate dal medesimo utente.

E’ necessario quindi individuare l’ID della sessione direttamente dall’interno della stessa eseguendo il command-let Get-Process

(Get-Process -PID $pid).SessionID

Ottenuto il valore numerico relativo alla sessione, è possibile effettuarne il mirroring come visto sopra.

Scenario di utilizzo delle funzioni di Shadow

in ambienti distribuiti, con operatori che svolgono la funzione di assistenza nei confronti degli utenti della farm RDS è importante permettere che da un lato l’operatore che richiede supporto possa indicare in modo preciso le informazioni sulla propria connessione, e dall’altro il personale addetto al supporto possa accedere in visualizzazione o controllo della sessione senza possibilità di errori.

Qui di seguito sono riportati due script in PowerShell che permettono in modo semplice l’individuazione delle informazioni sulla sessione connessa alla Farm RDS, e la creazione guidata di una sessione di accesso in mirror o controllo della sessione stessa, chiaramente il primo script dovrà essere eseguito all’interno della sessione, ed il secondo script dovrà essere eseguito da una qualunque postazione di rete con le credenziali di un utente che dispone dei permessi di accesso in Shadow come visto in precedenza.

Per fare si che ogni utente che accede alla farm RDS abbia disponibile sul desktop il collegamento allo script di identificazione della sessione è possibile usare le Group Policy.

Identificazione della sessione RDS

#### Script per identificare (dato un desktop in RDS) il client da cui viene avviata la  sessione, il server Session Host su cui si è collegati,e l'identificativo di Sessione
# dichiarazione Variabili e recupero info di sessione
$TsSessionID = (Get-Process -PID $pid).SessionID
$TsServerName = $env:COMPUTERNAME
$TsClientName = $env:CLIENTNAME

## Creazione della stringa messaggio inserita nel Pop-Up Utente

$InfoSessioneTS = "Nome Client:  " + $TsClientName   + "`r`n"  +  "Nome Server:  " + $TsServerName   +   "`r`n" +  "Identificativo Sessione RDS ID:   " +$TsSessionID
Write-Host $InfoSessioneTS

###
Add-Type -AssemblyName System.Windows.Forms

# Costruzione della Msg-Box 
function Read-MessageBoxDialog([string]$Message, [string]$WindowTitle, [System.Windows.Forms.MessageBoxButtons]$Buttons = [System.Windows.Forms.MessageBoxButtons]::OK, [System.Windows.Forms.MessageBoxIcon]$Icon = [System.Windows.Forms.MessageBoxIcon]::None)
{
       return [System.Windows.Forms.MessageBox]::Show($Message, $WindowTitle, $Buttons, $Icon)
}

$buttonClicked = Read-MessageBoxDialog -Message $InfoSessioneTS   -WindowTitle "IctPower " -Buttons OK -Icon Information

Una volta eseguito questo script costruisce una MsgBox con riassunte le informazioni utili ad identificare la sessione

Figura 6 informazioni di sessione

Lo script sarà avviato direttamente da un file .cmd opportunamente strutturato e nel caso si voglia utilizzare una GPO per la pubblicazione del link sul desktop, questa dovrà riferirsi al file di avvio

start /min C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe C:\supporto\IdentificaSessione.ps1

Gestione guidata del di Mirror della sessione RDS

Individuata la sessione all’interno della Farm RDS è possibile utilizzare questo script per creare l’accesso in Shadow alla sessione stessa, lo script è più complesso nella sua costruzione ma non fa altro che creare una check-box per ogni Session-Host presente, consentire l’immissione del valore dell’ID sessione ed un ulteriore check-box relativo alla funzione di controllo o semplice visualizzazione della sessione, ottenute queste impostazioni viene strutturato ed eseguito il comando MSTSC come visto sopra.

######   Script per l'avvio di una sessione Shadow su RDSSession Host 
######   Per ogni Controllo  System.Drawing.Point(x,y) per posizionamento nel Form (1,1) in alto a sx
######   Per ogni Session Host è necessario definire il comando VMIC di concessione della sessione Shadow al Gruppo/utenti 

Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName System.Drawing

# Creazione del Form generale
$form = New-Object System.Windows.Forms.Form
$form.Text = 'ICTPower'
$form.Size = New-Object System.Drawing.Size(500,300)
$form.StartPosition = 'CenterScreen'

# Creazione del Tasto Ok
$OKButton = New-Object System.Windows.Forms.Button
$OKButton.Location = New-Object System.Drawing.Point(150,220)
$OKButton.Size = New-Object System.Drawing.Size(75,23)
$OKButton.Text = 'OK'
$OKButton.DialogResult = [System.Windows.Forms.DialogResult]::OK
$form.AcceptButton = $OKButton
$form.Controls.Add($OKButton)

# Creazione del Tasto Cancel
$CancelButton = New-Object System.Windows.Forms.Button
$CancelButton.Location = New-Object System.Drawing.Point(300,220)
$CancelButton.Size = New-Object System.Drawing.Size(75,23)
$CancelButton.Text = 'Cancel'
$CancelButton.DialogResult = [System.Windows.Forms.DialogResult]::Cancel
$form.CancelButton = $CancelButton
$form.Controls.Add($CancelButton)

# Definizione di una Etichetta di Commento Generale
$TestoForm = New-Object System.Windows.Forms.Label
$TestoForm.Location = New-Object System.Drawing.Point(10,20)
$TestoForm.Size = New-Object System.Drawing.Size(280,20)
$TestoForm.Text = 'Inserire le Informazioni sulla Sessione Remota:'
$form.Controls.Add($TestoForm)



##### Costruzione Area Inserimento ID Sessione
##### Etichetta e Textbox    
$TestoRDSId = New-Object System.Windows.Forms.Label
$TestoRDSId.Location = New-Object System.Drawing.Point(10,40)
$TestoRDSId.Size = New-Object System.Drawing.Size(130,20)
$TestoRDSId.Text = 'Id Sessione RDS:'
$Form.Controls.Add($TestoRDSId)

$TsSessionID = New-Object System.Windows.Forms.TextBox
$TsSessionID.Location = New-Object System.Drawing.Point(150,40)
$TsSessionID.Size = New-Object System.Drawing.Size(40,20)
$form.Controls.Add($TsSessionID)


##### Costruzione Area Inserimento checkbox Monitoraggio/Controllo
#Checkbox Controllo
$CheckboxTsSessionControl = New-Object System.Windows.Forms.CheckBox
$CheckboxTsSessionControl.Location = New-Object System.Drawing.Point(250,40)
$CheckboxTsSessionControl.Size = New-Object System.Drawing.Size(210,30)
$CheckboxTsSessionControl.Text = "Selezionare per Controllo Sessione - Default solo Visualizzazione"
$form.Controls.Add($CheckboxTsSessionControl)


#### Costruzione Area Inserimento CheckBox di definizione dei SessionHost

#Checkbox RdSh01
 $Checkboxrdsh01 = New-Object System.Windows.Forms.Checkbox 
 $Checkboxrdsh01.Location = New-Object System.Drawing.Point(150,80) 
 $Checkboxrdsh01.Size = New-Object System.Drawing.Size(300,20)
 $Checkboxrdsh01.Text = "RDSH01"
 $Form.Controls.Add($Checkboxrdsh01)

 
 #Checkbox RdSh02
 $CheckboxRdsh02 = New-Object System.Windows.Forms.Checkbox 
 $CheckboxRdsh02.Location = New-Object System.Drawing.Point(150,110) 
 $CheckboxRdsh02.Size = New-Object System.Drawing.Size(300,20)
 $CheckboxRdsh02.Text = "RDSH02"
 $Form.Controls.Add($CheckboxRdsh02)

 #Checkbox RdSh03
 $CheckboxRdsh03 = New-Object System.Windows.Forms.Checkbox 
 $CheckboxRdsh03.Location = New-Object System.Drawing.Point(150,140) 
 $CheckboxRdsh03.Size = New-Object System.Drawing.Size(300,20)
 $CheckboxRdsh03.Text = "RDSH03"
 $Form.Controls.Add($CheckboxRdsh03)

 
 #Checkbox RdSh04
 $CheckboxRdsh04 = New-Object System.Windows.Forms.Checkbox 
 $CheckboxRdsh04.Location = New-Object System.Drawing.Point(150,170) 
 $CheckboxRdsh04.Size = New-Object System.Drawing.Size(300,20)
 $CheckboxRdsh04.Text = "RDSH04"
 $Form.Controls.Add($CheckboxRdsh04)


## Carico il Form
$form.Add_Shown({$TestoForm.Select()})
$result = $form.ShowDialog()
$form.Topmost = $true


### Attribuzione Switch di controllo alla stringa di Connessione
if ( $CheckboxTsSessionControl.Checked){

    $TsSessionControl = "/Control"
       }


# Avvio di MSTSC sulla base degli input definiti
$RDSId = $TsSessionID.Text
if (($result -eq [System.Windows.Forms.DialogResult]::OK) -and 
   (($Checkboxrdsh01.Checked) -or 
   ($CheckboxRdsh02.Checked)-or 
   ($CheckboxRdsh03.Checked) -or 
   ($CheckboxRdsh04.Checked))) {
   
   if ($Checkboxrdsh01.Checked)   {
        $RdsHost = "rdsh01.ictpower.local"
        Write-Host $RdsHost
   }
    elseif ($CheckboxRdsh02.Checked)   {
        $RdsHost = "rdsh02.ictpower.local"
        Write-Host $RdsHost
   }
    elseif ($CheckboxRdsh03.Checked)   {
        $RdsHost = "rdsh03.ictpower.local"
        Write-Host $RdsHost
   }
    elseif ($CheckboxRdsh04.Checked)   {
        $RdsHost = "rdsh04.ictpower.local"
        Write-Host $RdsHost
   }
  
    Mstsc.exe /v:$RdsHost  /shadow:$RDSId  $TsSessionControl
    
}

Figura 7

La figura qui sopra riporta il form che viene creato per mezzo di questo script, premendo ok in questo caso si effettua il mirror della sessione numero 5 sul Session Host RDSH01

Considerazioni

Le soluzioni proposte in questo articolo prendono spunto da un caso reale dove si è reso necessario permettere ad un gruppo di utenti di accedere in modalità di consultazione o controllo al fine di fornire assistenza agli utilizzatori su un certo numero di applicativi distribuiti da una Farm RDS, la scelta di implementazione della soluzione ha previsto l’impiego di pochi utenti di accesso comuni a numerosi utenti singoli, e demandando la successiva autenticazione a livello applicativo. Questa modalità ha evidenziato le problematiche esposte sopra relative all’identificazione delle singole Sessioni.

Dal 21 maggio 2019 tutti possono scaricare Windows 10, versione 1903 che finalmente è stata rilasciata al pubblico dopo che era stata rilasciata il 18 Aprile ai sottoscrittori MSDN.

Da tutti i partecipanti al programma Windows Insider questa versione era conosciuta come 19H1. Il nome ufficiale che è stato scelto è invece May 2019 Update e la build rilasciata è la 18362, che porta diverse novità interessanti.

Figura 1: build rilasciata di Windows 10, versione 1903

Le novità introdotte in questa versione di Windows 10 sono:

• Windows Sandbox (una delle novità più interessanti)
• Windows Defender Application Guard migliorato
• Windows Defender Application Control (WDAC) migliorato
• Reserved Storage (OEM e installazioni pulite)
• Miglioramenti nella protezione dell’Identità
• Miglioramenti nella Console e WSL
• Miglioramenti per la Sicurezza del sistema
• Miglioramenti nel pannello Impostazioni di Windows
• Miglioramenti nell’interfaccia del sistema
• Possibilità di rimuovere alcune applicazioni pre-installate
• Windows Update ridisegnato e semplificato
• Impostazioni privacy per il microfono
• Cortana separato dalla Ricerca

Tema Chiaro e nuovo sfondo

Tra le novità più evidenti vi segnalo un Tema chiaro (Light Theme), richiesto a gran voce dai feedback raccolti e uno nuovo sfondo ufficiale del sistema operativo, che ha ora un taglio essenziale e decisamente più moderno. Il menu Start è stato alleggerito e ci sono meno icone che ne semplificano l’utilizzo.

Figura 2: Tema light e nuovo sfondo per Windows 10, versione 1903

Clipboard History

È stata aggiunta una nuova esperienza per gli appunti (clipboard) che deve essere precedentemente abilitata dall’app Settings e che permette di mantenere una cronologia di ciò che avete copiato precedentemente negli appunti. Abilitando la Clipboard History potrete utilizzare la combinazione di tasti Win+V per far apparire uno snippet che vi mostrerà la cronologia degli appunti che potrete incollare.

Figura 3: Clipboard History in Windows 10, versione 1903

Mirroring degli smartphone Android

Dalla build 18356 di Windows 10 19H1 (Fast Ring) era apparsa agli Insider la possibilità di eseguire le applicazioni Android sul PC grazie ad una nuova funzionalità dell’applicazione Il tuo telefono e che permette di effettuare il mirroring del proprio smartphone Android. La funzionalità ha subito destato il mio interesse perché spesso durante le mie lezioni duplico lo schermo del mio smartphone per mostrare le app di gestione di Microsoft 365 oppure per mostrare le app di Multi-Factor Authentication. L’applicazione di fatto permette di controllare in maniera completa il proprio smartphone Android dal PC con Windows 10, solo che al momento della stesura di questo articolo è limitata solo a pochi modelli di smartphone con Android 7.0 o superiore:

• Samsung Galaxy S8
• Samsung Galaxy S8+
• Samsung Galaxy S9
• Samsung Galaxy S9+
• Samsung Galaxy S10
• Samsung Galaxy S10+
• Samsung Galaxy S10e
• Samsung Galaxy Note 8
• Samsung Galaxy Note 9
• OnePlus 6
• OnePlus 6T

Trovate la lista aggiornata alla pagina https://answers.microsoft.com/en-us/insider/forum/insider_apps-insider_other-insiderplat_pc/phone-screen-supported-devices/18794409-3e4a-40eb-a6b1-7d06a16b956e

Per poter collegare il telefono al proprio PC è necessario andare in Settings e scegliere Phone (in italiano Il tuo telefono).

Collegate il vostro smartphone cliccando su Add a phone e installate l’app Microsoft Launcher dal Play Store. Per collegare tra di loro i diversi dispositivi vi verrà chiesto di utilizzare un Microsoft Account. Se non avete mai collegato il vostro account Microsoft al vostro PC Windows 10 vi verrà chiesto di loggarvi. Cliccate sul pulsante Sign in with Microsoft.

Seguite la procedura per collegare il vostro Microsoft Account

Figura 4: Collegamento del Microsoft Account al proprio PC

Il Microsoft Account vi permette di poter ricevere la posta sul vostro PC Windows 10 oppure di sincronizzare la vostra rubrica e le vostre impostazioni. Ritornate alla pagina Home della vostra App Settings e cliccate nuovamente sul pulsante Phone. Cliccate sul pulsante “Add a phone” ed inserite il vostro numero di cellulare. Riceverete un SMS con un link che vi permetterà di scaricare l’App per lo smartphone che vi permetterà di collegarlo al vostro PC Windows 10.

Figura 5: Collegamento dello smartphone al proprio PC

Controllate quindi il vostro smartphone e verificate di aver ricevuto l’SMS con il link per scaricare l’App. Cliccate sul link e scaricate ed installate l’App Microsoft Launcher

Figura 6: Installazione dell’app Microsoft Launcher sul proprio smartphone

Installate e lanciate l’App Microsoft Launcher. Vi verrà chiesto di inserire le credenziali del vostro Microsoft Account. Seguite la procedura e al termine vedrete che il vostro smartphone sarà stato aggiunto al PC.

Per poter utilizzare lo Screen Mirroring è necessario che sia lo smartphone che il PC siano collegati tramite bluetooth e che il dispositivo bluetooth installato nel PC supporti la funzionalità “Bluetooth radio supports Low Energy Peripheral Role”

Per verificarlo potete utilizzare Gestione periferiche, selezionare il dispositivo Bluetooth e aprirne le Proprietà. Dalla Scheda Dettagli verificate che Bluetooth radio supports Low Energy Peripheral Role sia true.

Figura 7: Il dispositivo bluetooth deve supportare la funzionalità “Bluetooth radio supports Low Energy Peripheral Role”

Purtroppo, non ho potuto ancora testare personalmente la funzionalità, ma vi lascio qui sotto un video che ve la mostra:

Windows Sandbox

Si tratta di una funzionalità che permette di eseguire Windows 10 in un ambiente protetto all’interno del quale poter testare ed eseguire software che riteniamo non sicuro, senza il rischio che possa creare danni al nostro sistema.

Windows Sandbox è basato sulla tecnologia degli Hyper-V Containers, in cui ogni contenitore viene eseguito all’interno di una speciale macchina virtuale. In questo modo viene offerto un isolamento a livello di kernel tra ogni contenitore di Hyper-V e l’host Windows 10.

In questo ambiente desktop isolato siamo quindi sicuri che l’applicazione girerà in maniera completamente isolata rispetto al sistema operativo host e soprattutto non avremo la necessità di dover creare una macchina virtuale dedicata per questo scopo. Ogni software che verrà installato in Windows Sandbox rimarrà nella sandbox. Una volta che Windows Sandbox verrà chiuso, tutto il software installato e tutti i file creati verranno automaticamente cancellati.

Le caratteristiche principali di Windows Sandbox sono:

• È parte del sistema operativo: Tutto ciò che è necessario per far funzionare Windows Sandbox è incluso in Windows 10 Pro e Enterprise. Non c’è bisogno di scaricare o di creare un virtual disk (VHD)
• Installazione sempre pulita: Tutte le volte che Windows Sandbox viene eseguito è pulito come se fosse una nuova installazione di Windows.
• Usa e getta: Nulla resta sul dispositivo, tutto verrà cancellato una volta chiusa l’applicazione Windows Sandobx.
• Sicuro: Usa la virtualizzazione hardware-based per isolare il kernel, che si affida a Microsoft Hyper-V per eseguire un kernel separato che isola Windows Sandbox dal sistema operativo.

Windows Sandbox occupa solo 25MB e al momento dell’installazione occuperà circa 100MB. Si tratta infatti di un’immagine generata dinamicamente e che verrà utilizzata per creare un Hyper-V Container molto leggero. Utilizzerà infatti i file presenti all’interno del sistema operativo host Windows 10 per potersi generare, come mostrato nella figura sotto:

Figura 8: Principio di funzionamento dell’immagine di WIndows Sandbox

Prerequisiti per l’utilizzo della funzionalità Windows Sandbox

Per poter utilizzare questa nuova funzionalità è necessario che vengano rispettati i seguenti prerequisiti:

• Windows 10 Pro oppure Enterprise
• Architettura a 64bit
• Virtualization capabilities abilitate nel BIOS
• Almeno 4GB of RAM (8GB raccomandati)
• Almeno 1 GB di spazio disco libero (disco SSD raccomandato)
• Almeno 2 core (4 cores con hyperthreading raccomandati)

Se volete utilizzare questa funzionalità all’interno di una macchina virtuale, poiché verrà utilizzato Hyper-V, sarà necessario abilitare la virtualizzazione annidata (nested virtualization) nella VM. A macchina spenta, eseguite il seguente comando nell’host Hyper-V fisico:

Set-VMProcessor -VMName <Nome della VM> -ExposeVirtualizationExtensions $true

In questo modo viene abilitata la virtualizzazione nidificata per la macchina virtuale.

Per abilitare la funzionalità è sufficiente andare in Settings > Apps > Programs and Features > Turn Windows Features on or off, quindi selezionare Windows Sandbox come mostrato in figura:

Figura 9: Abilitazione della funzionalità Windows Sandbox

Il sistema di riavvierà un paio di volte, per permettere l’installazione della funzionalità.

Terminata l’installazione basterà cercare Windows Sandbox nel menu Start per poter avviare la sandbox.

Figura 10: Windows Sandbox in esecuzione

Per testare applicazioni o eseguire file sospetti vi basterà effettuare un copia-incolla per copiare l’eseguibile dall’host all’interno della Sandbox e poi testarlo, oppure potrete scaricarlo direttamente da Internet. La Windows Sandbox infatti naviga in Internet tramite una rete NAT grazie al Default Virtual Switch che viene installato in Windows 10.

Chiudendo la Windows Sandbox annullerete tutte le modifiche fatte. Un messaggio vi avvertirà che perderete tutti i dati.

Figura 11:Messaggio di avviso di perdita dati alla chiusura di Windows Sandbox

Miglioramenti nella protezione dell’identità

In Windows 10, versione 1903 è stato migliorato il supporto per la passwordless FIDO authentication tramite Windows Hello oppure tramite FIDO security Key che supportano gli standard FIDO2 (Fast IDentity Online) e CTAP2 (Client-to-Authenticator Protocol) in Microsoft Edge e nelle versioni più recenti di Mozilla Firefox. Trovate l’annuncio ufficiale alla pagina https://fidoalliance.org/microsoft-achieves-fido2-certification-for-windows-hello/

Accedere senza password è una delle funzionalità che ultimamente Microsoft sta promuovendo maggiormente e i dispositivi biometrici, ormai diffusi in tutti i computer portatili, possono essere utilizzati per accedere a Windows e alle applicazioni web. Per approfondimenti sull’uso del protocollo WebAuthn per l’autenticazione delle applicazioni web vi rimando alla lettura del documento https://www.w3.org/2018/Talks/06-WebAuthn.pdf

Per configurare Windows Hello con un lettore di impronte digitali e fare in modo che l’accesso al Microsoft Account avvenga senza inserire la password vi rimando alla lettura dell’articolo Utilizzare Windows Hello in Windows 10 per accedere al Microsoft Account con WebAuthn, mentre se volete farlo tramite una Security Key (nel mio caso una Yubikey 5 Nano) vi rimando alla lettura dell’articolo Passwordless login al Microsoft Account con Yubikey

Figura 12: Accesso al Microsoft Account utilizzando la webauth in Mozilla Firefox

Figura 13: Richiesta di autenticazione tramite impronta digitale oppure tramite Security Key

Reserved Storage

In questa release di Windows 10 sono state introdotte delle migliorie sulla gestione dello spazio del disco. Attraverso Reserved Storage parte dello spazio del disco verrà messo da parte in modo tale da poter essere utilizzato per gli aggiornamenti, per le applicazioni, per i file temporanei e per la cache di sistema. L’obiettivo è migliorare la funzionalità quotidiana del PC assicurando che le funzioni critiche del sistema operativo abbiano sempre accesso allo spazio su disco.

Se effettuate un’installazione pulita di Windows 10, versione 1903 Reserved Storage verrà abilitato di default e non sarà necessario effettuare alcuna operazione aggiuntiva. Se invece effettuate un aggiornamento al momento l’opzione non è disponibile.

Inizialmente lo spazio riservato è di 7GB, ma verrà dinamicamente aumentato man mano che installerete applicazioni. Reserved Storage non può essere rimosso dal sistema operativo, ma è possibile ridurre la quantità di spazio riservata rimuovendo funzioni (da Settings > Apps > Apps & features > Manage optional feature) e lingue opzionali inutilizzate.

Per verificare lo spazio utilizzato da Reserved Storage potete utilizzare l’app Settings > cercate Storage Settings > cliccate sul link Show more categories > cliccate su System & reserved

Figura 14: Reserved Storage in Windows 10, versione 1903

NOTA: Quando un nuovo aggiornamento sarà disponibile, Windows 10 cancellerà automaticamente i file che si troveranno in Reserved Storage in modo tale da liberare spazio per l’installazione del nuovo aggiornamento.

Windows Update

Nelle precedenti versioni di aggiornamento delle funzionalità di Windows 10 l’installazione degli aggiornamenti veniva avviata automaticamente. A partire dall’aggiornamento di Windows 10 versione 1903 gli utenti avranno più controllo sull’avvio dell’aggiornamento del sistema operativo. Agli utenti verrà mostrata la notifica che un aggiornamento è disponibile e consigliato, ma sarà compito dell’utente iniziare ed effettuare l’aggiornamento.

Mantenere le macchine supportate e ricevere aggiornamenti mensili è fondamentale per la sicurezza dei dispositivi. La nuova gestione di Windows Update permetterà agli utenti maggiore controllo e trasparenza in merito all’installazione degli aggiornamenti e tutti i client avranno la possibilità di scegliere esplicitamente se desiderano aggiornare il proprio dispositivo quando “controllano gli aggiornamenti” oppure potranno mettere in pausa gli aggiornamenti per un massimo di 35 giorni.

Trovate ulteriori notizie alla pagina Improving the Windows 10 update experience with control, quality and transparency

Figura 15: Nuova modalità di gestione di Windows Update

Figura 16: É possibile mettere in pausa gli aggiornamenti fino a 35 giorni

In questo modo, da un lato l’utente potrà continuare a ricevere e verificare la presenza degli aggiornamenti qualitativi mensili e, dall’altro decidere autonomamente quando installare l’aggiornamento di funzionalità. L’aggiornamento forzato entrerà in funzione quando la versione di Windows 10 installata ha terminato il suo ciclo di vita, ovvero dopo 18 mesi dal rilascio ufficiale per le versioni di marzo e 30 mesi per le versioni di settembre per le versioni Enterprise e 18 mesi per tutte le versioni Pro.

Per informazioni sul supporto di Windows 10 vi invito a leggere il documento https://support.microsoft.com/it-it/help/4462896/updates-to-servicing-and-support-for-windows-10

*Gli aggiornamenti delle funzionalità verranno rilasciati due volte all’anno, a marzo e a settembre.

NOTA: A partire da Windows 10, versione 1903 se il dispositivio non si riavverà automaticamente dopo l’installazione, gli aggiornamenti installati verranno rimossi automaticamente e riceverete al riavvio la notifica “We removed some recently installed updates to recover your device from a startup failure”. Il sistema provvederà a disabilitare l’aggiornamento che ha creato problemi per i successivi 30 giorni, sufficienti affinché venga rilasciata una nuova patch.

Windows Security

Diverse novità sono state introdotte anche nell’app Windows Security. Windows Defender Antivirus mantiene il PC al sicuro con la protezione antivirus integrata in Windows 10 e fornisce protezione in tempo reale contro le minacce software, come virus e malware provenienti da e-mail, app e Web.

Windows Defender Security Center è una potente suite di funzionalità di sicurezza ideata per proteggere Windows 10 per tutta la durata del supporto e assicura protezione completa da virus, malware, spyware e altre minacce per il sistema, i file e le attività online. Aprendo il Windows Defender Security Center potrete attivare gratuitamente la protezione e se collegate il vostro dispositivo a OneDrive oppure a OneDrive For Business avrete la possibilità di proteggervi dai Ransomware perché i vostri dati verranno caricati nel Cloud e saranno protetti dal versioning offerto da OneDrive.

Figura 17: Abilitazione di Virus & threat protection in Windows 10

Figura 18: configurazione di OneDrive per la protezione contro i ransomware

Figura 19: Ransomware protection

Ne volete sapere di più? Alla pagina What’s new in Windows 10, version 1903 IT Pro content trovate ulteriori e più dettagliate informazioni sulle novità rilasciate in Windows 10, versione 1903.

Conclusioni

Sono tante le novità inserite in Windows 10, versione 1903 e in questo articolo vi ho citato solo le più importanti. Il lavoro che Microsoft sta facendo per migliorare l’interazione con gli smartphone ed aumentare le funzionalità relative alla sicurezza è davvero notevole.

Da una decina di giorni circa, è possibile abilitare il passwordless sign in anche per gli account di Azure Active Directory, utiizzando una security key che supporta gli standard FIDO2 (Fast IDentity Online) e CTAP2 (Client-to-Authenticator Protocol). Attualmente la funzionalità è in preview, ma già da tempo viene utilizzata per accedere al Microsoft Account, come ho già avuto modo di scrivervi nell’articolo Passwordless login al Microsoft Account con Windows Hello e con Yubikey

La gestione delle password è sempre stata critica sia per gli utenti e che per gli amministratori di sistema e spesso è causa di accessi da parte di malintenzionati per via della scarsa cura che gli utenti ne hanno oppure della semplicità delle password utilizzate.

Accedere senza password (passwordless sign in) è una delle funzionalità che ultimamente Microsoft sta promuovendo maggiormente e i dispositivi biometrici, ormai diffusi in tutti i computer portatili, possono essere utilizzati per accedere a Windows e alle applicazioni web. A partire da Windows 10, versione 1809 (October 2018 Update), sono state diverse le novità introdotte da Microsoft per favorire gli utenti ed evitare sempre di più l’utilizzo delle password per effettuare l’autenticazione, a fronte dell’utilizzo di security key oppure di App installate in uno smartphone.

I concentti di base sull’autenticazione passworless sono ben descritti nell’articolo What is passwordless?

Prerequisiti

Per poter utilizzare il passwordless sign in con Azure AD è necessario avere:

• Una security key compatibile con FIDO2
• Aver abilitato Azure Multi-Factor Authentication (MFA)
• Windows 10 versione 1809 e successive
• Un browser che supporti il protocollo WebAuthn per l’autenticazione delle applicazioni web (al momento è possibile usare solo Microsoft Edge)

Per approfondimenti sul protocollo WebAuthN vi rimando alla lettura del documento https://www.w3.org/2018/Talks/06-WebAuthn.pdf

Per la realizzazione di questo articolo ho utilizzato una security Yubikey prodotta dalla Yubico che riesce a gestire la multi-factor authentication e la passwordless authentication.

Per poter utilizzare la passwordless authentication come metodo di autenticazione è necessario prima di tutto collegarsi al portale Azure e da Azure Active Directory > User Settings cliccare sul collegamento Manage user feature preview settings

Figura 1: Abilitazione della funzionalità di Preview in Azure Active Directory

Dal blade User feature previews selezionate in Users can use preview features for registering and managing security info – enhanced quale gruppo di utenti volete abilitare per poter testare le funzionalità in anteprima. Potete scegliere anche di abilitare la funzionalità per tutti gli utenti. Io ho scelto di abilitarla solo per un gruppo chiamato ICTPower Crew. Cliccate su Save per confermare la vostra scelta.

Figura 2: Abilitazione della funzionalità di anteprima solo per un gruppo di Azure AD

Navigate quindi in Azure Active Directory > Authentication methods > Authentication method policy (Preview) per abilitare il metodo da utilizzare. Cliccate su FIDO2 Security Key e abilitate la funzionalità. Non modificate altri parametri, perché al momento della stesura di questo articolo la funzionalità è ancora in preview e la key restriction policy non
funziona. Sarà disponibile al momento della general availability.

Figura 3: Abilitazione dell’uso della FISO2 Security Key come metodo di autenticazione passwordless

Registrazione della Security Key

Per poter registrare ed associare la propria security key all’account di Azure AD, ogni utente dovrà andare nel proprio profilo utilizzando il link https://myprofile.microsoft.com e modificare le Security Info. Dallo stesso link sarà possibile gestire anche le funzionalità di Multi-Factor Authentication.

Se l’utente ha già abilitato la Azure MFA potrà aggiungere direttamente la Security Key, altrimenti deve aggiungere almeno un metodo di autenticazione Azure MFA. L’account con cui mi sono loggato ha già abilitato Azure MFA e cliccando sul bottone +Add method ho potuto scegliere dal menù a tendina di aggiungere la Security Key.

Figura 4: Aggiunta del nuovo metodo di autenticazione basato su una Security Key

Poiché le Security Key possono essere sia USB che NFC (comode da utilizzare con uno smartphone), vi verrà presentato un menù da cui scegliere il tipo di chiave

Figura 5: Scelta del tipo di Security Key tra USB e NFC

Verrete a questo punto reindirizzati ad una pagina di login e vi verrà chiesto di inserire la vostra Security Key. Dopo l’inserimento della chiave dovrete proteggere l’accesso alla chiave con un PIN. Il PIN dovrà essere inserito ogni volta che vorrete utilizzare la Security Key per autenticarvi.

Figura 6: Configurazione di un PIN per utilizzare la Security Key

Dopo la configurazione del PIN sarà necessario toccare la chiave per attivarla.

Figura 7: Per utilizzare la chiave è necessario “toccarla”

Poiché è possibile utilizzare diverse chiavi per uno stesso account di Azure AD, vi verrà chiesto di inserire un nome descrittivo per distinguere facilmente le diverse Security Key.

Figura 8: Scelta del nome della Security Key per poterle distinguere facilmente

Figura 9: Associazione della Security Key all’account id Azure AD completata

Utilizzo della security Key per il login passwordless ad Azure AD

Per poter testare il login passwordless ad Azure AD (e quindi ad Office 365 o a Microsoft 365) dovrete servirvi di un browser che supporti il  protocollo WebAuthn e le Web Authentication API, che sono utilizzate dai browser più recenti, compresi Google Chrome (dalla versione 67 in poi https://developers.google.com/web/updates/2018/05/webauthn ) e Mozilla Firefox (dalla versione 60 in poi https://www.mozilla.org/en-US/firefox/60.0/releasenotes/ ).

Al momento della stesura di questa guida però l’unico browser funzionante è Microsoft
Edge. Mi sono collegato alla pagina di login di Office 365 e sono stato reindirzzato al sito https://login.microsoftonline.com. Nella finestra che si è aperta ho cliccato sul link Sign-in options

Figura 10: Test del login passwordless

A questo punto nel browser mi è stata presentata la possibilità di utilizzare Windows Hello oppure una Security Key

Figura 11: Tra le opzioni disponibili per il Sign-in c’è anche la Security Key

Vi verrà chiesto di inserire il PIN della Security Key e successivamente di confermare il login “toccando” la chiave, come mostrato nelle figure sotto:

Figura 12: Inserimento del PIN della Security Key

Figura 13: Richiesta di “toccare” la chiave per confermare l’autenticazione

È interessante notare che se utilizzate la stessa chiave per diversi account, vi verrà chiesto quale account utilizzare per il login e tutto questo senza digitare nulla dalla tastiera!

Figura 14: Richiesta di scelta dell’account di Azure AD con cui effettuare il login nel caso usiate la stessa security key con account differenti

Conclusioni

Il passwordless sign-in utilizzando una Security Key è decisamente una funzionalità interessante. L’accesso passwordless garantisce che ci si possa autenticare in modo molto semplice ma allo stesso tempo molto più sicuro. Il protocollo WebAuthn e lo standard FIDO2 sono pensati per gestire al meglio le nostre credenziali di accesso. Per ulteriori informazioni potete fare riferimento alla pagina Enable passwordless sign in for Azure AD (preview)

L’app Microsoft Authenticator consente di accedere a qualsiasi account di Azure AD senza usare la password. Se un utente ha abilitato l’accesso tramite telefono nell’app Microsoft Authenticator, dopo l’immissione del nome utente non verrà visualizzata la richiesta di inserimento della password, ma verrà visualizzato un messaggio che chiederà all’utente di toccare un numero nell’app. L’utente dovrà quindi toccare il numero corrispondente nell’app, scegliere l’opzione di approvazione e fornire il codice PIN o la chiave biometrica e l’autenticazione verrà completata.

La gestione delle password è sempre stata critica sia per gli utenti e che per gli amministratori di sistema e spesso è causa di accessi da parte di malintenzionati o di persone non autorizzate per via della semplicità delle password utilizzate oppure della disattenzione degli utenti, che magari la scrivono da qualche parte per non dimenticarla.

Accedere senza password (passwordless sign in) è una delle funzionalità che ultimamente Microsoft sta promuovendo maggiormente e i dispositivi biometrici, ormai diffusi in tutti i computer portatili, possono essere utilizzati per accedere a Windows e alle applicazioni web. A partire da Windows 10, versione 1809 (October 2018 Update), sono state diverse le novità introdotte da Microsoft per favorire gli utenti ed evitare sempre di più l’utilizzo delle password per effettuare l’autenticazione, a fronte dell’utilizzo di security key oppure di App installate in uno smartphone.

I concentti di base sull’autenticazione passworless sono ben descritti nell’articolo What is passwordless?

Prerequisiti

Per accedere ad Azure AD utilizzando lo smarthone e senza utilizzare la password (passwordless) devono essere rispettittati i seguenti prerequisiti:

• Abilitare la funzionalità in Azure AD
• Abilitare la Azure Multi-Factor Authentication (MFA) per l’utente
• Registrazione dello smartphone dell’utente

Abilitazione della passwordless authentication come metodo di autenticazione

Per poter utilizzare la passwordless authentication come metodo di autenticazione è necessario prima di tutto collegarsi al portale Azure e da Azure Active Directory > User Settings cliccare sul collegamento Manage user feature preview settings

Figura 1: Abilitazione della funzionalità di Preview in Azure Active Directory

Dal blade User feature previews selezionate in Users can use preview features for registering and managing security info – enhanced quale gruppo di utenti volete abilitare per poter testare le funzionalità in anteprima. Potete scegliere anche di abilitare la funzionalità per tutti gli utenti. Cliccate su Save per confermare la vostra scelta.

Figura 2: Abilitazione della funzionalità di anteprima solo per un gruppo di Azure AD

Navigate quindi in Azure Active Directory > Authentication methods > Authentication method policy (Preview) per abilitare il metodo da utilizzare. Cliccate su Microsoft Authenticator passwordless sign-in e abilitate la funzionalità.

Figura 3: abilitazione della funzionalità di Microsoft Authenticator passwordless sign-in

Attivazione della Multi-Factor Authentication

Per poter utilizzare la funzionalità di passwordless sign-in con lo smartphone è obbligatorio che l’utente utilizzi la Azure Multi-Factor Authentication e soprattutto che utilizzi l’app Microsoft Authenticator. Durante la scrittura di questo articolo ho notato che quando un utente appena creato in Azure AD si logga per la prima volta ad Office 365 oppure a Microsoft 365, gli viene chiesto in maniera automatica di abilitare Azure MFA. Parte una procedura guidata che chiede prima all’utente di scaricare l’app Microsoft Authenticator sul proprio smartphone e poi fa collegare il proprio account di Azure AD. Nelle figure sono mostrate tutte le fasi:

Figura 4: Richiesta di download dell’app Azure Authenticator

Figura 5. Aggiunta dell’account ad Azure Autneticator

Figura 6: QR code per l’aggiunta dell’account

Figura 7 – 7a: Aggiunta del nuovo account nell’app Microsoft Authenticator

Figura 8: Conferma dell’account di Microsoft Authenticator

Figura 9: Account aggiunto

In questo modo però ho notato una cosa particolare: dall’app di Microsoft Authenticator non era possibile abilitare il Phone Sign-In

Figura 10: Dall’app di Microsoft Authenticator non è possibile abilitare il Phone Sign-in

Abilitazione della Multi-Factor Authentication con le notifiche push

Dal portale https://myprofile.microsoft.com ho verificato che l’utente non ha abilitato l’app Microsoft Authenticator con le notifiche push. L’app Microsoft Authenticator permette due modalità di utilizzo: solo con codice OTP oppure con codice OTP e notifiche push). La configurazione del Microsoft Autheticator con le notifiche push è obbligatoria per abilitare il phone sign-in. Ho quindi deciso di aggiungere un secondo metodo di autenticazione basata su Authenticator App. Seguendo le indicazioni, ho abilitato il Microsoft Authenticator con le notifiche push:

Figura 11: Aggiunta di un secondo metodo di autenticazione MFA

Figura 12: Scansione del QR code per aggiungere l’account all’app Microsoft Authenticator

Figura 13: Aggiunta dell’account all’app Microsoft Authenticator

Figura 14: Verifica dell’aggiunta dell’accont con richiesta di invio di una notifica allo smartphone

Figura 15: Approvazione della richiesta sullo smartphone

Figura 16: Verifica effettuata

Come si può notare nell’immagine sotto, adesso l’utente ha due metodi di autenticazione, che riportano nomi diversi. Quello che interessa a noi per effettuare il phone sign-in, è quello che riporta la scritta Microsoft Authenticator (abilitato per le notifiche push)

Figura 17: Il metodo di autenticazione corretto è stato aggiunto

Sullo smartphone adesso ci sono due account. Quello che interessa a noi, per effettuare il passwordless phone sign-in è quello indicato nella freccia

Figura 18: Account corretto da utilizzare per il passwordless phone-sing-in

Infatti, adesso la voce Enable phone sign-in è disponibile e potremo utilizzare lo smartphone per il login. Abilitate la funzionalità e registrate il dispositivo, associandolo all’utente

Figura 19: Abilitazione del phone sign-in

NOTA: Uno dei prerequisiti per abilitare il Phone sign-in è che il dispositivo che si sta utilizzando sia registrato nel tenant di Azure AD per un singolo utente. A causa delle limitazioni relative alla registrazione dei dispositivi, un dispositivo può essere registrato solo in un singolo tenant. A causa di questa limitazione, nell’app Microsoft Authenticator può essere abilitato per l’accesso tramite telefono un solo account aziendale o dell’istituto di istruzione. Nel caso lo smartphone sia stato associato ad un altro tenant di Azure AD riceverete l’errore mostrato nella figura sotto:

Figura 20: Lo smartphone può essere associato solo ad un utente per volta

Una volta che avrete abilitato lo smartphone apparirà l’icona accanto all’account, come mostrato in figura:

Figura 21: Il simbolo accanto all’account indica che è stato abilitato il Phone Sign-in

Verifica dell’accesso con il passwordless phone sign-in

Per verificare che l’utente possa effettuare l’accesso senza usare la password vi basterà loggarvi ad Azure AD e dopo l’immissione del nome utente non verrà visualizzata la richiesta di inserimento della password, ma verrà visualizzato un messaggio che chiederà all’utente di toccare un numero nell’app.

Figura 22: Invio della notifica di accesso all’app AMicrosoft Authenticator

Figura 23: Numero da toccare nell’app Microsoft Authenticator

L’utente dovrà quindi toccare il numero corrispondente nell’app, scegliere l’opzione di approvazione e fornire il codice PIN o la chiave biometrica (viso o impronta digitale) e l’autenticazione verrà completata.

Figura 24: Nell’app Microsoft Authenticator appare il numero da toccare per confermare il login

Conclusioni

L’app Microsoft Authenticator consente di accedere ai propri account in modo più sicuro utilizzando la verifica a due fattori. Poiché le password possono essere dimenticate, rubate o compromesse, la verifica a due fattori è un’ulteriore misura di sicurezza che consente di proteggere l’account rendendo più difficile l’intromissione di altri utenti.

È possibile usare l’app Microsoft Authenticator in diversi modi:

• Richiedendo un secondo metodo di verifica dopo l’accesso con il nome utente e la password, sia con una notifica push che con un codice a tempo (OTP)
• Fornendo l’accesso senza richiedere una password, usando il nome utente e il dispositivo mobile con l’impronta digitale, il viso o il PIN.

Maggiori informazioni sono disponibili leggendo l’articolo Accedere agli account con l’app Microsoft Authenticator

Avere un modern desktop (cioè un’installazione di Windows 10 e Office 365, mantenuta costantemente aggiornata) significa sfruttare al massimo le funzionalità offerte sia dal sistema operativo che dalla suite di collaborazione Office 365, avendo la possibilità di migliorare la produttività, il lavoro di gruppo e la collaborazione all’interno dell’azienda. In più, avendo sempre un sistema aggiornato, possiamo assicurare un livello di efficienza ma soprattutto di sicurezza notevole, che ci permette di difenderci dai continui attacchi che ci arrivano dall’esterno (e molto spesso anche dall’interno) dell’azienda.

Con Microsoft 365 abbiamo la possibilità di poter avere con un licensing molto semplice la maggior parte dei software necessari per poter essere realmente competitivi in un mercato estremamente dinamico come quello che stiamo vivendo e di adattarci alle nuove modalità di lavoro (come ad esempio l’Home working o lo Smart working).

La soluzione Microsoft 365 integra in un unico pacchetto Windows 10 Enterprise, Office 365 e Enterrise Mobility + Security.

Figura 1: Passaggi chiave necessari per passare al Modern Desktop

Poiché le aziende hanno bisogno che i propri dipendenti siano sempre più “mobili”, il ruolo dell’IT Admin è diventato molto più complesso rispetto al passato e non è più limitato a gestire i desktop, ma anche i dispositivi mobili, come ad esempio tablet e smartphone.

La possibilità di utilizzare Microsoft Intune semplifica di molto il lavoro degli amministratori di sistema e questo servizio basato sul cloud permette di:

• Gestire i dispositivi mobili e i PC usati dagli utenti per accedere ai dati aziendali.
• Gestire le app per dispositivi mobili usati dagli utenti.
• Proteggere le informazioni aziendali grazie alla possibilità di controllare le modalità di accesso e condivisione dei dati da parte della forza lavoro.
• Assicurarsi che i dispositivi e le app siano conformi ai requisiti di sicurezza aziendali.

Microsoft Intune è il componente della suite Enterprise Mobility + Security (EMS) di Microsoft che gestisce dispositivi e app per dispositivi mobili. Intune è integrato con altri componenti EMS come Azure Active Directory (Azure AD) per il controllo delle identità e degli accessi e Azure Information Protection per la protezione dei dati. Quando viene usato con Office 365 consente agli utenti di essere produttivi con tutti i dispositivi, garantendo al tempo stesso la protezione delle informazioni aziendali.

Figura 2: Diagramma dell’architettura di Microsoft Intune

Abbiamo visto nel precedente articolo Attivazione di una sottoscrizione gratuita di Microsoft Azure che sono tanti i servizi GRATUITI che Microsoft mette a disposizione degli utenti per permettergli di poter testare la propria tecnologia, ma molto spesso non vengono utilizzati oppure sono sconosciuti ai più.

Per poter testare Microsoft Intune potete registrarvi gratuitamente alla versione di prova di Enterprise Mobility + Security al link https://www.microsoft.com/en-us/cloud-platform/enterprise-mobility-security-trial

Figura 3: Registrazione della trial di Enterprise Mobility + Security

Dopo esservi registrati alla trial potrete associare le licenze direttamente dal portale di Microsoft Azure. Microsoft Intune è infatti già da qualche tempo incorporato nel portale di amministrazione di Azure. Per cominciare a familiarizzare con Microsoft Intune vi consiglio di leggere la Guida introduttiva a Intune nel portale di Azure.

La gestione degli utenti può essere fatta sia da Azure che da Intune

Figura 4: Gestione degli utenti in Microsoft Intune

Mentre l’assegnazione delle licenze può essere fatta da Azure Active Directory > Licenses > All products > Enterprise Mobility + Security E5

Figura 5: Assegnazione delle licenze di Microsoft Intune

Impostazione dell’autorità di gestione dei dispositivi mobili

Prima di abilitare la registrazione dei dispositivi, è necessario impostare l’infrastruttura di Intune. In particolare, per la registrazione del dispositivo è necessario impostare l’autorità di gestione dei dispositivi mobili. L’impostazione dell’autorità di gestione dei dispositivi mobili (MDM) determina la modalità di gestione dei dispositivi.

Le configurazioni possibili sono:

• Intune autonomo: gestione solo cloud, che viene configurata tramite il portale di Azure. Include il set completo di funzionalità offerte da Intune.
• Co-gestione di Intune: integrazione della soluzione cloud di Intune con System Center Configuration Manager per dispositivi Windows 10. Intune viene configurato tramite la console di Configuration Manager.
• Gestione dei dispositivi mobili per Office 365: integrazione di Office 365 con la soluzione cloud di Intune. Intune viene configurato dall’interfaccia di amministrazione di Microsoft 365. Include un sottoinsieme delle funzionalità disponibili con Intune autonomo. Impostare l’autorità MDM nell’interfaccia di amministrazione di Microsoft 365.

Nel mio caso ho scelto di utilizzare solo Intune per la gestione dei dispositivi e dalla console di Intune ho selezionato in Device Enrollment > Choose MDM Authority la voce Intune MDM authority.

Figura 6: Selezione dell’autorità di gestione dei dispositivi mobili

Abilitazione della registrazione dei dispositivi in Azure AD

Per permettere agli utenti di poter aggiungere i propri dispositivi ad Azure AD è necessario abilitare la funzionalità in Azure AD. Verificate in Azure AD che in Devices > Device Settings sia abilitata la voce Users may join devices to Azure AD

Figura 7: Abilitazione della registrazione dei dispositivi in Azure AD

Integrazione di Azure AD con Intune per la registrazione automatica di Windows 10

Per configurare Microsoft Intune per registrare automaticamente i dispositivi quando utenti specifici eseguono l’accesso a dispositivi Windows 10 vi basterà semplicemente selezionare Azure Active Directory > Mobility (MDM and MAM) e successivamente Microsoft Intune. In questo modo sia i dispositivi aziendali sia i dispositivi BYOD degli utenti verranno registrati automaticamente.

Figura 8: Integrazione di Azure AD con Intune

Figura 9: Configurazione dell’integrazione di Azure AD con Intune

Enroll di Windows 10 in Microsoft Intune

Dopo aver preparato il tenant di Intune, è possibile registrare i dispositivi (enrollment). Per impostazione predefinita, i dispositivi di tutte le piattaforme sono autorizzati alla registrazione in Intune. Tuttavia, è possibile limitare i dispositivi in base alla piattaforma.

Ho deciso di gestire Windows 10 in workgroup tramite Microsoft Intune e di joinarlo ad Azure Active Directory. Questo permetterà all’utente di poter accedere a Windows utilizzando le proprie credenziali di Azure AD e di abilitare la modalità Bring Your Own Device (BYOD).

Poiché abbiamo abilitato la registrazione automatica, il dispositivo viene registrato automaticamente in Intune. Il vantaggio della registrazione automatica è che si tratta di un processo che può essere effettuato dall’utente in un unico passaggio.

NOTA: verificate che la versione di Windows 10 sia la 1607 o una versione successiva.

Dopo aver associato la licenza di Microsoft Intune all’utente, sono andato nell’App Settings di Windows 10 e ho effettuato il join ad Azure AD da Accounts
> Access work or school > +Connect. Quando ho scelto Join this device to Azure Active Directory ho inserito le credenziali dell’utente con la licenza di Enterprise Mobility + Security E5 e ho cliccato su Join.

Figura 10: Join di Windows 10 ad Azure Active Directory

Figura 11: Windows 10 è joinato ad Azure AD

La gestione del dispositivo verrà ora effettuata tramite Microsoft Intune, che ha provveduto ad installare dei certificati digitali che verranno utilizzati per la connessione al PC. Dalla console certlm.msc potrete verificare la presenza dei certificati

• Microsoft Intune MDM Device CA
• MS-Organization-Access
• MS-Organization-P2P-Access [2019]

Figura 12: Certificati digitali utilizzati da Intune per la gestione di Windows 10

In Azure Active Directory, selezionando l’utente, sarà possibile verificare che il PC è stato aggiunto alla lista dei dispositivi personali, come mostrato in figura:

Figura 13: Il PC è stato aggiunto alla lista dei dispositivi dell’utente di Azure AD

Per forzare la sincronizzazione delle configurazioni di Microsoft Intune è possibile utilizzare l’app Settings e da Access Work or School, cliccando sul nome dell’utente collegato ad Azure AD, scegliere il pulsante Info. Nella finestra che si aprirà sarà possibile verificare tutte le informazioni di connessione ed eventualmente forzare un Sync con l’apposito pulsante.

Figura 14: Utente di Azure AD collegato a Windows 10

Figura 15: Stato di sincronizzazione del dispositivo

Conclusioni

La gestione dei dispositivi mobili, tablet, smartphone oppure Windows 10, è sicuramente una delle maggiori difficoltà per un amministratore di sistema. Grazie a Microsoft Intune questa gestione è di fatto enormemente semplificata. In più con Microsoft Intune è anche possibile distribuire applicazioni sui nostri dispositivi. Date un’occhiata all’articolo Microsoft 365 Modern Desktop Management – Distribuire e gestire le applicazioni sui dispositivi aziendali con Microsoft Intune

Introduzione

System Center Data Protection Manager (DPM) consente il backup e il ripristino di file, cartelle, volumi, macchine virtuali Windows e Linux in ambienti Hyper-V, VMware e Azure, client fisici Windows, server fisici Windows, server Exchange, server SharePoint e server SQL Server. DPM può quindi essere impiegato come elemento abilitante per l’implementazione di una strategia aziendale di continuità e ripristino di emergenza (BCDR, Business Continuity and Disaster Recovery) che assicuri la disponibilità delle risorse durante le interruzioni pianificate e non pianificate e che consenta il ripristino delle condizioni di lavoro normali in caso di errori.

In questo articolo analizzeremo l’installazione della System Center Data Protection Manager 1807 ovvero l’ultima release nel System Center Semi Annual Channel (SAC) che può essere installata come aggiornamento di System Center Data Protection Manager (DPM) versione 1801.

DPM 1807, come riportano nella System Center Data Protection Manager 1807 – What’s new in System Center Data Protection Manager, apporta una serie di correzioni e miglioramenti alle performance rispetto alla versione 1801. Per la lista dei bugs corretti in DPM 1807 si veda invece la KB4339950 System Center Data Protection Manager, version 1807, per gli issues in DPM 1807 si veda System Center DPM 1807 Release Notes, mentre per gli senari supportati si veda System Center DPM 1807 – What’s supported and what isn’t for DPM?.

Sebbene al momento sia già disponibile System Center DPM 2019 in determinati scenari potrebbe essere necessario installare ancora DPM 1807 dal momento che tra le due versioni vi è un differenza tra i workloads per cui il backup è supportato, a riguardo si vedano System Center DPM 1807 – What can DPM back up? e System Center DPM 1807 – What can DPM back up?. Di seguito una tabella che riporta il supporto al backup nelle differenti versioni di DPM:

Requisti di sistema e note di installazione

Per dimensionare i requisiti di sistema su cui installare DPM 1807 è possibile fare riferimento alle indicazioni fornite in System Center DPM 1807 – Get DPM installed riguardo alle installazione di DPM 1807 in VM in Azure:

Partendo dalle indicazioni fornite nella precedente tabella e dalle indicazioni riguardo ai requisiti consigliati per l’installazione di SQL Server di 8 GB di RAM, fornite in System Center DPM 1807 – Preparing your environment for System Center Data Protection Manager, un dimensionamento di una VM per l’installazione di DPM 1807 e SQL Server che appare adeguato in termini di computazione prevede 4 o 8 vCPU e 16 GB di RAM.

Per il dimensionamento dello storage necessario è possibile attenersi alle seguenti indicazioni fornite in System Center DPM 1807 – Preparing your environment for System Center Data Protection Manager e in System Center DPM 1807 – Prepare data storage:

In base alle precedenti indicazioni un dimensionamento di una VM per l’installazione di DPM 1807 e SQL Server che appare adeguato i termini di storage prevede un disco da 64 GB per il sistema operativo e i binari di SQL Server, un disco da 32 GB per i database di SQL Server con dimensione di unità di allocazione a 64KB, un disco da 16 GB per i binari di DPM e un disco dedicato allo storage pool di DPM in RAID 5 con dimensione pari 3 volte la dimensione dei dati protetti e dimensioni del settore coerente con storage sottostante.

Per quanto riguarda il sistema operativo, in base a quanto riportato in System Center DPM 1807 – Preparing your environment for System Center Data Protection Manager, è possibile utilizzare le seguenti versioni di Windows Server:

• Windows Server 2019 Datacenter o Standard
• Windows Server 2016 Datacenter o Standard
• Windows Server 2012 R2 Datacenter o Standard

I prerequisiti vengono installati automaticamente se non presenti e il sistema su cui viene installato DPM 1807 non dovrebbe essere utilizzato per altri applicativi e/o servizi, in particolare viene specificato di non installare DPM su:

• Application Server role
• Operations Manager Management server
• Server con Exchange
• Server in esecuzione su un cluster node

Per quanto riguarda Active Directory il server DPM deve trovarsi in un dominio, volendo è anche possibile installare DPM su un Read Only Domain Controller (RDOC) come riportato in System Center DPM 1807- Get DPM installed – Install DPM on a domain controller, ma tale configurazione non sarà oggetto di questo articolo.

La versione di SQL Server che può essere utilizzata per memorizzare le informazioni di backup è la 2016 o la 2017 in edizione Standard o Enterprise a 64 bit, come riportato in System Center DPM 1807 – Preparing your environment for System Center Data Protection Manager. Dal momento che la versione 1807 di DPM deve installata come aggiornamento di System Center Data Protection Manager (DPM) versione 1801 la quale supporta la versione 2016 di SQL Server occorrerà iniziare l’installazione con la versione 2016 di SQL Server ed eventualmente migrare successivamente alla versione 2017.

Installazione di SQL Server 2016 SP2

L’installazione di SQL Server dovrà essere eseguita con le seguenti impostazioni tramite un account di Active Directory che sia amministratore locale (ad esempio l’utente amministratore di dominio), come riportato in System Center DPM 1807 – Get DPM installed:

• Eseguire un’installazione autonoma di SQL Server.
• Impostare l’utilizzo di Microsoft Update per verificare la disponibilità di aggiornamenti.
• Selezionare le seguenti funzionalità
  • Funzionalità istanza – Servizi motore di database
    
  • Funzionalità istanza – Servizi motore di database – Estrazioni full-text e semantiche per la ricerca
    
  • Funzionalità istanza – Reporting Services – Nativo
    
• E’ possibile accettare i path predefiniti dei file binari di SQL Server impostati sul disco di sistema
• Accettare l’impostazione di installare SQL Server come istanza predefinita
• Impostare in modalità di avvio automatico per i servizi SQL Agent, Motore di Database di SQL Server, SQL Server Reporting Services
• Impostare in modalità di avvio manuale il servizio SQL Full-text Filter Daemon
• Per l’avvio dei servizi SQL Server Agent, Motore di Database di SQL Server e SQL Server Reporting Services utilizzare un utente di Active Directory dedicato con minimi privilegi, password complessa e senza scadenza, per sicurezza l’utente non deve essere membro di Domain Users, ma di un gruppo dedicato
• Selezionare la regola di confronto SQL_Latin1_General_CP1_CI_AS (tale regola di confronto appartiene all’elenco delle regole di confronto SQL per compatibilità con le versioni precedenti) come specificato in System Center DPM 1807 – Preparing your environment for System Center Data Protection Manager
• Selezionare la modalità di autenticazione Windows e aggiungere l’account corrente come amministratore di SQL Server e l’amministratore locale
• Impostare la directory dei dati su un volume in un disco dedicato
• Selezionare l’opzione Installa e configurazione della modalità nativa di Reporting Services
  

Al termine dell’installazione installare gli aggiornamenti necessari, un elenco degli aggiornamenti disponibili con la relativa data di fine supporto è disponibile al seguente https://sqlcollaborative.github.io/builds..

Installazione di SQL Server Management Studio (SSMS) 16.5.3

Come indicato in System Center DPM 1807 – Get DPM installed
DPM 2016 richiede la versione 16.5 o precedente di SQL Server Management Studio (SSMS), mentre la versione 17 di SSMS è supportata in DPM 2019.

Dal momento che si intende installare la versione 1801 di DPM verrà installata la versione 16.5.3 di SSMS.

Al termine dell’installazione installare gli aggiornamenti necessari.

Installazione di System Center DPM 1801

L’installazione di DPM dovrà essere eseguita con le seguenti impostazioni tramite un account di Active Directory che sia amministratore locale (ad esempio l’utente amministratore di dominio), come riportato in System Center DPM 1807 – Get DPM installed:

• Avviare il file di setup SCDPM_1801.EXE ed indicare il path di estrazione dei file d’installazione
• Avviare il file Setup.exe dal path di estrazione dei file d’installazione
• Selezionare l’opzione per installazione di Data Protection Manager
  
• Selezionare l’utilizzo di un SQL Server autonomo specificando il nome NetBIOS, selezionare poi Controlla Installa per eseguire il controllo dei prerequisti e l’installazione dei componenti mancanti (per l’accesso al SQL Server e l’esecuzione delle verifiche verranno utilizzare le credenziali dell’utente con cui si esegue l’installazione)
• Se richiesto riavviare il computer dopo l’installazione del prerequisito HyperVPowerShell, quindi riavviare l’installazione
• Inserire i dati di registrazione e la chiave di licenza
  
• Impostare directory dei file binari di DPM dati su un volume in un disco dedicato
• Selezionare l’opzione per l’utilizzo di Microsoft Update per la verifica degli aggiornamenti
  

Durante l’installazione verranno create le seguenti eccezioni del firewall:

• Eccezione per comunicazione DCOM sulla porta 135 (TCP e UDP) in tutti i profili.
• Eccezione per Msdpm.exe in tutti i profili.
• Eccezione per DPMRA.exe in tutti i profili.
• Eccezione per AMSvcHost.exe in tutti i profili.
• Eccezione per comunicazione DPMAMService sulla porta 6075 (TCP e UDP) in tutti i profili

Il log dei del controllo dei prerequisti e l’installazione dei componenti mancanti viene memorizzato in %ProgramFiles%\Microsoft System Center\DPM\DPMLogs\DpmSetup.log.

Terminata l’installazione di DPM 1801 il numero di versione di DPM sarà la 5.1.363.0.

Al termine dell’installazione installare gli aggiornamenti necessari, l’elenco degli aggiornamenti è disponibile al seguente http://go.microsoft.com/fwlink/?linkid=820914.

Installazione dell’aggiornamento a System Center DPM 1807

Per aggiornare DPM 1801 alla versione 1870 occorre scaricare l’Update Rollup 1 for System Center Data Protection Manager (KB4339950). L’aggiornamento può essere scaricato dalla pagina della KB4339950 – System Center Data Protection Manager, version 1807 o direttamente dal Microsoft Update Catalog.

Scaricare i file di cui è composto l’aggiornamento:

• dataprotectionmanager-kb4339950_df898dc70f7d42d3dbfea90e39b74a8c49c3be64.exe
• dpmcentralconsoleserver-kb4339950_a9e665d2c62a9f1ed0bc31b91031ac1d20e1d462.exe
• dpmmanagementshell-kb4339950_89cb7159d1c57bf5bb8b58a002a5646bcf2c5057.exe
• dpmmanagementshell-kb4339950_b71482d6275d505e45b66d655938aa9046f7cf10.exe

Per l’installazione dell’aggiornamento di DPM 1801 alla versione 1807 eseguire il file dataprotectionmanager-kb4339950_df898dc70f7d42d3dbfea90e39b74a8c49c3be64.exe, al termine dell’installazione riavviare il sistema.

Terminata l’installazione il numero di versione di DPM sarà la 5.1.378.0.

A riguardo si veda anche System Center Data Protection Manager (DPM): Updating from 1801 to 1807.

Upgrade di SQL Server 2016 a SQL Server 2017

Come indicato in System Center DPM 1807 – Get DPM installed per utilizzare SQL Server 2017 in DPM 1801 o 1807 occorre eseguire l’upgrade da SQL Server 2016 a SQL Server 2017.

Per i passi necessari si veda System Center DPM 1807 – Get DPM installed – Upgrade SQL 2016 to SQL 2017.

Si tenga comunque conto che SQL Server 2016 SP2 sarà supportao fino al 14 luglio 2026, mentre SQL Server 2017 sarà fino 12 ottobre 2027. Quindi dal momento che non vi sono funzionalità in DPM 1807 che necessitano per essere utilizzate di SQL Server 2017 è anche possibile utilizzare SQL Server 2016 SP2 dal momento che i product lifecycle delle due versioni differiscono di poco.

Conclusioni

Dal momento che il sistema di backup deve oltre a permettere di gestire il salvataggio di tutti i sistemi, applicativi appartenenti all’infrastruttura informatica e in particolare quelle che per vari motivi non si è ancora riusciti ad aggiornate, quindi può avere senso in certi scenari utilizzare la versione 1807 di DPM anziché la 2019. Ovviamente bisogna tenere in considerazione che le nuove versioni di prodotto non sono supportate da versioni precedenti di DPM, quindi occorre predisporre l’installazione con le versioni dei vari componenti dell’architettura di DPM più recenti possibili in modo da semplificare le future migrazioni. Nell’ottica della migrazione se al momento è necessario adottare DPM 1807 può essere conveniente pianificare l’installazione su Windows Server 2019 e SQL Server 2016 o 2017.

Riferimenti

• KB 4339950 – System Center Data Protection Manager, version 1807
• System Center DPM 1807 – Preparing your environment for System Center Data Protection Manager
• System Center DPM 1807 – Get DPM installed
• System Center Data Protection Manager (DPM): Updating from 1801 to 1807

Dopo aver visto nell’articolo Microsoft 365 Modern Desktop Management – Enroll di un dispositivo in Microsoft Intune come gestire un dispositivo Windows 10 o un dispositivo Android in Microsoft Intune e nell’articolo Microsoft 365 Modern Desktop Management – Distribuire e gestire le applicazioni sui dispositivi aziendali con Microsoft Intune come distribuire le applicazioni aziendali, in questo articolo ci occuperemo della protezione delle applicazioni ed in particolar modo della creazione di una app protection policy in Intune.

I dipendenti usano dispositivi mobili per le attività personali e aziendali. Se da una parte è necessario assicurarsi che i dipendenti possano essere produttivi, dall’altra è indispensabile prevenire la perdita di dati, sia intenzionale sia non intenzionale. È anche opportuno proteggere i dati aziendali a cui si accede da dispositivi non gestiti dall’amministratore.

Non tutte le applicazioni possono essere protette tramite una mobile app protection policy. Per un elenco completo delle applicazioni supportate vi invito a visitare a pagina App protette di Microsoft Intune

Le app gestite hanno diversi vantaggi e permettono di:

• Limitare le funzioni di copia e incolla e salvataggio con nome
• Configurare i collegamenti Web da aprire nel browser Microsoft sicuro
• Abilitare l’uso di identità multiple e l’accesso condizionale a livello di app
• Applicare i criteri di prevenzione della perdita dei dati (data loss prevention) senza gestire il dispositivo dell’utente
• Abilitare la protezione delle app senza richiedere la registrazione
• Abilitare la protezione delle app nei dispositivi gestiti con strumenti di terze parti

I vantaggi più rilevanti dell’uso delle mobile app protection policy sono i seguenti:

• Proteggere i dati aziendali a livello di app. Dal momento che la gestione delle app per dispositivi mobili non richiede la gestione dei dispositivi, è possibile proteggere i dati aziendali su dispositivi sia gestiti sia non gestiti. La gestione dei dati è incentrata sull’identità dell’utente che elimina il requisito della gestione dei dispositivi.
• Non vi sono effetti sulla produttività degli utenti finali e i criteri non si applicano quando si usa l’app in un contesto personale. I criteri vengono applicati solo in un contesto aziendale, offrendo così la possibilità di proteggere i dati aziendali senza modificare i dati personali.

Quando le app vengono usate senza restrizioni, può crearsi una commistione di dati aziendali e personali. I dati aziendali possono finire in percorsi come l’archivio personale o essere trasferiti ad app esterne, causando la perdita di dati.

Figura 1: Applicazioni senza app protection policy

Figura 2: Pritezione dei dati con app protection policy

In questo articolo ci occuperemo di come proteggere i dati con app protection policy nei dispositivi gestiti tramite Microsoft Intune

Figura 3: Protezione dei dati con app protection policy nei dispositivi gestiti da una soluzione di gestione di dispositivi mobili (Microsoft Intune)

Creazione di una app protection policy

Dal portale di Azure è possibile selezionare la voce Microsoft Intune e spostarsi nel nodo App Protection Policy. Fate clic sul pulsante + Create Policy per Creare un nuovo criterio di protezione delle app.

Figura 4: Creazione di una nuova App Protection Policy dal portale di Microsoft Intune

Date un nome alla policy ed inserite una descrizione. Scegliete a questo punto la piattaforma (nel mio caso ho scelto Android). Selezionate Apps per aprire il pannello Apps, che contiene l’elenco delle app disponibili. Selezionate una o più app dall’elenco che si vuole associare al criterio che si sta creando. Io ho selezionato Excel, Word e Outlook.

Figura 5: Selezione delle app da proteggere

Selezionate Setting per configurare le impostazioni obbligatorie.

Sono tre le categorie di impostazioni dei criteri:

• Protezione dei dati (Data Protection): questo gruppo include i controlli di prevenzione della perdita dei dati, ad esempio le restrizioni relative alle operazioni Taglia, Copia, Incolla e Salva con nome. Queste impostazioni determinano la modalità con cui gli utenti interagiscono con i dati nelle app.
• Requisiti di accesso (Access requirements): questo gruppo contiene le opzioni PIN per ogni app che determinano in che modo l’utente finale accede alle app in un contesto aziendale.
• Avvio condizionale (Conditional launch): questo gruppo contiene impostazioni come le impostazioni minime del sistema operativo, il rilevamento di jailbreak e dispositivi rooted.

Nella figura sotto vi ho evidenziato i criteri che ho deciso di modificare:

Figura 6: Criteri per la protezione dei dati

Figura 7: Criteri per i requisiti di accesso all’app

Figura 8: Criteri per il lancio dell’app

Confermate con OK per salvare la configurazione e fate clic su Create policy per la creazione della policy.

Figura 9: Creazione della app protection policy completata

Distruzione della policy

Per distribuire la nuova app protection policy è necessario selezionarla e successivamente cliccare su Assignment. Le policy possono essere applicate a gruppi di utenti di Azure AD, quindi vi verrà chiesto quale gruppo includere.

Figura 10: Assegnazione della app protection policy ad un gruppo di Azure AD

Qual è l’esperienza utente con le app protection policy?

I criteri di protezione delle app vengono applicati solo alle app usate in un contesto aziendale, ad esempio quando l’utente accede alle app con un account aziendale o accede a file archiviati in un percorso di OneDrive for Business.

Figura 11-11A: Quando i documenti vengono creati in OneDrive for Business l’applicazione avvisa l’utente che i dati sono protetti

Proteggere i dati aziendali utilizzando Windows Information Protection (WIP)

Windows Information Protection consente di proteggere le app e i dati aziendali dalle perdite accidentali di dati nei dispositivi dell’azienda e nei dispositivi personali che i dipendenti portano al lavoro. Il continuo aumento dei dispositivi di proprietà dei dipendenti usati in ambito aziendale è accompagnato anche da maggiori rischi di perdita accidentale dei dati tramite app e servizi al di fuori del controllo dell’azienda, come e-mail, social media e cloud pubblico. Questo può ad esempio avvenire quando un dipendente invia dati aziendali dal proprio account e-mail personale, copia e incolla informazioni in una chat o salva dati in uno spazio di archiviazione pubblico sul cloud.

Mi è capitato anche che se i dipendenti non sono autorizzati a condividere file tramite un sistema protetto, abbiano fatto ricorso a un’app esterna che non disponeva degli opportuni controlli di sicurezza. È capitato anche a voi?

La soluzione a questo tipo di problematiche non è certamente semplice, ma è opportuno sviluppare dei meccanismi di Data Loss Prevention.

Windows Information Protection offre:

• La separazione tra dati personali e aziendali.
• Protezione dei dati aggiuntiva per le app line-of-business esistenti senza che risulti necessario aggiornare le app.
• Possibilità di cancellare i dati aziendali dai dispositivi registrati in Intune senza toccare i dati personali.
• Integrazione con il sistema di gestione esistente (Microsoft Intune, System Center Configuration Manager o un altro sistema di gestione dei dispositivi mobili (MDM)) per configurare, distribuire e gestire Windows Information Protection

Utilizzando una app protection policy per Windows 10 è possibile fare in modo che le app gestite (app incluse nell’elenco delle app protette nei criteri WIP) possano accedere ai dati aziendali e interagiscano in modo diverso quando vengono usate con app non consentite, non aziendali o personali. Dopo aver aggiunto un’app all’elenco delle app protette, l’app è considerata attendibile con i dati aziendali. Tutte le app non incluse in questo elenco non sono autorizzate ad accedere ai dati dell’organizzazione.

Per creare una app protection policy per
Windows 10 è sufficiente dal portale di Azure selezionare la voce Microsoft Intune e spostarsi nel nodo App Protection Policy. Fate clic sul pulsante + Create Policy per Creare un nuovo criterio di protezione delle app. In Platform scegliete Windows 10 ed in Enrollment state scegliete il tipo di stato del dispositivo da gestire (con o senza enrollment).

Figura 12: Creazione di una app protection policy per Windows 10

Fate clic su Add Apps e aggiungete l’app da proteggere. È possibile aggiungere questi tipi di App:

• App consigliate
• App Store
• App desktop

Figura 13: Aggiunta delle app da proteggere

Dopo avere aggiunto le app da proteggere con Windows Information Protection, dovete applicare una modalità di gestione e protezione.

In Required Settings consiglio di utilizzare Allow Overrides in modo tale da verificare se sono state inserite le app corrette nell’elenco delle app protette, assegnando inizialmente la policy ad un numero ristretto di dipendenti.

In Corporate identity potete definire l’identità aziendale,  espressa in genere come dominio Internet primario, che aiuta a identificare e contrassegnare con tag i dati aziendali dalle app specificate come protette in Windows Information Protection. Ad esempio, gli indirizzi e-mail che usano la corporate identity (nel mio caso nic03072019outlook.onmicrosoft.com) vengono identificati come aziendali e soggetti a restrizioni dai criteri di Windows Information Protection.

Figura 14: Gestione della modalità di protezione di Windows Information Protection

In Advanced Settings potete aggiungere altri domini, il percorso di rete in cui le app possono accedere ai dati aziendali. Bisogna aggiungere manualmente i percorsi di rete interessati e qualsiasi dispositivo che riceverà un indirizzo IP nella rete indicata sarà assoggettato alla regola di Windows Information Protection.

Figura 15: Gestione dei percorsi di rete da priteggere

Confermate con OK per salvare la configurazione e fate clic su Create policy per la creazione della policy. Una volta creata la policy la potrete assegnare ad un gruppo di utenti di Azure AD.

Figura 16: Gruppo di utenti di Azure AD a cui applicare la app protetion policy

Trovate maggiori Informazioni sulla creazione dei criteri di Windows Information Protection (WIP) al link https://docs.microsoft.com/it-it/windows/security/information-protection/windows-information-protection/create-wip-policy-using-intune-azure

Conclusioni

In molte aziende è consuetudine consentire agli utenti finali di usare sia i dispositivi gestiti tramite Intune, ad esempio i dispositivi di proprietà aziendale, sia i dispositivi non gestiti protetti solo con criteri di protezione delle app di Intune (app protection policy). I dispositivi non gestiti sono spesso noti come dispositivi Bring Your Own Device (BYOD). Poiché le app protection policy di Intune usano come destinazione l’identità di un utente, le impostazioni di protezione per un utente possono essere applicate sia ai dispositivi registrati (dispositivi MDM gestiti) che ai dispositivi non registrati (non MDM).

Windows AutoPilot è un servizio cloud che serve per la distribuzione di Windows 10. Con Windows AutoPilot è possibile personalizzare l’Out-Of-The-Box Experience (OOBE) per i computer Windows 10 senza che ci sia la necessità di distribuire una nuova immagine di Windows. L’utilizzo di Windows AutoPilot è utile specialmente in quegli scenari in cui i dipendenti ricevono un nuovo dispositivo direttamente dal produttore di hardware e devono essere produttivi il prima possibile.

Utilizzando questo servizio cloud al posto dei classici metodi di distribuzione on-premises è possibile beneficiare dei seguenti vantaggi:

• Non è necessario preparare delle immagini di Windows 10 on-premises
• Non è necessario personalizzare le distribuzioni aggiungendo drivers
• Non è necessario disporre di un’infrastruttura on-premises per la distribuzione delle immagini di Windows 10

Windows AutoPilot, disponibile con licenze Azure AD Premium oppure con Microsoft Intune, vi permetterà di:

• Aggiungere i dispositivi Windows 10 ad Azure AD in maniera automatica
• Fare l’auto-enrollment dei dispositivi in Microsoft Intune
• Impedire la creazione di un account amministrativo
• Personalizzare l’esperienza OOBE dei nuovi computer

Prerequisiti per l’uso di Windows AutoPilot

Per utilizzare Windows AutoPilot è necessario che il dispositivo sia “conosciuto” dalla vostra infrastruttura cloud. Quando comprate un nuovo dispositivo il produttore dell’hardware può caricare per conto vostro le informazioni specifiche del dispositivo. Se invece volete utilizzare Windows AutoPilot per gestire i dispositivi che già possedete nella vostra azienda, potete prendere le informazioni relative ai dispositivi utilizzando un apposito script PowerShell per generare un file .CSV con le informazioni che poi potete caricare all’interno di Microsoft Intune o di Microsoft Store for Business.

Prima di poter iniziare ad utilizzare Windows AutoPilot per la distribuzione di Windows 10 devono essere verificati i seguenti prerequisiti:

• I dispositivi devono avere già Windows 10 preinstallato. Windows AutoPilot trasforma un’installazione esistente di Windows 10 modificando i parametri di configurazione nella fase di OOBE. Non verrà infatti distribuita una immagine di Windows 10 e il dispositivo deve cominciare il setup OOBE. Il dispositivo può essere un nuovo dispositivo con già preinstallato il sistema operativo Windows 10 che un hardware vendor ha distribuito oppure può essere un dispositivo Windows 10 che già possedete e che è stato configurato per partire dal setup OOBE, per esempio utilizzando il System Preparation Tool (Sysprep).
• Utilizzare Windows 10 Pro, Enterprise oppure Education. Windows AutoPilot non può distribuire Windows 10 Home oppure un sistema operativo precedente alla Creators Update (versione 1703). Alcune funzionalità, come ad esempio Windows automatic redeployment, richiedono la versione 1709 o successiva.
• Il dispositivo deve essere registrato dall’organizzazione. Windows AutoPilot può distribuire sistemi operativi Windows 10 solo ai dispositivi “conosciuti” e “registrati”. Per prima cosa dovete caricare le informazioni specifiche del dispositivo che includono gli hardware IDs del device in Microsoft Intune oppure in Microsoft Store for Business.
• I dispositivi devono disporre di una connessione ad Internet. Windows AutoPilot è un servizio cloud e può distribuire il sistema operativo Windows 10 soltanto dopo che i dispositivi si sono connessi ad Internet.
• Le aziende devono utilizzare Azure AD. L’utilizzo di Azure AD è obbligatorio perché Windows AutoPilot dipende da Microsoft Intune o da Microsoft Store for Business ed entrambi richiedono Azure AD. È necessario possedere le licenze Azure AD Premium P1 oppure P2.
• Utilizzo di Intune o di Microsoft Store for Business. è necessario caricare le informazioni specifiche del dispositivo in Microsoft Intune o in Microsoft Store for Business

Fase di setup

Una volta che avete rispettato tutti i prerequisiti, il setup di svolge in queste fasi:

1. Ottenere gli Hardware IDs dei dispositivi che volete configurare con Windows AutoPilot
2. Caricare gli Hardware IDs nel portale di Intune o in Microsoft Store for Business
3. Creare un Windows AutoPilot deployment profile
4. Applicare il Windows AutoPilot deployment profile ai dispositivi da configurare

Figura 1: Principio di funzionamento di Windows AutoPilot

Gestione di Windows AutoPilot con Microsoft Intune

In questa guida darò per scontato che abbiate già una sottoscrizione Intune e abbiate un minimo di dimestichezza con l’interfaccia. Vi consiglio, prima di proseguire, di dare un’occhiata al mio articolo Microsoft 365 Modern Desktop Management – Enroll di un dispositivo in Microsoft Intune per verificare di aver integrato Azure AD con Intune, di aver abilitato la registrazione dei dispositivi in Azure AD e di aver impostato l’autorità per la gestione dei dispositivi.

È infatti obbligatorio che abbiate configurato il mobile device management enrollment automatico dei dispositivi Windows 10 in Azure AD. Dal portale di Azure selezionate Azure Active Directory > Mobility (MDM and MAM) e successivamente Microsoft Intune

Figura 2: Configurazione del mobile device management enrollment automatic

Nel blade di Microsoft Intune, in MDM User scope, selezionate All se volete permettere a tutti gli utenti della vostra Azure AD di poter effettuare l’enrollment dei propri dispositivi al mobile device management

Figura 3: Configurazione dell’MDM user scope per gli utenti di Azure AD

Personalizzazione del Company Branding

Per poter utilizzare Windows AutoPilot è obbligatorio personalizzare il Company Branding. Dal portale di Azure selezionate Azure Active Directory e successivamente cliccate su Company Branding. Cliccate su Configure e procedete alla personalizzazione. Per Windows AutoPilot è obbligatorio compilare i campi Sign-in page text e Square logo image.

Figura 4: Personalizzazione del Company Branding con le informazioni obbligatorie per Windows AutoPilot

Configurazione di Windows AutoPilot

Come primo test di Windows AutoPilot vi consiglio di utilizzare una macchina virtuale. Assicuratevi che siano rispettati i seguenti prerequisiti:

• Vi sia installato Windows 10 versione 1703 o successive (Professional, Enterprise oppure Education)
• La VM sia collegata ad Internet

Se la navigazione Internet è dietro proxy oppure firewall assicuratevi che la macchina possa utilizzare le porte HTTP 80 e HTTPS 443 e che possa navigare i seguenti URL:

• https://go.microsoft.com
• https://login.microsoftonline.com
• https://login.live.com
• https://account.live.com
• https://signup.live.com
• https://licensing.mp.microsoft.com
• https://licensing.md.mp.microsoft.com
• https://ctldl.windowsupdate.com
• https://download.windowsupdate.com

Maggiori informazioni sono disponibili al link https://docs.microsoft.com/en-us/intune/network-bandwidth-use

Ottenimento dell’Hardware ID del dispositivo

Poiché stiamo utilizzando una macchina di test e il produttore di hardware non ha provveduto ad inserire l’Hardware ID nel tenant di Azure, dobbiamo utilizzare uno script PowerShell per recuperare le informazioni che ci servono e che poi dovremo caricare nel portale di Microsoft Intune. Dalla VM accesa aprite un prompt di PowerShell con privilegi elevati e scaricate lo script Get-WindowsAutoPilotinfo dalla PowerShell Gallery con il comando Install-Script -Name Get-WindowsAutoPilotInfo

Una volta che avete effettuato il download dello script, per poterlo eseguire, dovete modificare la execution policy degli script con il
comando Set-ExecutionPolicy -ExecutionPolicy Bypass ed eseguire lo script con il comando Get-WindowsAutoPilotInfo.ps1 -OutputFile “C:\MyComputers.csv”

Figura 5: Download ed esecuzione dello script Get-WindowsAutoPilotInfo.ps1

Figura 6: Output del comando Get-WindowsAutoPilotInfo.ps1

Una volta che avrete ottenuto l’Hardware ID della vostra macchina, potrete caricare il file .CSV nel portale di Microsoft Intune. Dal portale di Azure andate in Device Enrollment e nella pagina Windows Enrollment selezionate Devices

Figura 7: Gestione dei dispositivi di Windows AutoPilot

Fate clic su Import per caricare il file con estensione .CSV che avete ottenuto come output dello script Get-WindowsAutoPilotInfo.ps1

Figura 8: Caricamento del file CSV con i dispositivi da gestire con Windows AutoPilot

Sarà necessario attendere fino a 15 minuti per completare il processo di importazione e sincronizzazione.

Figura 9: Il dispositivo è stato caricato correttamente nel portale di Microsoft Intune

Terminato il processo di importazione e di sincronizzazione dobbiamo assegnare un Windows AutoPilot deployment profile al nostro dispositivo. Per creare un nuovo deployment profile dal portale di Azure andate in Device Enrollment e nella pagina Windows Enrollment selezionate Deployment Profiles

Figura 10: Creazione di un nuovo deployment profile per l’enrollment di Windows 10 utilizzando Windows AutoPilot

Cliccate su + Create profile per creare un nuovo profilo. Date un nome ed una descrizione al profilo.

Figura 11: Nome e descrizione del deployment profile

Configurate la pagina di Out-Of-The-Box Experience (OOBE) scegliendo come Deployment mode
User-driven e modificando lo User Account type in Standard. Windows AutoPilot infatti, a differenza di quello che succede nei normali setup OOBE, permette di fare in modo che l’utente creato sia un utente standard e non un amministratore della macchina, come di solito avviene quando create il primo utente dopo il primo avvio della macchina. Nella casella Join to Azure AD potete scegliere se il dispositivo sarà Azure AD joined oppure Hybrid Azure AD joined

Figura 12: Configurazione della Out-Of-The-Box (OOBE)

Nella scheda Assignment decidete a quale gruppo di Azure AD volete assegnare il deployment profile. Io ho scelto un Security Group di Azure AD, all’interno del quale deve trovarsi il dispositivo da configurare.

Figura 13: Scelta del gruppo di utenti di Azure AD a cui assegnare il deployment profile

Figura 14: Review e creazione del deployment profile

Figura 15: Il dispositivo deve trovarsi nel gruppo di Azure AD a cui avete assegnato il deployment profile

A questo punto attendete che al dispositivo venga assegnato il deployment profile che avete appena creato. Dal portale di Azure andate in Device Enrollment e nella pagina Windows Enrollment selezionate Devices. Verificate che il Profile Status del vostro dispositivo sia Assigned. Ci potrebbero volere alcuni minuti.

Figura 16: Lo stato del profilo assegnato al dispositivo riporta la scritta Assigned

Assegnare un utente a un dispositivo Windows AutoPilot specifico

È possibile assegnare un utente a un dispositivo Windows AutoPilot specifico. Questa assegnazione precompila un utente di Azure Active Directory nella pagina di accesso distintiva dell’azienda durante l’installazione di Windows. Consente inoltre di definire il nome di un messaggio di saluto personalizzato. Questa informazione non viene precompilata nella pagina di accesso di Windows né la modifica. Solo gli utenti con licenza di Intune possono essere assegnati con questa procedura.

Test di Windows AutoPilot

Adesso che avete completato la configurazione di Windows AutoPilot nel portale di Intune, potete lanciare il tool Sysprep (che trovate nel percorso C:\Windows\System32\Sysprep) nella vostra macchina, in modo tale da poter poi testare l’OOBE. Lanciate il tool e spegnete la macchina. Io ho anche catturato un checkpoint della VM.

Figura 17: esecuzione di Sysprep per testare l’esperienza OOBE con Windows AutoPilot

Nel momento in cui riavvierete la macchina, procedete con la configurazione della tastiera e quando vi verrà chiesto potrete mettere le vostre credenziali di Azure AD per configurare il computer.

Figura 18: Richiesta di inserimento delle credenziali dell’utente

Al termine del login all’utente verrà chiesto di configurare Windows Hello per l’accesso al PC e di confermare la propria identità tramite chiamata telefonica oppure messaggio SMS.

Figura 19: Configurazione di Windows Hello al primo login dell’utente di Azure AD

Figura 20: Creazione del PIN in Windows Hello

Come potrete facilmente verificare l’utente è un utente Standard e non sarà amministratore del PC, ma solo un membro del gruppo Users. L’utente viene individuato come defaultuser0

Figura 21: L’utente creato è di tipo Standard

Nel portale di Intune, dalla scheda Devices potete selezionare Azure AD devices e verificare che il nuovo dispositivo sia stato automaticamente aggiunto ai dispositivi gestiti tramite MDM.

Figura 22: Il dispositivo è stato aggiunto a quelli gestiti da Microsoft Intune

Visto che adesso il dispositivo è aggiunto a Microsoft Intune, riceverà tutte le configurazioni e le app che avete deciso di distribuire all’utente con cui vi siete loggati. Per sapere come distribuire applicazioni utilizzando Microsoft Intune vi rimando alla lettura dell’articolo Microsoft 365 Modern Desktop Management – Distribuire e gestire le applicazioni sui dispositivi aziendali con Microsoft Intune

Figura 23: Se all’utente sono state assegnate delle app tramite Microsoft Intune, verranno immediatamente distribuite

Configurazione di Windows AutoPilot con una macchina nuova

L’utilizzo di Windows AutoPilot è utile specialmente in quegli scenari in cui i dipendenti ricevono un nuovo dispositivo direttamente dal produttore di hardware e devono essere produttivi il prima possibile.

Per recuperare l’Hardware ID (nel caso non sia stato creato dal produttore), è possibile lanciare lo script Get-WindowsAutoPilotinfo direttamente durante la prima accensione della macchina, subito dopo averla tirata fuori dalla confezione!

Scaricate lo script dal link https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo/1.6/Content/Get-WindowsAutoPilotInfo.ps1 e salvatelo in una cartella condivisa in rete.

Dopo aver acceso la macchina, appena vi appare la prima schermata, utilizzate la combinazione di tasti SHIFT+F10 per far apparire un prompt di DOS.

Figura 24: Lancio di un prompt di DOS durante il primo avvio della macchina

Utilizzate il comando NET USE per montare la share di rete dove avete salvato lo script Get-WindowsAutoPilotinfo. Digitando il comando Powershell passate ad un prompt PowerShell e dalla share di rete montata lanciate il
comando Set-ExecutionPolicy -ExecutionPolicy Bypass ed eseguite lo script con il comando Get-WindowsAutoPilotInfo.ps1 -OutputFile “C:\VostroFile.csv”. Nella figura sotto sono mostrati tutti i dettagli.

Figura 25: Esecuzione dello script Get-WindowsAutoPilotInfo.ps1 durante il primo avvio della VM

Una volta che avete ottenuto l’Hardware ID della macchina, potete caricarlo nel portale di Microsoft Intune. Dal portale di Azure andate in Device Enrollment e nella pagina Windows Enrollment selezionate Devices. Fate clic su Import per caricare il file con estensione .CSV che avete ottenuto come output dello script e attendete fino a 15 minuti per completare l’importazione e la sincronizzazione.

Figura 26: Upload del nuovo Hardware ID nel portale di Microsoft Intune

È anche possibile assegnare la macchina direttamente ad un utente. Dopo aver atteso che la macchina sia visibile nel portale di Microsoft Intune, selezionatela e cliccate su Assign User, come mostrato in figura:

Figura 27: Assegnazione della macchina ad uno specifico utente

Non dimenticate di aggiungere il nuovo dispositivo al gruppo di Azure AD a cui avete assegnato il deployment profile.

Figura 28: Aggiunta del nuovo device al gruppo di Azure AD a cui è stato assegnato il deployment profile

Verificate che il Profile Status del vostro dispositivo sia Assigned. Ci potrebbero volere alcuni minuti.

Figura 29: Assegnazione del deployment profile al nuovo dispositivo

Proseguite quindi il setup OOBE della macchina. Se avrete configurato tutto correttamente, andrete direttamente alla schermata di inserimento della password, in quanto avete assegnato il dispositivo ad un utente specifico di Azure AD.

Figura 30: Poiché il dispositivo è stato assegnato ad uno specifico utente, al primo avvio all’utente viene solo chiesto di inserire la password

Conclusioni

Windows AutoPilot semplifica la registrazione dei dispositivi in Intune. La creazione e la gestione di immagini del sistema operativo personalizzate sono processi che richiedono molto tempo. Richiede tempo anche l’applicazione di queste immagini personalizzate del sistema operativo ai nuovi dispositivi per prepararli per l’uso prima della consegna agli utenti finali. Con Microsoft Intune e AutoPilot è possibile assegnare i nuovi dispositivi agli utenti finali senza la necessità di compilare, gestire e applicare le immagini del sistema operativo personalizzate ai dispositivi. Quando si usa Intune per gestire i dispositivi AutoPilot, è possibile gestire criteri, profili, applicazioni e così via sui dispositivi che sono stati registrati.

Windows AutoPilot è un servizio cloud che serve per la distribuzione di Windows 10. Con Windows AutoPilot è possibile personalizzare l’Out-Of-The-Box Experience (OOBE) per i computer Windows 10 senza che ci sia la necessità di distribuire una nuova immagine di Windows. L’utilizzo di Windows AutoPilot è utile specialmente in quegli scenari in cui i dipendenti ricevono un nuovo dispositivo direttamente dal produttore di hardware e devono essere produttivi il prima possibile.

Utilizzando questo servizio cloud al posto dei classici metodi di distribuzione on-premises è possibile beneficiare dei seguenti vantaggi:

• Non è necessario preparare delle immagini di Windows 10 on-premises
• Non è necessario personalizzare le distribuzioni aggiungendo drivers
• Non è necessario disporre di un’infrastruttura on-premises per la distribuzione delle immagini di Windows 10

Windows AutoPilot, disponibile con licenze Azure AD Premium oppure con Microsoft Intune, vi permetterà di:

• Aggiungere i dispositivi Windows 10 ad Azure AD in maniera automatica
• Fare l’auto-enrollment dei dispositivi in Microsoft Intune
• Impedire la creazione di un account amministrativo
• Personalizzare l’esperienza OOBE dei nuovi computer

Con Windows AutoPilot con il White Glow verranno applicati tutti i criteri di sicurezza che l’IT ha deciso di implementare per i dispositivi (certificati, modelli di sicurezza, impostazioni, app e altro) durante il pre-provisioning e prima ancora che il PC venga distribuito all’utente. Inoltre, verranno installate anche tutte le app configurate per l’installazione nel dispositivo e anche quelle destinate all’utente che è stato preassegnato (nel caso lo abbiate preventivamente fatto) al dispositivo AutoPilot. Per sapere come distribuire applicazioni tramite Intune vi invito a leggere la guida Microsoft 365 Modern Desktop Management – Distribuire e gestire le applicazioni sui dispositivi aziendali con Microsoft Intune

In questo modo il PC sarà pre-configurato dallo staff IT e sarà pronto per poter essere utilizzato dai dipendenti.

Prerequisiti per l’uso di Windows AutoPilot

Per utilizzare Windows AutoPilot è necessario che il dispositivo sia “conosciuto” dalla vostra infrastruttura cloud. Quando comprate un nuovo dispositivo il produttore dell’hardware può caricare per conto vostro le informazioni specifiche del dispositivo. Se invece volete utilizzare Windows AutoPilot per gestire i dispositivi che già possedete nella vostra azienda, potete prendere le informazioni relative ai dispositivi utilizzando un apposito script PowerShell per generare un file .CSV con le informazioni che poi potete caricare all’interno di Microsoft Intune o di Microsoft Store for Business.

Prima di poter iniziare ad utilizzare Windows AutoPilot per la distribuzione di Windows 10 devono essere verificati i seguenti prerequisiti:

• I dispositivi devono avere già Windows 10 preinstallato. Windows AutoPilot trasforma un’installazione esistente di Windows 10 modificando i parametri di configurazione nella fase di OOBE. Non verrà infatti distribuita una immagine di Windows 10 e il dispositivo deve cominciare il setup OOBE. Il dispositivo può essere un nuovo dispositivo con già preinstallato il sistema operativo Windows 10 che un hardware vendor ha distribuito oppure può essere un dispositivo Windows 10 che già possedete e che è stato configurato per partire dal setup OOBE, per esempio utilizzando il System Preparation Tool (Sysprep).
• Utilizzare Windows 10 Pro, Enterprise oppure Education. Windows AutoPilot non può distribuire Windows 10 Home oppure un sistema operativo precedente alla Creators Update (versione 1703). Alcune funzionalità, come ad esempio Windows automatic redeployment, richiedono la versione 1709 o successiva.
• Il dispositivo deve essere registrato dall’organizzazione. Windows AutoPilot può distribuire sistemi operativi Windows 10 solo ai dispositivi “conosciuti” e “registrati”. Per prima cosa dovete caricare le informazioni specifiche del dispositivo che includono gli hardware IDs del device in Microsoft Intune oppure in Microsoft Store for Business.
• I dispositivi devono disporre di una connessione ad Internet. Windows AutoPilot è un servizio cloud e può distribuire il sistema operativo Windows 10 soltanto dopo che i dispositivi si sono connessi ad Internet.
• Le aziende devono utilizzare Azure AD. L’utilizzo di Azure AD è obbligatorio perché Windows AutoPilot dipende da Microsoft Intune o da Microsoft Store for Business ed entrambi richiedono Azure AD. È necessario possedere le licenze Azure AD Premium P1 oppure P2.
• Utilizzo di Intune o di Microsoft Store for Business. è necessario caricare le informazioni specifiche del dispositivo in Microsoft Intune o in Microsoft Store for Business

Prerequisiti per l’uso di Windows AutoPilot con il White Glove deployment

In aggiunta a tutti i prerequisiti per Windows AutoPilot che abbiamo visto prima, Windows AutoPilot con il White Glove deployment necessità anche dei seguenti prerequisiti:

• Windows 10, versione 1903 o successiva
• Una sottoscrizione di Microsoft Intune
• Un dispositivo fisico che supporta TPM 2.0 e la device attestation. Le macchine virtuali non sono supportate.
• Connettività Internet attraverso rete cablata. Non è supportata la connessione WiFi

Se la navigazione Internet è dietro proxy oppure firewall assicuratevi che la macchina possa utilizzare le porte HTTP 80 e HTTPS 443 e che possa navigare i seguenti URL:

• https://go.microsoft.com
• https://login.microsoftonline.com
• https://login.live.com
• https://account.live.com
• https://signup.live.com
• https://licensing.mp.microsoft.com
• https://licensing.md.mp.microsoft.com
• https://ctldl.windowsupdate.com
• https://download.windowsupdate.com

Maggiori informazioni sono disponibili al link https://docs.microsoft.com/en-us/intune/network-bandwidth-use

Fase di setup

Una volta che avete rispettato tutti i prerequisiti, il setup di svolge in queste fasi:

1. Ottenere gli Hardware IDs dei dispositivi che volete configurare con Windows AutoPilot
2. Caricare gli Hardware IDs nel portale di Intune o in Microsoft Store for Business
3. Creare un Windows AutoPilot deployment profile
4. Applicare il Windows AutoPilot deployment profile ai dispositivi da configurare

Figura 1: Principio di funzionamento di Windows AutoPilot

Gestione di Windows AutoPilot con Microsoft Intune

In questa guida darò per scontato che abbiate già una sottoscrizione Intune e abbiate un minimo di dimestichezza con l’interfaccia. Vi consiglio, prima di proseguire, di dare un’occhiata al mio articolo Microsoft 365 Modern Desktop Management – Enroll di un dispositivo in Microsoft Intune per verificare di aver integrato Azure AD con Intune, di aver abilitato la registrazione dei dispositivi in Azure AD e di aver impostato l’autorità per la gestione dei dispositivi.

È infatti obbligatorio che abbiate configurato il mobile device management enrollment automatico dei dispositivi Windows 10 in Azure AD. Dal portale di Azure selezionate Azure Active Directory > Mobility (MDM and MAM) e successivamente Microsoft Intune

Figura 2: Configurazione del mobile device management enrollment automatic

Nel blade di Microsoft Intune, in MDM User scope, selezionate All se volete permettere a tutti gli utenti della vostra Azure AD di poter effettuare l’enrollment dei propri dispositivi al mobile device management

Figura 3: Configurazione dell’MDM user scope per gli utenti di Azure AD

Personalizzazione del Company Branding

Per poter utilizzare Windows AutoPilot è obbligatorio personalizzare il Company Branding. Dal portale di Azure selezionate Azure Active Directory e successivamente cliccate su Company Branding. Cliccate su Configure e procedete alla personalizzazione. Per Windows AutoPilot è obbligatorio compilare i campi Sign-in page text e Square logo image.

Figura 4: Personalizzazione del Company Branding con le informazioni obbligatorie per Windows AutoPilot

Ottenimento dell’Hardware ID del dispositivo

Poiché stiamo utilizzando una macchina di test e il produttore di hardware non ha provveduto ad inserire l’Hardware ID nel tenant di Azure, dobbiamo utilizzare uno script PowerShell per recuperare le informazioni che ci servono e che poi dovremo caricare nel portale di Microsoft Intune. Dalla VM accesa aprite un prompt di PowerShell con privilegi elevati e scaricate lo script Get-WindowsAutoPilotinfo dalla PowerShell Gallery con il comando Install-Script -Name Get-WindowsAutoPilotInfo

Una volta che avete effettuato il download dello script, per poterlo eseguire, dovete modificare la execution policy degli script con il
comando Set-ExecutionPolicy -ExecutionPolicy Bypass ed eseguire lo script con il comando Get-WindowsAutoPilotInfo.ps1 -OutputFile “C:\MyComputers.csv”

Figura 5: Download ed esecuzione dello script Get-WindowsAutoPilotInfo.ps1

Figura 6: Output del comando Get-WindowsAutoPilotInfo.ps1

Una volta che avrete ottenuto l’Hardware ID della vostra macchina, potrete caricare il file .CSV nel portale di Microsoft Intune. Dal portale di Azure andate in Device Enrollment e nella pagina Windows Enrollment selezionate Devices

Figura 7: Gestione dei dispositivi di Windows AutoPilot

Fate clic su Import per caricare il file con estensione .CSV che avete ottenuto come output dello script Get-WindowsAutoPilotInfo.ps1

Figura 8: Caricamento del file CSV con i dispositivi da gestire con Windows AutoPilot

Sarà necessario attendere fino a 15 minuti per completare il processo di importazione e sincronizzazione.

Figura 9: Il dispositivo è stato caricato correttamente nel portale di Microsoft Intune

Dopo aver importato il dispositivo in Microsoft Intune, create un nuovo Security Group ed aggiungete il dispositivo al gruppo creato. Il security group verrà successivamente utilizzato per l’associazione del deployment
profile e per l’assegnazione delle licenze di Microsoft Intune.

Figura 10: Il dispositivo è stato aggiunto al security group di Azure AD

Terminato il processo di importazione e di sincronizzazione dobbiamo assegnare un Windows AutoPilot deployment profile al nostro dispositivo. Per creare un nuovo deployment profile dal portale di Azure andate in Device Enrollment e nella pagina Windows Enrollment selezionate Deployment Profiles

Figura 11: Creazione di un nuovo deployment profile per l’enrollment di Windows 10 utilizzando Windows AutoPilot

Cliccate su + Create profile per creare un nuovo profilo. Date un nome ed una descrizione al profilo.

Figura 12: Nome e descrizione del deployment profile

Configurate la pagina di Out-Of-The-Box Experience (OOBE) scegliendo come Deployment mode
User-driven e modificando lo User Account type in Standard. Windows AutoPilot infatti, a differenza di quello che succede nei normali setup OOBE, permette di fare in modo che l’utente creato sia un utente standard e non un amministratore della macchina, come di solito avviene quando create il primo utente dopo il primo avvio della macchina. Nella casella Join to Azure AD potete scegliere se il dispositivo sarà Azure AD joined oppure Hybrid Azure AD joined.

Ricordatevi di abilitare la funzionalità Allow White Glove OOBE

Figura 13: Configurazione della Out-Of-The-Box (OOBE)

Nella scheda Assignment decidete a quale gruppo di Azure AD volete assegnare il deployment profile. Utilizzate il security group che avete creato prima e a cui avete aggiunto il dispositivo.

Figura 14: Gruppo di dispositivi a cui verrà applicato il deployment profile

Figura 15: Review e creazione del deployment profile

Verificate che al dispositivo venga assegnato il deployment profile che avete appena creato. Dal portale di Azure andate in Device Enrollment e nella pagina Windows Enrollment selezionate Devices. Verificate che il Profile Status del vostro dispositivo sia Assigned. Ci potrebbero volere alcuni minuti.

Figura 16: Il deployment profile è stato assegnato al dispositivo

Assegnazione delle licenze di Microsoft Intune ai dispositivi

Per poter utilizzare il Windows AutoPilot con il white glove è necessario che i dispositivi abbiano una licenza di Microsoft Intune. Per comodità ho assegnato le licenze di Microsoft Intune all’intero security group di Azure AD in cui si trova il dispositivo, in modo tale che aggiungendo un nuovo dispositivo al gruppo la licenza venga immediatamente associata. Ovviamente è anche possibile associare la licenza ai singolo dispositivo.

Figura 17: Associazione delle licenze di Microsoft Intune ad un security group di Azure AD che contiene i dispositivi da gestire

Figura 18: Opzioni delle licenze da associare al dispositivo o al gruppo di Azure AD

Figura 19: Verifica dell’associazione delle licenze di Microsoft Intune

Funzionamento di Windows AutoPilot con il White Glow

Windows AutoPilot con il White Glow si compone di due fasi:

1. Il tecnico IT prepara il dispositivo che verrà successivamente distribuito all’utente finale (fase del White Glow)
2. L’utente finale prosegue con il setup di Windows 10, versione 1903 e successiva inserendo le proprie credenziali di Azure AD

Preparazione del dispositivo da parte del tecnico IT (fase del White Glow)

Dopo che il cliente o l’amministratore IT ha configurato tutte le app e le impostazioni desiderate per i propri dispositivi tramite Intune, il tecnico del White Glow può iniziare il processo di configurazione del dispositivo. Il tecnico potrebbe essere un membro del personale IT, un partner di servizi o un OEM: ogni organizzazione può decidere chi deve eseguire queste attività. Indipendentemente dallo scenario, il processo che deve essere eseguito dal tecnico è lo stesso.

Dopo aver avviato il dispositivo con Windows 10 Pro, Enterprise o Education, versione 1903 o successiva, nella prima schermata della configurazione guidata, non fate clic su Avanti. Premete invece il tasto Windows 5 volte per visualizzare una finestra di dialogo in cui vi verrà chiesto se volete installare un nuovo package di provisioning oppure se volete utilizzare il Windows AutoPilot provisioning, per fare il pre-provisioning del dispositivo con le configurazioni e le applicazioni impostate in Microsoft Intune.

Figura 20: Nella prima schermata di avvio del dispositivo bisogna premere 5 volte il tasto Windows:

Figura 21: Schermata dove scegliere di effettuare il Windows AutoPilot provisioning

Nella schermata di configurazione di Windows Autopilot verranno visualizzate le seguenti informazioni sul dispositivo:

• Il deployment profile di Windows AutoPilot assegnato al dispositivo.
• Il mome dell’organizzazione.
• L’utente assegnato al dispositivo (se presente).
• Un codice QR che contiene un identificatore univoco per il dispositivo

Figura 22: Configurazione di Windows AutoPilot

Se le informazioni riportate nella schermata sono corrette, fate clic su Provision.

Figura 23: Il dispositivo viene configurato tramite Windows AutoPilot

Se il processo di pre-provisioning viene completato correttamente, dopo qualche minuto verrà visualizzata una schermata di colore verde con le informazioni sul dispositivo, inclusi gli stessi dettagli presentati in precedenza.

Figura 24: La configurazione del dispositivo tramite Windows AutoPilot è andata a buon fine

Fate clic su Reseal per completare la procedura sul dispositivo. A questo punto, il dispositivo può essere spedito all’utente finale.

Se il processo di pre-provisioning non riesce vi verrà visualizzata una schermata di colore rosso con le informazioni sul dispositivo, inclusi gli stessi dettagli presentati in precedenza. I log diagnostici possono essere raccolti dal dispositivo, possono essere analizzati per capire il motivo del fallimento e il dispositivo può essere reimpostato per avviare di nuovo il processo. Se eseguite l’operazione su una macchina virtuale o se vi dimenticate di assegnare la licenza di Intune al dispositivo ricevete la schermata di errore di colore rosso.

Figura 25: Il processo di pre-provisioning è fallito

Avvio del dispositivo da parte dell’utente finale

Se il processo di pre-provisioning è stato completato correttamente e il dispositivo è stato consegnato all’utente finale per completare il normale processo di configurazione basato su Windows Autopilot, l’utente non dovrà fare altro che accenderlo e seguire le configurazioni classiche del setup OOBE. Dopo aver inserito le credenziali di Azure AD, gli verrà chiesto di configurare Windows Hello per l’accesso al PC e di confermare la propria identità tramite chiamata telefonica oppure messaggio SMS.

Figura 26: Richiesta di inserimento delle credenziali dell’utente

Figura 27: Configurazione di Windows Hello al primo login dell’utente di Azure AD

Figura 28: Creazione del PIN in Windows Hello

Conclusioni

Windows AutoPilot con il white glove deployment permette alle aziende di poter configurare facilmente i nuovi dispositivi e di poter distribuire i computer con Windows 10 già completamente configurati e pronti per poter essere utilizzati dall’utente finale. Quando l’utente finale accenderà per la prima volta il proprio dispositivo lo troverà perfettamente configurato e la fase di inizializzazione sarà molto più veloce, permettendo all’utente di essere operativo nel minor tempo possibile.

Avere un modern desktop (cioè un’installazione di Windows 10 e Office 365, mantenuta costantemente aggiornata) significa sfruttare al massimo le funzionalità offerte sia dal sistema operativo che dalla suite di collaborazione Office 365, avendo la possibilità di migliorare la produttività, il lavoro di gruppo e la collaborazione all’interno dell’azienda. In più, avendo sempre un sistema aggiornato, possiamo assicurare un livello di efficienza ma soprattutto di sicurezza notevole, che ci permette di difenderci dai continui attacchi che ci arrivano dall’esterno (e molto spesso anche dall’interno) dell’azienda.

Con Microsoft 365 abbiamo la possibilità di poter avere con un licensing molto semplice la maggior parte dei software necessari per poter essere realmente competitivi in un mercato estremamente dinamico come quello che stiamo vivendo e di adattarci alle nuove modalità di lavoro (come ad esempio l’Home working o lo Smart working).

La soluzione Microsoft 365 integra in un unico pacchetto Windows 10 Enterprise, Office 365 e Enterrise Mobility + Security.

Figura 1: Passaggi chiave necessari per passare al Modern Desktop

Poiché le aziende hanno bisogno che i propri dipendenti siano sempre più “mobili”, il ruolo dell’IT Admin è diventato molto più complesso rispetto al passato e non è più limitato a gestire i desktop, ma anche i dispositivi mobili, come ad esempio tablet e smartphone.

La possibilità di utilizzare Microsoft Intune semplifica di molto il lavoro degli amministratori di sistema e questo servizio basato sul cloud permette di:

• Gestire i dispositivi mobili e i PC usati dagli utenti per accedere ai dati aziendali.
• Gestire le app per dispositivi mobili usati dagli utenti.
• Proteggere le informazioni aziendali grazie alla possibilità di controllare le modalità di accesso e condivisione dei dati da parte della forza lavoro.
• Assicurarsi che i dispositivi e le app siano conformi ai requisiti di sicurezza aziendali.

Microsoft Intune è il componente della suite Enterprise Mobility + Security (EMS) di Microsoft che gestisce dispositivi e app per dispositivi mobili. Intune è integrato con altri componenti EMS come Azure Active Directory (Azure AD) per il controllo delle identità e degli accessi e Azure Information Protection per la protezione dei dati. Quando viene usato con Office 365 consente agli utenti di essere produttivi con tutti i dispositivi, garantendo al tempo stesso la protezione delle informazioni aziendali.

Figura 2: Diagramma dell’architettura di Microsoft Intune

In questa guida ci occuperemo di configurare i computer Windows 10 che hanno effettuato l’enrollment a Microsoft Intune. Vi invito quindi, prima di procedere oltre, a leggere la guida Microsoft 365 Modern Desktop Management – Enroll di un dispositivo in Microsoft Intune

Assicuratevi di aver già:

• Abilitato la gestione dei dispositivi e configurato la Mobile Device Management Authority. In questa guida considererò che utilizziate solo Microsoft Intune senza integrazione con System Center Configuration Manager.
• Personalizzato il portale di accesso ed il Company branding
• Effettuato l’Enrollment di un dispositivo Windows 10

Nelle figure sotto è mostrato l’enrollement del dispositivo solo per la gestione

Figura 3: Enrollment del dispositivo Windows 10 solo per la gestione

Figura 4: Configurazione del dispositivo dopo l’enrollment

Figura 5. Enrollment di Windows 10 completato

Configurazione di Windows 10 Update Rings in Microsoft Intune

Tramite Microsoft intune è possibile configurare e gestire i Windows 10 update rings, in modo tale da assicurarci che i sistemi Windows 10 vengano mantenuti aggiornati quando le nuove build vengono rilasciate. Un update ring include un gruppo di configurazioni che gestisce quando e come gli aggiornamenti di Windows verranno installati. Per maggiori dettagli potete visitare la pagina Manage software updates in Intune.

Dal portale di Azure navigate in Microsoft Intune e selezionate la voce Software Updates. In Windows 10 Update Rings, cliccate su + Create per creare una nuova Update Ring policy.

Figura 6: Creazione di una nuova Update Ring policy

Dopo aver dato un nome ed una descrizione alla Update Ring policy, cliccate su Settings per configurare la modalità in cui verranno distribuiti gli aggiornamenti e le diverse configurazioni in merito alle ore lavorative, alle modalità di riavvio del sistema, ecc.

Trovate alla pagina https://docs.microsoft.com/en-us/intune/windows-update-settings informazioni dettagliate sulle configurazioni dei Windows 10 update rings

Figura 7: Configurazioni dei Windows 10 update rings

Terminate le configurazioni, fate clic su Save per salvare la policy e dal nodo Assignments decidete a quale gruppo di utenti di Azure AD volete assegnare la Update Ring policy creata.

Figura 8: Assegnazione della Update Ring policy ad un gruppo di Azure AD

Nella scheda Overview dei Software Updates è possibile visualizzare informazioni sullo stato di tutti gli update rings che avete assegnato ai dispositivi e agli utenti. È possibile anche andare nel dettaglio e selezionando il singolo update ring potrete ricevere maggiori informazioni in merito allo stato dello specifico update ring.

Figura 9: Informazioni sullo stato di tutti gli update rings

Figura 10: Informazioni sullo stato dell’update ring che abbiamo creato prima

Creazione di un Device Configuration profile

Microsoft Intune include impostazioni e funzionalità che è possibile abilitare o disabilitare nei diversi dispositivi all’interno dell’azienda ed è possibile applicare dei veri e propri profili di configurazione. Per creare un nuovo device configuration profile, dal portale di Azure navigate in Microsoft Intune e scegliete Device configuration > Profiles > +
Create profile

Figura 11: Creazione di un nuovo device configuration profile

Nel nuovo blade che si aprirà inserite un nome per la vostra configurazione ed inserite il tipo di piattaforma da gestire e il tipo di profilo che volete creare.

Tra le diverse piattaforma potete scegliere:

• Android
• Android enterprise
• iOS
• macOS
• Windows Phone 8.1
• Windows 8.1 and later
• Windows 10 and later

Mentre tra i profili potete scegliere:

• Administrative templates
• Custom
• Delivery optimization
• Device features
• Device restrictions
• Edition upgrade and mode switch
• Education
• Email
• Endpoint protection
• Identity protection
• Kiosk
• PKCS certificate
• SCEP certificate
• Trusted certificate
• Update policies
• VPN
• Wi-Fi
• Windows Defender ATP
• Windows Information Protection

Maggiori informazioni sulle configurazioni sono disponibili alla pagina https://docs.microsoft.com/it-it/intune/device-profile-create

Nel mio caso come piattaforma da gestire ho scelto Windows 10 and later e come profile type
ho scelto Custom. Cliccando su Settings ho aggiunto una nuova configurazione OMA-URI (Open Mobile Alliance Uniform Resource Identifier). Le configurazioni OMA-URI permettono di controllare il comportamento dei dispositivi e sono di fatto uno standard utilizzo nel mondo Mobile che viene utilizzato per controllare le funzionalità dei dispositivi. Trovate maggiori dettagli sulla creazione dei profili personalizzati alla pagina https://docs.microsoft.com/it-it/intune/custom-settings-windows-10

Figura 12: Creazione di un nuovo profilo personalizzato e di una nuova confgiurazione OMA-URI (Open Mobile Alliance Uniform Resource Identifier)

Poiché voglio gestire la protezione real-time di Windows 10, dopo aver dato un nome alla configurazione OMA-URI, ho inserito il valore ./Vendor/MSFT/Policy/Config/Defender/AllowRealtimeMonitoring (il valore è case-sensitive e ha un punto all’inizio). Ho scelto come data type
Integer e come value il valore 1 per abilitare la funzionalità.

Figura 13: Creazione del nuovo OMA-URI setting per la configurazione della real-time protection di Windows 10

Cliccate due volte su OK e poi su Create per confermare la creazione del nuovo device configuration profile. Dopo aver creato il profilo è necessario assegnarlo agli utenti e ai dispositivi. Cliccate su Assignment per assegnarlo. Io ho selezionato il security group di Azure AD dove si trova l’utente collegato al mio dispositivo.

Figura 14: Assegnazione del device configuration profile ad un security group di Azure AD

Verifica dell’avvenuta applicazione del nuovo device configuration profile

Per verificare che il nuovo device configuration profile sia stato assegnato, collegatevi alla macchina gestita e dall’app Settings andate in Accounts > Access work or school. Cliccando sulla voce Connected to <Azienda> MDM cliccate su Info e successivamente su Sync per forzare la sincronizzazione delle policy. Assicuratevi che la sincronizzazione sia andata a buon fine.

Figura 15: Sincronizzazione completata con successo

Sempre dall’app Settings, andate in Update & Security > Windows Security and cliccate Open Windows Security.

Figura 16: Apertura dell’app Windows Security

Dall’app Windows Security, navigate fino a Virus & threat protection settings e cliccate sul link Manage settings

Figura 17: Verifica delle configurazioni di Virus & threat protection

Confermate che le configurazioni relative alla Real-time protection siano su ON e che siano in grigio (non modificabili), in quanto sono state imposte tramite una policy di Microsoft Intune.

Figura 18: Le configurazioni relative alla Real-time protection di windows 10 sono state impostate tramite policy di Microsoft Intune

Dynamic Management in Windows 10

Windows 10 permette di gestire i dispositivi in maniera differente in base alla posizione, alla rete a cui sono connessi oppure in base all’orario. A partire da Windows 10, versione 1703 è possibile, ad esempio, fare in modo che i dispositivi gestiti da Microsoft Intune abbiano la webcam disabilitata quando si trovano nella rete aziendale , possano avere la rete cellullare disabilitata quando si trovano fuori dalla nazione per evitare d’incorrere in roaming costoso oppure la rete wireless può essere disabilitata quando il dispositivo non si trova all’interno dell’azienda. Una volta configurati, queste configurazioni verranno forzate anche se il dispositivo non è in grado di raggiungere il server di gestione.

Figura 19: Principio di funzionamento del Dynamic Management

Dal portale di Azure andate in Microsoft Intune e scegliete Device configuration > Profiles > +
Create profile per creare un nuovo device configuration profile. Nel mio caso come piattaforma da gestire ho scelto Windows 10 and later e come profile type
ho scelto Custom. Cliccando su Settings ho aggiunto una nuova configurazione OMA-URI (Open Mobile Alliance Uniform Resource Identifier).

Figura 20: Creazione di nuovo device configuration profile per Windows 10

Voglio fare in modo che la webcam sia disabilitata quando il dispositivo Windows 10 si trovi all’interno della rete aziendale, ma torni ad essere abilitata quando invece il dispositivo si trova in un’altra rete. La prima configurazione OMA-URI che ho creato disabilita la webcam. Inserite il valore ./Vendor/MSFT/DynamicManagement/Contexts/NetworkBased/SettingsPack (il valore è case-sensitive e ha un punto all’inizio) nel campo OMA-URI, scegliete String come Data type e incollate il seguente valore:

<SyncML>
  <SyncBody>
     <Replace>
       <CmdID>1331</CmdID>
         <Item>
           <Target>
               <LocURI>./Vendor/MSFT/Policy/Config/Camera/AllowCamera</LocURI>
           </Target>
           <Meta>
              <Format xmlns="syncml:metinf">int</Format>
           </Meta>
           <Data>0</Data>
         </Item>
      </Replace>
      <Final/>
   </SyncBody>
</SyncML>

Figura 21: Configurazione per gestire la webcam

Aggiungete un nuovo Custom
OMA-URI Setting e nel campo OMA-URI inserite ./Vendor/MSFT/DynamicManagement/Contexts/NetworkBased/SignalDefinition (il valore è case-sensitive e ha un punto all’inizio). In Data type scegliete String e incollate il valore riportato sotto:

<rule schemaVersion="1.0">
   <signal type="ipConfig">
      <ipv4Gateway>10.0.0.254</ipv4Gateway>
   </signal>
</rule>

Con questa regola abbiamo definito quale sarà la rete aziendale, indicando di fatto che se il dispositivo Windows 10 è configurato per avere l’indirizzo IP del gateway 10.0.0.254, allora si troverà nella rete aziendale. Modificate ovviamente il parametro in base alle vostre necessità.

Figura 22: Creazione della regola per identificare la rete aziendale

L’ultima regola da aggiungere serve ad abilitare le notifiche. Aggiungete un nuovo Custom
OMA-URI Setting e nel campo OMA-URI inserite ./Vendor/MSFT/DynamicManagement/NotificationsEnabled (il valore è case-sensitive e ha un punto all’inizio). Nel campo Data type scegliete Boolean e in Value selezionate True.

Figura 23: Creazione dela regola per abilitare le notiifche

Cliccate due volte su OK e poi su Create per confermare la creazione del nuovo device configuration profile. Dopo aver creato il profilo è necessario assegnarlo agli utenti e ai dispositivi. Cliccate su Assignment per assegnarlo. Io ho selezionato il security group di Azure AD dove si trova l’utente collegato al mio dispositivo.

Figura 24: Assegnazione del nuovo device configuration profile ad un gruppo di Azure AD

Verifica dell’avvenuta applicazione del nuovo device configuration profile

Per verificare che il nuovo device configuration profile sia stato assegnato, collegatevi alla macchina Windows 10 e dall’app Settings andate in Accounts > Access work or school. Cliccando sulla voce Connected to <Azienda> MDM cliccate su Info e successivamente su Sync per forzare la sincronizzazione delle policy. Assicuratevi che la sincronizzazione sia andata a buon fine.

Figura 25: Sincronizzazione completata con successo

Nell’app Setttings navigate in Privacy > Camera. Modificando le congiurazioni di rete, noterete che la camera verrà automaticamente abilitate o disabilitata a seconda che si trovi o meno in quella che avete individuato come la rete aziendale.

Figura 26: All’esterno della rete aziendale la webcam è abilitata

Figura 27: All’interno della rete aziendale la webcam è disabilitata e una notifica appare quando avviene il cambio di rete

Conclusioni

Microsoft Intune permette di gestire impostazioni e funzionalità che è possibile abilitare o disabilitare nei diversi dispositivi aziendali. Queste impostazioni e funzionalità vengono aggiunte ai “profili di configurazione” (device configuration profiles). È possibile creare i profili per diversi dispositivi e diverse piattaforme, tra cui iOS, Android e Windows.

L’esigenza di un amministratore di sistema è quella di gestire in maniera centralizzata le configurazioni dei dispositivi e le impostazioni delle utenze aziendali.

In infrastrutture on-premises basate su Active Directory le Group Policy permettono di gestire i criteri a livello di dominio e permettono di standardizzare le configurazioni lato computer e lato utente.

Microsoft ha introdotto in Intune gli Administrative Templates, che includono centinaia di impostazioni per gestire Internet Explorer, Office, OneDrive, password e tanto altro.

Microsoft Intune permette di gestire impostazioni e funzionalità che è possibile abilitare o disabilitare nei diversi dispositivi aziendali. Queste impostazioni e funzionalità vengono aggiunte ai “profili di configurazione” (device configuration profiles). È possibile creare i profili per diversi dispositivi e diverse piattaforme, tra cui iOS, Android e Windows. Nell’articolo Microsoft 365 Modern Desktop Management – Gestione di Windows 10 con Microsoft Intune abbiamo già visto come sia possibile creare i device configuration profile per gestire Windows 10.

In questa guida ci occuperemo di un particolare tipo di device configuration profile che è attualmente in preview e che permette di usare lo stesso meccanismo che utilizzano le group policy in Active Directory.

Utilizzo degli Administrative Templates

Di seguito un esempio di utilizzo degli Administrative Templates per configurare le impostazioni di OneDrive tramite Intune.

Nell’articolo Configurare OneDrive for Business in un ambiente Enterprise trovate degli approfondimenti sulle Group Policy per OneDrive adottate in un ambiente on-premises.

Una volta effettuato l’accesso su Intune, selezionate Device configuration -> Profiles -> Create profile.

Figura 1 – Creazione di un Device Configuration Profile

In Name inserite il riferimento de set di policy da applicare, in Platform selezionate Windows 10 and later ed in Profile type: Administrative Templates.

Figura 2 – Administrative Templates in Device Configuration Profile

Successivamente in Applicability Rules, indicate la piattaforma sul quale il set di policy verrà applicato:

Figura 3 – Configurazione del device profile

Una volta salvata la configurazione, procedete con la creazione del profilo.

Figura 4 – Creazione del profilo

Cliccando Create, verrete automaticamente reindirizzati in Settings dove troverete la lista delle impostazioni disponibili. Nel mio caso, ho effettuato una ricerca per OneDrive come da seguente immagine.

Figura 5 – Ricerca delle policy di OneDrive

Selezionando il singolo settaggio, è possibile applicare l’impostazione desiderata:

Figura 7 – OneDrive Policy 1

Figura 8 – OneDrive Policy 2

Figura 9 – OneDrive Policy 3

Figura 10 – OneDrive Policy 4

Una volta terminate le configurazioni desiderate, cliccando su State potrete visualizzare le impostazioni abilitate.

Figura 11 – Impostazioni abilitate sul profile

Dopo aver creato il profilo, è necessario assegnarlo agli utenti o ai device desiderati. Cliccando su Assignments selezionate i destinatari.

Figura 12 – Assegnazione del profilo ai destinatari desiderati.

Per sincronizzare manualmente le nuove impostazioni con il device interessato, andate in Settings -> Accounts -> Access work or school -> Connected to (azienda) MDM -> Info -> Sync. Qui troverete anche tutte le policies assegnate al dispositivo.

Figura 13 – Sync del device con Intune

Una delle impostazioni configurate in precedenza impediva che l’utente potesse configurare un account personale su OneDrive. Di seguito un esempio della corretta applicazione della policy.

Figura 14 – Errore OneDrive sync personal account

Conclusioni

Come abbiamo potuto vedere, l’utilizzo degli Administrative Templates semplifica molto il lavoro degli amministratori di sistema. Ad oggi non sono ancora molte le impostazioni disponibili, ma sicuramente è un ottimo punto di partenza soprattutto per la gestione della suite Office. Per sfruttare a pieno le funzionalità, si consiglia di aggiornare i client interessati a Windows 10 build 1903.

Ulteriori informazioni sono disponibili alla pagina https://docs.microsoft.com/en-us/intune/administrative-templates-windows

Poiché le aziende hanno bisogno che i propri dipendenti siano sempre più “mobili”, il ruolo dell’IT Admin è diventato molto più complesso rispetto al passato e non è più limitato a gestire i desktop, ma anche i dispositivi mobili, come ad esempio tablet e smartphone.

La possibilità di utilizzare Microsoft Intune semplifica di molto il lavoro degli amministratori di sistema e questo servizio basato sul cloud permette di:

• Gestire i dispositivi mobili e i PC usati dagli utenti per accedere ai dati aziendali.
• Gestire le app per dispositivi mobili usati dagli utenti.
• Proteggere le informazioni aziendali grazie alla possibilità di controllare le modalità di accesso e condivisione dei dati da parte della forza lavoro.
• Assicurarsi che i dispositivi e le app siano conformi ai requisiti di sicurezza aziendali.

Microsoft Intune è il componente della suite Enterprise Mobility + Security (EMS) di Microsoft che gestisce dispositivi e app per dispositivi mobili. Intune è integrato con altri componenti EMS come Azure Active Directory (Azure AD) per il controllo delle identità e degli accessi e Azure Information Protection per la protezione dei dati. Quando viene usato con Office 365 consente agli utenti di essere produttivi con tutti i dispositivi, garantendo al tempo stesso la protezione delle informazioni aziendali.

Figura 1: Diagramma dell’architettura di Microsoft Intune

Per poter testare Microsoft Intune potete registrarvi gratuitamente alla versione di prova di Enterprise Mobility + Security al link https://www.microsoft.com/en-us/cloud-platform/enterprise-mobility-security-trial

Figura 2: Registrazione della trial di Enterprise Mobility + Security

Dopo esservi registrati alla trial potrete associare le licenze direttamente dal portale di Microsoft Azure. Microsoft Intune è infatti già da qualche tempo incorporato nel portale di amministrazione di Azure. Per cominciare a familiarizzare con Microsoft Intune vi consiglio di leggere la Guida introduttiva a Intune nel portale di Azure.

La gestione degli utenti può essere fatta sia da Azure che da Intune

Figura 3: Gestione degli utenti in Microsoft Intune

Mentre l’assegnazione delle licenze può essere fatta da Azure Active Directory > Licenses > All products > Enterprise Mobility + Security E5

Figura 4: Assegnazione delle licenze di Microsoft Intune

Impostazione dell’autorità di gestione dei dispositivi mobili

Prima di abilitare la registrazione dei dispositivi, è necessario impostare l’infrastruttura di Intune. In particolare, per la registrazione del dispositivo è necessario impostare l’autorità di gestione dei dispositivi mobili. L’impostazione dell’autorità di gestione dei dispositivi mobili (MDM) determina la modalità di gestione dei dispositivi. Per maggiori informazioni vi invito a leggere l’articolo https://docs.microsoft.com/it-it/intune/mdm-authority-set

Le configurazioni possibili sono:

• Intune autonomo: gestione solo cloud, che viene configurata tramite il portale di Azure. Include il set completo di funzionalità offerte da Intune.
• Co-gestione di Intune: integrazione della soluzione cloud di Intune con System Center Configuration Manager per dispositivi Windows 10. Intune viene configurato tramite la console di Configuration Manager.
• Gestione dei dispositivi mobili per Office 365: integrazione di Office 365 con la soluzione cloud di Intune. Intune viene configurato dall’interfaccia di amministrazione di Microsoft 365. Include un sottoinsieme delle funzionalità disponibili con Intune autonomo. Impostare l’autorità MDM nell’interfaccia di amministrazione di Microsoft 365.

Nel mio caso ho scelto di utilizzare solo Intune per la gestione dei dispositivi e dalla console di Intune ho selezionato in Device Enrollment > Choose MDM Authority la voce Intune MDM authority.

Figura 5: Selezione dell’autorità di gestione dei dispositivi mobili

Per impostazione predefinita, Intune permette la registrazione di dispositivi Android e Samsung Knox Standard. Dopo aver soddisfatto i prerequisiti, gli amministratori devono semplicemente indicare agli utenti come registrare i propri dispositivi.

Da Microsoft Intune è possibile amministrare i seguenti dispositivi Android:

• I dispositivi Android dalla versione 4.4 e successive e i dispositivi Samsung KNOX Standard.
• I dispositivi Android Enterprise, inclusi:
  • Dispositivi con profilo di lavoro Android Enterprise: Dispositivi personali con autorizzazione ad accedere ai dati aziendali. Gli amministratori possono gestire gli account aziendali, le app e i dati. I dati personali nel dispositivo vengono tenuti separati dai dati di lavoro e gli amministratori non controllano le impostazioni o i dati personali.
  • Dispositivi dedicati Android Enterprise: Dispositivi a uso singolo di proprietà dell’azienda, ad esempio per insegna digitale, stampa di biglietti o gestione dell’inventario. Gli amministratori bloccano l’utilizzo di un dispositivo per un set limitato di app e collegamenti Web. Viene anche impedito agli utenti di aggiungere altre app o eseguire altre azioni sul dispositivo.
  • Dispositivi completamente gestiti Android Enterprise: Dispositivi con utente singolo di proprietà dell’azienda, usati esclusivamente per lavoro e non per uso personale. Gli amministratori possono gestire interamente tali dispositivi e applicare controlli di criteri non disponibili nei profili di lavoro.

Per registrare i propri dispositivi Android in Intune, gli utenti devono prima installare l’app Portale aziendale Intune gratuita da Google Play. Nelle figure sotto sono mostrate tutte le schermate che appariranno all’utente:

Dal portale di Azure sarà possibile verificare che il dispositivo Android sia stato registrato per l’utente.

Figura 6: Dal portale di Azure è possibile verificare che il dispositivo Android è stato registrato per l’utente

Conclusioni

La gestione dei dispositivi mobili, tablet, smartphone oppure Windows 10, è sicuramente una delle maggiori difficoltà per un amministratore di sistema. Grazie a Microsoft Intune questa gestione è di fatto enormemente semplificata. In più con Microsoft Intune è anche possibile distribuire applicazioni sui nostri dispositivi. Date un’occhiata all’articolo Microsoft 365 Modern Desktop Management – Distribuire e gestire le applicazioni sui dispositivi aziendali con Microsoft Intune

Ormai i dispositivi mobili sono diventati una parte necessaria se non indispensabile delle dotazioni hardware in azienda. Con lo sviluppo dell’home working, con la notevole potenza raggiunta dagli smartphone e dai tablet e con l’accesso quotidiano ai servizi cloud, ormai non possiamo più fare a meno di questi dispositivi per lavorare.

Diventa però difficile per gli amministratori IT gestire questi dispositivi e quindi sempre più spesso si utilizzano sistemi di gestione della mobilità aziendale (EMM, Enterprise Mobility Management), come ad esempio Microsoft Intune.

Abbiamo visto nel precedente articolo Microsoft Intune – Enroll di un dispositivo Android come effettuare l’enroll di un dispositivo Android in Microsoft Intune e come utilizzare dispositivi personali ad accedere ai dati aziendali.

In questo articolo vi voglio parlare di Android Enterprise. Android Enterprise permette di poter gestire al meglio i dispositivi ed in particolar modo tramite Microsoft Intune è possibile gestirli in tre modi diversi:

• Android Enterprise work profile devices: Quando si gestisce un dispositivo con profilo di lavoro Android Enterprise usando Intune, non si gestisce l’intero dispositivo. Le funzionalità di gestione avranno effetto solo sul profilo di lavoro creato nel dispositivo durante la registrazione. Qualsiasi app distribuita nel dispositivo con Intune viene installata nel profilo di lavoro. Le icone delle app nel profilo di lavoro si differenziano dalle app personali nel dispositivo. Tutti i dati e le app Android all’esterno della parte dedicata ad Android Enterprise del dispositivo rimangono personali e sotto il controllo dell’utente finale. Gli utenti possono installare qualsiasi app nella parte personale del dispositivo. Gli amministratori possono gestire e monitorare le app e le azioni nell’ambito del profilo di lavoro.
• Android Enterprise dedicated devices: Dispositivi pensati per un compito specifico (gestione biglietti, inventario, ecc). Gli amministratori bloccano l’utilizzo di un dispositivo per un set limitato di app e collegamenti Web. Viene anche impedito agli utenti di aggiungere altre app o eseguire altre azioni sul dispositivo.
  
• Android Enterprise fully managed devices: Dispositivi con utente singolo di proprietà dell’azienda, usati esclusivamente per lavoro e non per uso personale. Gli amministratori possono gestire interamente tali dispositivi e applicare controlli di criteri non disponibili nei profili di lavoro.

Prerequsiti

Per preparare la gestione dei dispositivi mobili è necessario impostare l’autorità per la gestione dei dispositivi mobili su Microsoft Intune. Accedete al portale Azure, scegliete All services > Intune. Selezionate l’intestazione arancione per aprire l’impostazione Mobile Device Management Authority. L’intestazione arancione viene visualizzata solo se l’autorità MDM non è stata ancora impostata. In Mobile Device Management Authority scegliete Intune MDM Authority, come mostrato in figura:

Figura 1: Scelta di Intune come Mobile Device Management Authority

Connettere l’account di Intune all’account del Managed Google Play

Per supportare il profilo di lavoro Android Enterprise e i dispositivi Android Enterprise completamente gestiti e dedicati, è necessario connettere l’account del tenant di Intune all’account Managed Google Play.

Accedete al portale di Azure, passate alla console di Intune e scegliete Device enrollment > Android enrollment > Managed Google Play

\

Figura 2: Connessione del tenant di Intune all’account Managed Google Play

Figura 3: Selezionare I agree per concedere a Microsoft l’autorizzazione a inviare informazioni su utenti e dispositivi a Google

Cliccate su Launch Google to connect now per aprire il portale web Managed Google Play. Il portale viene aperto in una nuova scheda del browser. Nella pagina di accesso di Google immettere le credenziali dell’account Google che verrà associato a tutte le attività di gestione di Android Enterprise per il vostro tenant di Intune. Questo sarà l’account Google che verrà condiviso dagli amministratori IT dell’organizzazione per gestire e pubblicare le app nella console di Google Play. È possibile usare un account Google esistente oppure crearne uno nuovo. L’account scelto non deve però essere associato a un dominio G-Suite.

Figura 4: Portale di accesso al Managed Google Play

Figura 5: Creazione di un nuovo Google Account dedicato alla gestione dei dispositivi aziendali

Terminata la creazione dell’account, se avete ovviamente deciso di farla invece che utilizzare un account esistente, sarete pronti per utilizzare il portale

Figura 6: Login effettuato al portale del Managed Google Play

Specificate il nome della società in Nome organizzazione. Come provider della gestione della mobilità aziendale deve essere visualizzato Microsoft Intune. Accettate il contratto di Android e scegliere Conferma. La richiesta verrà elaborata.

Figura 7: Completamento della procedura di registrazione al Managed Google Play

Nel portale di Microsoft Intune potrete verificare che la connessione al Managed Google Play sia avvenuta con successo.

Figura 8: connessione al Managed Google Play avvenuta con successo

Configurare la registrazione dei dispositivi Android Enterprise work profile

Microsoft Intune consente la distribuzione di app e impostazioni ai dispositivi con profilo di lavoro Android Enterprise per assicurare che le informazioni di lavoro e quelle personali restino separate.

È importante notare gli Android Enterprise work profile sono supportati solo in alcuni dispositivi Android specifici. I dispositivi che supportano gli Android Enterprise work profile supportano anche la gestione di Android convenzionale. Per garantire che gli utenti abbiano sempre accesso alla versione più aggiornata dell’app Portale aziendale di Intune (Intune Company Portal), è necessario approvare l’app Company Portal app for Android nel Managed Google Play Store. In seguito all’approvazione, gli utenti otterranno gli aggiornamenti in maniera automatica.

Per approvare l’app Intune Company Portal andate nel Managed Google Play Store e loggatevi con l’account di gestione Enterprise che avete utilizzato al momento della registrazione con il Managed Google Play. Cliccate su Approve per approvare l’app.

Figura 9: Approvazione dell’app Intune Company Portal nel Managed Google Play Store

Gestione delle app tramite il Managed Google Play utilizzando Intune

Il Managed Google Play permette di poter aggiungere le Managed Google Play apps a Microsoft Intune. Un amministratore di Intune può infatti scegliere quali app possono essere approvate e distribuite ai dispositivi direttamente dal portale di Intune. Dal portale di Azure selezionate Client apps > Apps e fate clic su Add

Figura 10: Aggiunta delle app dal portale di Intune

Nel menu a tendina scegliete come App type il valore Managed Google Play e selezionando Managed Google Play – Approve vi si aprirà il catalogo del Managed Google Play, da cui potrete scegliere ed approvare le applicazioni.

Figura 11 :Scelta dell’app dal catalogo del Managed Google Play

Selezionate la voce Keep approved when app requests new permissions nella finestra Approval Settings e quindi fare clic su Save. Se non scegliete questa opzione e lo sviluppatore dell’app pubblica un aggiornamento, sarà necessario approvare manualmente eventuali nuove autorizzazioni.

Figura 12: Approvazione automatica delle nuove versioni dell’app

Approvate tutte le applicazioni che avete deciso di distribuire e al termine fate clic su OK e successivamente su Sync per eseguire la sincronizzazione con il servizio Managed Google Play.

Figura 13: Sincronizzazione delle app approvate con il servizio Managed Google Play

La sincronizzazione delle app potrebbe richiedere qualche minuto. Al termine, potrete assegnare l’app del Managed Google Play ad un gruppo di utenti di Azure AD, come assegnate qualsiasi altra app. Dopo aver assegnato l’app, questa viene installata nei dispositivi selezionati come destinazione. All’utente del dispositivo non viene chiesto di approvare l’installazione.

NOTA : Vi ricordo che in Microsoft Intune è possibile assegnare le app a utenti e dispositivi e che è possibile assegnare un’app a un dispositivo indipendentemente dal fatto che il dispositivo sia gestito da Intune o meno.

Figura 14: Le app del Managed Google Play sono state aggiunte

Cliccando sulle app sarà possibile assegnarle ai diversi utenti e dispositivi. Nella figura sotto sono mostrate le diverse opzioni disponibili. Potete fare anche in modo tale che alcune applicazioni siano obbligatorie per tutti i dispositivi registrati. Fate riferimento alla pagina https://docs.microsoft.com/it-it/intune/apps-deploy per maggiori informazioni.

Figura 15: Distribuzione dell’app ad un gruppo di Azure AD

È possibile distribuire anche altri tipi di app. Per un elenco completo delle modalità di distribuzione vi rimando alla lettura della guida https://docs.microsoft.com/it-it/intune/apps-add-android-for-work#assigning-the-managed-google-play-app

Enroll di un dispositivo personale e distribuzione di un work profile

Per impostazione predefinita l’enrollment dei dispositivi personali con work profile è abilitata di default e non è necessaria nessuna configurazione aggiuntiva.

Figura 16: L’enrollment dei personally-owned work profile devices è abilitato per default

Per registrare i propri dispositivi Android personali in Intune, gli utenti devono prima installare l’app Portale aziendale Intune gratuita da Google Play. Nelle figure sotto sono mostrate tutte le schermate che appariranno all’utente:

Set up degli Android Enterprise dedicated device management

Android Enterprise supporta dispositivi aziendali che possono essere utilizzati in modalità Kiosk, come ad esempio dispositivi da utilizzare per la firma digitale, per la stampa di biglietti o per la gestione di magazzini. Gli amministratori possono limitare l’utilizzo del dispositivo per un set limitato di app e collegamenti web. Viene anche impedito agli utenti di aggiungere altre app o eseguire altre azioni sul dispositivo. Intune consente di distribuire app e impostazioni in dispositivi Android Enterprise dedicati.

I dispositivi gestiti in questo modo vengono registrati in Intune senza un account utente e non sono associati ad alcun utente finale. Non sono progettati per le applicazioni o le app ad uso personale che richiedono dati di account specifici dell’utente, ad esempio Outlook o Gmail.

Requisiti dei dispositivi dedicati Android Enterprise

Per essere gestiti come dispositivi dedicati Android Enterprise, i dispositivi devono soddisfare i requisiti seguenti:

• Sistema operativo Android versione 5.1 e successive.
• I dispositivi devono eseguire una distribuzione di Android che include la connettività Google Mobile Services (GMS). I dispositivi devono includere GMS e devono essere in grado di connettersi a GMS.

Configurare la gestione di dispositivi dedicati Android Enterprise

Per configurare la gestione di dispositivi dedicati Android Enterprise, effettuate i seguenti passaggi:

• Impostate l’autorità MDM (Mobile Device Management) su Microsoft Intune.
• Connettete l’account del tenant di Intune all’account di Managed Google Play.
• Create un profilo di registrazione.
• Create un gruppo di dispositivi.
• Registrate i dispositivi dedicati.

Creazione di un profilo di registrazione per dispositivi dedicati e di proprietà dell’azienda

Per poter registrare i dispositivi dedicati, è necessario creare un profilo di registrazione. Il profilo creato fornisce un token di registrazione (stringa casuale) e un codice a matrice (QR code). A seconda del sistema operativo Android e della versione del dispositivo, per registrare il dispositivo dedicato è possibile usare il token o il QR code.

Andate nel portale di Intune e da Device enrollment > Android enrollment scegliete Corporate-owned dedicated devices

Figura 17: Creazione di un profilo di registrazione per dispositivi dedicati

Cliccate su + Create profile e scegliete il nome che volete dare al profilo (che verrà successivamente assegnato ad un gruppo dinamico di Azure AD) e la data di scadenza del token di registrazione.

Figura 18: Creazione del nuovo profilo di registrazione per i dispositivi dedicati

In Intune è possibile assegnare app e policy sia a gruppi statici che a gruppi dinamici. In Azure AD è possibile creare gruppo di dispositivi dinamici in modo tale che si possa assegnare automaticamente ai dispositivi registrati con un profilo di registrazione specifico. Nel portale di Azure selezionate Azure Active Directory e quindi Groups. Create un nuovo security group, dategli un nome e come membership type scegliete Dynamic Device. Scegliete Add dynamic query e nel blade  Dynamic membership rules  create una Simple rule
enrollmentProfileName match NomeDelProfiloCreatoPrima, come mostrato in figura:

Figura 19: Creazione di un gruppo dinamico di Azure AD a cui assegnare i dispositivi dedicati

Enroll dei dispositivi dedicati Android Enterprise

Per effettuare l’enroll dei dispositivi dedicati seguite la procedura completa alla pagina https://docs.microsoft.com/it-it/intune/android-dedicated-devices-fully-managed-enroll. Utilizzate il token generato nel profilo per aggiungere i Corporate-owned dedicated devices.

NOTA: Nei dispositivi dedicati Android Enterprise è possibile installare soltanto app con il tipo di assegnazione impostato su Obbligatoria. Le app vengono installate dal Managed Google Play Store nello stesso modo dei dispositivi con profilo di lavoro Android Enterprise. Le app vengono aggiornate automaticamente sui dispositivi gestiti quando lo sviluppatore pubblica un aggiornamento in Google Play.

Figura 20: Token generato nel profilo per aggiungere i Corporate-owned dedicated devices da utilizzare per l’enrollment dei dispositivi dedicati

Nelle figure sotto sono mostrate tutte le schermate che appariranno all’utente, subito sotto aver acceso il dispositivo per la prima volta (cioè subito dopo il factory reset):

Set up degli Android Enterprise fully managed devices (Preview)

I dispositivi Android Enterprise completamente gestiti sono dispositivi di proprietà aziendale associati a un utente singolo e usati esclusivamente per lavoro e non per uso personale. Gli amministratori IT possono gestire interamente tali dispositivi e applicare controlli di criteri non disponibili nei profili di lavoro, come ad esempio:

• Consentire l’installazione di app solo dal Managed Google Play.
• Bloccare la disinstallazione di app gestite.
• Impedire agli utenti di ripristinare le impostazioni predefinite dei dispositivi.

Intune facilita la distribuzione di app e impostazioni nei dispositivi Android Enterprise, inclusi i dispositivi Android Enterprise completamente gestiti.

Prerequisiti degli Android Enterprise fully managed devices

Per gestire dispositivi Android Enterprise completamente gestiti, è necessario un tenant autonomo di Intune. La gestione di dispositivi completamente gestiti non è disponibile in modalità ibrida (con connessione a Configuration Manager).

In più i dispositivi devono soddisfare i seguenti requisiti:

• Sistema operativo Android versione 5.1 e successive.
• I dispositivi devono eseguire una build di Android dotata di connettività Google Mobile Services (GMS). I dispositivi devono includere GMS e devono essere in grado di connettersi a GMS.

Configurare la gestione di dispositivi Android Enterprise fully managed

Per configurare la gestione di dispositivi dedicati Android Enterprise, seguite questi passaggi:

• Impostate l’autorità MDM (Mobile Device Management) su Microsoft Intune.
• Connettete l’account del tenant di Intune all’account di Managed Google Play.
• Create un profilo di registrazione.
• Create un gruppo di dispositivi.
• Registrate i dispositivi dedicati.

Creazione di un profilo di registrazione per dispositivi Android Enterprise fully managed

Per poter registrare i dispositivi completamente gestiti, è necessario creare un profilo di registrazione. Il profilo creato fornisce un token di registrazione (stringa casuale) e un codice a matrice (QR code). A seconda del sistema operativo Android e della versione del dispositivo, per registrare il dispositivo dedicato è possibile usare il token o il QR code.

Andate nel portale di Intune e da Device enrollment > Android enrollment > Corporate-owned, fully managed user devices (Preview). Nel blade Under Allow users to enroll corporate-owned user devices scegliete Yes. In questo modo riceverete un token di registrazione (una stringa casuale) e un codice a matrice (QR code). Questo token di registrazione singola è valido per tutti gli utenti e non scade. A seconda del sistema operativo Android e della versione del dispositivo, per registrare il dispositivo in modalità tutto schermo è possibile usare il token o il QR code.

Figura 21: Abilitazione del profilo Corporate-owned, fully managed user devices (Preview) nel portale di Intune

Enroll dei dispositivi fully managed in Android Enterprise

Per effettuare l’enroll dei dispositivi completamente gestiti seguite la procedura completa alla pagina https://docs.microsoft.com/it-it/intune/android-dedicated-devices-fully-managed-enroll . Utilizzate il token generato nel profilo per aggiungere i fully managed devices.

NOTA: Assicuratevi di aver distribuito l’app Intune Company Portal dal Managed Google Play

Dal portale di Microsoft Intune, selezionando Devices e successivamente il nodo All Devices potrete avere visibilità sui diversi dispositivi di cui avete effettuato l’enrollment. Sarà possibile visualizzare se i dispositivi sono Corporate oppure Personal ed in più per ognuno di loro sarà visibile la modalità di gestione (Work Profile, Dedicated oppure Fully Managed).

Figura 22: Nella console di Intune è possibile visualizzare il tipo di sistema operativo dei diversi dispositivi, la loro proprietàe la loro modalità di gestione di Android Enterprise

Conclusioni

Android Enterprise permette di gestire i dispositivi mobili in diversi modi: dispositivi personali con autorizzazione ad accedere ai dati aziendali, dispositivi di proprietà dell’azienda pensati per uno specifico utilizzo (dedicati) e dispositivi aziendali usati esclusivamente per lavoro e non per uso personale (completamente gestiti). In questo modo gli amministratori di Microsoft Intune possono gestire in modi diversi i dispositivi, a seconda della loro proprietà e del loro utilizzo.

Il DHCP è il tipico servizio che installiamo, sul quale definiamo le varie configurazioni e poi, fortunatamente, ci dimentichiamo della sua esistenza.

Tuttavia, nel momento in cui dobbiamo effettuare delle attività di manutenzione, come ad esempio la migrazione o l’aggiornamento del sistema che lo ospita, dobbiamo necessariamente considerare i vari aspetti collegati alla disponibilità del servizio ed alle conseguenze che una sua indisponibilità può comportare.

La prima considerazione da fare in senso generale è quella della continuità del servizio, e nell’articolo di Nicola Ferrini relativo al DHCP Failover troviamo un valido aiuto alla configurazione in alta affidabilità.

In realtà piccole può non essere possibile dedicare più macchine alla configurazione in ridondanza del DHCP, ma può essere comunque necessario spostare l’intero Database e le sue configurazioni su sistemi differenti. In questo caso è necessario effettuare uno spostamento completo di configurazioni ed indirizzi dal server principale al server secondario, il tutto riducendo al massimo i tempi di intervento in modo da minimizzare i tempi di indisponibilità.

Sul server di destinazione è necessario, ovviamente, installare i ruoli ed effettuarne l’autorizzazione in AD prima di eseguire la migrazione delle informazioni.

L’operazione di autorizzazione in AD è molto semplice ed è la condizione affinché il server DHCP possa operare, vediamo di seguito come è possibile autorizzare un nuovo DHCP server all’interno del dominio Active Directory

Autorizzazione del servizio DHCP

È possibile procedere con l’autorizzazione, dopo averne installato il ruolo, in due modi, con la classica GUI dalla quale si apre lo snap-in di management del DHCP e selezionando il server con il click desto del mouse si procede con AUTHORIZE

Figura 1 autorizzazione con GUI

Oppure tramite il cmdlet Powershell Add-DhcpServerInDC il quale deve essere eseguito in un ambiente con privilegi elevati

La sintassi per autorizzare il server dc01.ictpower.local con ip 192.168.0.1 sarà quindi Add-DhcpServerInDC -DnsName “dc01.ictpower.local” -IPAddress 192.168.0.1

Figura 2 autorizzazione con PowerShell

Per visualizzare i server eventualmente già autorizzati o la corretta esecuzione del comando di figura 2 è possibile usare il CmdLet Get-DhcpServerInDC

Figura 3 get-DhcpServerInDC

A questo punto il server su cui verrà trasferita l’intera configurazione del DHCP è pronto per l’importazione

Nota, sarebbe anche possibile eseguire l’autorizzazione tramite il comando Netsh, così come l’export e l’import della configurazione, ma siccome il comando potrebbe essere deprecato in futuro, si è ritenuto di non considerarlo in questa guida

PS C:\Users\Administrator.DC01> netsh

netsh>dhcp

In future versions of Windows, Microsoft might remove the Netsh functionality

for DHCP Server.

Microsoft recommends that you transition to Windows PowerShell if you currently

use netsh to configure and manage DHCP Server.

Type Get-Command -Module DhcpServer at the Windows PowerShell prompt to view

a list of commands to manage DHCP Server.

Visit https://go.microsoft.com/fwlink/?LinkId=217627 for additional information

about PowerShell commands for DHCP Server.

netsh dhcp>

qui sopra è riportato l’output del comando Netsh/Dhcp

Passi da seguire per la completa migrazione del servizio DHCP dal server rdcb01.ictpower.local al server dc01.ictpower.local

• Export della configurazione dal server rdcb01.ictpower.local
  
• Arresto del servizio DHCP sul server rdcb01.ictpower.local
  
• Copia dell’export sul server dc01.ictpower.local
  
• Import della configurazione sul server dc01.ictpower.local
  

Export delle configurazioni e dati del DHCP server attivo

Anche l’export può essere effettuato con PowerShell o con Netsh, ma quest’ultimo comando per le ragioni di cui sopra non verrà compreso in questa guida.

Per effettuare l’export è disponibile il CmdLet Export-DhcpServer che permette l’esportazione soltanto della configurazione, della configurazione di alcuni Scope, o dell’intero contenuto del server, compresi i lease, piuttosto che soltanto di alcuni Scope comprendendo anche in questo caso i lease attivi.

Figura 4 Opzioni di export del DHCP

La sintassi per esportare le configurazioni ed i dati di lease dell’intero server DHCP in rdcb01.ictpower.local sarà quindi

Export-DhcpServer -ComputerName “rdcb01.ictpower.local” -File “C:\Supporto\20190801DhcpBackup\20190801DhcpBackup.xml” -Leases

L’opzione -File indica il percorso dove verrà salvato l’intero export in formato XML

L’opzione -Leases informa il CmdLet di esportare anche l’intero contenuto del DB, ossia anche i lease attivi insieme alla configurazione completa

Figura 5 Dhcp Server Attivo da migrare

Figura 6 Esecuzione cmdlet Export-DhcpServer

A questo punto, se non vi sono errori, l’export completo è disponibile in C:\Supporto\20190801DhcpBackup\ ed è sufficiente copiarlo sul nuovo server per procedere poi all’importazione.

Import delle configurazioni e dati nel nuovo server

Avendo già in precedenza effettuato l’autorizzazione del DHCP in Active Directory, sempre da PowerShell dovremo usare il CmdLet Import-DhcpServer e supponendo di importare le configurazioni e dati sul server dc01.ictpower.local la sintassi del comando sarà

Import-DhcpServer -ComputerName “dc01.ictpower.local” -File “C:\Supporto\20190801DhcpBackup\20190801DhcpBackup.xml” -Leases -BackupPath c:\supporto\20190801DhcpBackup

L’opzione -File indica il percorso da dove verrà letto l’intero export in formato XML

L’opzione -Leases informa il CmdLet di importare anche l’intero contenuto del DB, compresi i lease attivi

L’opzione -backupPath definisce un percorso dove viene effettuato il backup realizzato contestualmente all’importazione

Figura 7 Esecuzione CmdLet Import-DhcpServer

Terminata l’esecuzione del comando troveremo i dati e le configurazioni presenti sul nuovo server

Figura 8 Ripristino delle configurazioni

Chiaramente il servizio presente sul server da cui sono stati esportati i dati dovrà essere posto in stato disattivo prima dell’importazione nel nuovo server al fine di evitare la sovrapposizione dei due server DHCP. E’ da tenere presente che in ambienti di grandi dimensioni può essere necessario riconfigurare i DHCP proxy che hanno il compito di reindirizzare le richieste DHCP provenienti dalle varie VLAN verso un IP puntuale, che in questo caso deve essere riconfigurato verso il nuovo server

Riferimenti

https://docs.microsoft.com/en-us/powershell/module/dhcpserver/export-dhcpserver?view=win10-ps

https://docs.microsoft.com/en-us/powershell/module/dhcpserver/import-dhcpserver?view=win10-ps

https://docs.microsoft.com/en-us/windows-server/networking/technologies/dhcp/what-s-new-in-dhcp

MBAM (Microsoft BitLocker Administration and Monitoring) è un prodotto incluso nel MDOP (Microsoft Desktop Optimization Pack) che permette una gestione avanzata della funzionalità Bitlocker. Consente di automatizzare il processo di crittografia dei volumi e determinare rapidamente lo stato di conformità sui computer client all’interno dell’azienda.

Abbiamo già parlato di Bitlocker e delle relative funzionalità nell’articolo Gestire la crittografia dei dischi con Bitlocker in un ambiente Enterprise .

Per implementare MBAM all’interno della propria organizzazione, è necessaria la configurazione di un’infrastruttura server. Trovate informazioni alla pagina https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/mbam-v25/deploying-the-mbam-25-server-infrastructure .

Microsoft ha rilasciato la soluzione integrata direttamente in SCCM Technical Preview 1905 e non sono necessarie attività infrastrutturali lato MBAM. Diverso il discorso per SCCM, dove bisogna configurare il traffico in HTTPS e di conseguenza è richiesta una Certification Authority.

Di seguito i passaggi per l’implementazione della soluzione.

Sulla consolle SCCM selezionate Assets and Compliance -> Overview -> Endpoint Protection -> Bitlocker Management (MBAM):

Figura 1 – Bitlocker Management in SCCM technical preview

Cliccate su “Create Bitlocker Management Control Policy” e successivamente spuntate Client Management e Operating System Drive.

Figura 2 – Bitlocker Management Control Policy

Nel tab Setup selezionate il metodo di encryption dei volumi. Nel mio caso, ho definito solo quelli di Windows 10 non avendo client con versioni OS precedenti.

Figura 3 – Configurazione del metodo di crittografia dei volume

Successivamente abilitate gli MBAM services per far si che le chiavi di ripristino e le informazioni sui volumi vengano salvati in SCCM.

Figura 4 – MBAM Services in SCCM

Nel tab Operating System Drive, se abilitato, si definiscono le impostazioni per la crittografia del volume del sistema operativo.

Figura 5 – Operating System Drive Bitlocker in SCCM

Figura 6 – Summary Bitlocker Policy in SCCM

Figura 7 – Bitlocker Policy Completion in SCCM

Una volta terminata la configurazione, è necessario effettuare il deploy della policy Bitlocker sulla collection interessata.

Figura 8 – Deploy della Bitlocker policy

Figura 9 – Deploy Settings Bitlocker Policy in SCCM

Per verificare lato client la corretta esecuzione della policy Bitlocker, nei log del client SCCM (C:\Windows\CCM\Logs) troverete 2 nuovi file BitlockerManagementHandler e BitlockerManagement_GroupPolicyHandler.

Figura 10 – BitlockerManagementHandler Log in SCCM Client

Tra i programmi installati ci sarà MDOP MBAM che è il tool utilizzato per il sync e la crittografia del volumi.

Figura 11 – Programma MDOP MBAM client

Avendo impostato nella Bitlocker policy la necessità di un PIN all’avvio del sistema operativo, lato client apparirà il seguente wizard per la creazione.

Figura 12 – Bitlocker Wizard su client

Figura 13 – Inserimento del PIN sul wizard Bitlocker

Figura 14 – Crittografia del volume

Terminata la crittografia del volume, possiamo verificare lato log la compliance o meno della policy Bitlocker sul client.

Figura 15 – Bitlocker Management Policy compliance su client

Le chiavi di ripristino e relative informazioni, sono recuperabili direttamente dal DB Sql di SCCM.

Ad esempio, disabilitando il TPM tramite BIOS di un client con Bitlocker, verrà richiesto l’inserimento della chiave di ripristino.

Figura 16 – Richiesta della chiave di ripristino Bitlocker

Con una query SQL, è possibile recuperare la chiave associata al Recover Key ID della macchina.

SELECT [Id]
	      ,[LastUpdateTime]
	      ,[VolumeId]
	      ,[RecoveryKeyId]
	      ,[RecoveryKey]
	      ,[RecoveryKeyPackage]
	      ,[Disclosed]
	  FROM [DatabaseSCCM].[dbo].[RecoveryAndHardwareCore_Keys]
	  WHERE RecoveryKeyID = ‘Recovery Key ID’

Figura 17 – SQL Query per recupero chiave di ripristino

Conclusioni

Con l’integrazione dell’infrastruttura MBAM in Configuration Manager, si facilita notevolmente l’implementazione di Bitlocker all’interno di una organizzazione.

Il rilascio della nuova funzionalità dovrebbe avvenire nella prossima versione Current Branch. Per chi volesse testare la soluzione è disponibile il download di System Center Configuration Manager Technical Preview alla pagina: https://www.microsoft.com/it-it/evalcenter/evaluate-system-center-configuration-manager-and-endpoint-protection-technical-preview

Introduzione

Il Modern Backup Storage (MBS) è stato introdotto in System Center Data Protection Manager (DPM) 2016 e consente un risparmio del 50% dello spazio di archiviazione, backup 3 volte più veloci e archiviazione più efficiente.

MBS è abilitato automaticamente quando si esegue almeno DPM 2016 in Windows Server 2016, mentre se DPM è in esecuzione su di una versione di Windows Server precedente a Windows Server 2016 non viene usato MBS. Se non viene utilizzato MBS ogni origine dati richiede due volumi, uno per il backup iniziale e l’altro per le modifiche delta.

I backup MBS vengono archiviati in un disco ReFS in quanto MSB usa la clonazione dei blocchi ReFS e la tecnologia VHDX, ma occorre tenere presente che DPM non supporta la deduplicazione nel disco ReFS usato per i backup MBS. I volumi ReFS non possono essere creati su di disco dinamico, ma occorre utilizzare un disco di base.

Per consentire un semplice espansione del volume ReFS utilizzato in DPM per l’archiviazione dei backup tramite la tecnologia MBS occorre assegnare i dischi disponibili ad un pool di archiviazione su cui creare il volume che verrà esposto a DPM, tale volume potrà essere esteso quando necessario.

Se si desidera usare la deduplicazione per l’archiviazione di DPM, è necessario eseguire DPM in una macchina virtuale Hyper-V e archiviare i dati di backup in VHD/VHDX archiviati in una condivisione SMB 3.0 in cartelle condivise con la deduplicazione dei dati abilitata, a riguardo si veda Deduplicate DPM storage.

Di seguito verrà illustrato come utilizzare il Modern Backup Storage in System Center Data Protection Manager 1807 nell’ipotesi che DPM sia installato in una macchina virtuale in ambiente Windows Server 2019 in esecuzione su Hyper-V in ambiente Windows Server 2012 R2 o successivo.

Configurazione di MBS

Per poter utilizzare MBS occorre utilizzare DPM 2016 o successivo, di seguito si ipotizzerà di utilizzare DPM 1807 in macchina virtuale, occorre infatti tenere presente che non è possibile utilizzare un disco virtuale (VHDX) creato localmente come spazio di archiviazione in un server DPM fisico.

In sintesi, i passi necessari alla configurazione di MBS sono i seguenti:

• Creare un disco virtuale da un pool di archiviazione con layout Simple, sarà possibile poi estendere il disco virtuale aggiungendo ulteriori dischi
• Creare uno o più volumi nel disco virtuale
• Aggiungere i volumi in DPM
• Configurare lo spazio di archiviazione

Creazione di un volume su un disco virtuale in un pool di archiviazione

Di seguito i passaggi da seguire per la creazione di un volume su un disco virtuale in un pool di archiviazione in ambiente Windows Server 2019.

Passo 1: Creare un pool di archiviazione tramite Servizi file e archiviazione di Server Manager.

Passo 2: Aggiungere i dischi fisici disponibili nel pool di archiviazione.

Passo 3: Creare un disco virtuale dal pool di archiviazione con layout Simple e provisioning Thin.

In seguito sarà possibile aggiungere dischi fisici al pool di archiviazione ed estendere la dimensione del disco virtuale.

Passo 4: Creazione di un volume nel disco virtuale.

Aggiunta del volume allo storage di DPM

Dopo aver creato un volume su un disco virtuale in un pool di archiviazione è possibile aggiungerlo nello storage di DPM.

Se necessario è possibile configurare lo storage di DPM per specifici carichi di lavoro (FileSystem, Client, SQL, SharePoint, Exchange, SystemProtection, HyperV, VMware, Other e All) tramite PowerShell, per impostazione predefinita il carico di lavoro di un volume è impostata su All.

Di seguito alcuni esempi di comandi PowerShell per la gestione dell’archiviazione in DPM.

# Elenco dei volumi configurati in DPM
Get-DPMDiskStorage -Volumes

# Impostazione volumi per carichi di lavoro Hyper-V
$volumes = Get-DPMDiskStorage –Volumes

Update-DPMDiskStorage -Volume $volumes[0] -FriendlyName “DPM Backup test” -DatasourceType HyperV

Conclusioni

Il Modern Backup Storage di DPM consente di gestire meglio i workload di backup, ma per una gestione più efficace è consigliabile creare in DPM più spazi di archiviazione. In questo modo è possibile gestire workload di backup diversi su volumi differenti e memorizzare gli stessi su volume creati su dischi virtuale in un pool di archiviazione differenti.

In questo modo sarà agevole gestire eventuali espansioni delle dimensioni dei volumi dedicati a specifici workload e gestire anche eventuali migrazioni di tali volumi su storage differenti, in quanto il singolo pool di archiviazione sarà memorizzato su uno specifico VHDX.

Riferimenti

• System Center DPM 1807 – Add Modern Backup Storage to DPM
• Deploy Storage Spaces on a stand-alone server

Il 17 settembre è stata rilasciata una nuova versione in preview di Windows Admin Center. Questa release contiene migliorie su funzionalità rilasciate nelle precedenti versioni, soprattutto su UI e PacketMon.

Ecco le principali novità:

Pagina connessioni

Nella dashboard principale, da questa release, sono state apportate una serie di modifiche, sia grafiche che funzionali.

Le funzioni di connessione ai cluster, Failover Cluster e Cluster HCI, sono state unite in un’unica tipologia di connessione denominata Windows Server cluster.

A seconda della tipologia, gli strumenti di gestione specifici per ogni cluster verranno caricati e mostrati in base all’attivazione, o meno, di Storage Spaces Direct.

Inoltre, è stata introdotta la possibilità di connettere e gestire una VM ubicata su Azure

Figura 1: WAC – Connessioni

PacketMon

PacketMon è una feature rilasciata nelle precedenti release che permette di effettuare analisi catturando il traffico di rete. Questa funzionalità è specifica per Windows Server 2019 e supporta le builds 19H1 e 19H2.

Nella versione di WAC 1909, le migliorie sono le seguenti:

• Nuovo wizard di cattura
• Pulsante Condizioni di catturaPulsante Restart – reuse same conditions to restart capture
• Display Filtri
• Pulsante Salva
• La pagina di dettaglio mostra i nomi attuali delle component di rete.

Figura 2: WAC – Wizard PacketMon

Estensioni

L’argomento estensioni continua a suscitare molto interesse e la quantità di tool rilasciati cresce costantemente. Con WAC 1909 è stata rilasciata la prima versione di un tool per la gestione di IIS!

Per poterla scaricare ed installare è necessario cercare, tra le estensioni disponibili, la stringa msft.iis.iis-management. Al primo avvio verificherà la corretta installazione di IIS Administration API, successivamente abilita l’utente alla gestione di IIS, dei web sites e degli application pools.

Figura 3: WAC – IIS Extension

Security

Sempre tra le estensioni disponibili, è possibile scaricare ed installare il tool Security. Già disponibile nella release precedente, permette di gestire ed utilizzare Windows Defender, eseguire scansioni, visualizzare storici e gestire le remediation actions.

Figura 4: WAC – Security

Developer Tools

Nella dashboard principale è possibile entrare nella sezione Developer Tools.

Figura 5: WAC – Developer Tools

Questa sezione fornisce tutta una serie di strumenti per lo sviluppo di nuove componenti per Windows Admin Center.

Figura 6: WAC – Developer Tools

Sono stati messe a disposizione molte informazioni, esempi per iniziare e funzionalità interattive per l’utilizzo dell’SDK nella creazione di una nuova estensione.

Figura 7: WAC – Developer Tools

Conclusioni

La prossima release sarà una Generally Available (GA), la seconda dalla nascita di Windows Admin Center, e verrà rilasciata nei prossimi due mesi. Nell’attesa, il link per effettuare il download di questa versione è disponibile nella sezione Windows Insider Preview e qualsiasi feedback può essere rilasciato sul portale UserVoice. Possiamo contribuire attivamente sullo spazio messo a disposizione sui forum delle Microsoft Tech Communities su Windows Admin Center.

Stay tuned!

Il Failover Cluster è un gruppo di computer che interagiscono tra di loro per migliorare la disponibilità e la scalabilità dei ruoli cluster. Se in uno o più nodi del cluster si verifica un errore, il servizio verrà garantito dagli altri nodi (processo di failover). I ruoli cluster, inoltre, vengono monitorati in modo proattivo per verificare che funzionino correttamente. Se non funzionano, vengono riavviati o spostati in un altro nodo.

Novità del clustering di failover in Windows Server 2019

• Set di cluster – Consentono di aumentare il numero di server oltre i limiti correnti di un cluster. Questa operazione viene eseguita mediante il raggruppamento di più cluster in un set di cluster. Maggiori papprofondimenti sono disponibili leggendo il mio articolo Introduzione ai Cluster Sets in Windows Server 2019
• Azure-aware cluster – I cluster di failover rileva ora automaticamente quando è in esecuzione nelle macchine virtuali IaaS di Azure e ottimizza la configurazione per garantire il failover proattivo e la registrazione degli eventi di manutenzione pianificata di Azure per ottenere i massimi livelli di disponibilità.
• Migrazione del cluster tra domini (cross-domain)– I cluster di failover si possono ora spostare in modo dinamico da un dominio di Active Directory ad un altro, semplificando il consolidamento dei domini.
• USB witness – È ora possibile usare un semplice dispositivo USB collegato a uno switch di rete come witness nella determinazione del quorum per un cluster.
• Miglioramenti all’infrastruttura di cluster – La cache CSV è ora abilitata per impostazione predefinita per migliorare le prestazioni delle macchine virtuali.
• Cluster Aware Updating supporta Storage Spaces Direct – Cluster Aware Updating (CAU) è ora integrato e compatibile con Storage Spaces Direct e convalida e garantisce il completamento della risincronizzazione dei dati su ciascun nodo. In più controlla gli aggiornamenti solo se necessario e riavvia i nodi in modo intelligente. In questo modo orchestra i riavvii di tutti i server del cluster per la manutenzione pianificata.
• Cluster hardening – Le comunicazioni interne a un cluster tramite Server Message Block (SMB) per Cluster Shared Volumes e Storage Spaces Direct ora sfruttano i certificati per rendere la piattaforma più sicura. In questo modo i cluster di failover possono funzionare senza dipendenze su NTLM e abilitare le baseline di sicurezza.
• Eliminazione dell’autenticazione NTLM – Il cluster di failover non utilizza più l’autenticazione NTLM, ma usa in maniera esclusiva l’autenticazione Kerberos e l’autenticazione basata su certificati. Non sono necessarie modifiche da parte per sfruttare i vantaggi di questo miglioramento della sicurezza.
  

Schema di funzionamento di un cluster

Per realizzare questa guida ho creato un domain controller (DC1.virtual.lab) e due server che verranno poi clusterizzati (HV1-NIC.virtual.lab e HV2-NIC.virtual.lab). Ho anche creato una macchina che farà da ISCSI target (STORAGE-NIC) ed ospiterà lo storage condiviso dei due nodi del cluster.

Anche se utilizzerò Windows Server 2019, la stessa procedura è valida se utilizzate Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012.

Nella figura sotto è mostrato lo schema del laboratorio realizzato:

Figura 1: Schema del laboratorio realizzato

Prerequisiti per la creazione di un Failover Cluster

Prima di iniziare a configurare il cluster, verificate i prerequisiti seguenti:

• Assicuratevi che tutti i server da aggiungere come nodi del cluster eseguano la stessa versione di Windows Server.
• Esaminate i requisiti hardware per assicurarvi che la configurazione in uso sia supportata. Per altre informazioni seguite la guida Requisiti hardware per il clustering di failover e opzioni di archiviazione.
• Assicuratevi che tutti inodi del cluster possano accedere ad uno storage condiviso.
• Assicuratevi che tutti i server da aggiungere come nodi del cluster siano aggiunti allo stesso dominio Active Directory.
• Assicuratevi che l’account da usare per la creazione del cluster sia un utente di dominio che dispone di diritti di amministratore su tutti i server da aggiungere come nodi del cluster.

NOTA: Per essere supportato da Microsoft, tutto l’hardware deve essere certificato per la versione di Windows Server in esecuzione e la soluzione completa del cluster di failover deve superare tutti i test della Convalida guidata configurazione. Per altre informazioni sulla convalida del cluster di failover, vedere Convalidare l’hardware per un cluster di failover.

Check-list delle attività da eseguire

La creazione di un Failover Cluster richiede l’esecuzione delle seguenti attività:

• Verificare i prerequisiti
• Installare la funzionalità Clustering di failover in tutti i server da aggiungere come nodi del cluster
• Eseguire la convalida guidata del cluster per la verifica della configurazione
• Eseguire la Creazione guidata cluster per creare il cluster di failover
• Creare ruoli del cluster per ospitare i carichi di lavoro del cluster

Configurazione dello storage condiviso

Ad ogni nodo del cluster deve essere collegato storage condiviso, cioè visibile da tutti i nodi. È possibile presentare lo storage ai diversi nodi tramite ISCSI, SAN Fiber Channel, Shared SAS oppure tramite gli Storage Spaces. Ho già avuto modo di parlarvi degli Storage Spaces nell’articolo Implementare Storage Spaces Direct in Windows Server 2016 con Microsoft Azure e nell’articolo Storage Spaces Tiering in Windows Server 2016

In questa guida mi servirò di un ISCSI Target installato sulla macchina ISCSI1.demo.lab che pubblica due dischi: un disco di quorum da 10 GB e un disco dati da 500GB. La configurazione dell’ISCSI Target esula dai contenuti di questa guida. Per approfondimenti vi rimando alla lettura dell’articolo Configure Windows 2012 R2 as iSCSI target

Sui due nodi del cluster, HV1-NIC.virtual.lab ed HV2-NIC.virtual.lab, ho collegato i dischi ISCSI utilizzando l’ISCSI Initiator, come mostrato in figura:

Figura 2: Configurazione dell’ISCSI Initiator sui due nodi del cluster

Ho anche configurato il Multipath I/O poiché i due nodi del cluster raggiungono lo STORAGE ISCSI utilizzando due percorsi diversi.

Figura 3: Configurazione del Multipath I/O

Dopo aver collegato i dischi tramite l’ISCSI Initiator, ho provveduto sulla macchina HV1-NIC.virtual.lab ad inizializzare i dischi e a formattarli, come mostrato nelle figure sotto:

Figura 4: Inizializzazione dei dischi ISCSI sulla macchina FS2.demo.lab

Figura 5: Formattazione dei due dischi ISCSI sulla macchina HV1-NIC.virtual.lab

Poiché si tratta di dischi ISCSI, sulla macchina HV2-NIC.virtual.lab i due dischi risulteranno formattati ma saranno visti offline. Windows infatti non supporta la clusterizzazione dei dischi NTFS. Provvederemo più tardi ad utilizzare la funzionalità di Cluster Shared Volume per permettere ad entrambi i nodi di poter scrivere contemporaneamente sullo stesso disco.

NOTA: Non portate online i dischi sul secondo nodo altrimenti potete corrompere il File System

Figura 6: Sul secondo nodo i dischi devono essere mantenuti offline

Configurazione della rete

I due nodi sono collegati tramite due schede di rete: una di management ed una dedicata all’heartbeat. Vi consiglio la lettura dell’articolo Configuring Windows Failover Cluster Networks per approfondire tutti i requisiti di rete necessari per il corretto funzionamento del Cluster.

Figura 7: Dettaglio delle connessioni di rete presenti sui due nodi del cluster

Installazione e configurazione del Cluster

Per configurare un Hyper-V Cluster è necessario che su entrambi i nodi venga installato il ruolo di Hyper-V e la funzionalità di Failover Clustering. Potete servirvi del Server Manager per installare le funzionalità su entrambi i nodi, oppure potete utilizzare il comando PowerShell

$servers = "hv1-nic.virtual.lab", "hv2-nic.virtual.lab"
foreach ($server in $servers)
{
    Install-WindowsFeature -computername $server –Name Hyper-V, Failover-Clustering –IncludeManagementTools -Restart 

}

Figura 8: Installazione del ruolo Hyper-V e della funzionalità di Failover Clustering tramite PowerShell

Figura 9: Aggiunta del secondo nodo al Server Manager per poterlo gestire

Figura 10: Aggiunta del ruolo Hyper-V e della funzionalità di Failover Clustering

Terminata l’installazione della funzionalità, utilizzate la console del Failover Cluster Manager per testare la configurazione dei due nodi e per creare il nuovo cluster. Vi consiglio di verificare i prerequisiti elencati alla pagina Creare un cluster di failover

Lanciate quindi il wizard per la validazione del cluster, in modo tale da essere sicuri che tutti i prerequisiti siano stati rispettati.

Figura 11: Validazione dei nodi del cluster

Figura 12: Validazione del cluster effettuata

In alternativa potete utilizzare il comando PowerShell

Test-Cluster –Node HV1-NIC.virtual.lab, HV2-NIC.virtual.lab

Terminata la validazione potete creare il nuovo cluster. Cliccate su Create the cluster now using the validates nodes e seguite il wizard di creazione. Indicate il nome del cluster (nel mio caso CLUSTER1) e l’indirizzo IP da assegnargli, come mostrato nelle figure sotto. Io ho anche scelto di aggiungere al cluster tutti i dischi condivisi che sono stati agganciati ai nodi, utilizzando Add all eligible storage to the cluster.

Figura 13: Indicazione del nome e dell’indirizzo IP del cluster

Figura 14: Aggiunta dello storage condiviso da tutti i nodi del cluster

Figura 15: Creazione del cluster completata

La creazione del cluster può essere eseguita anche utilizzando il comando PowerShell

New-Cluster –Name "CLUSTER-NIC" –Node HV1-NIC.virtual.lab, HV2-NIC.virtual.lab –StaticAddress 10.10.10.69

Verificate la creazione del cluster dalla console del Failover Cluster Manager e verificate che i dischi condivisi siano stati aggiunti. Come si vede dalla figura sotto, il disco da 1GB viene utilizzato per il quorum, mentre quello da 50GB è disponibile per i dati e può essere trasformato in un Cluster Shared Volume (CSV). I CSV permettono a tutti i nodi di un cluster di failover di poter accedere contemporaneamente sia in lettura che in scrittura ad un disco formattato NTFS o ReFS. NTFS ed ReFS non sono infatti file system clusterizzabili. Per approfondimenti vi rimando alla lettura dell’articolo Utilizzare volumi condivisi del Cluster in un cluster di failover

Cliccate col tasto destro sul disco da utilizzare e scegliete la voce Add to Cluster Shared Volume.

Figura 16: Aggiunta del disco condiviso al Cluster Shared Volume

Il processo è praticamente istantaneo e permette di trasformare il disco in un mount point. Adesso tutti i nodi del cluster potranno accedere al disco utilizzando il percorso predefinito C:\ClusterStorage\Volume1 e potranno leggere e scrivere contemporaneamente nello storage condiviso.

Figura 17: Il disco è stato trasformato in un Cluster Shared Volume

Verificate anche la configurazione delle schede di rete per controllare che ognuna delle schede sia utilizzata nel modo corretto per il management, lo storage e per l’heartbeat. Nel mio caso le reti Cluster Network 1 e Cluster Network 2 sono le reti utilizzate dall’ISCSI e non vengono utilizzate dal cluster per le connessioni trai nodi, mentre la rete Cluster Network 3 è la rete utilizzata dall’Heartbeat. La rete Custer Network 4 è la rete di Management ed è la rete che verrà utilizzata anche dalle VM. Le reti si sono autoconfigurate in maniera perfetta

Figura 18: Configurazione delle reti del cluster

Il cluster è ora configurato.

Creazione di una VM

D’ora in poi tutte le creazioni e le configurazioni delle macchine virtuali dovranno essere effettuate dalla console del Failover Custer Manager e non più dall’Hyper-V Manager. Cliccate sul nodo Roles e col tasto destro fate partire il wizard di creazione di una nuova VM con Virtual MachinesàNew Virtual Machine…

Figura 19: Wizard per la creazione di una nuova VM dalla console del Failover Custer Manager

Scegliete su quale nodo volete che venga creata la macchina virtuale

Figura 20: Scelta del nodo del cluster su cui sarà creata la macchina virtuale

Ricordatevi di posizione la VM nel Cluster Shared Volume, altrimenti non sarà visibile da tutti i nodi del cluster.

Figura 21: I file della VM devono essere salvati nel Cluster Shared Volume altrimenti non saranno visibili da tutti i nodi del cliuster

Figura 22: Creazione della VM completata

Per effettuare le modifiche alla configurazione della macchina virtuale servitevi sempre della console del Failover Cluster Manager. Dalla stessa console potete avviarla, spegnerla, migrarla su un altro nodo, ecc…

Figura 23: Tutte le operazioni sulla VM devono essere effettuate dalla console del Failover Cluster Manager

Figura 24: Avvio della VM

Conclusioni

La funzionalità di Failover Clustering permette di rendere altamente disponibili le nostre applicazioni o le macchine virtuali e diminuisce drasticamente le interruzioni di servizio (downtime). Già da Windows Server 2012 R2 Microsoft supporta failover cluster fino a 64 nodi fisici ed una scalabilità fino a 8.000 macchine virtuali in esecuzione contemporaneamente. Ogni nodo fisico con Hyper-V è in grado di eseguire fino a 1024 macchine virtuali.