Ieri, venerdì 11 dicembre 2020, è stato realizzato il secondo evento POWERCON della community ICT Power completamente online. Abbiamo affrontato l’importante tema dei nuovi modelli di lavoro nelle aziende al tempo del Covid-19 e di come stanno affrontando il “new normal”.

Attraverso 5 sessioni, che si sono perfettamente incastrate grazie al grande lavoro svolto da Nicola, Roberto, Ermanno, Roberto, Albano e Vito, abbiamo cercato di dare una risposta a tutta una serie di domande che ci siamo posti negli ultimi mesi:

Come si stanno evolvendo le aziende in questo periodo? Come la pandemia ha cambiato le nostre abitudini lavorative? Quali sono i vantaggi ed i limiti del modern workplace?

Per coloro che non hanno potuto partecipare nessun problema, perché qui di seguito troverete tutte le sessioni e il materiale proiettato in modo da guardarlo liberamente:

• #POWERCON2020 – Nicola Ferrini – Azure Active Directory come Security Boundary
• #POWERCON2020 – Roberto Tafuri – La sicurezza del Modern Desktop passa da Microsoft Endpoint Manager (Intune)
• #POWERCON2020 – Ermanno Goletto – Roberto Massa – Migrare Active Directory a Windows Server 2019
• #POWERCON2020 – Albano Lala – Intelligent Communications con Microsoft Teams
• #POWERCON2020 – Vito Macina – Windows 10 Eternal, Continuous Evolution

Grazie a tutti per la partecipazione! Ieri abbiamo raggiunto il nostro picco storico di iscrizioni e sopratutto di partecipanti. Ci vediamo il prossimo anno con la #POWERCON2021!

L'articolo #POWERCON2020 – Nuovi modelli di lavoro nelle aziende al tempo del Covid-19 – Grazie per aver partecipato proviene da ICT Power.

Nell’articolo Funzionamento delle Group Policy in Windows Server Nicola Ferrini ha affrontato in modo approfondito le tematiche di gestione ed uso delle GPO. In questo articolo affronteremo alcuni altri aspetti relativi all’uso ed alla gestione delle GPO, soffermandoci sulle modalità di applicazione di queste ultime in relazione ai filtri di sicurezza ed ai filtri WMI.

Se nella definizione delle Group Policy Preference abbiamo a disposizione la funzione di Item Level Targeting per determinare con precisione dove applicare le impostazioni della GPO, in una Group Policy “tradizionale” questo strumento non è presente e dovremo impiegare altre modalità di selezione o filtraggio per quanto riguarda l’applicazione o meno di una determinata GPO.

A questo proposito abbiamo a disposizione due strumenti

• Il tab Security Filtering
• I filtri WMI

Con il primo è possibile applicare una Group Policy ad un preciso gruppo di sicurezza, o ad un singolo utente agendo direttamente sugli oggetti che potranno “leggere” la GPO, mentre con il WMI Filtering è possibile interagire direttamente con il moto WMI in modo da applicare una Group Policy in presenza di una ben determinata condizione, ad esempio dell’appartenenza ad una subnet di rete.

Uso del Security Filtering

Di default una GPO creata ex novo o built-in si presenta in questo modo

Figura 1 Impostazioni di sicurezza GPO

La Security è impostata in modo che la GPO sia applicata a tutti gli Authenticated Users e, per impostazione predefinita, a questa Special Identity appartengono tutti gli account in relazione di trust con il dominio (sia gli Utenti che i Computer). Per informazioni ulteriori potete consultare la pagina https://www.devadmin.it/2017/01/18/everyone-vs-authenticated-users-vs-domain-users/

E quindi ne consegue che qualunque oggetto per cui sia applicabile la GPO, Utente, Computer (o entrambi) è in grado di “leggerla” ed applicarla.

È da tenere presente che dal Security Update di giugno 2016, ogni Group Policy, anche quelle riferite esclusivamente ad impostazioni utente DEVONO poter essere lette dal PC sul quale vengono applicate. Infatti, rimuovendo il gruppo Authenticated Users (impostato di default) veniamo avvisati con questo messaggio relativo alla KB3163622

Figura 2 Avviso KB3163622

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the computer’s security context.

Se volessimo che una GPO fosse applicata esclusivamente agli utenti appartenenti al gruppo Vendite, presente nel nostro dominio, dovremo impostare la Security in questo modo:

Figura 3 definizione della Security per il Gruppo di Utenti “vendite”

Questa possibilità offerta dal Security Filtering permette di raggiungere una granularità molto precisa sull’applicazione delle Group Policy andando a definire con precisione quali entità del dominio devono ricevere le impostazioni.

Tuttavia con questa modalità non è possibile definire quali GPO saranno applicate al di fuori dell’appartenenza o meno a determinati gruppi di Active Directory.

Uso del WMI Filtering

Se dobbiamo applicare una GPO esclusivamente se la postazione ha un determinato indirizzo IP o appartiene ad una determinata sottorete oppure ad una ben precisa versione di Windows, con i Filtri di Sicurezza non possiamo farlo. In questo caso è necessario ricorrere al Filtro WMI. L’applicazione della Group Policy avviene esclusivamente se la query WMI ritorna un valore positivo.

Che cosa è WMI (pillole)

Windows Management Instrumentation (WMI) è un Framework o meglio una infrastruttura per la standardizzazione della gestione di dati ed informazioni su un dispositivo, è indipendente dal dispositivo stesso ed è presente già Windows 2000 in modo integrato nel Sistema Operativo.

WMI è l’implementazione in casa Microsoft del Web-Based Enterprise Management (WBEM), che è gestito dal Distributed Management Task Force (DMTF). WBEM definisce gli standard in modo che la gestione di ogni componente possa avvenire con caratteristiche di interoperabilità. A puro titolo di informazione la stessa struttura di gestione può essere presente anche in Linux.

Come si utilizza WMI

Possiamo semplificare molto il concetto immaginando WMI come un Database su cui eseguire delle query, che riguardano le componenti del sistema. Le varie query sono contenute all’interno dell’ambiente di gestione delle GPO.

Dalla Group Policy Management Console dovremo utilizzare il container WMI Filters e successivamente New…

Figura 4 Creazione di un filtro WMI

Successivamente dovremo definire il nome ed una eventuale descrizione e proseguire con Add

Figura 5 Definizione del nome del filtro WMI

Nel campo successivo definire la query verso WMI; in questo esempio vogliamo identificare i sistemi operativi di architettura a 32 bit, indipendentemente dalla versione, per cui la query da impostare sarà select * from Win32_Processor where AddressWidth=”32″

Figura 6 Compilazione della Query WMI nel filtro

Procedendo con OK e poi Save abbiamo definito genericamente il filtro che sarà poi utilizzato nella Group Policy da applicare esclusivamente a questi sistemi operativi con architettura a 32 Bit. Riaprendo poi la GPO creata in precedenza potremo scegliere il Filtro WMI da applicare:

Figura 7 Applicazione del filtro WMI alla GPO

Le impostazioni della GPO “Impostazione-PC-32Bit” definite in Figura 7 verranno applicate esclusivamente a sistemi con architettura a 32 Bit.

La definizione di un filtro WMI può essere anche molto complessa a seconda della granularità richiesta dall’applicazione del filtro stesso, l’esecuzione di un test direttamente applicando il filtro stesso alla GPO può essere molto dispendiosa in termini di tempo ed introdurre margini di errore.

È più pratico eseguire un test del filtro, al di fuori della Group Policy, per valutarne eventuali errori ed applicarlo solamente quando sarete certi della correttezza sintattica. A questo scopo possiamo interagire direttamente con il “motore” WMI tramite PowerShell oppure con il tool wbemtest.exe (presente in tutti i Sistemi Operativi)

Per eseguire una Query WMI con PowerShell è necessario richiamare il cmdlet Get-WmiObject specificando poi la query da eseguire nell’ambiente WMI. Ad esempio, la verifica preventiva per il filtro di figura 7 sarà:

Get-WmiObject -Query “select * from Win32_Processor where AddressWidth=’32′”

Figura 8 Validazione della query WMI

In questo caso la select è stata eseguita su un’architettura a 32 Bit, quindi è stato ottenuto un valore di confronto e la query applicata al filtro sappiamo che è sintatticamente corretta e potrà essere eseguita correttamente

Qui di seguito potete trovare alcune query già strutturate per filtrare differenti Sistemi Operativi

Windows 10
select * from Win32_OperatingSystem WHERE Version like “10.%” AND ProductType=”1″

Windows 8.1
select * from Win32_OperatingSystem WHERE Version like “6.3%” AND ProductType=”1″

Windows Server 2012 R2 – 64-bit – DC
select * from Win32_OperatingSystem WHERE Version like “6.3%” AND ProductType=”2″

Windows Server 2012 R2 – 64-bit – non-DC
select * from Win32_OperatingSystem WHERE Version like “6.3%” AND ProductType=”3″

Come possiamo notare le query differiscono per la diversa ricerca del valore nelle classi Win32_OperatingSystem e ProductType che ci permettono di rilevare i diversi sistemi operativi, troviamo riportato nelle tabelle qui sotto il valore proprio di ognuna delle due classi.

Win32_OperatingSystem

• 5.1 – Windows XP
• 5.2 – Windows Server 2003
• 5.2.3 – Windows Server 2003 R2
• 6.0 – Windows Vista & Windows Server 2008
• 6.1 – Windows 7 & Windows Server 2008 R2
• 6.2 – Windows 8 & Windows Server 2012
• 6.3 – Windows 8.1 & Windows Server 2012 R2
• 10.0 – Windows 10 & Windows Server 2016 & 2019

ProductType

• ProductType 1 – Sistema Operativo Desktop (Client)
• ProductType 2 – Sistema Operativo Server Domain Controller
• ProductType 3 – Sistema Operativo Server Non Domain Controller

Applicare una Group Policy se il sistema è in una specifica sottorete

Potrebbe essere utile rilevare la rete (IP) a cui appartiene una determinata postazione in modo da applicare Group Policy specifiche; questo tipo di rilevazione si può fare a partire dalla Route di Default.

Se la Group Policy è da applicare alle postazioni configurate sulla Subnet con IP 192.168.200.0/24 che ha il Default Gateway all’indirizzo 192.168.200.1, sarà sufficiente rilevare la presenza di quest’ultimo per stabilire che la postazione si trova nella sottorete dove vogliamo che venga applicata la GPO:

select * from Win32_IP4RouteTable Where NextHop=’192.168.200.1′

Figura 9 rilevazione del default gateway tramite WMI filter

Applicare una Specifica Group Policy ogni domenica

La classe WMI Win32_LocalTime ha la proprietà DayOfWeek che contiene valori numerici da 0 a 6, dove 0 è la domenica, per cui la nostra query WMI sarà:

select DayOfWeek from Win32_LocalTime where DayOfWeek = 0

Questi sono solo alcuni esempi di quello che è possibile fare con i filtri WMI. Vi rimando alla lettura della pagina ufficiale https://docs.microsoft.com/it-it/windows/security/threat-protection/windows-firewall/create-wmi-filters-for-the-gpo per maggiori informazioni.

Gestione dei backup e restore delle Group Policy

Benché le GPO siano parte del System State backup, la procedura di restore in questo caso è laboriosa e lunga. Il modo più rapido per gestire il salvataggio delle GPO è di utilizzare la GPMC dalla quale possiamo effettuare backup e restore selettivi o completi degli oggetti Group Policy.

All’interno della console dobbiamo posizionarci sul ramo Group Policy Objects e premere il tasto desto del mouse sulla selezione dove è presente il menù di gestione.

Figura 10 Gestione backup GPO

Selezionando Back Up All possiamo scegliere la posizione in cui eseguire il salvataggio completo.

Figura 11 Backup GPO

Tramite la funzione di Manage Backup possiamo invece visualizzare e gestire il restore di ogni singola GPO nei vari salvataggi eseguiti, è anche possibile verificare le impostazioni presenti prima del restore

Figura 12 Gestione backup e restore

Naturalmente le funzioni di backup possono essere svolte tramite PowerShell per mezzo del Cmd-Let Backup-Gpo, ad esempio se volessimo salvare tutte le nostre Group Policy in un percorso di rete in modo automatizzato, dovremmo utilizzare questo comando:

Backup-Gpo -All -Path "c:\GpoBackup\"

Eseguendo poi il restore come visto in Figura 11 non dovremo preoccuparci di gestire una sorta di Versione di Backup in quanto la console GPMC è in grado di rilevare tutte le sessioni di salvataggio e di visualizzarle per il restore.

Figura 13 Archivio di backup delle GPO

Anche per il restore abbiamo a disposizione un Cmd-Let che in questo caso è Restore-GPO, quindi se volessimo rispristinare tutte le Group Policy del backup più recente, dovremmo utilizzare questo comando:

Restore-GPO -All -Path "c:\GpoBackup\"

Oppure se volessimo ripristinare una Group policy specifica ad esempio “Impostazione-PC-32Bit” utilizzeremo:

Restore-GPO -Name "Impostazione-PC-32Bit" -Domain "ictpower.local" -Path "C:\GpoBackup"

Nota Importante:

Il restore di una Group Policy NON RIPRISTINA anche le posizioni nell’albero AD in cui questa era collegata.

Il restore di una Group Policy RIPRISTINA i Security Filters ed i Filtri WMI collegati alla GPO stessa.

Salvataggio della Struttura delle GPO

Finora abbiamo visto come eseguire il salvataggio ed il ripristino degli oggetti Group Policy all’interno del nostro dominio, abbiamo anche visto alcuni limiti che gli oggetti base hanno, non ultimo il fatto di perdere completamente il riferimento alla collocazione nell’albero AD delle varie GPO, a questo punto ci può venire incontro un altro cmdlet che è Get-GPOReport
tramite il quale possiamo esportare in formato Html o XML l’intera configurazione del nostro sistema di Group Policy:

Get-GPOReport -All -ReportType Html -Path C:\GpoBackup\GpoReport\GpoReport.html

Figura 14 Report completo sulle impostazioni delle GPO in Dominio

Il cmdlet visto sopra può chiaramente essere utilizzato per riportare le impostazioni di una singola GPO

Get-GPOReport -Name "Configurazione-Desktop-Utenti" -ReportType Html -Path C:\GpoBackup\GpoReport\GpoReport.html

Precisazioni Ulteriori

Gli oggetti Group Policy sono a tutti gli effetti oggetti di AD, quindi la loro eliminazione (se il cestino di Active Directory è attivo) non è una eliminazione vera e propria, ma un flag di “delete” abilitato per l’oggetto eliminato. Il cmdlet Restore-Gpo non esegue il restore di oggetti che sono stati cancellati; praticamente esegue il recupero di oggetti che sono stati sovrascritti o erroneamente modificati, ma che sono ancora presenti in AD.

Per effettuare il restore di un oggetto “cancellato” è necessario usare la console GPMC, in quanto un semplice “restore” anche dal cestino di AD non recupera la struttura della GPO che può includere diversi altri oggetti quali script eccetera che risiedono nella Cartella Sysvol.

Se volessimo ripristinare una Group Policy erroneamente cancellata dal ramo “Group Policy Objects” senza utilizzare le funzioni disponibili in GPMC dovremo quindi per prima cosa recuperarla dal cestino di AD (inviduandola tramite la GUI) e successivamente ripristinarla tramite il cmdlet Powershell Restore-GPO, a questo punto anche utilizzando il nome della GPO stessa.

All’interno del backup così come abbiamo visto sopra, ogni GPO è archiviata con un proprio (del backup) ID, che nulla ha a che vedere con il GUID della GPO, all’interno di questa cartella possiamo trovare un file Gpreport.xml che riporta tutte le informazioni della Group Policy salvata, comprese le informazioni del link alle OU in Active Directory.

La sezione del file è <LinksTo>

<LinksTo>
<SOMName>Utenti-Vendite</SOMName>
<SOMPath>ictpower.local/Utenti-Vendite</SOMPath>
<Enabled>true</Enabled>
<NoOverride>false</NoOverride>
</LinksTo>
<LinksTo>
<SOMName>Utenti-Acquisti</SOMName>
<SOMPath>ictpower.local/Utenti-Acquisti</SOMPath>
<Enabled>true</Enabled>
<NoOverride>false</NoOverride>
</LinksTo>

Considerazioni

Le possibilità offerte dalle Group Policy sono enormi: possiamo gestire decine e decine di postazioni, server, stampanti, utenti con pochissimi click del mouse. Tuttavia, un ambiente come questo può diventare un’arma a doppio taglio, se non lo gestiamo correttamente, e nella gestione corretta sono da considerare anche i backup e la possibilità di ricostruire le configurazioni a seguito di un guasto o di una errata configurazione che necessita di essere racuperata.

Riferimenti:

Gestione delle Group Policy tramite PowerShell
https://docs.microsoft.com/en-us/powershell/module/grouppolicy/?view=win10-ps

Applicazione del Security Filtering alla Group Policy
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/assign-security-group-filters-to-the-gpo

Creazione di filtri WMI per l’applicazione alle GPO
https://docs.microsoft.com/it-it/windows/security/threat-protection/windows-firewall/create-wmi-filters-for-the-gpo

Interazione di PowerShelll con WMI
https://docs.microsoft.com/it-it/powershell/scripting/learn/ps101/07-working-with-wmi?view=powershell-7.1

L'articolo Gestione avanzata delle Group Policy in Windows Server: Filtri WMI, backup e restore proviene da ICT Power.

Già da tempo è possibile utilizzare gli Administrative Templates in Microsoft Endpoint Manager – Intune e la capacità di gestione del software di Mobile Device Management (MDM) di Microsoft è stata enormemente potenziata. Le migliaia di configurazioni già presenti, di cui ha avuto modo di parlarvi Roberto Tafuri nella guida Microsoft 365 Modern Desktop Management – Utilizzo degli Administrative Templates (preview) in Microsoft Intune, permettono una gestione granulare di Windows e di Office.

In più è anche disponibile il tool Group Policy Analytics in Microsoft Endpoint Manager – Intune con l’obiettivo di aiutare le organizzazioni a migrare dall’utilizzo delle classiche GPO ad una gestione moderna delle impostazioni e dei criteri dei dispositivi direttamente in cloud. Trovate maggiori informazioni sul funzionamento del tool visitando la pagina Microsoft Endpoint Manager – Intune – Utilizzo di Group Policy Analytics

Abbiamo già visto in una precedente guida Funzionamento delle Group Policy in Windows Server: facciamo un po’ di chiarezza che gli Administrative Templates permettono di configurare un notevole numero di parametri del sistema operativo e di alcuni applicativi e che è possibile aggiungere ulteriori administrative templates alle nostre group policy per poter configurare in ambiente enterprise prodotti come Microsoft Office, Adobe Acrobat Reader, Google Chrome, Mozilla Firefox e tanti altri.

Oggi invece voglio mostrarvi come aggiungere degli Administrative Templates a quelli già previsti da Microsoft in Endpoint Manager – Intune. Trovate un riferimento completo delle configurazioni già presenti alla pagina https://docs.microsoft.com/en-us/windows/client-management/mdm/policies-in-policy-csp-admx-backed

In particolare, vedremo come gestire Google Chrome da Microsoft Endpoint Manager utilizzando i Chrome policy templates che è possibile scaricare dalla pagina https://support.google.com/chrome/a/answer/187202?hl=en

Figura 1: Pagina di download del bundle di gestione di Google Chrome

Una volta scaricato il bundle di gestione di Google Chrome potete estrarlo e all’interno, nella cartella Configurationàadmx potrete trovare gli Administrative Templates per gestirlo. Nelle sottocartelle ci sono invece i file .adml, che rappresentano i language pack e che vengono utilizzati per descrivere le diverse configurazioni e parametri nella lingua del vostro domain controller.

Figura 2: Administrative Templates per la gestione di Google Chrome

Gli Administrative Templates sono file in formato .XML

Se li aprite con un visualizzatore XML (io ho utilizzato Notepad++) avrete la possibilità di vedere quali sono le chiavi di registro presenti nei rami del registro computer HKEY_LOCAL_MACHINE e dell’utente HKEY_CURRENT_USER che vengono modificate dalle diverse policy.

Figura 3: Contenuto del file Google.admx

Distribuzione degli Administrative Templates utilzizando i Device configuration Profiles di Microsofot Endpoint Manager

Come di può vedere dalla figura sotto, se aprite l’editor del registro di Windows Da una delle macchine che gestite tramite Microsoft Endpoint Manager , nel ramo Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager potrete vedere gli attuali ADMX che vengono distribuiti.

Figura 4: Ramo del registro di Windows dove è possibile visualizzare gli ADMX che vengono distribuiti tramite Microsoft Endpoint Manager

Scopo di questa guida è mostrarvi come creare un profilo di configurazione di Microsoft Endpoint Manager che permetta di distribuire gli administrative templates personalizzati che non sono disponibili nel portale. Dal portale di Microsoft Endpoint Manager https://endpoint.microsoft.com/ selezionate il nodo Devices e successivamente Configuration Profiles. Cliccate su + Create Profile per creare un nuovo profilo di configurazione per Windows 10 di tipo Custom, come mostrato nella figura sotto:

Figura 5: Creazione di un nuovo profilo di tipo Custom per configurare Windows 10

Date un nome al vostro profilo e fate clic su Next per proseguire.

Figura 6: Nome del profilo Custom per configurare Windows 10

Per poter distribuire gli Administrative Templates sarà necessario creare un nuovo OMA-URI Setting nella pagina Configuration Settings del wizard.

NOTA: Gli OMA-URI sono CASE-SENSITIVE!

La sintassi da utilizzare per distribuire gli administrative templates per i dispositivi è:

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{nome applicazione}/Policy/{nome configurazione}

Io utilizzerò il valore

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/GoogleChrome/Policy/ChromeSettings

Se invece volete configurare gli utenti basterà sostituire la parte Device con User:

./User/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{nome applicazione}/Policy/{nome configurazione}

Ad esempio:

./User/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/GoogleChrome/Policy/ChromeSettings

Scegliete con Data Type
String e nel campo Value incollate TUTTO il contenuto del file chrome.admx come mostrato nella figura sotto:

Figura 7: Distribuzione dell’Administrative Templates per la gestione di Chrome

Completate il wizard di configurazione e distribuite il nuovo profilo a tutti i dispositivi, come mostrato nelle figure seguenti:

Figura 8: Confjgurazione da distribuire

Figura 9: Assegnazione del profilo di configurazione di Microsoft Endpoint Manager a tutti i dispositivi gestiti

Figura 10: Pagina ci creazione del profilo di configurazione

A questo punto potete forzare l’applicazione del nuovo profilo di configurazione andando in uno dei client Windows 10 gestiti da Microsoft Endpoint Manger e da Settings forzate l’aggiornamento di Intune.

Trick: È possibile eseguire la stessa operazione anche da PowerShell lanciando con privilegi amministrativi il comando Get-ScheduledTask -TaskName ‘PushLaunch’ | Start-ScheduledTask

Figura 11: Sincronizzazione delle ultime configurazioni distribuite tramite Microsoft Endpoint Manager

Sul client gestito da Microsoft Endpoint Manager, aprendo l’editor di registro di Windows vedrete che si sarà creato un nuovo nodo chiamato Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\AdmxDefault (che prima non esisteva) con all’interno le diverse policy per la gestione di Google Chrome.

Figura 12: Creazione di un nuovo ramo nel registro di Windows con le policy per la gestione di Google Chrome

Dopo l’applicazione del profilo di configurazione del dispositivo potrete visualizzare nel portale di Microsoft Endpoint Manager lo status di assegnazione di ogni singolo device.

Figura 13: Status di assegnazione del profilo di configurazione

Distribuzione delle configurazioni per Google Chrome utilizzando gli Administrative Templates

Ora che abbiamo distribuito gli Administrative Templates per poter gestire Google Chrome è possibile modificare il profilo di configurazione di Microsoft Endpoint Manager per poter procedere alla distribuzione delle diverse configurazioni. In questa guida vi mostrerò come modificare la home page di Google Chrome. Procedete ad aprire le proprietà del device configuration profile e in Configuration settings fate click su Edit, come mostrato nella figura sotto:

Figura 14: Modifica delle configurazioni del profilo per la gestione di Google Chrome

Fate click per aggiungere un nuovo OMA-URI Settings e dategli il nome che preferite. Inserite in OMA-URI il valore ./Device/Vendor/MSFT/Policy/Config/GoogleChrome~Policy~googlechrome~Startup\RestoreOnStartup , scegliete come Data Type
String e in Value inserite il valore <enabled/><data id=”RestoreOnStartup” value=”4″/>

Ho ricavato l’OMA-URI da inserire nel campo richiesto prendendolo direttamente dalla chiave di registro che è stata precedentemente aggiunta tramite la distribuzione degli Administrative Templates , mentre il valore da mettere nel campo Value l’ho ricavato prendendolo direttamente dal file .ADMX . Nelle figure sotto sono evidenziati i diversi punti da cui ho prelevato i valori. La voce Enabled equivale al radio button per la selezione e il valore 4 si riferisce alla scelta di una lista di URL da aprire come Home Page.

Figura 15: Creazione di un OMA-URI setting per gestire la Home Page di Google Chrome

Figura 16: Ramo del registro di Windows dove sono state aggiunte le chiavi per gestire Google Chrome

Figura 17: Parametri del file .ADMX utilizzati per configurare la Home Page di Google Chrome

Poiché ho scelto di utilizzare per l’apertura della home page di Google Chrome una lista di URL , sarà necessario inserire un nuovo OMA-URI Settings che definisca quali sono queste pagine.

Fate click per aggiungere un nuovo OMA-URI Settings e dategli il nome che preferite. Inserite in OMA-URI il valore  ./Device/Vendor/MSFT/Policy/Config/GoogleChrome~Policy~googlechrome~Startup\RestoreOnStartupURLs , scegliete come Data Type
String e in Value inserite il valore <enabled/><data id=”RestoreOnStartupURLsDesc” value=”1&#xF000;https://www.ictpower.it”/>

Ho ricavato l’OMA-URI da inserire prendendolo direttamente dalla chiave di registro che è stata aggiunta tramite la distribuzione degli Administrative Templates, mentre il valore da mettere nel campo Value l’ho ricavato dalla documentazione. Nelle figure sotto sono evidenziati i diversi punti da cui ho prelevato i valori. La voce Enabled equivale al radio button per la selezione del parametro e il valore si riferisce al numero di siti da aggiungere alla lista (nel mio caso 1), separati dal carattere unicode &#xF000; e seguito dall’URL da aprire come Home Page.

Maggior informazioni dono disposnibii alla pagina https://docs.microsoft.com/it-it/windows/client-management/mdm/understanding-admx-backed-policies

Figura 18: Aggiunta di un OMA-URI setting per dichiarare quali pagine aprire all’avvio di Google Chrome

Figura 19: Ramo del registro di Windows dove sono state aggiunte le chiavi per gestire Google Chrome

Figura 20: Parametri del file .ADMX utilizzati per definire gli URL da utilizzare come Home Page di Google Chrome

Verificate di aver aggiunto in maniera corretta tutti gli OMA-URI che intendete distribuire con il profilo di configurazione e fate click su Save.

Figura 21: Salvataggio dei nuovi parametri aggiunti al profilo di configurazione

Figura 22: Device configuration Profile aggiornato con i nuovi Settings

Verifica di funzionamento

Per verificare che i nuovi settings del profilo di configurazione del dispositivo siano state applicate correttamente sarà necessario prima effettuare un aggiornamento delle policy dall’ app Settings di Windows 10.

Figura 23: Aggiornamento delle configurazioni distribuite tramite Microsoft Endpoint Manager

Come si può vedere dalla figura sotto, dopo la sincronizzazione e l’applicazione del profilo di configurazione distribuito da Microsoft Endpoint Manager nel ramo di registro Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager è stata aggiunta una nuova voce chiamata AdmxInstalled con le configurazioni che abbiamo deciso di distribuire per Google Chrome.

Figura 24: Configurazioni distribuite per la gestione di Google Chrome

La configurazione che abbiamo deciso di utilizzare ha modificato il ramo di registro Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\RestoreOnStartupURLs ed ha inserito l’URL che vogliamo utilizzare come home page.

Figura 25: Modifica del registro applicata dalla policy e dall’Administrative Template di Google Chrome

Dal browser Google Chrome possiamo digitare chrome://policy nella Omnibox (altro nome con cui è conosciuta la barra degli indirizzi di Chrome) e verificare che siano state applicate correttamente tutte le policy che abbiamo deciso di distribuire.

Figura 26: Policy distribuite a Chrome tramite Microsoft Endpoint Manager

Se digitiamo chrome://settings nella omnibox noteremo in alto che ci viene notificato che il browser è gestito dall’organizzazione tramite le policy.

Figura 27: Il browser è gestito dall’organizzazione tramite le policy

Spostandoci nel nodo On startup sarà possibile verificare graficamente quello che abbiamo visto prima nel registro di Windows, cioè che all’avvio del browser deve essere aperto l’URL che abbiamo specificato tramite la console di Microsoft Endpoint Manager.

Figura 28: All’avvio del browser vengono aperti gli URL che abbiamo configurato tramite Microsoft Endpoint Manager

Conclusioni

Con la possibilità di poter distribuire attraverso Microsoft Endpoint Manager gli Administrative Templates per poter gestire applicazioni anche non Microsoft, abbiamo davvero la possibilità di poter amministrare tutte le nostre postazioni di lavoro Windows 10 direttamente dal cloud, riuscendo ad ottenere gli stessi risultati che possiamo avere utilizzando le Group Policy on-premises. Il lavoro che è stato fatto nell’ultimo anno su Intune è davvero notevole e rende il prodotto completo.

L'articolo Microsoft 365 Modern Desktop Management – Creare ADMX-backed policies in Microsoft Endpoint Manager – Intune proviene da ICT Power.

MSIX è un formato di pacchetto di app di Windows (introdotto in Windows 10 versione 1709 (10.0.16299.0)) che permette di distribuire e gestire le app in maniera moderna. Le applicazioni vengono racchiuse all’interno di un unico file e possono essere distribuite in maniera molto semplice nei sistemi operativi Windows. Trovate maggiori informazioni al link https://docs.microsoft.com/it-it/windows/msix/overview

Già nell’articolo Microsoft 365 Modern Desktop Management – Distribuire e gestire le applicazioni sui dispositivi aziendali con Microsoft Intune abbiamo affrontato nel dettaglio la capacità di Microsoft Endpoint Manager – Intune di poter automatizzare la distribuzione la configurazione di diversi tipi di applicazione.

in questa guida mi occuperò della distribuzione dei pacchetti in formato MSIX utilizzando Microsoft Endpoint Manager. Le applicazioni Windows possono essere convertite in formato MSIX partendo da file MSI, EXE, ClickOnce o App-V.

NOTA: Non è necessario inserire o distribuire nessun client per l’esecuzione dei pacchetti MSIX perché il client è già disponibile in Windows 10 versione 1709 (10.0.16299.0) e versioni successive.

Preparare l’ambiente per la conversione

La preparazione dell’ambiente di conversione è un passaggio importante del processo di conversione. Le raccomandazioni minime sono:

• Sistema operativo minimo Windows 10 1809
• Installazione pulita di Windows. Sul computer dove verrà effettuata la conversione non devono essere installati altre applicazioni perché lo strumento per la creazione di pacchetti MSX vedrà tutti gli elementi dell ambiente per acquisire le attività del programma di installazione.
• L’ambiente di conversione deve corrispondere all’architettura di in cui verrà distribuita l’applicazione. Se ad esempio si intende distribuire il pacchetto MSIX in un computer x64, è necessario eseguire la conversione in un computer x64.
• È consigliato l’utilizzo di una macchina virtuale hyper V ed è anche disponibile un ambiente già pronto al link https://docs.microsoft.com/it-it/windows/msix/packaging-tool/quick-create-vm
• Utilizzo di una macchina virtuale offre anche la comodità di creare un checkpoint. In questo modo è possibile usare la macchina virtuale per convertire, ripristinare il checkpoint precedente e sarà un computer pulito e configurato pronto per la conversione o per verificare che il pacchetto MSIX sia stato convertito correttamente.
• È anche utile sapere quali tipi di dipendenze ha l’applicazione, per capire quali devono essere eseguite con l’app e quali devono essere inserite in un pacchetto di modifica (runtime oppure plug-in)

Converitre un’applicazione utilizzando MSIX Packaging Tool

Per poter scaricare MSIX Packaging Tool è sufficiente effettuare una ricerca nel Microsoft Store. dopo aver trovato il tool procedete alla sua installazione come mostrato nelle figure sotto:

Figura 1: Ricerca dell’MSIX Packaging Tool nel Microsoft Store

Figura 2: Download e installazione dell’MSIX Packaging Tool

Figura 3: dell’MSIX Packaging Tool installato

Prima di poter procedere alla creazione di un nuovo package è necessario possedere un certificato digitale che verrà utilizzato per firmare il pacchetto MSIX. Nel caso in cui non può non possediate questo tipo di certificato è anche possibile crearlo in modalità self-signed utilizzando i comandi PowerShell mostrati sotto. Ho provveduto quindi alla creazione del certificato e alla esportazione sia della chiave privata che della chiave pubblica, che verranno successivamente utilizzati.

NOTA: E importante sottolineare che il certificato con la chiave pubblica dovrà essere presente sui client di destinazione, altrimenti l’installazione del pacchetto MSIX fallirà.

$certificate
=
New-SelfSignedCertificate
-DNSName
“Example Self-Signed Code Signing for Nicola Ferrini”
-CertStoreLocation
Cert:\CurrentUser\My
-Type
CodeSigningCert
-Subject
“Example Code Signing”

$SecurePassword
=
Read-Host
-Prompt
“Enter password for the .PFX file”
-AsSecureString

Export-PfxCertificate
-Cert
“Cert:\CurrentUser\My\$($certificate.Thumbprint)“
-FilePath
“codesigning.pfx”
-Password $SecurePassword

Export-Certificate
-Cert
“Cert:\CurrentUser\My\$($certificate.Thumbprint)“
-FilePath
“codesigning.cer”

Figura 4: Creazione del certificato self-signed per la firma del pacchetto MSIX

Figura 5: verifica della creazione del certificato self-signed

A questo punto possiamo procedere alla creazione di un nuovo package utilizzando MSIX Package Tool. Fate click sulla prima icona per far partire il wizard di creazione del package.

Figura 6: Lancio del wizard per la creazione di un nuovo package MSIX

Figura 7: Scelta della modalitò della creazione del wizard

Attendete l’installazione del MSIX Packaging tool driver e cliccate nella casella di controllo per disabilitare Windows Search. Fate click su Next per proseguire. Nel caso il tool vi chieda di riavviare , premete Cancel , effettuato il riavvio e ripetete il processo per la creazione di nuovo package subito dopo il reboot.

Figura 8: Installazione dell’ MSIX Packaging tool driver

Procedete quindi a selezionare installa del software di cui volete creare package. In questo esempio ho deciso di distribuire Notepad++ ed ho provveduto a scegliere il file .PFX del certificato da utilizzare per la firma del pacchetto, che avevo creato pocanzi utilizzando PowerShell. Fate click su Next per proseguire nel wizard.

Figura 9: Scelta del pacchetto e del certificato di utilizzare per firmarlo

Inserite a questo punto le informazioni richieste dal wizard e decidete in quale cartella dovrà essere salvato il file .MSIX che verrà creato. una volta che avrete cliccato su Next comincerà l’installazione del vostro software e non potrete tornare alla schermata precedente.

Figura 10: Inserimento delle informazioni del package

Procedete quindi all’installazione del software e alla successiva esecuzione. Personalizzate il software a vostro piacimento . Ricordatevi che qualsiasi operazione che farete verrà registrata dall’MSIX Packaging Tool. Se l’applicazione prevede componenti aggiuntivi o prerequisiti, installate tutto ciò che viene richiesto per la sua corretta esecuzione.

Figura 11: Avvio dell’installazione dell’applicazione da trasformare in package

Figura 12: Esecuzione dell’applicazione ed eventuali personalizzazioni

Dopo aver completato l’installazione e la personalizzazione dell’applicazione è possibile chiuderla e proseguire con il wizard di creazione del nuovo package. Fate click su Next per proseguire.

Figura 13: Installazione dell’applicazione completata

L’MSIX Packaging Tool mostrerà tutte le applicazioni e gli entry point che è riuscito a catturare durante l’installazione. In questo caso viene mostrata l’applicazione in maniera corretta . Fate click su Next per continuare.

Figura 14: applicazioni registrate dall’MSIX Packaging Tool

Un prompt vi chiederà conferma dell’ avvenuta installazione e configurazione di tutte le applicazioni. Fate click su Yes, Move on.

Figura 15:Prompt di conferma prima di proseguire con il wizard

Nella schermata successiva verranno mostrati eventuali servizi che sono stati installati dall’ applicazione. La possibilità di creare pacchetti di servizi in MSIX è stata introdotta in Windows 10 Client 2004 (10.0.19041.0). In questo caso non sono stati installati servizi. Fate click su Next per continuare.

Figura 16: Eventuali servizi installati dall’applicazione

Scegliete quindi la cartella di installazione e il nome del file :MSIX che volete creare. Fate click su Create per la creazione del package.

Figura 17: Scelta del percorso di installazione e del nome del file .MSIX

Dopo pochi secondi il pacchetto sarà stato creato ed un messaggio vi avviserà dell’ avvenuta creazione.

Figura 18: Creazione del package completata con successo

Figura 19: File .MSIX creato dal Packaging Tool

Distribuzione del certificato self-signed

Poiché per firmare digitalmente il nostro pacchetto MSIX abbiamo utilizzato un certificato self-signed sarà prima necessario distribuire il certificato sulle nostre macchine client utilizzando un configuration profile di Microsoft Endpoint Manager.

Procedete quindi alla distribuzione del certificato utilizzando tutti i passaggi mostrati nelle figure sotto:

Figura 20: Creazione di un nuovo device configuration profile per la distribuzione di un certificato digitale

Figura 21: Scelta del nome del profilo per la distribuzione del certificato digitale

Provvedete quindi a caricare il certificato con la chiave pubblica, in formato .CER, che avevate precedentemente estratto utilizzando i comandi PowerShell.

Figura 22: Upload del certificato digitale e della chiave pubblica

Assegnate questo profilo a tutti i dispositivi e procedete con la sua distribuzione, come mostrato nelle figure sotto:

Figura 23: Assegnazione del profilo a tutti i dispositivi gestiti da Microsoft Endpoint Manager

Figura 24: Creazione del profilo per la distribuzione del certificato

Distribuzione dell’applicazione MSIX

La distribuzione dell’applicazione in formato MS IX attraverso il portale di Microsoft Endpoint Manager prevede che aggiungete una nuova applicazione e che scegliate line-of-business app

Figura 25: Distribuzione di una applicazione di tipo line-of-business app

Figura 26: Conferma del tipo di applicazione da distribuire

Procedete quindi a selezionare il package in formato MSIX che avete precedentemente creato.

Figura 27: Scelta del pacchetto MSIX da distribuire

Compilate i campi richiesti per le informazioni dell’applicazione da distribuire e provvedete a selezionare anche un’icona, come mostrato nella figura sotto:

Figura 28: Informazioni dell’applicazione da distribuire

Figura 29: Inserimento delle informazioni completato

Decidete quindi a quali utenti volete distribuire l’applicazione. Nel mio caso ho reso disponibile l’applicazione per tutti gli utenti su tutti i dispositivi gestiti da Microsoft Endpoint Manager.

Figura 30: Scelta del gruppo di utenti o dispositivi a cui rendere disponibile il pacchetto MSIX

Figura 31: Creazione dell’app da distribuire tramite Microsoft Endpoint Manager

Figura 32: Caricamento dell’app completato

Verifica della distribuzione del pacchetto MSIX

, er procedere alla verifica dell’ avvenuta installazione sia del certificato digitale che del pacchetto MSIX potete loggarvi su una delle macchine gestite da Microsoft Endpoint Manager e aprire la console dei certificati macchina il tool Intune Company Portal, come mostrato nelle figure sotto:

Figura 33: Distribuzione del certificato avvenuta con successo

Figura 34: L’applicazione è disponibile per poter essere installata

Procedete all’ installazione dell’applicazione.

Figura 35: Installazione del pacchetto MSIX

Figura 36: Installazione dell’applicazione avvenuta con successo

Lanciate l’applicazione e dal task manager verificate dove è stata installata.

Figura 37: Cartella di installazione dell’applicazione Distribuita con il pacchetto MSIX

Conclusioni

La creazione di pacchetti MSIX semplifica molto il processo di distribuzione delle applicazioni e permette di poter utilizzare una modalità moderna, rapida ed efficace per rendere subito le applicazioni disponibili sui nostri client Windows 10. I pacchetti MSIX possono essere aggiornati, sottoposti a downgrade o corretti quando il pacchetto originale viene reinstallato. Per migliorare l’efficienza, quando si effettua il downgrade, MSIX esegue un aggiornamento differenziale. Questo significa che non viene eseguito un nuovo download del payload precedente.
Quando si disinstalla MSIX o se ne effettua il downgrade, MSIX mantiene i dati dell’app dell’utente. È quindi importante tenere presente che, a meno che i dati creati dall’app più recente non siano compatibili con le versioni precedenti, l’accesso ai dati con l’app di cui è stato effettuato il downgrade potrebbe causare un problema.

L'articolo Microsoft 365 Modern Desktop Management – Distribuire pacchetti MSIX con Microsoft Endpoint Manager – Intune proviene da ICT Power.

Usare il Data warehouse di Intune per compilare report consente di accedere ad informazioni che non sono disponibili nel portale di Microsoft Endpoint Manager. I dati possono essere acceduti in maniera giornaliera e possono essere modellati utilizzando Power BI e lo standard OData. Obiettivo del datawarehouse è quello di permettere l’analisi di grandi quantità di dati (anche da più origini) per poter consentire alle aziende di ricavare importanti insight dai loro dati per migliorare il processo di gestione. L’Intune Data warehouse ha proprio questo compito: permettere un’analisi dettagliata dei nostri dispositivi gestiti.

In questa breve guida vi mostrerò un paio di esempi che vi potranno aiutare a capire la potenzialità di questo tipo di soluzione.

Integrazione di Intune Data Warehouse con Microsoft Power BI Online

È possibile integrare Power BI Online con Intune accedendo al portale di Microsoft Endpoint Manager
https://endpoint.microsoft.com/ e collegandosi a Reports > Data warehouse. Nel blade che si aprirà fate clic per lanciare il collegamento Get Power BI app.

Figura 1: Blade Intune Data warehouse nel portale di Microsoft Endpoint Manager

Nella finestra del browser che si aprirà provvedete a scaricare ed installare l’applicazione Intune Compliance (Data Warehouse), come mostrato nelle figure sotto:

Figura 2: Applicazione Intune Compliance (Data Warehouse)

Collegatevi con le credenziali di un utente che sia:

• Amministratore globale di Azure AD (Global Administrator)
• Amministratore del servizio Intune (Intune Administrator)
• Utente con accesso basato sul ruolo (RBAC) alla risorsa data warehouse di Intune

Figura 3: Accettazione dei termini di utilizzo per l’applicazione Intune Compliance (Data Warehouse)

Figura 4: Installazione dell’applicazione Intune Compliance (Data Warehouse)

Terminata l’installazione, dal portale di Power BI lanciate la nuova app Intune Compliance (Data Warehouse).

Figura 5: L’applicazione Intune Compliance (Data Warehouse) è stata aggiunta al portale di Power BI

L’applicazione Intune Compliance (Data Warehouse) presenterà dei dati di esempio, per darvi un’idea del funzionamento e della potenzialità della stessa.

Per poter accedere ai vostri dati cliccate sul collegamento Connect your data, come mostrato nella figura sotto:

Figura 6: L’applicazione Intune Compliance (Data Warehouse) mostra dei dati di esempio

Figura 7: Connessione ai propri dati utilizzando l’applicazione Intune Compliance (Data Warehouse)

I requisiti per l’accesso al data warehouse di Intune (inclusa l’API) richiedono che l’utente debba essere uno dei seguenti:

• Amministratore globale di Azure AD (Global Administrator)
• Amministratore del servizio Intune (Intune Administrator)
• Utente con accesso basato sul ruolo alla risorsa data warehouse di Intune

Effettuato il login come le credenziali di un utente che abbia le credenziali specificate prima, procedete al caricamento dei vostri dati.

Figura 8: Autenticazione e connessione ai propri dati di Intune

Nel giro di pochi secondi vedrete apparire i vostri dati. Ricordatevi di selezionare la visualizzazione Compliance Overview nel pannello di navigazione a sinistra, come mostrato nella figura sotto:

Figura 9: Compliance Overview della nostra organizzazione gestita da Intune

Questo è ovviamente solo un piccolo esempio di quello che è in grado di farvi visualizzare l’applicazione Intune Compliance (Data Warehouse) di Power BI, che contiene informazioni per il tenant e un set di report predefiniti basati sul modello di dati del data warehouse.

Connettersi al data warehouse con Power BI Desktop

È possibile ricevere informazioni più complete e molto più dettagliate utilizzando il collegamento OData e caricando i dati in Power BI Desktop. L’applicazione Power BI Desktop (che è gratuita) permette di creare report personalizzati e di visualizzare i dati a nostro piacimento. Scaricate l’applicazione dal link https://powerbi.microsoft.com/en-us/desktop/ e installatela seguendo le istruzioni visualizzate.

Figura 10: Download dell’app gratuita Power BI Desktop

Figura 11: Download dell’app gratuita Power BI Desktop tramite Microsoft Store

Figura 12: Scaricamento e installazione dell’app gratuita Power BI Desktop

Dopo aver lanciato l’applicazione Power BI Desktop chiudete la finestra iniziale.

Figura 13: Avvio dell’app gratuita Power BI Desktop

Scegliete Get data dal ribbon Home e selezionare OData feed.

Figura 14: Importazione dei dati tramite OData feed

Accedete all’interfaccia di amministrazione di Microsoft Endpoint Manager https://endpoint.microsoft.com/ , selezionate Report > Data warehouse di Intune > Data warehouse e recuperate l’URL feed personalizzato nel pannello Report, come mostrato nella figura sotto:

Figura 15: Recupero dell’OData feed per il servizio di reportistica

Incollate l’URL nel campo Odata feed di Power BI Desktop e fate click su OK.

Figura 16: Inserimento dell’OData feed in Power BI Desktop

Selezionate il nodo Organizational Account nella finestra dell’OData Feed e cliccate su Sign In per effettuare il login. Utilizzate le credenziali di un utente che sia:

• Amministratore globale di Azure AD (Global Administrator)
• Amministratore del servizio Intune (Intune Administrator)
• Utente con accesso basato sul ruolo alla risorsa data warehouse di Intune

Figura 17: Autenticazione al feed OData utilizzando un account amministrativo di Intune

Dopo l’autenticazione fate click su Connect per poter recuperare i dati dall’Intune Data warehouse.

Figura 18: Connessione al feed OData utilizzando un account amministrativo di Intune

Nella finestra Navigator selezionate tutte le tabelle. Potete selezionare la prima e tenendo premuto il tasto SHIFT potete selezionare l’ultima tabella. Dopo aver selezionato tutte le tabelle potete importarle in Power BI Desktop cliccando sul tasto Connect.

Figura 19: Selezione delle tabelle di Intune Data warehouse da caricare in Power Bi Desktop

Figura 20: Caricamento delle tabelle di Intune Data warehouse in Power Bi Desktop

Figura 21: Le tabelle sono state importate correttamente in Power BI Desktop

Creazione di un report personalizzato utilizzando Power BI e Intune Data Warehouse

Power BI Desktop è uno strumento davvero potente e versatile che vi dà la possibilità di poter visualizzare i vostri dati in molteplici modi. In questa guida vi mostrerò come creare alcune visualizzazioni (report). Dopo esservi connessi a Intune Data Warehouse,
troverete le tabelle importate nel campo Fields a destra della console di Power BI Desktop.

Selezionate dal pannello Visualizations l’opzione Treemap, che verrà aggiunta al canvas di Power BI Desktop (la parte centrale dell’applicazione). Nel pannello Fields cercate la tabella devices ed espandetela. Selezionate il campo dati deviceName e trascinatelo direttamente all’interno del grafico Treemap nel canvas e successivamente trascinate il campo dati deviceKey nella sezione Values nel box che si chiama Add data fields here, come mostrato nella figura sotto.

Figura 22: Creazione di un report di tipo Treemap

Nel pannello Fields spostatevi sino alla tabella users e trascinate il campo dati displayName nella sezione Details del pannello Visualizations, come mostrato nella figura sotto:

Figura 23: Aggiunta di campi al nostro report

Come si può vedere dalla figura sopra, è stato creato un report con i nomi dei dispositivi e i rispettivi utenti. Cliccando su ogni singolo quadrato sarà possibile anche evidenziare alcune informazioni di quel singolo dispositivo.

Figura 24: Selezione di un dispositivo per evidenziarne le caratteristiche

Ovviamente potete procedere alla personalizzazione del report, potete cambiarne il nome, potete aggiungere dei filtri e potete così decidere qual è la miglior visualizzazione dei dati che vi interessa. In qualsiasi momento potete cliccare nel pannello Visualization e modificare il tipo di report (grafico) a vostro piacimento, come mostrato nella figura sotto:

Figura 25: Modifica del tipo di report in Power BI Desktop

È anche possibile esportare il report in formato PDF.

Figura 26: Esportazione del report in formato PDF

Figura 27: Report esportato in formato PDF

Power BI Desktop vi permette anche di salvare i dati, i report e le visualizzazioni per poterle poi successivamente modificare. Il formato di salvataggio è .PBIX

Figura 28: Salvataggio del report in Power BI Desktop

Conclusioni

Intune Data Warehouse usa il protocollo OData (Open Data Protocol) versione 4.0, uno standard dell’organizzazione OASIS (Organization for the Advancement of Structured Information Standards) che definisce la procedura consigliata per creare e utilizzare le API RESTful per l’importazione dei dati.
Nonostante nel portale di Microsoft Endpoint Manager siano già disponibili tantissimi report, grazie a Intune Data Warehouse abbiamo la possibilità di poter creare i nostri report personalizzati utilizzando Power BI e poterli successivamente analizzare e visualizzare nel modo che preferiamo.

L'articolo Microsoft 365 Modern Desktop Management – Creare report dall’Intune Data Warehouse utilizzando Power BI proviene da ICT Power.

L’utilizzo di Desktop Analytics offre una serie di vantaggi agli amministratori di sistema per gestire in modo avanzato gli aggiornamenti e la compatibilità applicativa su dispositivi Windows 10.

Desktop Analytics raccoglie e analizza i dati, le applicazioni e driver dei dispositivi gestiti con Microsoft Endpoint Configuration Manager.

Nell’articolo precedente Microsoft Endpoint Configuration Manager – Integrazione della soluzione cloud-based Desktop Analytics – ICT Power sono elencati i prerequisiti e gli step necessari per implementare la soluzione.

Oggi voglio mostrarvi le funzionalità principali come la gestione ed il monitoraggio degli aggiornamenti sui dispositivi Windows 10 con Desktop Analytics.

N.B. Essendo un ambiente demo alcune funzionalità, numero di dispositivi ed applicazioni non saranno disponibili o limitate.

Assets Devices & Apps

In questa sezione è possibile visualizzare tutti i dispositivi e le applicazioni rilevate da Desktop Analytics.

Accedete al portale Desktop Analytics presente all’interno dell’admin center di Microsoft Endpoint Manager (se non visibile lo troverete nel tab All services), selezionate la voce Assets.

Figure 1 – Dispositivi presenti in Desktop Analytics

Nel tab Apps verranno mostrate tutte le applicazioni rilevate.

Figure 2 – Tab Apps in Desktop Analytics

Selezionando dalla lista un’applicazione è possibile visualizzarne i dettagli e definire “l’importanza” ed ownership .

Figure 3 – Dettagli app in asset Desktop analytics

Monitor – Security updates

In questa sezione è disponibile un riepilogo generale degli aggiornamenti di sicurezza applicati ai dispositivi.

N.B. A partire da dicembre 2020, questa sezione è deprecata. Verrà ritirata a marzo 2021. Per monitorare gli aggiornamenti di Windows dei dispositivi e lo stato di Microsoft Defender, è necessario utilizzare Update Compliance.

Figure 4 – Security updates in Desktop Analytics

Monitor – Feature Updates

Questa sezione riepiloga gli aggiornamenti delle build per i dispositivi che eseguono Windows 10 all’interno della propria organizzazione.

Figure 5 – Feature updates in Desktop Analytics

Per maggiori informazioni vi invito a visualizzare l’articolo ufficiale Updates in Desktop Analytics – Configuration Manager | Microsoft Docs

Creazione dei Deployment plans

La creazione di un deployment plan offre la possibilità di indicare i criteri ed i dispositivi coinvolti all’aggiornamento del sistema operativo Windows 10.

Nei Deployment Plan sono previste le seguenti azioni:

• Definire la versione di Windows 10 da distribuire;
• Scegliere i gruppi di dispositivi in cui si vuole eseguire la distribuzione;
• Creare regole di idoneità per la distribuzione.

I Deployment plans supportano solo le tre versioni più recenti rilasciate da Microsoft di Windows 10. Nel momento in cui verrà rilasciata una nuova versione di Windows 10, Desktop Analytics aggiungerà il supporto entro 45 giorni dal rilascio.

Di default, Desktop Analytics aggiorna quotidianamente i dati del piano di distribuzione. Tutte le modifiche apportate in un deployment plan, vengono elaborate in 24 ore. Per velocizzare questo processo, è possibile richiedere un aggiornamento dati su richiesta.

Per maggiori informazioni, vi invito a visualizzare l’articolo ufficiale Deployment plans in Desktop Analytics – Configuration Manager | Microsoft Docs

Accedete al portale Desktop Analytics presente all’interno dell’admin center di Microsoft Endpoint Manager (se non visibile lo troverete nel tab All services), selezionate la voce Deployment plans e successivamente cliccate Create.

Figure 6 – Creazione di un deployment plan

Indicate un nome al Deployment plan e selezionate la versione di Windows 10 da distribuire.

Figure 7 – Configurazione nome e versione Windows 10 da distribuire nel Deployment plan

Selezionate le device collections interessate (sincronizzate da Microsoft Endpoint Configuration Manager) che contengono i dispositivi soggetti all’applicazione del deployment plan.

Figure 8 – Selezione della/e device collection soggetta al deployment plan

In Readiness rules (regole di idoneità) sono disponibili le seguenti impostazioni:

• Device Drivers: Se i dispositivi ricevono gli aggiornamenti dei drivers da Configuration Manager lasciate l’opzione a Off, in caso contrario (utilizzo di Windows Update for Business) spuntate l’opzione a Yes.
• Le app ritenute importanti da Desktop Analytics si basano sulla soglia del numero di installazioni minime. Impostare questa soglia nelle regole di idoneità per il Deployment Plan. Di default, questa soglia è 2.0% . È possibile modificare il valore da 0.0 a 10.0.

Figure 9 – Configurazione regole di idoneità in deployment plan

Scegliete la data di completamento della distribuzione di Windows 10 in tutti i dispositivi coinvolti dal deployment plan e cliccate Create per confermare la configurazione.

Figure 10 – Data completamento deployment plan

Selezionate la voce interessata per l’overview e la gestione del deployment plan creato in precedenza.

Figure 11 – Selezione del deployment plan interessato in Desktop Analytics

Figure 12 – Deployment Plan Overview in Desktop Analytics

Per la gestione completa di un deployment plan, vi lascio la seguente documentazione ufficiale:

• How to create deployment plans – Configuration Manager | Microsoft Docs
• How to deploy to pilot – Configuration Manager | Microsoft Docs;
• How to deploy to production – Configuration Manager | Microsoft Docs.

Microsoft Endpoint Configuration Manager – Deployment Plan

Una volta terminata la configurazione del Deployment Plan in Desktop Analytics, quest’ultimo al prossimo sync utile, sarà visibile anche in Microsoft Endpoint Configuration Manager.

Microsoft Endpoint Configuration Manager -> Software Library -> Overview -> Desktop Analytics Servicing -> Deployment Plans.

Figure 13 – Deployment Plan in Microsoft Endpoint Configuration Manager

Cliccando sul deployment plan interessato, è possibile visualizzarne i dettagli:

Figure 14 – Deployment Plan Overview in MECM

Conclusioni

In questo articolo abbiamo visto le funzionalità di Deployment Plan, asset e monitoring disponibili in Desktop Analytics. Gli amministratori di sistema avendo a disposizione delle informazioni dettagliate sulla compatibilità applicativa e di drivers con gli ultimi aggiornamenti di sistema, possono distribuire il sistema operativo Windows 10 in modo semplice e controllato.

L'articolo Microsoft Endpoint Configuration Manager – Utilizzo della soluzione cloud-based Desktop Analytics proviene da ICT Power.

Ieri 2 febbraio 2021 Microsoft ha reso disponibile un nuovo sito web dedicato agli IT Pro che vogliono distribuire e configurare i dispositivi Windows 10 in un approccio Cloud-first. Il sito è raggiungibile al link Windows 10 in cloud configuration e contiene diversi suggerimenti per configurare Windows 10, Microsoft Endpoint Manager e una serie di applicazioni Windows, tra cui Microsoft 365 Apps for Windows 10, per i frontline workers, i remote workers e gli studenti.

Figura 1: Panorama della Windows 10 cloud configuration

All’interno del sito è presente una guida che vi permetterà di semplificare sia l’esperienza degli IP Pro per le configurazioni, sia quella degli utenti finali:

• Configurazione ottimizzata per il cloud applicabile a Windows 10 Pro, Enterprise o Education .Gli utenti possono registrare i dispositivi con il loro account di Azure AD e ricevere le configurazioni tramite le policy di Microsoft Endpoint Manager
• I dispositivi sono configurati con le impostazioni di sicurezza e vengono aggiornati automaticamente tramite Windows Update for Business.
• Microsoft Teams, Microsoft Edge e Microsoft 365 Apps per Windows 10 possono essere distribuire e configurate direttamente dal cloud
• Anche le applicazioni line-of-business possono essere distribuite tramite Endpoint Manager
• Ogni PC avrà una configurazione standard, semplificando la risoluzione dei problemi e la sostituzione dei dispositivi.

Figura 2: Differenze di approccio alla configurazione di Windows 10

Attualmente la configurazione è disponibile solo manualmente ed è scaricabile dal link  Overview and Setup Guide, ma probabilmente in futuro potrebbe essere automatizzata.

NOTA: Windows 10 in cloud configuration NON è una nuova versione di Windows 10, ma una serie di raccomandazioni di Microsoft per configurare al meglio Windows 10 Pro, Enterprise o Education per la gestione cloud e per aumentarne la sicurezza.

Per poter utilizzare le configurazioni proposte è necessario possedere le seguenti licenze:

• Azure Active Directory Premium P1
• Microsoft Intune
• Microsoft Teams
• OneDrive for Business
• Windows 10 Pro

Microsoft raccomanda di possedere almeno le licenze Enterprise Mobility + Security E3 e Office 365 E3 e possedere un dispositivo con installato almeno Windows 10 Pro.

Nella Overview and Setup Guide vengono descritti i diversi passaggi per:

• Effettuare l’enrollment dei dispositivi Windows 10
  
  • Microsoft 365 Modern Desktop Management – Distribuzione di Windows Autopilot per i dispositivi esistenti con l’Offline Windows Autopilot deployment profile
  • Microsoft 365 Modern Desktop Management – Enroll di Windows 10 in Microsoft Intune
• Utilizzare Windows AutoPilot per effettuare l’enrollment dei dispositivi Windows 10
  
  • Microsoft 365 Modern Desktop Management – Hybrid Azure AD Join dei dispositivi Windows 10 con Autopilot in Microsoft Intune
  • Microsoft 365 Modern Desktop Management – Windows AutoPilot con il White Glove deployment
  • Microsoft 365 Modern Desktop Management – Windows AutoPilot
• Utilizzare OneDrive For Business per salvare le cartelle Desktop, Documenti e Immagini (Known Folder Move)
  
  • Configurare OneDrive for Business in un ambiente Enterprise
• Distribuire le applicazioni utilizzando Microsoft Intune – Microsoft Endpoint Manager
  
  • Microsoft 365 Modern Desktop Management – Distribuire pacchetti MSIX con Microsoft Endpoint Manager – Intune
  • Microsoft 365 Modern Desktop Management – Distribuire e gestire le applicazioni sui dispositivi aziendali con Microsoft Intune
• Gestire le Windows Security Baseline utilizzando Microsoft Intune – Microsoft Endpoint Manager
  
  • Microsoft 365 Modern Desktop Management – Abilitare Bitlocker su dispositivi Windows 10 utilizzando Microsoft Intune
• Gestire i Windows Updates utilizzando Microsoft Intune – Microsoft Endpoint Manager
  
  • Microsoft 365 Modern Desktop Management – Delivery Optimization su dispositivi Windows 10 con Microsoft Intune
  • Microsoft 365 Modern Desktop Management – Gestione di Windows 10 con Microsoft Intune utilizzando i device profiles
• Gestire le Compliance Policy utilizzando Microsoft Intune – Microsoft Endpoint Manager
  
  • Microsoft 365 Modern Desktop Management – Gestione di Windows 10 con Microsoft Intune utilizzando i device profiles
• Monitorare i dispositivi Windows 10
  
  • Microsoft 365 Modern Desktop Management – Creare report dall’Intune Data Warehouse utilizzando Power BI

Conclusioni

La gestione semplificata, l’ottimizzazione e la protezione dei dipendenti, dei dati e degli asset aziendali sono ormai prioritari in quello che viene chiamato “new normal” e le aziende hanno dovuto cambiare modo di lavorare per colpa della pandemia. Le misure di distanziamento sociale, fondamentali per prevenire l’espansione dei contagi causati da COVID-19, hanno dato una fortissima spinta alla diffusione del lavoro “da remoto”. Il Remote Working rappresenta un nuovo approccio al modo di lavorare e collaborare all’interno di una qualsiasi organizzazione, privata e/o pubblica. Ne abbiamo parlato anche nell’articolo Smart working, home working, remote working, agile working… proviamo a fare un po’ di chiarezza.

Grazie alle configurazioni semplificate possiamo distribuire e configurare i dispositivi Windows 10 in un approccio Cloud-first ed essere operativi in brevissimo tempo, addirittura acquistando semplicemente il dispositivo ed inviandolo a casa del lavoratore, che grazie alla sua connessione Internet riceverà tutte le configurazioni e le applicazioni necessarie, senza dover prima preparare il dispositivo in laboratorio. Soprattutto vale la pena ricordare che anche gli studenti possono beneficiare di questo approccio e ricevere le applicazioni scolastiche e le configurazioni in maniera centralizzata.

L'articolo Configurazione di Windows 10 in cloud: distribuzione e gestione semplificata del modern workplace proviene da ICT Power.

Ogni volta che affrontiamo le tematiche di migrazione di Active Directory dobbiamo in qualche modo fare i conti con I livelli funzionali. Ne abbiamo anche fatto cenno in occasione della recente #POWERCON2020 durante la sessione Migrare Active Directory a Windows Server 2019.

In parole molto semplici il livello funzionale è un insieme di caratteristiche che Active Directory mette a disposizione degli amministratori, ma anche una forma di protezione che impedisce la promozione a Domain Controller di versioni obsolete di sistema operativo.

Active Directory è strutturata in domini e foreste; il primo dominio che viene installato quando si esegue la “promozione” del primo server a Domain Controller di fatto installa anche la prima Foresta che avrà il nome del dominio stesso.

Da quando, con Windows 2000, è nata Active Directory ogni versione ha caratteristiche proprie che sono identificate con i livelli funzionali.

Di versione in versione i vari livelli funzionali hanno introdotto nuove caratteristiche, ed evoluzioni, senza deprecarne di già presenti.

I livelli funzionali di Foresta e di Dominio non necessariamente devono essere allineati, anche per il fatto che ad una foresta possono appartenere più domini. In generale, quindi, possiamo considerare che il livello di funzionalità del dominio può essere di un valore maggiore rispetto al livello di funzionalità della foresta, ma non su un valore minore. Il livello funzionale della foresta definisce quindi il livello funzionale minimo di un dominio che può essere collegato alla foresta stessa.

Compatibilità tra livelli funzionali di AD e versioni di Sistema Operativo

Nella pratica quotidiana, ci si può trovare in scenari in cui il livello funzionale di una infrastruttura è rimasto ad una versione non allineata con il sistema operativo del domain controller; a questo scopo è bene prestare attenzione a questa tabella di compatibilità

Tabella 1 Compatibilità tra Versioni di sistema Operativo e Livelli Funzionali

Può apparire strano l’aver riportato sistemi operativi come 2000 o 2003, ma in realtà potrebbe esserci la situazione in cui un dominio/foresta è attivo a livello funzionale 2003 ma fisicamente installato su un server 2012 R2. In questo scenario, l’installazione di un nuovo Domain Controller di ultima versione richiederà di elevare il livello funzionale dell’infrastruttura.

Considerazioni relative alla Sicurezza

Come possiamo notare il fatto di avere definito un ben preciso livello funzionale impone che i Domain Controller appartenenti al dominio non possano essere di versione inferiore. Questa peculiarità fa sì che su infrastrutture molto grandi e distribuite non vengano inseriti come funzioni di DC sistemi operativi non aggiornati.

Vediamo ora quelle che sono le funzioni proprie dei vari livelli funzionali sia di dominio che di foresta, con una descrizione (breve) delle caratteristiche introdotte nei vari livelli funzionali di Active Directory

Livello Funzionale 2000

Dominio

• Disponibilità dei gruppi universali di Distribuzione e Sicurezza
• Possibilità di “annidamento” dei gruppi
• Possibilità di conversione tra gruppi di sicurezza e distribuzione
• Disponibilità del SID History

Foresta

• Disponibili le funzioni “Native” della prima versione di AD

Livello Funzionale 2000 (Mixed)

• Il livello funzionale Windows 2000 Mixed è stato concepito per supportare la transizione e la migrazione da ambienti NT 4 a domini Active Directory 2000
  

Livello Funzionale 2003

Dominio

• È possibile rinominare i Domain Controller tramite il tool Netdom.exe
• Aggiornamento e replica tra DC dell’attributo logonTime Stamp
• Al fine di una piena rispondenza alla RFC 2798 è disponibile la classe inetOrgPerson all’interno della directory AD, è anche possibile all’interno della stessa classe impostare l’attributo userPassword. Questa caratteristica può essere utile e quindi utilizzata appieno negli scenari di migrazione da altre directory verso AD
• Possibilità di ridefinire i contenitori di default di creazione dei nuovi utenti e computer, nella versione precedente questi venivano creati di default in cn=Computers, e cn=Users
• Authorization Manager (AM) utilizza Active Directory per archiviare le proprie informazioni. AM è il framework utilizzato per il controllo degli accessi in base al ruolo.
• Constrained Delegation
  • È un’estensione del Protocollo Kerberos che permette di richiedere un Kerberos Service Ticket senza autenticazione presso il KDC, È possibile specificare la delega in modo granulare per specifici servizi.
• Selective Authentication
  • La Selective authentication permette di specificare in modo puntuale quali gruppi p1ossono autenticarsi a risorse specifiche in un Trust di Foreste

Foresta

• Da questa versione di AD È stato introdotto il Trust tra Foreste
• Dal livello funzionale 2003 di AD è possibile rinominare il Dominio
  
• Linked-value replication (LVR)
  • LVR è una funzione di ottimizzazione dei dati replicati all’interno di AD, ad esempio anziché replicare completamente tutti i membri di un gruppo, qualora questo cambi, si trasferiscono solamente le variazioni. Questa implementazione previene anche la perdita di informazioni quando vengono contemporaneamente modificati gli stessi oggetti su più Domain Controller
    
• Da questa versione è introdotta la funzionalità di Read Only Domain Controller (RODC);
  • Il RODC può essere utile in realtà in cui è necessario portare una sorgente di autenticazione del dominio, all’esterno del perimetro di sicurezza del dominio stesso. Il Read Only Domain controller permette le autenticazioni e la disponibilità dei servizi di un DC senza consentire modifiche alla Directory. Il Domain controller in modalità Read-Only deve essere almeno di versione 2008 così come il server che ospita il ruolo di PDC Emulator, tuttavia il livello funzionale della Foresta può anche essere 2003
• Migliorato l’algoritmo del servizio di controllo Knowledge Consistency Checker (KCC), a cui è demandato il compito di replica dei metadati di AD, generando uno schema di replica inter ed intra Sito
• Il processo di intersite topology generator (ISTG) è stato migliorato permettendo la gestione di foreste articolate su un gran numero di Siti.
  • Il Domain Controller che detiene il “ruolo” di ISTG organizza due funzioni:
  • Seleziona automaticamente uno o più Bridgehead Server tra i Domain Controller
  • Esegue il processo di KCC per determinare la topologia di replica e le modalità di connessione che i bridghead server usano per le comunicazioni
• In questo livello funzionale è stata introdotta la possibilità di convertire l’oggetto inetOrgPerson nell’oggetto User e viceversa
• I nuovi tipi di gruppo creati supportano, da questa versione la role-based authorization
• È ora possibile disattivare e ridefinire attributi e classi nello schema di AD, diventa possibile il riutilizzo di questi attributi: ldapDisplayName, schemaIdGuid, OID, e mapiID.
• Il “motore” di replica dati DFS include, da questa versione il supporto alla access-based enumeration e presenta una scalabilità migliorata

Livello Funzionale 2003 (Interim)

È anche possibile in contesti particolarmente datati (probabilmente non è più una condizione ricorrente) che venga visualizzato il livello funzionale di Dominio e Foresta Windows 2003 (Interim). Questa è una condizione intermedia di stato, disponibile esclusivamente in 2003 Server, che è (era) utilizzata negli scenari di migrazione da NT Server. Questo livello funzionale permette ancora la coesistenza di BDC di versione NT4 ed è una situazione di transizione in scenari particolarmente complessi dove la migrazione a versioni successive del dominio NT richiedeva tempi lunghi per la presenza di un numero elevato di DC.

Le funzionalità di questa modalità sono limitate pur introducendo due caratteristiche migliorative.

• La replica ottimizzata dei gruppi di sicurezza e il supporto per più di 5000 membri per gruppo.
• Ottimizzazione dell’algoritmo del processo KCC.

Livello Funzionale 2008

Dominio

• Fine Graned Password Policy; possibilità di definire regole e criteri relativi alla password secondo l’appartenenza a Security Group differenti.
• Last Interactive Logon; Tramite una Group Policy apposita è possibile far comparire all’utente, all’atto del Login, una informazione puntuale sullo stato dell’ultimo login interattivo sia fallito che completato.
• Abilitazione del protocollo Kerberos all’uso dell’encryption AES 128 ed AES 256
• Supporto della replica del file system distribuito (DFS) per il volume di sistema (SYSVOL)

Foresta

• Nessuna nuova funzione rispetto alla versione 2003

Livello Funzionale 2008R2

Dominio

• Introduzione dei Managed Service Account e Virtual Account

Foresta

• Disponibilità del Cestino di Active Directory

Livello Funzionale 2012

Dominio

• Flexible Authentication Secure Tunneling (FAST), interessa le fasi di preautenticazione relative al protocollo Kerberos, richiede che il client sia almeno di versione 8
  
• Introduzione dei Claims come entità di autenticazione
  

Livello Funzionale 2012 R2

Dominio

• Introduzione del gruppo “Protected Users” gli utenti che fanno parte di questo gruppo, quando accedono a Sistemi di versione 2012R2/8.1 (o superiori) beneficiano di una protezione ulteriore:
  
  • Le credenziali non vengono salvate in cache localmente
    
  • Usare l’autenticazione NTLM
    
  • Usare algoritmi di cifratura obsoleti (RC4/ DES) nella preautenticazione Kerberos
    
  • Nel caso di abilitazione od utilizzo della Digest Authentication i dati di autenticazione non vengono salvati in Cache
    
  • Non è più possibile l’accesso Offline
    

Livello Funzionale 2016

Dominio

• I Domain controller supportano la RFC 8070 relativa alla Preautenticazione Kerberos (PKInit Freshness Extension) nel contesto di autenticazione tramite chiave pubblica (il client di accesso deve essere almeno di versione W10 1607)
  
• I Domain controller gestiscono ora la rotazione dell’hash della password per gli utenti configurati con l’accesso tramite Smart Card
  
• I Domain controller supportano ora la Policy “Allow NTLM network authentication when the user is restricted to selected devices.” Che permette la gestione granulare delle autenticazioni NTLM

Foresta

• Disponibilità della funzione Privileged Access Managment (PAM). Tramite Microsoft Identity Manager e PAM vengono irrobustiti gli accessi amministrativi

Livello Funzionale 2019

Dominio

• Non sono state introdotte nuove funzionalità rispetto alla versione precedente

Foresta

• Non sono state introdotte nuove funzionalità rispetto alla versione precedente

Nello schema sopra sono riportate le varie funzionalità che di volta in volta, a partire dalla versione 2000 fino all’ultima 2019 sono state aggiunte alla Directory, in questo contesto è importante notare come le funzionalità sono sempre state aggiunte mentre quelle presenti non sono mai state deprecate

Considerazioni in merito alle relazioni tra Active Directory ed LDAP

Che cosa è LDAP? (Lightweight Directory Access Protocol)

Ldap nasce come implementazione più leggera (Lightweight) del suo predecessore DAP, In modo generico usiamo il termine LDAP per indicare una directory di oggetti che utilizziamo per la gestione delle infrastrutture informatiche, in realtà LDAP è un protocollo di accesso ad una directory, ossia definisce tutte le specifiche per l’accesso, autenticazione e la gestione di una Directory di oggetti. La prima RFC che ha definito questo protocollo è la RFC 1487, del 1993, da quella data ad oggi il protocollo ha subito considerevoli implementazioni ed aggiornamenti.

La prima versione di Ldap è stata aggiornata alla versione2 (LdapV2) le cui specifiche sono definite nella RFC 1777, tuttavia questa versione è rimasta in bozza, successivamente con la RFC 3377 il protocollo è stato definito in modo più completo arrivando alla versione attuale anche conosciuta come LdapV3.

In questo contesto Active directory è dichiarata nominalmente conforme alle RFC 1777, e 3377 anche se con una nota di implementazione che riportiamo integralmente:

3.1.1.3.1 LDAP Conformance

• 08/24/2020
  

The purpose of this section is to document how the implementation of Active Directory DCs interprets the LDAP v3 RFCs, including differences from those RFCs. Except as noted in the following subsections, Active Directory is compliant to [RFC3377].

Active Directory DCs nominally implement support for LDAP v2 [RFC1777]. However, except as noted in the next paragraph, Active Directory processes LDAP v2 requests and generates responses as if LDAP v3 had been requested by the client.

When processing an LDAP v2 request, Active Directory exhibits the following behavioral differences from processing an LDAP v3 request:

• Instead of using the UTF-8 character encoding for LDAPString [RFC2251], the system’s configured code page is used. The code page is configured locally on the DC by the DC’s administrator.
  
• Referrals and continuation references are generated using the format for LDAP v2 referrals as specified in section 3.1.1.3.4.
  

All LDAP error codes returned by Active Directory are taken from the resultCode enumeration of the LDAPResult structure defined in [RFC2251] section 4.1.10.

Nel contesto di analisi dei livelli funzionali visti in precedenza, Active Directory ha seguito le proprie evoluzioni ed implementazioni mantenendo ed aggiornando la rispondenza agli standard relativi al protocollo LDAP, possiamo quindi dedurre che l’innalzamento dei vari livelli funzionali di AD non modifica il comportamento del protocollo LDAP stesso. Questa analisi può essere necessaria, qualora Active Directory venga utilizzata come provider di autenticazione a livello applicativo in un contesto in cui è necessario innalzare il livello funzionale dell’infrastruttura per adeguamenti ed evoluzioni di sicurezza.

Ogni Domain Controller è quindi utilizzabile come Ldap server, tuttavia è necessario considerare che se le interazioni con Ldap sono relative al singolo dominio, è possibile utilizzare un qualsiasi Domain Controller del dominio stesso, se invece il contesto dell’uso di Ldap è relativo alla foresta è necessario utilizzare un Domain Controller con la funzione di Global Catalog abilitata.

Il protocollo Ldap prevede per le comunicazioni le porte TCP 389 e 636, la prima è utilizzata per le comunicazioni non cifrate mentre la seconda permette connessioni protette con il protocollo SSL/TLS, nel caso dell’utilizzo di un Global Catalog le due porte sono rispettivamente 3268 e 3269

Riepilogo dei livelli funzionali disponibili

Nello schema di Active Directory è presente un attributo numerico definito a livello di dominio e di foresta il cui valore ne indica il livello funzionale, la tabella seguente presenta un riepilogo in relazione ad entrambe

Tabella 2 attributo msDS-Behavior-Version e relativi contesti

La gestione del livello funzionale del dominio e della foresta può essere eseguita tramite alcuni strumenti e comandi, alcuni più intuitivi, in quanto grafici, altri a linea di comando.

• Dsquery
  
• Powershell,
  
• Active Directory Administrative Center
  
• Active Directory Users And Computers
  
• Active Directory Domains and Trust
  

DSQUERY

È possibile rilevare i valori contenuti nell’attributo con il comando DSQUERY

Foresta

dsquery * “CN=Partitions,CN=Configuration,DC=ICTPOWER,DC=LOCAL” -scope base -attr msDS-Behavior-Version

Dominio

dsquery * “DC=ICTPOWER, DC=LOCAL” -scope base -attr msDS-Behavior-Version

Figura 1    rilevazione con DSQUERY del livello funzionale di foresta e dominio

PowerShell

La visualizzazione del livello funzionale di Active Directory tramite PowerShell Utilizza due Cmdlet Get-ADDomain e Get-ADForest, in sé i due comandi permettono di ottenere numerose informazioni, ma nel nostro caso utilizzeremo esclusivamente quelle relative al livello funzionale

Get-ADDomain | fl Name,DomainMode

Figura 2    rilevazione del livello funzionale di Dominio

Get-ADForest | fl Name,ForestMode

Figura 3 rilevazione del livello funzionale di Foresta

Active Directory Administrative Center

È lo strumento grafico più semplice e intuitivo, nel senso che in un unico punto permette la rilevazione e la gestione dei livelli funzionali di entrambe le componenti di Active Directory, è sufficiente selezionare il Dominio nel tab di sinistra e nell’area a destra relativa ai Task selezionare “Properties”

Figura 4 AD Administrative Center proprietà di dominio e foresta

Dove compare un riepilogo generale dell’infrastruttura come riportato qui sotto

Figura 5 riepilogo delle impostazioni dei livelli funzionali

Active Directory Users And Computers /Active Directory Domains and Trust

I due Snap-In di gestione sono utilizzati rispettivamente nel contesto del dominio e della foresta, è possibile rilevare il livello funzionale del dominio tramite ADUC selezionando il dominio e facendo click con il tasto destro del mouse, in questo modo attivando la scelta Raise Domain Functional Level è possibile identificare, ed eventualmente elevare, il livello funzionale del Dominio.

Figura 6 ADUC gestione del livello funzionale di dominio

Figura 7 ADUC gestione del livello funzionale di dominio

Per mezzo dello Snap-In Active Directory Domain and Trust è possibile gestire la visualizzazione e la modifica del livello funzionale di AD relativamente alla foresta, aprendo il Tool e posizionandosi direttamente sulla “radice” dello strumento con il tasto dx del mouse, analogamente a quanto fatto con ADUC accediamo alla funzione di Raise Forest Functional Level

Figura 8 AD Domain and Trust gestione del livello funzionale di Foresta

Figura 9 AD Domain and Trust gestione del livello funzionale di Foresta

Modifica dei livelli funzionali di Active Directory

Per mezzo dei tool visti sopra, è anche possibile elevare i livelli funzionali del dominio e della foresta alla versione voluta, compatibilmente con i vincoli di versione di sistemi operativi dei Domain Controller presenti nell’infrastruttura secondo la tabella 1.

PowerShell

• Set-ADForestMode (usato per la gestione a livello di foresta)
• Set-ADDomainMode (usato per la gestione a livello di dominio)

Sono i due Cmdlet che permettono come possiamo vedere qui di seguito la gestione del livello funzionale della Directory

Set-ADForestMode -Identity ictpower.local -ForestMode Windows2016Forest

Figura 10 elevazione del livello funzionale di foresta a 2016

Set-ADDomainMode -Identity ictpower.local -DomainMode Windows2016Domain

Figura 11 elevazione del livello funzionale di dominio a 2016

Active Directory Administrative Center

Anche con questo strumento, è possibile gestire i livelli funzionali di dominio e foresta

Figura 12 elevazione del livello funzionale di foresta

Figura 13 elevazione del livello funzionale di dominio

Active Directory Users And Computers /Active Directory Domains and Trust

Analogamente a quanto visto per la rilevazione del livello funzionale, come visto in precedenza, possiamo anche modificarne l’impostazione, l’accesso alla modifica è indicato nelle figure 6 e 8.

Figura 14 elevazione del livello funzionale di foresta

Figura 14 elevazione del livello funzionale di dominio

Verifica della modifica del livello funzionale tramite il Registro Eventi

L’effettivo innalzamento del livello funzionale, di dominio e foresta, può essere rilevato tramite il Registro Eventi nella sezione relativa ai Directory Services.

In particolare, l’evento ID 2040 è relativo alle modifiche del Livello Funzionale della foresta, mentre l’evento ID 2039 è relativo alle modifiche del Livello Funzionale del dominio. Dopo aver modificato le impostazioni è bene verificare anche dal registro eventi che non siamo presenti errori.

Figura 15 identificazione degli eventi 2039/2040

Per praticità ed eventualmente per una gestione automatizzata del controllo, è possibile utilizzare questo comando PowerShell per la rilevazione puntuale dei due eventi.

Get-EventLog -LogName ‘Directory Service’ | where {$_.eventID -eq 2039 -or $_.eventID -eq 2040} | Format-List

Figura 16 output del Cmd-Let PowerShell

Particolarità relativa alla regressione del Livello Funzionale

Finora abbiamo visto e descritto come gestire l’innalzamento dei vari livelli, ma non abbiamo precisato che, seppur con una qualche limitazione è possibile anche abbassare le funzionalità di AD.

Questa caratteristica è valida solamente dalla versione 2008 in poi, in pratica il passaggio da 2003-à2008 non è reversibile, lo diventano i livelli funzionali più alti, per cui avremo 2008ß–à2008R2ß–à2012ß–à2012R2ß–à2016 ma anche 2008ß–à2016 e le varie combinazioni.

Naturalmente deve essere rispettata la tabella 1 in termini di dipendenza dal sistema operativo, ed il ritorno a livelli funzionali più bassi può essere esclusivamente eseguito con PowerShell.

Relazione tra Schema di Active Directory e Livelli Funzionali

In altri articoli, ad esempio in quelli relativi alla migrazione, abbiamo anche fatto cenno alla versione dello schema di Active Directory, in qualche modo la versione dello schema di AD è “svincolata” dal livello funzionale della directory stessa. Ossia se una infrastruttura Active Directory è composta interamente da domain controller di versione 2016 ma il livello funzionale è 2008R2, vedremo come lo schema di Active Directory sarà comunque relativo alla versione più elevata di Domain Controller installata in foresta, mentre i livelli funzionali resteranno o potranno essere abbassati alla versione 2008R2.

Lo schema di Active Directory è la definizione formale di ogni classe di oggetti che può essere creata in una foresta, e di conseguenza di ogni attributo presente. Ad esempio la classe Utente ha una serie di attributi propri quali Nome, Cognome etc.

Lo schema viene “preparato” all’atto della promozione alla funzione di domain controller del server di versione di sistema operativo più elevata, nella tabella qui sotto riportate le varie versioni di schema di AD in relazione alla versione del sistema operativo.

Tabella 3 versioni dello schema di AD

Per determinare la versione dello schema corrente in una foresta è possibile utilizzare

• PowerShell
• Dsquery
• Registry

Powershell

Il Cmdlet per ottenere l’informazione relativa allo schema di AD è Get-ADObject

Get-ADObject “cn=schema,cn=configuration,dc=ICTPOWER,dc=LOCAL” -properties objectversion

Figura 17 rilevazione della versione dello schema di AD

Dsquery

Anche in questo contesto il comando già usato in precedenza per rilevare il Livello Funzionale di AD ci permette di ottenere l’informazione sullo schema

dsquery * cn=schema,cn=configuration,dc=ICTPOWER,dc=LOCAL -scope base -attr objectVersion”

Figura 18 rilevazione della versione dello schema di AD tramite Dsquery

Registry

Per mezzo del registro di sistema in: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version> possiamo trovare l’informazione relativa allo schema version della Directory

Figura 19 rilevazione della versione dello schema di AD tramite registry

Considerazioni:

In questo articolo abbiamo riportato quelle che possono essere informazioni utili nel lavoro quotidiano e che possono aiutarci a manutenere ed organizzare al meglio una Directory, sempre di più questo strumento è il provider di autenticazione aziendale, ad esso è affidata anche la protezione delle credenziali che rappresentano sovente un tassello poco considerato in termini di protezione.

Riferimenti:

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc784826(v=ws.10)?redirectedfrom=MSDN
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/view-set-ldap-policy-using-ntdsutil

Qui di seguito trovate invece alcune guide di migrazione che abbiamo realizzato:

https://www.ictpower.it/sistemi-operativi/migrare-active-directory-da-windows-server-2008-2008-r2-a-windows-server-2019.htm
https://www.ictpower.it/sistemi-operativi/upgrade-domain-controller-a-windows-server-2016-parte-1-di-4.htm
https://www.ictpower.it/sistemi-operativi/upgrade-domain-controller-a-windows-server-2016-parte-2-di-4.htm
https://www.ictpower.it/sistemi-operativi/upgrade-domain-controller-a-windows-server-2016-parte-3-di-4.htm
https://www.ictpower.it/sistemi-operativi/upgrade-domain-controller-a-windows-server-2016-parte-4-di-4.htm

L'articolo Livelli funzionali di Active Directory: a cosa servono ed implicazioni sulla sicurezza proviene da ICT Power.

Il termine Informatica deriva dalla fusione delle due parole Informazione e Automatica. Le informazioni che gestiamo ogni giorno rappresentano, per gli utenti e per le aziende, delle importanti risorse per il business. Uno degli obiettivi più importanti che ci dobbiamo prefissare è quello relativo alla protezione dei dati e di tutte le informazioni aziendali. Tantissime informazioni vengono condivise ogni giorno dagli utenti, a volte anche in maniera sbagliata perché possono essere sensibili per l’azienda.

Per evitare che informazioni importanti vengano inviate dai nostri utenti a persone non autorizzate, anche per sbaglio, abbiamo a disposizione uno strumento davvero potente: Azure Information Protection.

Azure Information Protection (AIP) è un servizio cloud che permette di proteggere e classificare documenti ed inviare messaggi di posta elettronica con contenuti che saranno disponibili solo per i destinatari. Questa funzionalità fa parte della soluzione Microsoft Information Protection (MIP) disponibile in Microsoft 365, di cui trovate maggiori dettagli alla pagina https://docs.microsoft.com/it-it/microsoft-365/compliance/information-protection?view=o365-worldwide

La protezione delle informazioni è basata sulla gestione dei diritti sul file, che includono copia, stampa, modifica e controllo completo.

Figura 1: Microsoft 365 Compliance e gestione dei dati

Le informazioni e i dati vengono protetti grazie alla crittografia e le autorizzazioni che concediamo permettono di accedere al file ed interagire con lo stesso anche a chi non fa parte del nostro Tenant Azure AD, come ad esempio aziende partner con cui vogliamo collaborare. La protezione che applichiamo tramite i Rights Management Services (Azure RMS) rimane associata ai documenti e ai messaggi di posta elettronica indipendentemente che si trovino all’interno o all’esterno della nostra infrastruttura. La condivisione diventa quindi allo stesso tempo semplice e sicura.

Un altro grande vantaggio di Azure Information Protection è rappresentato anche dalla possibilità di poter essere usato su più dispositivi, inclusi telefoni, tablet e PC. Questo rende di fatto possibile mantenere il file protetto indipendentemente dalla piattaforma dalla quale viene usufruito.

Come ottenere Azure Information Protection

Per utilizzare Azure Information Protection è necessario disporre di:

• Un Piano di Azure Information Protection. Obbligatorio per la classificazione, l’assegnazione di etichette e la protezione tramite il Azure Information Protection scanner o il client (classica o unificata con etichetta)
• Un Piano di Office 365 che include Azure Information Protection. Obbligatorio solo per la protezione.

Azure Information Protection è disponibile in due piani: Azure Information Protection P1 e Azure Information Protection P2

I piani possono essere acquistati in modalità standalone (come licenze aggiuntive), mentre sono già contenuti in alcune licenze:

• Microsoft 365 Enterprise plans
• Microsoft 365 Compliance plan (include Azure Information Protection P2)
• Microsoft 365 Business (include Azure Information Protection P1)
• Enterprise Mobility + Security plans

Alla pagina https://azure.microsoft.com/en-us/pricing/details/information-protection/ trovare tutti dettagli relativi ai prezzi e alle differenze tra Azure Information Protection P1 e Azure Information Protection P2

Attivazione di Azure Information Protection

Information Protection è configurabile dal portale della Microsoft 365 Security & Compliance, raggiungibile dal link diretto https://compliance.microsoft.com/ oppure dal portale amministrativo di Microsoft 365 https://admin.microsoft.com/

Se accedete ad un tenant creato da poco e state lavorando su un nuovo cliente sarà necessario effettuare alcune configurazioni, come ad esempio abilitare la funzionalità delle Sensitivity Labels, lo strumento che permette di classificare le informazioni aziendali e, sulla base di questa classificazione, proteggerle.

Le Sensitivity Labels si appoggiano alla Unified Labeling Platform e ad Azure Information Protection configurato in modalità di supportare lo Unified Labeling Store. Per maggiori informazioni vi invito alla lettura della nostra guida Come classificare e proteggere le informazioni con le Sensitivity Labels di Office 365 Security & Compliance

Figura 2: Abilitazione della funzionalità di Processing dei file di Office online

Nell’articolo Azure Information Protection – Protezione delle informazioni e dei dati aziendali avevo già fatto vedere come configurare Azure Information Protection  in modalità classica (che verrà deprecata il 31 Marzo 2021, come annunciato qualche mese fa https://techcommunity.microsoft.com/t5/microsoft-security-and/announcing-timelines-for-sunsetting-label-management-in-the/ba-p/1226179 ). Per poter utilizzare la nuova modalità sarà necessario migrare le vecchie etichette di Azure Information Protection a etichette di riservatezza unificate (unified labeling)

NOTA: Se la sottoscrizione di Azure Information Protection è piuttosto nuova, potrebbe non essere necessario eseguire la migrazione delle etichette perché il tenant si trova già nella piattaforma di etichettatura unificata.

Migrare le vecchie etichette di Azure Information Protection a etichette di riservatezza unificate (unified labeling)

Nel portale Microsoft 365 Security & Compliance selezionate il nodo Information Protection e cliccate su Go to Azure Information Protection to migrate labels

Figura 3: Migrazione di etichette di Azure Information Protection a etichette di riservatezza unificate

Verrete rediretti al portale di Azure Information Protection classico, all’interno del quale potrete verificare le policy di distribuzione delle etichette di riservatezza. Nel mio caso c’è un’unica policy, chiamata Global, che distribuisce alcune etichette di default, come mostrato nelle figure sotto:

Figura 4: Azure Information Protection policy

Figura 5: Etichette distribuite dalla policy Global

Per migrare le etichette esistenti sarà sufficiente selezionare il nodo Unified Labeling e cliccare sul pulsante Copy policies (Preview). Come potete notare dalla figura sotto, un messaggio vi avvisa che dal 1 Aprile 2021 le etichette potranno essere gestite solo dal Microsoft 365 Security & Compliance Center.

Figura 6: Migrazione delle etichette di riservatezza dal portale di Azure Information Protection classico

Figura 7: Conferma della migrazione delle etichette di riservatezza dal portale di Azure Information Protection classico

Dopo qualche secondo, la migrazione delle etichette di riservatezza dal portale di Azure Information Protection classico sarà completata e riceverete un messaggio che vi avviserà che è stata creata la nuova policy chiamata AIP_Global.

Figura 8: Messaggio di conferma dell’avvenuta migrazione delle etichette di riservatezza dal portale di Azure Information Protection classico

Applicare le etichette di riservatezza ai gruppi di Microsoft 365, ai Teams e ai siti di SharePoint

Dal portale di Microsoft 365 Security & Compliance è possibile anche applicare delle etichette di riservatezza ai gruppi di Microsoft 365, ai Teams e ai siti di SharePoint. La funzionalità deve essere prima attivata e, come si può vedere dalla figura sotto, un banner ci avvisa che è necessario prima effettuare dei passaggi per abilitare la funzionalità. Alla pagina https://docs.microsoft.com/it-it/microsoft-365/compliance/sensitivity-labels-teams-groups-sites?view=o365-worldwide#enable-this-preview-and-synchronize-labels trovate maggiori informazioni su come usare le etichette di riservatezza per proteggere il contenuto in Microsoft Teams, gruppi di Microsoft 365 e siti di SharePoint.

Figura 9: Abilitazione della funzionalità per l’applicazione delle etichette di riservatezza anche ai gruppi di Microsoft 365, ai Teams e ai siti di SharePoint

Per attivare le etichette di riservatezza anche ai gruppi di Microsoft 365, ai Teams e ai siti di SharePoint è necessario abilitarle tramite PowerShell. Qui di seguito sono indicati i comandi:

#Preparare l'esecuzione dei comandi
Install-Module AzureADPreview
Connect-AzureAD


#Recuperare le impostazioni di gruppo correnti per l'organizzazione Azure AD
$Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id

Figura 10: Errore nel recupero delle informazioni perché non sono presenti impostazioni nel tenant di Azure AD

Se NON sono state create impostazioni di gruppo per questo tenant di Azure AD, nel cmdlet precedente verrà visualizzato un errore che indica che “non è possibile associare l’argomento al parametro ‘ ID ‘ perché è null”. In questo caso è necessario innanzitutto creare le impostazioni.

Per creare le impostazioni utilizzare i seguenti comandi:

Nei cmdlet DirectorySettings è necessario specificare l’ID del SettingsTemplate che si vuole usare. Se non si conosce l’ID, questo cmdlet restituisce l’elenco di tutti i modelli di impostazioni:

#Recuperate le informazioni relative al template di configurazioni
$TemplateId = (Get-AzureADDirectorySettingTemplate | where { $_.DisplayName -eq "Group.Unified" }).Id
$Template = Get-AzureADDirectorySettingTemplate | where -Property Id -Value $TemplateId -EQ

#Create un nuovo oggetto impostazioni sulla base del modello
$Setting = $Template.CreateDirectorySetting()

#Aggiornate quindi l'oggetto Settings con un nuovo valore. Ad esempio, abilitiamo la funzionalità di Unified Labeling per i gruppi Microsoft 365
$Setting["EnableMIPLabels"] = "True"

#Applicate quindi l'impostazione
New-AzureADDirectorySetting -DirectorySetting $Setting

#Per leggere i valori
$Setting.Values

Figura 11: Abilitazione delle etichette per i gruppi di Azure AD (Unified Groups)

Maggiori informazioni sono disponibili alla pagina https://docs.microsoft.com/it-it/azure/active-directory/enterprise-users/groups-assign-sensitivity-labels e alla pagina https://docs.microsoft.com/it-it/azure/active-directory/enterprise-users/groups-settings-cmdlets

Nel portale di Microsoft 365 Security & Compliance vedrete che è scomparso il banner che vi avvisava di apportare modifiche alla configurazione di Azure AD

Figura 12: È scomparso il banner che vi avvisava di apportare modifiche alla configurazione di Azure AD

D’ora in poi al momento della creazione dell’etichetta sarà possibile selezionare anche Groups & Sites.

Figura 13: Applicazione delle etichette di sensibilità anche ai gruppi di Microsoft 365 e ai siti di SharePoint

Ora è necessario sincronizzare le etichette di riservatezza in Azure AD, come ben documentato nella guida Assegnare etichette di riservatezza ai gruppi-Azure AD | Microsoft Docs. Prima di tutto, connettetevi a PowerShell in Centro sicurezza e conformità con i privilegi di amministratore globale. Successivamente eseguite il comando Execute-AzureAdLabelSync per assicurarsi di poter usare le etichette di riservatezza con i gruppi di Microsoft 365. Qui di seguito i comandi che ho utilizzato:

#Installazione del modulo ExchangeOnline EXO2
Install-Module ExchangeOnlineMangement

#Connessione ad Exchange Online
Connect-ExchnageOnline

#Connessione al Centro sicurezza e conformità tramite PowerShell
Connect-IPPSSession -UserPrincipalName <global admin>

#Esecuzione della sincronizzazione delle etichette già presenti, che permette di poter usare le etichette di riservatezza con i gruppi di Microsoft 365
Execute-AzureAdLabelSync

Figura 14: Comandi per assicurarsi di poter usare le etichette di riservatezza con i gruppi di Microsoft 365

Creazione di una nuova etichetta di riservatezza di Azure Information Protection

Per creare una nuova etichetta di riservatezza è sufficiente cliccare su + Create a label e seguire il wizard.

Figura 15: Creazione di una nuova etichetta di riservatezza

Inserite un nome per l’etichetta, un nome per la sua visualizzazione e una descrizione, sia per aiutare gli utenti a capire che cosa fa sia per gli amministratori.

Figura 16: Scelta del nome dell’etichetta e delle descrizioni

Nel passaggio successivo definite dove potrà essere utilizzata la nuova etichetta. Come si può vedere dalla figura sotto, le etichette di riservatezza, oltre a essere usate per classificare e proteggere documenti e messaggi di posta elettronica, possono essere usate per proteggere il contenuto dei siti di Microsoft Teams, dei gruppi di Microsoft 365 (in precedenza gruppi di Office 365) e dei siti di SharePoint.

Se non avete ancora attivato la funzionalità per usare le etichette di riservatezza per proteggere il contenuto in Microsoft Teams, gruppi di Microsoft 365 e siti di SharePoint vedrete che l’opzione Groups & Sites non è disponibile.

Figura 17: Le etichette di riservatezza, oltre a essere usate per classificare e proteggere documenti e messaggi di posta elettronica, possono essere usate per proteggere il contenuto dei siti di Microsoft Teams, dei gruppi di Microsoft 365 (in precedenza gruppi di Office 365) e dei siti di SharePoint.

Nella schermata successiva scegliete la modalità di protezione per i file e le mail e decidete se volete cifrarli e se volete aggiungere una filigrana, per evidenziare che si tratterà di contenuto sensibile oppure riservato.

Figura 18: Scelta della cifratura del file e della filigrana per i documenti

Se avete scelto di proteggere il file con la cifratura, vi verrà chiesto di indicare a quali utenti o gruppi sarà concessa l’apertura e/o la modifica dei file.

Figura 19: Configurazione dei permessi di accesso al file

Assegnate quindi permessi necessari seguendo le indicazioni presenti nei diversi blade. Nelle immagini sotto sono mostrati tutti i passaggi.

Figura 20: Aggiunta di utenti e gruppi a cui concedere i privilegi di accesso al file

Figura 21: Scelta del gruppo o degli utenti

Figura 22: Utenti o gruppi che potranno avere accesso ai file a cui sarà applicata l’etichetta di riservatezza

Figura 23: Scelta del permesso di accesso al file a cui sarà applicata l’etichetta di riservatezza

Figura 24: Conferma della scelta dei permessi di accesso al file a cui sarà applicata l’etichetta di riservatezza

Se avete scelto di aggiungere una filigrana, sarà possibile aggiungerla nell’intestazione, nel corpo o nel piè di pagina del documento.

Figura 25: Aggiunta di una filigrana al documento

Nella schermata successiva, se avete abilitato la protezione per i gruppi di Microsoft 365 e per i siti di SharePoint vi verrà chiesto se volete controllare il livello di accesso ai file quando vengono aperti da utenti dell’organizzazione o quando vengono condivisi all’esterno.

Figura 26: Definizione della protezione per i gruppi di Microsoft 365 e per i siti di SharePoint

Se possedete la licenza corretta, è possibile applicare delle etichette di riservatezza in maniera automatica. Esistono due metodi diversi per applicare automaticamente un’etichetta di riservatezza al contenuto in Microsoft 365:

• Etichettatura lato client quando gli utenti modificano documenti o compongono (e rispondono o inoltrano) messaggi di posta elettronica: usare un’etichetta configurata per l’applicazione automatica di etichette per file e messaggi di posta elettronica (include Word, Excel, PowerPoint e Outlook).
  Questo metodo supporta la raccomandazione di un’etichetta agli utenti, nonché l’applicazione automatica di un’etichetta.
• Etichettatura lato servizio quando il contenuto è già salvato (in SharePoint o OneDrive) o inviato tramite posta elettronica (elaborato da Exchange Online):
  usare un criterio di applicazione automatica di etichette.
  Questo metodo potrebbe essere indicato anche come applicazione automatica di etichette per i dati salvati (documenti in SharePoint e OneDrive) e per i dati in transito (messaggi di posta elettronica inviati o ricevuti da Exchange). Per Exchange, non include i messaggi di posta elettronica già presenti nelle cassette postali.
  

Trovate maggiori informazioni alla pagina Applicare automaticamente un’etichetta di riservatezza al contenuto in Microsoft 365 – Microsoft 365 Compliance | Microsoft Docs

Figura 27: Applicazione dell’etichettatura automatica in base ai criteri

Figura 28: Pagina di riepilogo e creazione dell’etichetta

Azure Purview è un servizio unificato di governance dei dati che facilita la gestione e la governance dei dati in ambienti locali, multi-cloud e SaaS. Consente di creare facilmente una mappa aggiornata del panorama dei dati con funzionalità di individuazione dei dati automatica, classificazione dei dati sensibili e derivazione dei dati end-to-end. Aiuta i consumer di dati a trovare dati di valore e affidabili. Per approfondimenti vistate la pagina Introduzione ad Azure Purview (anteprima) – Azure Purview | Microsoft Docs

Figura 29. Auto-labeling per le colonne di Azure Database tramite Azure Purview

Figura 30: Creazione dell’etichetta completata

Una volta create tutte le etichette desiderate, rivedete l’ordine e, se necessario, spostatele verso l’alto o verso il basso. Per modificare l’ordine di un’etichetta selezionare il simbolo … per Altre azioni, quindi selezionare Sposta su o Sposta giù.  L’ordine delle etichette è importante perché ne riflette la priorità. È importante che l’etichetta con il grado di riservatezza più restrittivo, come Riservatezza elevata, sia visualizzata nella parte inferiore dell’elenco e che l’etichetta con il grado di riservatezza meno restrittivo, ad esempio Pubblico, sia visualizzata nella parte superiore.

Pubblicazione della nuova etichetta tramite una policy

Terminata la creazione della nuova etichetta di riservatezza sarà necessario pubblicarla. Dal Microsoft Security & Compliance Center fate clic su Publish Labels e seguite le indicazioni del wizard.

Figura 31: Pubblicazione di un’etichetta

Figura 32: Scelta dell’etichetta da pubblicare attraverso la policy

È possibile applicare una sola etichetta di riservatezza a un elemento, ad esempio un documento, un messaggio di posta elettronica o un gruppo di Microsoft 365. È possibile impostare un’opzione per richiedere agli utenti di fornire una giustificazione per modificare un’etichetta applicando una classificazione inferiore (questa opzione non si applica alle sottoetichette) ed è anche possibile scegliere se i documenti devono avere un’etichetta predefinita. Nella figura sotto viene mostrata la schermata dove possibile applicare queste configurazioni.

Figura 33: Configurazioni delle policy di pubblicazione dell’etichetta

La policy di pubblicazione dell’etichetta permette di rendere disponibile l’etichetta (o le etichette) per gli utenti per un gruppo di distribuzione per un gruppo di sicurezza che ha anche un indirizzo di posta elettronica e per i gruppi di Microsoft 365.

Figura 34: Scelta dei gruppi a cui distribuire e pubblicare le etichette

Figura 35: Nome della policy di distribuzione delle etichette

Figura 36: Creazione della policy di distribuzione delle etichette completata

Figura 37: Pubblicazione della nuova policy di distribuzione delle etichette di riservatezza

Nella scheda Label Policies sarà visualizzata la policy appena creata. nel mio caso è anche visibile la policy AIP_Global che è stata migrata dal vecchio portale di Azure Information Protection.

NOTA: per pubblicare una nuova etichetta di riservatezza non è necessario creare una nuova policy ma è anche possibile modificare una policy già esistente.

Figura 38: Policy per la pubblicazione delle etichette

NOTA: Quando viene pubblicata una nuova etichetta potrebbe essere necessario attendere fino ad un ora per poterla vedere nei diversi programmi di Office. Se invece modificate un’etichetta esistente, non sarà necessario creare una nuova policy per pubblicarla ma saranno necessarie fino a 24 ore affinché le modifiche vengano replicate in tutte le app e i servizi.

Verifica della creazione e distribuzione dell’etichetta

Dopo aver pubblicato le etichette di riservatezza dal Centro conformità Microsoft 365, queste vengono visualizzate nelle app di Office per consentire agli utenti di classificare e proteggere i dati durante la creazione o la modifica. Per usare le etichette di riservatezza incorporate nelle app desktop di Office per Windows e Mac
utilizzando l’etichettatura incorporata è necessario usare un’edizione in abbonamento di Office (Microsoft 365 Apps for Business oppure Microsoft 365 Apps for Enterprise) che sia almeno la versione 1910 o superiore. Se avete Office 2016 oppure Office 2019 sarà necessario utilizzare il client di etichettatura unificata (Unified Labeling) di Azure Information Protection.

NOTA: le etichette di riservatezza sono integrate anche nell’app di Office per iOS e Office per Android.

Figura 39: La nuova etichetta è disponibile nelle Microsoft 365 Apps che supportano l’etichettatura incorporat

Installazione del client di Azure Information Protection per lo Unified Labeling

Per poter creare file protetti con Azure Information Protection e per applicare le etichette è necessario utilizzare un client sulle versioni di Office non in abbonamento. Il client permetterà di far apparire un nuovo pulsante sulla barra di Office e ci permetterà di visualizzare le etichette create ed applicare le policy configurate. Il client si integra anche con il sistema operativo e vi permetterà di poter rendere sicuri anche file diversi da quelli classici di Office, come ad esempio i file .PDF.

Potete scaricare il client dal link Download Microsoft Azure Information Protection from Official Microsoft Download Center e procedere alla sua installazione.

Figura 40: Download del client di Azure Information Protection

Figura 41: Client di Unified Labeling per Azure Information Protection

Figura 42: Installazione del client di Azure Information Protection

Il client di Azure Information Protection si integra anche con Esplora Risorse ed è quindi possibile classificare e proteggere i file semplicemente cliccando col tasto destro sul file e scegliendo Classify and protect.

Figura 43: Protezione del file utilizzando Windows Explorer

La prima volta che utilizzerete il client di Microsoft Azure Information Protection vi verrà chiesta l’ autenticazione.

Figura 44: Autenticazione richiesta dal client di Azure Information Protection

In base alle credenziali che avete inserito verranno mostrate tutte le etichette di riservatezza che vi sono state consentite attraverso le policy implementate nel Microsoft 365 Security & Compliance Center.

Figura 45: Il client mostra le etichette disponibili per l’utente e permette di applicarla al file

Figura 46: Applicazione dell’etichetta di riservatezza e delle relative restrizioni effettuata con successo

Distribuzione di file protetti da Azure Information Protection e relativa apertura e modifica

Prima di poter visualizzare il file protetto, il servizio Azure Rights Management (Azure RMS) usato per proteggere il file deve verificare che siano presenti le autorizzazioni necessarie per la visualizzazione del file. Il servizio esegue tale controllo verificando il nome utente e la password. In alcuni casi, le credenziali possono essere memorizzate nella cache e non verrà visualizzato un messaggio che richiede di eseguire l’accesso, altrimenti verrà richiesto di immettere le credenziali.

Nell’immagine sotto ho provato ad aprire il file riservato utilizzando il browser Microsoft Edge, il lettore PDF predefinito di Windows 10.

Figura 47: Richiesta delle credenziali per l’apertura del file PDF in Microsoft Edge

L’utente, dopo essersi correttamente autenticato e ovviamente soltanto se avrà le autorizzazioni necessarie, sarà in grado di visualizzare il file.

Figura 48: L’utente è autorizzato alla visualizzazione del file protetto con l’etichetta di riservatezza

Se nel computer è installato Adobe Acrobat Reader sarà lo stesso programma a notificarvi che il file è protetto con Azure Information Protection e quindi sarà necessario installare un componente aggiuntivo. Questa funzionalità è molto interessante perché dimostra che Azure Information Protection è ormai uno standard de facto per proteggere i documenti e anche gli altri vendor si sono integrati con la funzionalità.

Figura 49: Adobe Acrobat Reader notifica all’utente che il file è protetto con Azure Information Protection

Seguite quindi le indicazioni per scaricare il plugin di Microsoft Azure Information Protection per Adobe Acrobat Reader DC.

Figura 50: Download e installazione del plugin per Azure Information Protection in Adobe Acrobat Reader DC

Figura 51: Richiesta dell’autenticazione con un account di Microsoft 365 per poter aprire il file PDF

Figura 52: Richiesta di mantenere le credenziali di accesso in cache per poter velocizzare le successive aperture di file protetti da Azure Information Protection

Figura 53: Concessione delle autorizzazioni per l’app Adobe Acrobat Reader per avere accesso alle info dell’utente e ai suoi permessi di accesso al file

Figura 54: Apertura del file protetto da Azure Information Protection completata

Condivisione dei file protetti con Microsoft Azure Information Protection all’esterno dell’azienda

Tra le domande che più spesso mi vengono fatte c’è sicuramente quella riguardante la possibilità di condividere file protetti con Azure Information Protection all’esterno dell’azienda e se i destinatari che hanno indirizzi email non ospitate in Microsoft 365 potranno aprire il file, se gli abbiamo concesso le giuste autorizzazioni. La risposta è SI. Possiamo condividere a autorizzare all’apertura anche utenti con mail GMAIL, Libero, Domini proprietari non ospitati in Microosft 365.

Per condividere file protetti con Microsoft Azure Information Protection all’esterno dell’azienda è sufficiente utilizzare come indirizzi per la condivisione degli indirizzi di posta elettronica associati ad un Microsoft Account. Per poter utilizzare dei permessi di condivisione personalizzati sarà necessario però prima creare una nuova etichetta di riservatezza e successivamente pubblicarla con una policy, esattamente come abbiamo fatto prima.

Dal portale Microsoft 365 Security & Compliance Center create una nuova etichetta di riservatezza. Date nome che faccia capire in maniera chiara all’utente per quale motivo la dovrà utilizzare.

Figura 55: Creazione di una nuova etichetta di riservatezza

Figura 56: Definizione dell’ambito di utilizzo dell’etichetta

Figura 57: Utilizzo dell’etichetta per la crittografia o per l’inserimento di una filigrana nel documento

Nella schermata relativa all’Encryption configurate i parametri di far scegliere all’utente i permessi di accesso al file, come mostrato in figura sotto:

Figura 58: Viene lasciato all’utente la possibilità di poter scegliere i permessi di accesso al file

Proseguite nel wizard completando le configurazioni a piacimento, esattamente come abbiamo fatto prima. Terminato il wizard create l’etichetta.

Figura 59: Completamento della creazione della nuova etichetta

Figura 60: nuova etichetta completata con successo

Una volta che l’etichetta sarà stata creata, sarà necessario distribuirla attraverso una policy, esattamente come abbiamo fatto prima. Decidete voi quale policy modificare per poter distribuire la nuova etichetta che permetterà di dare delle autorizzazioni personalizzate. Nel mio caso ho deciso di modificare la policy chiamata AIP_Global,
che contiene tutte le etichette che avevo precedentemente migrato dal portale di Azure Information Protection classico.

Dopo aver selezionato la policy, fate clic su Edit Policy e aggiungete la nuova etichetta, come mostrato nelle figure sotto:

Figura 61: Modifica di una policy esistente per distribuire la nuova etichetta di riservatezza

Figura 62: Aggiunta della nuova etichetta di riservatezza alla policy

Procedete nella configurazione delle diverse schermate, apportando le modifiche che ritenete opportune e completate la modifica della policy.

Figura 63: Review delle configurazioni e delle modifiche apportate alla policy

Figura 64: Policy aggiornata con successo

NOTA: potrebbe essere necessario fino ad un’ora per vedere apparire la nuova etichetta di riservatezza pubblicata.

Quando l’etichetta di riservatezza sarà stata distribuita, gli utenti potranno utilizzarla per proteggere i propri file, come mostrato nella figura sotto:

Figura 65: La nuova etichetta di riservatezza che permette di aggiungere autorizzazioni personalizzate è stata distribuita

All’utente verrà quindi chiesto di inserire gli indirizzi di posta elettronica degli utenti che potranno avere accesso al documento. È importante ricordare che questi indirizzi di posta elettronica devono essere account di Azure AD oppure devono essere dei Microsoft Account. Nel caso l’utente utilizzi un per la condivisione un indirizzo di posta elettronica che non sia un Microsoft account, la prima volta verrà chiesto al destinatario di convertire quell’indirizzo di posta elettronica in Microsoft account.

Figura 66: L’utente può decidere a chi deve essere concesso il privilegio di apertura o modifica del file

Se, ad esempio, decidete di consentire l’accesso al file a un utente che ha un indirizzo @gmail.com quando l’utente riceverà l’e-mail con il file allegato gli verrà notificato che all’interno della e-mail c’è un allegato cifrato, come mostrato nella figura sotto:

Figura 67: L’utente riceve un file crittografato e protetto con Azure Information Protection

Se l’utente salva il documento sul proprio computer e successivamente tenta di aprirlo, nel caso in cui non gli sia stato concesso il permesso di apertura, riceverà un errore come quello mostrato nella figura sotto (non ha le autorizzazioni per accedere al file) e potrà richiedere tramite e-mail autorizzazione al proprietario del documento per poter avere la possibilità di aprire o di modificare il file.

Figura 68: L’utente non ha l’autorizzazione all’apertura del file

Utilizzando Outlook, ad esempio, che permette di avere un’ anteprima del documento, quando si tenterà di visualizzare il file allegato verrà mostrato un messaggio di errore che notificherà che non ha le autorizzazioni per aprire il file e che è necessario richiedere le autorizzazioni al proprietario.

Figura 69: L’utente non ha l’autorizzazione all’apertura del file

Facendo clic sul pulsante Richiedi autorizzazione potrà inviare un’e-mail al proprietario del file per farsi concedere l’autorizzazione all’apertura e all’eventuale modifica del file protetto. Non sarà necessario dover scambiare nuovamente i file perché le autorizzazioni sono memorizzate in Azure e vengono scaricate ogni volta che viene effettuato l’accesso al file protetto da Azure Information Protection.

Conclusioni

Azure Information Protection consente di proteggere i documenti e i messaggi di posta elettronica importanti dagli utenti che non sono autorizzati a visualizzarli, anche se il messaggio di posta elettronica viene inoltrato o se il documento viene salvato in un altro percorso. In questo modo siamo capaci di gestire e limitare l’accesso alle nostre informazioni sensibili anche se queste dovessero essere condivise all’esterno dell’organizzazione per errore oppure essere aperte da persone non autorizzate.

L'articolo Azure Information Protection in Microsoft 365 – Protezione e prevenzione contro la perdita di dati aziendali utilizzando lo Unified Labeling proviene da ICT Power.

Il Remote Desktop Connection Broker  è il server che nell’infrastruttura di Remote Desktop Services di Windows Server si occupa di gestire le connessioni verso i Session Host e verso le RemoteApp. Il ruolo di RD Connection Broker è un ruolo vitale della vostra infrastruttura e rappresenta il cervello che si occupa di distribuire le nuove connessioni oppure effettuare le riconnessioni in caso di perdita di connettività.

Abbiamo già visto nella guida Configurare l’alta disponibilità dei Remote Desktop Services in Windows Server 2016 e Windows Server 2019 – ICT Power che l’alta disponibilità dei Remote Desktop Services in Windows Server viene stabilita attraverso la duplicazione di ognuno dei ruoli di infrastruttura Desktop remoto.

In questa guida mostrerò come mettere in alta disponibilità il ruolo di Remote Desktop Connection Broker di una Farm RDS pensata per il Session-based deployment. Utilizzerò Windows Server 2019, ma le stesse operazioni sono valide anche per Windows Server 2016.

In particolar modo il ruolo RD Connection Broker utilizzerà un database reso altamente disponibile grazie ai SQL Server Always On Availability Groups.

Nella figura sotto sono mostrati i nomi dei server che utilizzerò per il mio deployment.

Figura 1: Schema di funzionamento dell’infraastruttura

Questa guida esula dalla creazione di un RDS Session-based deployment. Nell’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016 e Windows Server 2019 – ICT Power potete trovare tutti gli steps per mettere in piedi un RDS Session-based deployment e come configurare le RemoteApp.

Ho provveduto a creare un gruppo di computer in Active Directory nel quale ho inserito le due macchine su cui installerò il ruolo di RD Connection Broker. questo gruppo mi servirà più avanti per poter accedere al database condiviso che verrà utilizzato dai due . Ho chiamato il gruppo RDS_Broker e ho aggiunto le due macchine NIC-RDCB3 e NIC-RDCB3

Figura 2: Gruppo RDS_Broker con le due macchine che hanno il ruolo di Connection Broker

Nel DNS ho anche creato il nome NIC-RDS che risolve in Round Robin i nomi dei due RD Connection Broker. Il nome verrà utilizzato più tardi quando metterò in alta disponibilità il ruolo di Connection Broker.

Figura 3: Creazione nel DNS dei record per la risoluzione degli indirizzi IP dei due Connection Broker

Creazione del SQL Server Always On Availability Group

La funzionalità Always On di SQL Server è una soluzione di disponibilità elevata e recupero di emergenza che supporta fino a 9 repliche del database senza che sia necessario avere dei dischi condivisi tra i diversi database server. La funzionalità è disponibile sia in SQL Standard (con la limitazione ad un unico database) che in SQL Enterprise.

In questa guida utilizzerò SQL Server 2019, installato su due database server chiamati NIC-SQL1 e NIC-SQL2. IN realtà è possibile utilizzare anche SQL Server 2016 / 2017.

Dopo aver installato SQL Server 2019 su entrambi i server è necessario abilitare la funzionalità di Windows Failover Cluster per poter successivamente abilitare l’Always On Availability Group.

Aggiungete la funzionalità di Failover Clustering a tutti i SQL Server utilizzando il Server Manager oppure utilizzando PowerShell:

$servers = "NIC-SQL1.demo.lab", "NIC-SQL2.demo.lab"

foreach ($server in $servers)

{ Install-WindowsFeature -computername $server –Name Failover-Clustering –IncludeManagementTools }

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 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.

Figura 4: Installazione della funzionalità di Failover Cluster sul primo server SQL

Figura 5: Installazione della funzionalità di Failover Cluster sul secondo server SQL

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

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 6: Wizard di validazione dei nodi del cluster. Scelta dei nodi

Figura 7: Esecuzione di oltre 120 controlli durante il wizard di validazione dei nodi del cluster

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 NIC-SQLCluster) e l’indirizzo IP da assegnargli, come mostrato nelle figure sotto.

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

Figura 9: Creazione del cluster in corso

Figura 10: Creazione del cluster completata con successo

Poiché si tratta di un cluster a due nodi ho deciso di modificare la modalità di quorum, che di default è Node Majority. Cliccando col tasto destro sul nome del cluster, scegliete More Actions > Configure Cluster Quorum Settings… e decidete di utilizzare una cartella condivisa in rete, come mostrato nelle figure sotto:

Figura 11: Modifica della modalità di quorum del Cluster SQL

Figura 12: Selezione del witness

Figura 13: Scelta del file share witness

Figura 14: File share da utilizzare per conservare i dati del quorum witness

Figura 15: Modifica della modalità di quorum completata con successo

Figura 16: Il cluster è configurato per utilizzare un File Share Witness

Abilitazione della funzionalità di SQL Server Always On Availability Group

Per abilitare la funzionalità di SQL Server Always On Availability Group è necessario configurare tutte le istanze di SQL server che saranno configurate come repliche nell’Availability Group. Su ognuno dei nodi SQL, dal SQL Server Configuration Manager cliccate due volte sul servizio SQL Server (MSSQLSERVER) e dalla scheda Always On Availability Groups mettete il segno di spunta per abilitare la funzionalità di Always On Availability Groups, come mostrato nella figura sotto.

Figura 17: Abilitazione della funzionalità di Always On Availability Groups

Confermate con OK e provvedete al riavvio del servizio SQL Server (MSSQLSERVER), come richiesto.

Figura 18: Riavvio del servizio SQL Server (MSSQLSERVER)

Creazione del database che verrà utilizzato dall’RD Connection Broker

È necessario che i diversi RD Connection Broker scrivano in un database SQL condiviso, che potrebbe essere un SQL Server locale oppure un database SQL di Azure.

Come prima operazione create sul primo server SQL, dal SQL Management Studio, una nuova login e aggiungete il gruppo degli RDS-Broker che avete creato in precedenza in Active Directory. Nella figura sotto sono mostrati tutti i passaggi necessari. Grazie a questa login i due RD Connection Broker saranno capaci di gestire il database dove verranno conservate tutte le informazioni e le configurazioni.

Figura 19: Creazione della login per l’accesso del gruppo degli RD Connection Broker

Assegnate alla login che state creando il ruolo di dbcreator

Figura 20: Assegnazione del ruolo di dbcreator alla login che permetterà l’accesso dei due RD Connection Broker

Procedete quindi alla creazione di un nuovo database, lasciando le configurazioni di default. Io l’ho chiamato RDSHA.

Figura 21: Creazione di un nuovo database

Dopo aver creato il database, modificate le proprietà della login che avete creato in precedenza e dal nodo User Mapping, selezionate il segno di spunta vicino al database creato (nel mio caso RDSHA) e selezionate la casella db owner, come mostrato nella figura sotto:

Figura 22: Assegnazione del ruolo di db owner alla login utilizzata dai due RD Connection Broker

Creazione e configurazione del SQL Server Always On Availability Group

Per creare un SQL Server Always On Availability Group aprite il SQL Server Management Studio e collegatevi all’istanza SQL Server dove avete creato il database. Espandete il nodo Always On High Availability e cliccando col tasto destro sulla cartella Availability Groups fate partire il wizard New Availability Group Wizard…

Figura 23: New Availability Group Wizard…

Figura 24: Avvio del New Availability Group Wizard…

Figura 25: Inserimento del nome dell’Availability Group

Nella schermata di scelta del database mettete un segno di spunta accanto al dataBase da aggiungere all’Availability Group. Nel mio caso ho ricevuto un errore: non era stato ancora effettuato un full backup del DB.

Figura 26: Errore riferito al database selezionato: è necessario effettuare prima un full backup

Per effettuare il Full Backup del database potete Cliccare col tasto destro sul DB e scegliere Tasks > Back Up…

Figura 27: Task di Backup del database

Figura 28: Scelta delle impostazioni e della destinazione del backup del database

Ritornando nel wizard per la creazione del nuovo Availability Group basterà cliccare su Refresh per verificare che adesso il database soddisfa tutti i prerequisiti. Mettete un segno di spunta accanto al nome del database e proseguite nel wizard.

Figura 29: Il database soddisfa tutti i prerequisiti. Adesso può essere scelto

Nella schermata Specify Replicas aggiungete il secondo nodo SQL del vostro cluster. Fate clic su Add Replica… e loggatevi al server con credenziali amministrative.

Figura 30: aggiunta del SQL Server di replica

Figura 31: Connessione al SQL Server di replica

Selezionate i due SQL Server e abilitate l’Automatic Failover mettendo i segni di spunta accanto ai due server.

Figura 32: Abilitazione dell’Automatic Failover

Nella Scheda Endpoints assicuratevi che il Port Number sia 5022.

Figura 33: Endpoint esposti dai due server SQL

Nella scheda Listener create un nuovo Availability Group Listener e mettete il nome DNS, che verrà registrato nella vostra zona di dominio, la porta 1433 e l’indirizzo IP da assegnare al Listener. Questa parte è molto importante perché viene creato un componente che permetterà alle applicazioni di potersi connettere al database senza dover conoscere quale istanza di SQL Server sta ospitando la replica primaria. Ogni Availability Group avrà il proprio Listener . Verrà creato un nuovo computer in Active directory e verrà registrato il nome all’interno della zona DNS.

Figura 34: Creazione del Listener utilizzato dall’Availability Group

Scegliete a questo punto nella pagina Select Initial Data Synchronization di effettuare una sincronizzazione di tipo Full. Indicate anche una cartella condivisa in rete all’interno della quale verrà messo il file del database e il file di log.

Figura 35: Sincronizzazione Full del database

Figura 36:Validazione delle scelte effettuate

Figura 37: Schermata di riepilogo del wizard

Figura 38: Abilitazione dell’Availability Group completata

Nel SQL Management Studio potrete vedere l’ Availability Group che avete creato e potrete verificare che il database è stato correttamente replicato sul secondo SQL Server, come mostrato nella figura sotto:

Figura 39: Il database è stato correttamente replicato sul secondo SQL Server

Figura 40: In Active Directory stato creato un oggetto per il Listener dell’Availability Group creato

Installazione del client SQL sui server RD Connection Broker

Installate il SQL Server Native Client 11 sui vostri RD Connection Broker. Su ognuno di loro procedete a scaricare il client partendo dall’indirizzo https://go.microsoft.com/fwlink/?linkid=866658

Scegliete Download Media e dopo aver estratto i file accedete alla cartella \SQLEXPR_x64_ENU\1033_ENU_LP\x64\Setup\x64 all’interno della quale troverete il file SQLNCLI.msi

Figura 41: Download dei tools di SQL Server

Figura 42: Scelta della lingua dell’installer di SQL Server

Figura 43: Installazione del SQL Server Native Client 11 in tutti e due i Connection Broker

NOTA: Assicuratevi di installare almeno la versione 11.4.7462.6 di SQL Server Native Client 11 sui vostri RD Connection Broker ,altrimenti potreste avere problemi di connessione al server SQL 2019.

Configurazione dell’alta disponibilità del ruolo RD Connection Broker

Possiamo quindi ora tornare nel Server Manager e dal Deployment Overview cliccare col tasto destro sul’icona RD Connection Broker e scegliere la voce Configure High Availability.

Figura 44: Configurazione High Availability dell’RD Connection

Figura 45: Wizard di configurazione High Availability dell’RD Connection Broker

Figura 46: Scelta del tipo di database server da utilizzare

Inserite a questo punto il nome del cluster di RD Connection Broker (vi ricordate il record NIC-RDS che abbiamo creato poco fa nel DNS?) e la stringa di connessione al database, nella forma DRIVER=SQL Server Native Client 11.0;SERVER=<nome del Listener creato per l’Availability Group>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<nome del database>. Nel mio caso la stringa di connessione è:

DRIVER=SQL Server Native Client 11.0;SERVER=NIC-SQLAG;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDSHA

Figura 47: Inserimento del nome del cluster RD Connection Broker e stringa di connessione al database

Se non ci saranno problemi, procederete col wizard. In caso contrario vi apparirà una schermata di errore e dovrete investigare sui permessi di accesso al database, sulle regole del firewall dei server SQL e dei server RDCB, sulla correttezza della stringa di connessione e sulla versione del SQL Server Native client 11. Insomma tutto quello che potrebbe impedire agli RD Connection Broker di potersi collegare al database che avete precedentemente creato.

Figura 48: Connessione al database SQL avvenuta correttamente

Figura 49: Configurazione dell’alta disponibilità completata

Una volta completata la configurazione dell’alta disponibilità degli R the connection broker , nel Server Manager sarà evidenziato che il primo RD Connection Broker (nel mio caso NIC-RDCB3) è stato configurato per l’alta disponibilità.

Figura 50: Il primo RD Connection Broker (nel mio caso NIC-RDCB1) è stato configurato per l’alta disponibilità

Procedette quindi ad aggiungere il secondo RD Connection Broker cliccando con il tasto destro sull’icona RD Connection Broker e scegliendo Add RD Connection Broker Server, come mostrato nella figura sotto:

Figura 51: Aggiunta del secondo RD Connection Broker al nostro deployment

Figura 52: Prerequisiti necessari ad aggiungere il secondo RD Connection Broker

Figura 53: Scelta del secondo RD Connection Broker

Figura 54: Conferma della selezione dl secondo server

Figura 55: Wizard completato con successo

Adesso i vostri due RD Connection Broker sono stati resi altamente disponibili utilizzando un database ospitato su un SQL Server Always On Availability Group.

Conclusioni

Per assicurare l’alta disponibilità della nostra infrastruttura di Remote Desktop Services è necessario almeno raddoppiare tutti gli elementi che compongono l’infrastruttura. Sicuramente l’operazione non è banale e richiede l’utilizzo di molte risorse. Se volete sapere come mettere in alta disponibilità gli altri ruoli dei Remote Desktop Services di Windows Server, vi invito alla lettura della mia guida Configurare l’alta disponibilità dei Remote Desktop Services in Windows Server 2016 e Windows Server 2019 – ICT Power

L'articolo Configurare l’alta disponibilità di RDS Connection Broker in Windows Server 2016 e Windows Server 2019 con SQL Server Always On Availability Group proviene da ICT Power.

Windows Virtual Desktop è un servizio completo di virtualizzazione di desktop e applicazioni che viene eseguito nel cloud. È possibile connettersi da qualsiasi dispositivo tramite un’applicazione nativa oppure tramite il client Web HTML5 di Windows Virtual Desktop.

Sicuramente negli ultimi mesi questo tipo di soluzione ha avvantaggiato parecchio il lavoro remoto sicuro e molte aziende lo stanno utilizzando per ospitare macchine Windows 10, usando le licenze esistenti per ridurre i costi con un’infrastruttura VDI (Virtual Desktop Infrastructure) moderna basata sul cloud e pagando solo per le risorse usate. Grazie alla multisessione di Windows 10, è possibile eseguire facilmente più sessioni interattive simultanee degli utenti con la stessa distribuzione, per incrementare l’efficienza dei costi, e l’offerta di Microsoft 365 completa l’approccio al Modern Desktop: sicuro, flessibile ed efficiente.

Avevo già avuto modo di parlare della soluzione quasi due anni fa nell’articolo Windows Virtual Desktop – Il Desktop As A Service di Microsoft – ICT Power, in tempi non sospetti e quando era ancora in preview. La soluzione è ormai matura ed è già utilizzata da moltissime aziende.

È anche vero che tantissime aziende utilizzano i Remote Desktop Services, ma molte si stanno avvicinando alla soluzione Windows Virtual Desktop per ottimizzare efficienza e costi di gestione.

Io oggi voglio proporvi proprio questo tipo di migrazione, cioè il passaggio dall’on-premises al cloud delle soluzioni Remote Desktop Services (RDS).

Figura 1: Architettura di Windows Virtual Desktop

L’approccio alla migrazione di Remote Desktop Services (RDS) verso Azure Windows Virtual Desktop potrebbe essere di due tipi:

1. GreenField: In Informatica si riferisce all’approccio tale per cui è preferibile creare una soluzione parallela a quella già esistente, completamente nuova;
2. BrownField: È invece riferito alla creazione del nuovo sistema in coesistenza con quello già esistente e ne possa permettere successivamente la migrazione.

Se volete dare un’occhiata alla soluzione GreenField potete confrontare la mia guida Configurare i Remote Desktop Services in Azure Windows Virtual Desktop.

In questa guida mi occuperò della soluzione BrownField, evidenziando la possibilità di migrare le macchine RD Session Host esistenti direttamente nell’infrastruttura di Windows Virtual Desktop.

È infatti possibile utilizzare Azure Migrate, di cui avevo già trattato nella guida Migrazione delle macchine virtuali VMware verso Microsoft Azure con l’utilizzo di Azure Migrate – ICT Power, per migrare anche l’infrastruttura VDI o RDS.

Figura 2: Utilizzo di Azure Migrate per la migrazione dell’infrastruttura VDI o RDS

Architettura proposta

La soluzione proposta è quella di portare tutte le VM o le macchine fisiche in Azure, compresi i Domain Controller. In alternativa si potrebbe anche pensare ad una soluzione ibrida in cui parte del workload rimane ancora on-premises, come ad esempio i domain controller, e grazie ad una connessione VPN Site-To-Site con Azure oppure con ExpressRoute la nostra rete aziendale diventa un tutt’uno con il Cloud. Alla fine è come se considerassimo il Cloud una nostra sede remota.

Figura 3: Architettura proposta: Migrazione del workload RDS su Azure

Processo di migrazione

Il processo di migrazione si articola in diverse fasi:

1. Verifica di tutti i prerequisiti necessari per poter migrare l’ambiente esistente. In particolar modo è necessario avere:
   1. Una sottoscrizione di Azure con un credito sufficiente (necessario per ospitare le risorse).
   2. Assicurarsi che la rete virtuale in Azure (VNET) sia configurata in modo tale che le nuove macchine virtuali possano contattare il controller  di dominio o i servizi di dominio di Azure AD (Azure AD Domain Services).
   3. Assicurarsi che tutte le risorse di Azure si trovino nella stessa regione di Azure.
   4. Verificare che i servizi di dominio, Active Directory o Azure Active Directory Domain Services, siano sincronizzati con Azure Active Directory (Azure AD). Verificare che il servizio del dominio sia accessibile dalla sottoscrizione di Azure e dalla rete virtuale da connettere in cui verrà distribuito Windows Virtual Desktop.
   5. Avere uno storage account dove poter replicare le VM.
2. Configurare un progetto di migrazione con Azure Migrate.
3. Valutare l’ambiente RDS corrente.
4. Effettuare un assessment per capire quante risorse utilizza l’infrastruttura RDS e come viene utilizzata dagli utenti.
5. Replicare le macchine RDS locali in Azure.
6. Testare che la replica sia avvenuta in maniera corretta.
7. Completare la migrazione.

Figura 4: Processo di migrazione di un’infrastruttura VDI/RDS a Windows Virtual Desktop

Figura 5: Checklist per la migrazione a Windows Virtual Desktop

Gestione degli utenti

Uno dei prerequisiti più importanti è che i servizi di dominio, Active Directory o Azure Active Directory Domain Services, siano sincronizzati con Azure Active Directory (Azure AD). Nel mio caso ho sincronizzato la mia Active Directory locale con Azure Active Directory (Azure AD) utilizzando il tool Azure AD Connect.

Figura 6: Sincronizzazione della Active Directory locale con Azure AD utilizzando il tool Azure AD Connect

Figura 7: Utenti sincronizzati con Azure AD

Creazione di un nuovo progetto di Azure Migrate

Azure Migrate è un tool gratuito che permette di individuare le risorse nel datacenter, effettuare l’analisi dell’idoneità delle macchine per la migrazione verso il Azure, stima dei costi e visualizzazione delle dipendenze delle app, nel caso in cui abbiate delle applicazioni multi-tier. Gli strumenti a disposizione permettono di velocizzare il trasferimento rapido in modalità lift-and-shift e hanno l’obiettivo di farvi risparmiare, suggerendovi le dimensioni ottimali per le vostre risorse cloud.

Dal portale di Azure cercate la funzionalità Azure Migrate e, come si può vedere dalle figure sotto, noterete che è disponibile il nodo VDI,  che è l’opzione per la valutazione e la migrazione dei server RDS oppure delle macchine Windows Client.

Figura 8: Scheda Overview di Azure Migrate

Figura 9: Opzione VDI in Azure Migrate

Cliccate su Create project e inserite le informazioni richieste, facendo attenzione a scegliere di voler tenere i dati di progetto in Europa. Impostate la sottoscrizione, il gruppo di risorse, il nome del progetto e la geografia per i dati del progetto di migrazione. Qui verranno messi solo i vostri dati di progetto; successivamente potrete decidere dove mettere le macchine da replicare e da migrare.

Figura 10: Creazione del progetto di migrazione

Microsoft si avvale della collaborazione del partner Lakeside per effettuare un assessment completo dell’infrastruttura esistente on-premises. Durante il processo di assessment vengono collezionate molte informazioni relative al vostro ambiente, che vi potranno aiutare successivamente a scegliere le risorse (e quindi gestire i costi) della vostra infrastruttura di Windows Virtual Desktop. Vi invito a dare un’occhiata alla sessione di Ignite Accelerate your RDS and VDI migration to Windows Virtual Desktop dove è stata presentata la soluzione, per avere un’idea delle potenzialità del prodotto.

Figura 11: Lakeside assessment integration

Se volete utilizzare Lakeside Assessment Tool è necessario prima registrarsi. Nelle schermate sotto sono mostrati tutti i passaggi, che non necessitano di spiegazioni.

Figura 12: Registrazione del Lakeside Assessment Tool con Azure Migrate

Figura 13: Creazione di una nuova utenza in Lakeside

Figura 14: Autenticazione con le proprie credenziali di Azure AD

Figura 15: Richiesta di autorizzazione da parte di Lakeside ad utilizzare la vostra utenza di Azure AD

Figura 16: Conferma dell’utenza scelta

Figura 17: Completamento informazioni di registrazione a Lakeside

Al termine del processo di registrazione vi apparirà un messaggio che vi avviserà che la vostra richiesta di integrazione è stata presa in carico e che un amministratore di Lakeside dovrà approvarla.

Figura 18: Un amministratore di Lakeside dovrà approvare la vostra richiesta

Se la registrazione sarà stata accettata vi basterà collegarvi al tool direttamente da Azure Migrate, potrete creare un nuovo tenant e iniziare a valutare l’ambiente RDS locale. Scaricando il client sarà possibile iniziare a distribuirlo nella propria infrastruttura ed iniziare a collezionare i dati.

Figura 19: Dashboard di Lakeside Assessment tool – Credits: Microsoft

Una volta acquisita una quantità di dati adeguata, esaminate i dati per determinare il percorso di migrazione migliore. I dati raccolti sono:

• Numero di utenti
• Applicazioni utilizzate dagli utenti.
• Consumo di risorse per utente.
• Media di utilizzo delle risorse da persona utente.
• Dati sulle prestazioni del server RDS.
• Report utenti simultanei.
• Principali pacchetti software in uso.

Nel mio ambiente di test non ho effettuato nessun assessment, ma il risultato finale, dopo aver utilizzato il tool SysTrack di Lakeside sarà simile a quello mostrato nella figura sotto:

Figura 20: Report di Systrack di Lakeside – Credits: Microsoft

Migrazione degli RD Session Host esistenti

Come già detto prima, in questa guida mi occuperò di affrontare lo scenario BrownField e di riutilizzare gli RD Session Host disponibili in azienda perpoter creare un template con cui creare la mia soluzione di Windows Virtual Desktop. Per iniziare la migrazione delle macchine (lift-and-shift), da Azure Migrate, nel nodo VDI, cliccate su Discover e iniziate la procedura per trovare le macchine on-premises da migrare. Il wizard vi guiderà con la richiesta del tipo di virtualizzazione utilizzate in casa e della Region di destinazione delle VM. Io ho utilizzato delle macchine ospitate in Hyper-V.

Figura 21: Inizio del Discover delle VM presenti on-premises

Figura 22: Scelta del tipo di virtualizzatore utilizzato on-premises

NOTA: La procedura mostrata di seguito è valida se utilizzate Hyper-V on-premises. Nel caso utilizziate VMware, abbiate macchine fisiche o dobbiate migrare da AWS o GCP la procedura sarà diversa.

A questo punto verrà creato una Azure Recovery Services Vault all’interno del quale verranno replicate le vostre VM. Scaricate il client di Azure Site Recovery e della chiave per la sua successiva attivazione.

Figura 23: Download del client di replica di Azure Site Recovery

Terminato il download del client, provvedete alla sua installazione, come mostrato nelle figure sotto:

Figura 24: Azure Site Recovery Setup Provider per Hyper-V

Figura 25: Cartella di installazione di Azure Site Recovery Setup Provider per Hyper-V

A questo punto del wizard dovete utilizzare il file con le chiavi di accesso al vostro Azure Site Recovery Vault, che avete scaricato precedentemente dal portale di Azure Migrate.

Figura 26: Inserimento delle credenziali per l’accesso ad Azure Site Recovery Vault

Figura 27: Installazione del Azure Site Recovery Setup Provider per Hyper-V completata

Il passaggio successivo consiste nel terminare la procedura di aggiunta del vostro server on-premises. Cliccate su Finalize registration e attendete qualche minuto per il completamento della procedura.

Figura 28: Finalizzazione della procedura di registrazione dei server on-premises

Figura 29: La procedura di finalizzazione richiede qualche minuto

Figura 30: Finalizzazione della procedura di registrazione dei server on-premises completata

Nel giro di qualche minuto verrà effettuato il Discover dell’infrastruttura on-premises e sarete pronti per migrare le vostre VM.

NOTA: Assicuratevi di aver già creato una VNET ed uno Storage Account dove mettere la replica delle VM. Il wizard di replica, infatti, non vi permetterà di crearli al momento. Le due risorse devono essere già esistenti.

Cliccate sul pulsante Replicate per iniziare la procedura di replica delle VM.

Figura 31: Inizio della procedura di replica delle VM

Figura 32: Scelta del tipo di virtualizzatore utilizzato on-premises

Nella schermata successiva decidete quali VM volete portare nel Cloud. L’obiettivo di questa guida è quello di poter riutilizzare l’RD Session Host che abbiamo on-premises come macchina di partenza per la creazione dei Session Host da utilizzare per il nostro pool di Windows Virtual Desktop. Quindi mi basta selezionare solo UN RD Session Host.

NOTA: Scegliete quali macchine portare in cloud secondo le vostre necessità. Se avete una connessione VPN Site-To-Site oppure una ExpressRoute con Azure potete lasciare ancora parte delle macchine on-premises. Se volete migrare completamente la vostra infrastruttura allora potete decidere di portare i domain controller, i file server, ecc.

Figura 33: Scelta delle VM da replicare in Azure

Figura 34: Inserimento delle informazioni relative alla sottoscrizione, al resource group, alla VNET e allo storage account dove mettere le VM

Decidete quale dimensione deve avere la VM oppure lasciate decidere ad Azure Migrate, secondo le informazioni che avrà raccolto. Scegliete anche il tipo di sistema operativo che è installato nella VM.

Figura 35: Scelta della dimensione delle VM

Figura 36: Scelta dei dischi da replicare

Figura 37: Schermata di riepilogo ed avvio della replica delle VM

Figura 38: Stato di avanzamento della replica delle VM

Al termine della replica della VM (ci sono volute alcune ore) ho cliccato su Test migration per assicurarmi che la migrazione sia andata a buon fine. Ho scelto a quale virtual network collegare la macchina virtuale, in modo tale da potermici poi successivamente connettere e verificare che tutto funzionasse in maniera corretta.

Figura 39: Inizio del test di migrazione della VM

NOTA: la virtual network a cui collegare la VM deve essere già esistente. Vi consiglio di utilizzare una virtual network non collegata alla rete di produzione perché altrimenti vi ritroverete due host con lo stesso nome nella rete. Sarebbe anche il caso di avere nella rete di test un domain controller da poter utilizzare per le autenticazioni.

Figura 40: Scelta della virtual network a cui collegare la VM, per effettuare i test.

Figura 41: Avvio della VM per poter effettuare il test di migrazione

Noterete a questo punto che è stata creata una nuova macchina virtuale a cui vi potrete collegare per effettuare tutte le prove di funzionamento, come mostrato nella figura sotto:

Figura 42: VM di test creata

Collegatevi quindi la macchina virtuale ed effettuate tutte le prove che ritenete necessarie.

Figura 43: Collegamento alla VM per il test di migrazione

Terminati tutti i test potete quindi ritornare nel pannello di Azure Migrate e utilizzare il tasto Clean up test migration per completare la procedura di test e per distruggere la macchina di testa che era stata creata.

Figura 44: Completamento del test di migrazione e pulizia delle risorse di test create

Figura 45: Conferma della pulizia delle risorse di test

Migrazione della VM

Terminati tutti i test sarà possibile migrare la macchina virtuale utilizzando il tasto Migrate. Partirà una procedura che vi guiderà nell’operazione di lift-and-shift e di accensione della macchina in Azure. Come si può vedere dalle figure sotto l’operazione è molto semplice e non necessita di spiegazioni.

Figura 46: Migrazione della VM per l’accensione nel Cloud

Figura 47: Conferma della migrazione

Figura 48: Avvio della migrazione

L’operazione di accensione della macchina in Azure (Planned failover) dura veramente pochissimi minuti.

Figura 49: L’operazione di planned failover viene completata in pochissimi minuti

A questo punto è possibile interrompere la replica e completare la migrazione. Verrà fermata la macchina on-premises e verrà anche interrotta la replica con la macchina accesa in Azure. Dal pannello di Azure Migrate fate clic su Stop replication.

Figura 50: interruzione della replica tra la VM on-premises e quella migrata in Azure

Figura 51: Conferma dell’interruzione della replica

Figura 52: L’operazione dura qualche minuto

Adesso la vostra macchina è stata completamente migrata in Azure, ma sarà ancora capace di parlare con l’infrastruttura on-premises grazie al collegamento tra la virtual network e la vostra azienda, realizzato con una VPN Site-to-Site oppure con ExpressRoute.

Figura 53: La VM è operativa ed è perfettamente funzionante

Cattura dell’immagine della VM da utilizzare come template per la creazione dei Session Host di Windows Virtual Desktop

Scopo di questa guida è quello di poter utilizzare uno degli RD Session Host come immagine di partenza per la creazione del nostro pool di Windows Virtual Desktop. Prima di utilizzare il session host migrato è necessario però generalizzare l’immagine con il tool sysprep e successivamente spegnerla, in modo tale che possa essere catturata e riutilizzata come immagine. Collegatevi quindi alla macchina accesa in Azure e lanciate il tool Sysprep.exe con l’opzione di Shutdown.

Figura 54: Utilizzo del tool Sysprep per la generalizzazione dell’immagine

Nel giro di pochi istanti la macchina verrà generalizzata e spenta, pronta per poter essere trasformata in una Immagine.

Cliccate sul tasto Capture per trasformare la vostra macchina virtuale migrata in un’immagine da poter successivamente riutilizzare.

Figura 55: Cattura dell’immagine della VM

Inserite le informazioni richieste nel wizard, scegliete in quale Resource Group mettere l’immagine e decidete se condividerla all’interno di una Shared Image Gallery oppure utilizzarla come immagine gestita. Ho già avuto modo di trattare l’argomento delle Shared Image Gallery nella guida Creazione di una Shared Image Gallery in Microsoft Azure – ICT Power

Figura 56: Cattura della VM e creazione dell’immagine

Al termine della cattura della creazione della nuova immagine la VM di partenza verrà cancellata, come si può vedere nelle notifiche mostrate nella figura sotto:

Figura 57: Cattura dell’immagine completata

Figura 58: L’immagine è presente nel Resource Group scelto

Creazione di un Windows Virtual Desktop Host Pool

Siamo quindi finalmente pronti per poter creare il nostro pool di macchine virtuali a cui poi gli utenti potranno connettersi. Dal portale di Azure cerchiamo la voce Windows Virtual Desktop e clicchiamo sul pulsante Create a host pool.

Figura 59: creazione di un Windows Virtual Desktop Host pool

Nella scheda Basic inserite tutte le informazioni richieste e scegliete il tipo di host pool da creare. Poiché noi vogliamo creare un pool di Session Host scegliete come tipo Pooled e decidete il numero massimo di sessioni che potrà accettare. È possibile definire anche il metodo di bilanciamento del carico sui vari Session Host ed è possibile scegliete tra due modalità:

• Breadth-first: questa modalità (che è quella impostata di default) esegue prima una query sugli host e seleziona quindi il Session Host con il minor numero di sessioni;
• Depth-first: i nuovi utenti vengono assegnati al primo host disponibile una volta che quello precedente ha superato il numero massimo di sessioni;

Figura 60: Configurazioni di base per il Windows Virtual Desktop Host Pool

Nella scheda Virtual Machines scegliete il prefisso che verrà assegnato alle VM che verranno create e l’immagine da utilizzare. Ovviamente utilizzate l’immagine che avete generato dal vostro Session Host migrato, come mostrato nella figura sotto. In Number of VMs specificare il numero di macchine virtuali (al massimo 400) che si vuole creare per il pool di host.

Figura 61: Scelta dell’immagine da utilizzare per la creazione dei Session Host

Scegliete a quale virtual network connettere l’host pool, assicurandovi che la rete virtuale possa connettersi al domain controller, poiché sarà necessario joinare le macchine virtuali al dominio aziendale. I server DNS della rete virtuale selezionata devono essere quindi configurati per l’uso degli indirizzi IP dei controller di dominio.

Se volete permettere l’accesso da Internet potete dare un IP pubblico alle VM. Vi consiglio di selezionare No, perché un IP privato è più sicuro. Gli utenti, infatti, si potranno collegare anche da Internet attraverso il client di Windows Virtual Desktop anche se non assegnare un indirizzo IP pubblico alle macchine che compongono l’Host Pool.

Specificate il dominio della vostra infrastruttura a cui devono essere aggiunte le VM che saranno create e inserite le credenziali corrette per effettuare il join.

Figura 62: Completamento delle informazioni richieste per la creazione dell’Host Pool

Nella schermata Workspace è possibile registrare un gruppo di applicazioni che saranno poi utilizzate dai nostri utenti. Scegliere quindi se volete creare una nuova area di lavoro o selezionare un’area di lavoro esistente.

Figura 63: Creazione del Workspace

Figura 64: Verifica delle informazioni inserite

Dopo aver fatto clic su Create verrà lanciato il processo di distribuzione, che creerà:

• Un nuovo pool di host.
• Un gruppo di app desktop.
• Un’area di lavoro, se si è scelto di crearla.
• Se si sceglie di registrare il gruppo di app desktop, la registrazione verrà completata.
• Le macchine virtuali, che verranno aggiunte al dominio e registrate con il nuovo pool di host.
• Un collegamento di download per un template di Azure Resource Manager in base alla configurazione che avete scelto.

Figura 65: Creazione del nuovo Windows Virtual Desktop Host Pool

Nella schermata sotto è possibile verificare tutte le risorse di Azure che sono state create:

Figura 66: Risorse di Azure che sono state create

Connessione a Windows Virtual Desktop

Prima che i vostri utenti possano connettersi a Windows Virtual Desktop è necessario assegnare gli utenti al Desktop Application Group (DAG) che è stato creato attraverso l’HostPool wizard. Il nome è in genere <HostPoolname>-DAG. Selezionate il Desktop Application Group dal pannello di Azure e nel nodo Assignment procedete ad aggiungere gli utenti , o meglio ancora i gruppi, che potranno accedere alle applicazioni offerta dal Windows Virtual Desktop Host Pool.

Figura 67: Aggiunta di utenti e gruppi che potranno acceder al Desktop Application Group

Figura 68. Utenti aggiunti al Desktop Application Group

Connessione al Windows Virtual Desktop Host Pool

Per poter accedere a Windows Virtual Desktop è possibile utilizzare il client web HTML 5 disponibile all’indirizzo https://rdweb.wvd.microsoft.com/arm/webclient oppure è possibile utilizzare i client Windows dedicati, che potete trovare alla pagina Connettersi a desktop virtuale Windows 10 o 7-Azure | Microsoft Docs. Potete installare il client per l’utente corrente, nel qual caso non sono richiesti diritti di amministratore, oppure l’amministratore può installare e configurare il client in modo che tutti gli utenti del dispositivo possano accedervi. Dopo l’installazione, il client può essere avviato dal menu Start cercando Desktop remoto.

Nel mio caso ho utilizzato il client web e dopo l’autenticazione mi sono collegato al WorkSpace che avevo creato durante il wizard. L’unica applicazione disponibile è quella che permette di collegarsi alla sessione desktop remota. In alternativa potete pubblicare le applicazioni e utilizzare le RemoteApp.

Figura 69: Connessione a Windows Virtual Desktop effettuata

Inserite le credenziali per poter accedere al desktop remoto e sarete pronti per cominciare a lavorare!

Figura 70: Inserimento delle credenziali per poter accedere al desktop remoto

Figura 71: Richiesta di consentire l’accesso alle stampanti locali e ai dischi del dispositivo da cui si sta effettuando la connessione

Quando la connessione verrà instaurata, potrete lavorare col vostro Desktop remoto e potrete accedere a tutte le risorse, anche a quelle on-premises grazie alle connessioni VPN Site-To-Site oppure grazie ad ExpressRoute. Nella figura sotto l’utente ha l’accesso al file server aziendale.

Figura 72: Connessione effettuata ed utilizzo delle risorse di rete aziendali

Conclusioni

Windows Virtual Desktop consente di lavorare in maniera remota e sicura e permette di sfruttare la scalabilità del Cloud per semplificare la distribuzione e la gestione dell’infrastruttura. La migrazione delle risorse esistenti on-premises è molto semplificata grazie ad Azure Migrate e la migrazione dell’infrastruttura esistente può essere effettuata con pochi passaggi ed in brevissimo tempo.

L'articolo Migrare Remote Desktop Services ad Azure Windows Virtual Desktop proviene da ICT Power.

Windows Virtual Desktop è un servizio di virtualizzazione per desktop e app eseguito sul cloud. È possibile connettersi da qualsiasi dispositivo tramite un’applicazione nativa oppure tramite il client Web HTML5 di Windows Virtual Desktop.

Sicuramente negli ultimi mesi questo tipo di soluzione ha avvantaggiato parecchio il lavoro remoto sicuro e molte aziende lo stanno utilizzando per ospitare macchine Windows 10, usando le licenze esistenti per ridurre i costi con un’infrastruttura VDI (Virtual Desktop Infrastructure) moderna basata sul cloud e pagando solo per le risorse usate. Grazie alla multisessione di Windows 10, è possibile eseguire facilmente più sessioni interattive simultanee degli utenti con la stessa distribuzione, per incrementare l’efficienza dei costi, e l’offerta di Microsoft 365 completa l’approccio al Modern Desktop: sicuro, flessibile ed efficiente.

Tantissime aziende utilizzano i Remote Desktop Services, ma molte si stanno avvicinando alla soluzione Windows Virtual Desktop per ottimizzare efficienza e costi di gestione e oggi voglio proporvi proprio questo tipo di migrazione, cioè il passaggio dall’on-premises al cloud delle soluzioni Remote Desktop Services (RDS).

Figura 1: Architettura di Windows Virtual Desktop

L’approccio alla migrazione di Remote Desktop Services (RDS) verso Azure Windows Virtual Desktop potrebbe essere di due tipi:

1. GreenField: In Informatica si riferisce all’approccio tale per cui è preferibile creare una soluzione parallela a quella già esistente, completamente nuova;
2. BrownField: È invece riferito alla creazione del nuovo sistema in coesistenza con quello già esistente e ne possa permettere successivamente la migrazione.

In questa guida mi occuperò della soluzione GreenField e creerò delle macchine virtuali che ospiteranno i servizi RDS direttamente in Azure, ma allo stesso tempo integrate con l’infrastruttura aziendale e aggiunte alla nostra directory locale.

Se invece siete interessati alla soluzione BrownField e volete migrare le macchine RD Session Host esistenti direttamente nell’infrastruttura di Windows Virtual Desktop, allora potete leggere la mia guida Migrare Remote Desktop Services ad Azure Windows Virtual Desktop – ICT Power

Requisiti

Per configurare Windows Virtual Desktop e collegare correttamente gli utenti ai relativi desktop e applicazioni Windows sono necessari alcuni requisiti:

• Un’istanza di Azure Active Directory.
• Un’istanza di Windows Server Active Directory sincronizzata con Azure Active Directory. È possibile eseguirne la configurazione con Azure AD Connect (per organizzazioni ibride) o Azure AD Domain Services (per organizzazioni ibride o cloud).
• Una sottoscrizione di Azure, associata allo stesso tenant di Azure AD padre, che contiene una rete virtuale contenente l’istanza di Windows Server Active Directory o Azure AD DS o connessa a tale istanza.
• L’utente deve essere originato dalla stessa istanza di Active Directory che è connessa ad Azure AD. Desktop virtuale Windows non supporta account del servizio gestito o B2B.

Licenze

È possibile accedere ai desktop e alle app di Windows 10 Enterprise e Windows 7 Enterprise senza costi aggiuntivi se avete una licenza per utente Windows o Microsoft 365 idonea:

• Microsoft 365 E3/E5
• Microsoft 365 A3/A5/Student Use Benefits
• Microsoft 365 F3
• Microsoft 365 Business Premium**
• Windows 10 Enterprise E3/E5
• Windows 10 Education A3/A5
• Windows 10 VDA per utente

È possibile accedere ai desktop e app con tecnologia Remote Desktop Services di Windows Server senza costi aggiuntivi se sei un cliente idoneo con licenza CAL per Servizi Desktop remoto Microsoft:

• Licenza CAL Servizi Desktop remoto con Software Assurance per Windows Server 2012 R2, 2016, 2019

Maggiori informazioni sul pricing sono disponibili al link Prezzi di Desktop virtuale Windows | Microsoft Azure

Gestione degli utenti

Uno dei prerequisiti più importanti è che i servizi di dominio, Active Directory o Azure Active Directory Domain Services, siano sincronizzati con Azure Active Directory (Azure AD). Nel mio caso ho sincronizzato la mia Active Directory locale con Azure Active Directory (Azure AD) utilizzando il tool Azure AD Connect.

Figura 2: Sincronizzazione della Active Directory locale con Azure AD utilizzando il tool Azure AD Connect

Figura 3: Utenti sincronizzati con Azure AD

Creazione di un Windows Virtual Desktop Host Pool

Per creare un Windows Virtual Desktop Host Pool dal portale di Azure cercate la voce Windows Virtual Desktop e cliccate sul pulsante Create a host pool.

Figura 4: Creazione di un Windows Virtual Desktop Host pool

Nella scheda Basic inserite tutte le informazioni richieste e scegliete il tipo di host pool da creare. Poiché noi vogliamo creare un pool di Session Host scegliete come tipo Pooled e decidete il numero massimo di sessioni che potrà accettare. È possibile definire anche il metodo di bilanciamento del carico sui vari Session Host ed è possibile scegliete tra due modalità:

• Breadth-first: questa modalità (che è quella impostata di default) esegue prima una query sugli host e seleziona quindi il Session Host con il minor numero di sessioni;
• Depth-first: i nuovi utenti vengono assegnati al primo host disponibile una volta che quello precedente ha superato il numero massimo di sessioni;

Figura 5: Configurazioni di base per il Windows Virtual Desktop Host Pool

Nella scheda Virtual Machines scegliete il prefisso che verrà assegnato alle VM che verranno create e l’immagine da utilizzare.

Scelta del tipo di immagine da utilizzare: Potete scegliere un’immagine dal Marketplace di Azure tra quelle disponibili oppure potete utilizzare una vostra immagine precedentemente realizzata. Vi rimando alla lettura dell’articolo Preparare e personalizzare un’immagine del disco rigido virtuale Master-Azure | Microsoft Docs per le istruzioni corrette su come realizzare un’immagine specifica per Windows Virtual Desktop.

In Number of VMs specificare il numero di macchine virtuali (al massimo 400) che si vuole creare per il pool di host.

Figura 6: Scelta dell’immagine da utilizzare per la creazione dei Session Host

Scegliete a quale virtual network connettere l’host pool, assicurandovi che la rete virtuale possa connettersi al domain controller, poiché sarà necessario joinare le macchine virtuali al dominio aziendale. I server DNS della rete virtuale selezionata devono essere quindi configurati per l’uso degli indirizzi IP dei controller di dominio.

Se volete permettere l’accesso da Internet potete dare un IP pubblico alle VM. Vi consiglio di selezionare No, perché un IP privato è più sicuro. Gli utenti, infatti, si potranno collegare anche da Internet attraverso il client di Windows Virtual Desktop anche se non assegnare un indirizzo IP pubblico alle macchine che compongono l’Host Pool.

Specificate il dominio della vostra infrastruttura a cui devono essere aggiunte le VM che saranno create e inserite le credenziali corrette per effettuare il join.

Figura 7: Completamento delle informazioni richieste per la creazione dell’Host Pool

Nella schermata Workspace è possibile registrare un gruppo di applicazioni che saranno poi utilizzate dai nostri utenti. Scegliere quindi se volete creare una nuova area di lavoro o selezionare un’area di lavoro esistente.

Figura 8: Creazione del Workspace

Figura 9: Verifica delle informazioni inserite

Dopo aver fatto clic su Create verrà lanciato il processo di distribuzione, che creerà:

• Un nuovo pool di host.
• Un gruppo di app desktop.
• Un’area di lavoro, se si è scelto di crearla.
• Se si sceglie di registrare il gruppo di app desktop, la registrazione verrà completata.
• Le macchine virtuali, che verranno aggiunte al dominio e registrate con il nuovo pool di host.
• Un collegamento di download per un template di Azure Resource Manager in base alla configurazione che avete scelto.

Figura 10: Creazione del nuovo Windows Virtual Desktop Host Pool completata

Nella schermata sotto è possibile verificare tutte le risorse di Azure che sono state create:

Figura 11: Risorse di Azure che sono state create

Connessione a Windows Virtual Desktop

Prima che i vostri utenti possano connettersi a Windows Virtual Desktop è necessario assegnare gli utenti al Desktop Application Group (DAG) che è stato creato attraverso l’HostPool wizard. Il nome è in genere <HostPoolname>-DAG. Selezionate il Desktop Application Group dal pannello di Azure e nel nodo Assignment procedete ad aggiungere gli utenti, o meglio ancora i gruppi, che potranno accedere alle applicazioni offerta dal Windows Virtual Desktop Host Pool.

Figura 12: Desktop Application group creato

Figura 13: Applicazioni distribuite dal Desktop Application Group

Figura 14: Aggiunta di utenti e gruppi che potranno acceder al Desktop Application Group

Figura 15: Gruppo di utenti aggiunti al Desktop Application Group

Connessione al Windows Virtual Desktop Host Pool

Per poter accedere a Windows Virtual Desktop è possibile utilizzare il client web HTML 5 disponibile all’indirizzo https://rdweb.wvd.microsoft.com/arm/webclient oppure è possibile utilizzare i client Windows dedicati, che potete trovare alla pagina Connettersi a desktop virtuale Windows 10 o 7-Azure | Microsoft Docs. Potete installare il client per l’utente corrente, nel qual caso non sono richiesti diritti di amministratore, oppure l’amministratore può installare e configurare il client in modo che tutti gli utenti del dispositivo possano accedervi. Dopo l’installazione, il client può essere avviato dal menu Start cercando Desktop remoto.

Nel mio caso ho utilizzato il client web e dopo l’autenticazione mi sono collegato al WorkSpace che avevo creato durante il wizard. L’unica applicazione disponibile è quella che permette di collegarsi alla sessione desktop remota. In alternativa potete pubblicare le applicazioni e utilizzare le RemoteApp.

Figura 16: Connessione a Windows Virtual Desktop effettuata e richiesta di consentire l’accesso alle stampanti locali e ai dischi del dispositivo da cui si sta effettuando la connessione

Inserite le credenziali per poter accedere al desktop remoto e sarete pronti per cominciare a lavorare! Quando la connessione verrà instaurata, potrete lavorare col vostro Desktop remoto e potrete accedere a tutte le risorse, anche a quelle on-premises grazie alle connessioni VPN Site-To-Site oppure grazie ad ExpressRoute. Nella figura sotto l’utente ha l’accesso al file server aziendale.

Figura 17: Connessione a Windows Virtual Desktop effettuata

Conclusioni

Windows Virtual Desktop consente di lavorare in maniera remota e sicura e permette di sfruttare la scalabilità del Cloud per semplificare la distribuzione e la gestione dell’infrastruttura. È possibile creare un ambiente di virtualizzazione desktop completo nella sottoscrizione di Azure senza dover eseguire server gateway aggiuntivi e pubblicare tutti i pool di host necessari per gestire i diversi carichi di lavoro. Utilizzando anche la propria immagine personalizzata è possibile avere il massimo della flessibilità e della personalizzazione delle proprie applicazioni in maniera davvero rapidissima!

L'articolo Configurare i Remote Desktop Services in Azure Windows Virtual Desktop proviene da ICT Power.

Azure Migrate è un tool gratuito che permette di individuare le risorse nel datacenter, effettuare l’analisi dell’idoneità delle macchine per la migrazione verso il Azure, stima dei costi e visualizzazione delle dipendenze delle app, nel caso in cui abbiate delle applicazioni multi-tier. Gli strumenti a disposizione permettono di velocizzare il trasferimento rapido in modalità lift-and-shift e hanno l’obiettivo di farvi risparmiare, suggerendovi le dimensioni ottimali per le vostre risorse cloud.

Affrontare una migrazione verso il cloud potrebbe essere per molti una vera e propria sfida e sicuramente la valutazione dei costi è un fattore importante per molte realtà, che però possono usufruire nel cloud della sicurezza, della governance e della scalabilità delle soluzioni proposte. Senza dimenticare che l’implementazione delle best practices e dei team di supporto a nostra disposizione in Azure migliorano di molto la nostra soluzione, che potrebbe essere obsoleta, sottodimensionata, poco sicura e perché no, anche costosa nella sua attuale gestione.

Azure migrate ci aiuta nel processo di migrazione utilizzando tre fasi ben precise:

• Discovery: Il tool si occupa di trovare tutte le risorse che possono essere migrate nel cloud
• Assessment: è la fase più importante, perché ci permette di valutare se le nostre macchine possono essere migrate e ci permette di avere una stima dei costi della nostra infrastruttura ospitata in Azure
• Migration: la migrazione è enormemente semplificata e ci permette di portare le macchine nel cloud e successivamente eseguirle con pochissimi clic ed in pochissimo tempo.

Figura 1: Azure Migrate capabilities – Credits: Microsoft

Creazione del progetto di migrazione utilizzando Azure Migrate

Dal portale di Azure cercate la funzionalità Azure Migrate e nella scheda Overview vi verranno mostrati gli scenari per migrare i datacenter on-premises ad Azure.

Figura 2: Scheda Overview di Azure Migrate

Cliccando su Assess and migrate Servers verrete reindirizzati al nodo Servers, da cui potrete lanciare il wizard per creare un nuovo progetto di migrazione.

Figura 3: Opzione Servers in Azure Migrate e lancio del wizard di creazione di un nuovo progetto di migrazione

Cliccate su Create project e inserite le informazioni richieste, facendo attenzione a scegliere di voler tenere i dati di progetto in Europa. Impostate la sottoscrizione, il gruppo di risorse, il nome del progetto e la geografia per i dati del progetto di migrazione. Qui verranno messi solo i vostri dati di progetto; successivamente potrete decidere dove mettere le macchine da replicare e da migrare.

Figura 4: Creazione del progetto di migrazione

Microsoft permette di effettuare un assessment completo dell’infrastruttura esistente on-premises. Durante il processo di assessment vengono collezionate molte informazioni relative al vostro ambiente, che vi potranno aiutare successivamente a scegliere le risorse (e quindi gestire i costi) della vostra infrastruttura.

Discover

In questa prima fase abbiamo la possibilità di valutare il nostro ambiente e capire se esistono configurazioni che non sono adatte per Azure, come ad esempio la versione del sistema operativo oppure la dimensione del disco troppo grande da poter essere supportata in Azure. In più, a seconda delle problematiche riscontrate, ci verranno proposte anche delle soluzioni per poter evitare problemi con la successiva migrazione.

Fate clic su Discover nel nodo Assessment tools per iniziare il wizard, che vi assisterà nella fase di valutazione della vostra infrastruttura on-premises.

Figura 5: Inizio della fase di assessment

Nella schermata successiva vi verrà chiesto se volete fare un Discover della vostra infrastruttura utilizzando un’appliance oppure semplicemente importando un file CSV con le caratteristiche delle vostre macchine. Dopo aver scelto la modalità, scegliete in che modo le vostre macchine sono virtualizzate nel datacenter on-premises (Hyper-V oppure VMware) o se sono macchine fisiche o macchine ospitate in altri cloud pubblici, come AWS, GCP, Xen, ecc.).

Effettuate il download della Azure Migrate appliance, una VM preparata da Microsoft con all’interno tutti i tool necessari al Discover, oppure potete scaricare un file ZIP con all’interno uno script PowerShell di installazione e tutto il software necessario a poter fare l’assessment della vostra infrastruttura, da eseguire in una macchina creata da voi on-premises.

Successivamente generate una chiave che vi servirà a configurare la vostra Azure Migrate appliance e che collegherà l’appliance al vostro progetto di Azure Migrate, in cui verranno caricate tutte le informazioni recuperate dai software di analisi e discovery.

NOTA: In questa guida utilizzerò una mia infrastruttura on-premises basata su Microsoft Hyper-V

Figura 6: Download dell’appliance o dello script di configurazione di Azure Migrate

Nel caso in cui abbiate deciso di scaricare il file ZIP con lo script di installazione e i software da utilizzare in una delle vostre macchine virtuali, all’interno del file troverete i tool mostrati nella figura sotto:

Figura 7: Script di installazione di Azure Migrate

Io ho deciso di utilizzare lo script di PowerShell e ho provveduto ad installarlo in una macchina presente all’interno della mia infrastruttura, seguendo le indicazioni riportate nel portale di Azure Migrate (Windows Server 2016, 32 GB di RAM, 8 vCPU e 80 GB di spazio disco). L’installazione di tutti i componenti necessari dura pochissimi minuti.

Figura 8: Installazione dello script di Azure Migrate per la creazione dell’appliance di Assessment

Al termine dell’installazione, si aprirà l’Appliance Configuration Manager che vi permetterà, tramite una pagina web, di configurare l’appliance per poter comunicare tutti i dati relativi alle vostre macchine virtuali nel progetto di Azure Migrate. Le configurazioni richieste sono molto semplici e la pagina web è molto intuitiva.

Figura 9: Accettazione dei termini di licenza

A questo punto, dopo aver controllato i prerequisiti software necessari al funzionamento dell’appliance, è necessario registrare la Azure Migrate appliance utilizzando la chiave di progetto che avete generato prima. In questo modo l’appliance invierà i dati collezionati direttamente nel nostro progetto di Azure Migrate.

Figura 10: Controllo dei prerequisiti software richiesti dalla Azure Migrate appliance e inserimento della chiave di progetto

Cliccate quindi su Login per effettuare l’accesso a Microsoft Azure e associare l’appliance al vostro progetto di Azure Migrate.

Figura 11: Login a Microsoft Azure

Figura 12: Inserimento delle credenziali di accesso a Microsoft Azure

La procedura di registrazione dell’appliance di Azure Migrate potrebbe durare alcuni minuti. Nel mio caso sono bastati solo tre minuti, ma ce ne potrebbero volere fino a dieci.

Figura 13: Registrazione dell’appliance con il progetto di Microsoft Azure Migrate

Terminata la procedura di registrazione, fate clic su Add credentials per inserire le credenziali amministrative del vostro host o del vostro cluster Hyper-V, in modo tale che sia possibile fare il discover delle macchine virtuali.

Figura 14: Inserimento delle credenziali di accesso all’host/cluster Hyper-V

Aggiungete gli host o il cluster Hyper-V che volete utilizzare per il vostro progetto di migrazione con Azure Migrate, indicando l’indirizzo IP o l’FQDN. È anche possibile importare una lista di host utilizzando un file CSV.

Figura 15: Aggiunta degli host/cluster di Hyper-V di cui effettuare il discover e l’assessment

Terminato l’inserimento di tutte le informazioni richieste, potete procedere facendo clic su Start discovery.

Figura 16: Inizio della discovery delle VM on-premises

La discovery inizia nel giro di pochissimi minuti. Il tool si connetterà al vostro host o al vostro cluster Hyper-V e comincerà a collezionare informazioni. Potete passare nel portale di Azure per vedere i dati che sono collezionati.

Figura 17: La discovery è iniziata e i dati vengono caricati nel nostro progetto di Azure Migrate

Dal portale di Azure, nel nodo Servers di Azure Migrate, vedrete che la Discovery è in progress e nel giro di qualche minuto sarà possibile fare l’ assessment, come mostrato nelle figure sotto:

Figura 18: La discovery delle VM on-premises è in progress

Asssessment

La fase di assessment è quella più importante perché ci mostrerà se le nostre macchine possono essere migrate ad Azure e soprattutto che costi dovremo affrontare per ospitare la nostra infrastruttura nel cloud.

Dal nodo Servers di Azure Migrate, cliccate su Assess nella scheda Asessment
tools.

Figura 19: Terminata la discovery è possibile effettuare l’assessment

Partirà un wizard che vi guiderà nella creazione del report di assessment.

Figura 20: Wizard per la creazione del report di assessment

Scegliete di quale macchine volete effettuare l’ assessment, selezionando quelle che sono state trovate dalla appliance di Azure Migrate che avete installato on-premises e che ha effettuato il discovery.

Figura 21: Scelta delle macchine on-premises di cui fare l’assessment

Figura 22: Creazione dell’assessment

Nel giro di pochissimo tempo verrà creato l’ assessment e sarà possibile visualizzarne i risultati , partendo direttamente dal nodo server di Azure Migrate.

Figura 23: Assessment creato

L’assessment utilizza delle configurazioni predefinite, decidendo un quale location posizionare le macchine virtuali migrate e decidendo la dimensione delle VM in base alle informazioni raccolte dalla Azure
Migrate
appliance.

Figura 24: Scelta dell’assessment

Come si può vedere dalla figura sotto, sono state trovate diverse macchine virtuali e i costi stimati e la possibilità delle macchine di poter essere migrate ed eseguite in Azure.

Figura 25: Risultati dell’Assessment creato

Cliccando su Azure readiness potete ricevere il dettaglio per ogni singola macchina virtuale ed in più cliccando su Edit properties avete la possibilità di modificare il vostro assessment.

Figura 26: Dettaglio della Azure readiness delle VM scelte

Io ho deciso di modificare l’ assessment scegliendo una target location diversa da quella proposta, ho cambiato la dimensione delle macchine virtuali, il VM uptime ed altri parametri disponibili, come mostrato nella figura sotto:

Figura 27: Modifica dei parametri dell’assessment

Come si può vedere dalla figura sotto, i risultati dell’ assessment sono molto diversi da quelli proposti inizialmente, perché tengono conto le modifiche che ho effettuato e ricalcolano i costi considerando le nuove configurazioni che ho scelto.

Figura 28: Assessment modificato secondo i nuovi parametri inseriti

Migration

Dopo l’assessment siamo pronti per la terza fase, cioè per migrare le macchine virtuali in Azure. Dal portale di Azure, scegliete Azure Migrate scegliete il nodo Servers e cliccate su Discover nella scheda dei Migration tools. Dopo aver scelto il virtualizzatore che utiizzate on-premises e la regione dove volete migrare le macchine virtuali fate clic su Create Resources.

NOTA: La procedura mostrata di seguito è valida se utilizzate Hyper-V on-premises. Nel caso utilizziate VMware, abbiate macchine fisiche o dobbiate migrare da AWS o GCP la procedura sarà diversa.

Figura 29: Fase di Discover dei Migration Tools

Il processo di creazione delle risorse necessarie alla migrazione dura pochi minuti. Verrà creato un Azure Recovery Services Vault all’interno del quale verranno replicate le vostre VM.

Figura 30: Creazione delle risorse Azure necessarie alla migrazione

Per poter replicare le vostre macchine virtuali in Azure, sarà necessario scaricare un software da installare sull’host Hyper-V (Hyper-V Replication Provider) e sarà necessario procedere alla successiva registrazione dell’host o del cluster Hyper-V con il progetto di Azure Migrate.

Figura 31: Download del client di replica di Azure Site Recovery

Terminato il download dell’ Hyper-V Replication Provider, provvedete alla sua installazione on-premises, come mostrato nelle figure sotto:

Figura 32: Azure Site Recovery Setup Provider per Hyper-V

Figura 33: Cartella di installazione di Azure Site Recovery Setup Provider per Hyper-V

A questo punto del wizard dovete utilizzare il file con la chiave di accesso al vostro Azure Site Recovery Vault, che avete scaricato precedentemente dal portale di Azure Migrate.

Figura 34: Inserimento delle credenziali per l’accesso ad Azure Site Recovery Vault

Figura 35: Installazione del Azure Site Recovery Setup Provider per Hyper-V completata

Figura 36: Finalizzazione della procedura di registrazione dei server on-premises

La finalizzazione della procedura di registrazione degli Host Hyper-V on-premises dura un paio di minuti.

Figura 37: La procedura di finalizzazione richiede qualche minuto

Figura 38: Finalizzazione della procedura di registrazione dei server on-premises completata

Subuto dopo la registrazione dell’host on-premises, nel giro di qualche minuto verrà effettuato il Discover dell’infrastruttura on-premises e sarete pronti per migrare le vostre VM.

NOTA: Assicuratevi di aver già creato una VNET ed uno Storage Account dove mettere la replica delle VM. Il wizard di replica, infatti, non vi permetterà di crearli al momento. Le due risorse devono essere già esistenti.

Cliccate sul pulsante Replicate per iniziare la procedura di replica delle VM.

Figura 39: Inizio della procedura di replica delle VM

Figura 40: Scelta del tipo di virtualizzatore utilizzato on-premises

Nella schermata successiva decidete quali VM volete portare nel Cloud. È possibile scegliere le macchine che sono state trovate dal processo di assessment e di discovery di Azure Migrate fatto prima.

Figura 41: Selezione delle VM da migrare utilizzando il progetto di Assessment creato in precedenza

Figura 42: Scelta delle VM da replicare in Azure

Figura 43: Inserimento delle informazioni relative alla sottoscrizione, al resource group, alla VNET e allo storage account dove mettere le VM

Decidete quale dimensione deve avere ogni singola VM oppure lasciate decidere ad Azure Migrate, secondo le informazioni che avrà raccolto e secondo le indicazioni che avete dato voi se avete cambiato l’assessment come mostrato prima. Scegliete anche il tipo di sistema operativo che è installato nella VM.

Figura 44: Scelta della dimensione delle VM Scelta della dimensione delle VM

Figura 45: Scelta dei dischi da replicare

Figura 46: Schermata di riepilogo ed avvio della replica delle VM

A questo punto non vi resta che attendere la prima replica di tutte le VM scelte. Mettetevi comodi

Figura 47: Replica iniziale in Azure delle VM scelte

Al termine della replica della VM (ci sono volute alcune ore) tutte le VM riporteranno lo stato Protected.

Figura 48: Tutte le macchine sono state replicate correttamente in Azure

Per assicurarvi che la migrazione sia andata a buon fine potete effettuare un test di migrazione, che catturerà uno snapshot del disco della macchina virtuale che avete replicato e successivamente lo collegherà ad una VM di test da eseguire in Azure per le verifiche del caso. Selezionate la VM e dal simbolo con i tre puntini scegliete Test Migration. Nella schermata successiva scegliete a quale virtual network collegare la macchina virtuale, in modo tale da potermici poi successivamente connettere e verificare che tutto funzionasse in maniera corretta.

Figura 49: Inizio del test di migrazione della VM

NOTA: la virtual network a cui collegare la VM deve essere già esistente. Vi consiglio di utilizzare una virtual network non collegata alla rete di produzione perché altrimenti vi ritroverete due host con lo stesso nome nella rete.

Figura 50: Scelta della virtual network a cui collegare la VM, per effettuare i test. e inizio del test di migrazione

Figura 51: Avvio della VM per poter effettuare il test di failover

Noterete a questo punto che è stata creata una nuova macchina virtuale, con lo stesso nome della VM ma con il suffisso -test, a cui vi potrete collegare per effettuare tutte le prove di funzionamento, come mostrato nella figura sotto:

Figura 52: VM di test creata

Collegatevi quindi alla macchina virtuale in desktop remoto ed effettuate tutte le prove che ritenete necessarie per verificarne il corretto funzionamento nel cloud.

Figura 53: Collegamento alla VM per il test di migrazione

Ripetete la stessa procedura per tutte le VM, in modo tale da poter verificare se tutti software funzionano perfettamente e le VM possono scambiare dati tra di loro.

Figura 54: Avvio del Test failover per tutte le macchine da migrare

Figura 55: Tutte le macchine di test sono attive e potete procedere con le verifiche di funzionamento

Terminati tutti i test potete quindi ritornare nel pannello di Azure Migrate e utilizzare il tasto Clean up test migration per completare la procedura di test e per distruggere la macchina di test che era stata creata.

Figura 56: Completamento del test di migrazione e pulizia delle risorse di test create

Figura 57: Conferma della pulizia delle risorse di test

Migrazione delle VM

Terminati tutti i test sarà possibile migrare la macchina virtuale utilizzando il tasto Migrate. Partirà una procedura che vi guiderà nell’operazione di lift-and-shift e di accensione della macchina in Azure. Come si può vedere dalle figure sotto l’operazione è molto semplice e non necessita di spiegazioni.

Figura 58: Migrazione delle VM per l’accensione nel cloud

Figura 59: Scelta delle VM da migrare e da accendere nel cloud

Figura 60: Avvio della fase di migrazione delle VM scelte

Il Planned Failover dura veramente pochi secondi e consiste nello spegnimento della VM on-premises, della replica di tutti i dati che sono stati creati nella VM di partenza dall’ultima replica effettuata e accensione della VM in Azure.

Figura 61: L’operazione di planned failover viene completata in pochissimi minuti

Nel portale di Azure troverete le macchine migrate e potrete cominciare ad utilizzarle.

Figura 62: Le macchine migrate sono visibili nel portale di Azure

A questo punto è possibile interrompere la replica e completare la migrazione. Verrà fermata la macchina on-premises e verrà anche interrotta la replica con la macchina accesa in Azure. Dal pannello di Azure Migrate fate clic su Stop replication.

Figura 63: Interruzione della replica tra la VM on-premises e quella migrata in Azure

Figura 64: Conferma dell’interruzione della replica

Procedete alla migrazione delle restanti macchine virtuali.

Figura 65: Migrazione delle restanti VM

Figura 66: Tutte le macchine scelte sono state migrate e sono operative in Azure

A questo punto è possibile interrompere la replica delle macchine virtuali accese e completare la migrazione. Verranno fermate le macchine on-premises e verrà anche interrotta la replica con le macchine accese in Azure. Dal pannello di Azure Migrate selezionate ogni singola macchina e dal menù con i tre puntini scegliete Stop replication.

Figura 67: Interruzione della replica per ogni singola macchina migrata

L’operazione viene completata in pochi secondi.

Figura 68: Interruzione della replica per le VM migrate

Adesso le vostre macchine sono state completamente migrate in Azure, ma sarà ancora capace di parlare con l’infrastruttura on-premises grazie al collegamento tra la virtual network e la vostra azienda, realizzato con una VPN Site-to-Site oppure con ExpressRoute.

Come si può vedere dall’immagine sotto, in Hyper-V le VM migrate sono spente, mentre le altre macchine che abbiamo deciso di non migrare sono raggiungibili dal cloud, se abbiamo configurato correttamente la rete virtuale.

Figura 69: Le macchina virtuali migrate sono spente nell’infrastruttura on-premises

Conclusioni

Grazie ad Azure Migrate siamo capaci di spostare facilmente i nostri workload dall’on-premises verso Azure. Dopo una prima fate di assessment possiamo avere un’idea dei costi di esercizio e delle configurazioni migliori per l’esecuzione delle nostre VM nel cloud di Microsoft. La fase di discovery e di assessment rappresentano un punto cruciale per la scelta strategica della migrazione. Il tool poi ci permette davvero con pochi clic di portarla a compimento, nel minor tempo possibile.

L'articolo Migrazione dall’on-premises ad Azure utilizzando Azure Migrate proviene da ICT Power.

MSIX è un formato di pacchetto di app di Windows (introdotto in Windows 10 versione 1709 (10.0.16299.0)) che permette di distribuire e gestire le app in maniera moderna. Le applicazioni vengono racchiuse all’interno di un unico file e possono essere distribuite in maniera molto semplice nei sistemi operativi Windows. Trovate maggiori informazioni al link https://docs.microsoft.com/it-it/windows/msix/overview

Windows Virtual Desktop è un servizio di virtualizzazione per desktop e app eseguito sul cloud. È possibile connettersi da qualsiasi dispositivo tramite un’applicazione nativa oppure tramite il client Web HTML5 di Windows Virtual Desktop.

MSIX app attach è una nuova modlaità di distribuzione delle applicazioni alle macchine fisiche o alle macchine virtuali. C’è differenza però con le classiche applicazioni MSIX perché MSIX app attach è stata pensata ed ottimizzata appositamente per Windows Virtual Desktop.

Invece che installare le applicazioni direttamente nell’immagine delle macchine del nostro Host Pool di Windows Virtual Desktop, abbiamo la possibilità di distribuirle sotto forma di MSIX Containers (file VHD oppure VHDX), che vengono agganciati agli utenti che hanno il diritto di accdere alle app, semplificando moltissimo la fase di distribuzione ed aggiornamento delle nostre applicazioni.

IMPORTANTE: Prima di poter utilizzare la funzionalità di MSIX app attach preview è necessario registrare la propria sottoscrizione utilizzando l’apposito form. Potrebbe essere necessario attendere fino a 24 ore (nei giorni lavorativi) per l’approvazione della richiesta, senza la quale MSIX app attach non funzionerà.

Figura 1: Funzionamento di MSIX app attach – Credits: https://christiaanbrinkhoff.com/

Creazione del pacchetto MSIX – Preparazione dell’ambiente per la conversione

La preparazione dell’ambiente di conversione è un passaggio importante del processo di creazione di un pacchetto MSIX. Le raccomandazioni minime sono:

• Sistema operativo minimo Windows 10 1809
• Installazione pulita di Windows. Sul computer dove verrà effettuata la conversione non devono essere installate altre applicazioni perché lo strumento per la creazione di pacchetti MSX vedrà tutti gli elementi dell’ambiente per acquisire le attività del programma di installazione.
• L’ambiente di conversione deve corrispondere all’architettura di in cui verrà distribuita l’applicazione. Se ad esempio si intende distribuire il pacchetto MSIX in un computer x64, è necessario eseguire la conversione in un computer x64.
• È consigliato l’utilizzo di una macchina virtuale Hyper-V ed è anche disponibile un ambiente già pronto al link https://docs.microsoft.com/it-it/windows/msix/packaging-tool/quick-create-vm
• Utilizzo di una macchina virtuale offre anche la comodità di creare un checkpoint. In questo modo è possibile usare la macchina virtuale per convertire, ripristinare il checkpoint precedente e avere un computer pulito e configurato pronto per la conversione o per verificare che il pacchetto MSIX sia stato convertito correttamente.
• È anche utile sapere quali tipi di dipendenze ha l’applicazione, per capire quali devono essere eseguite con l’app e quali devono essere inserite in un pacchetto di modifica (runtime oppure plug-in)

Converitre un’applicazione utilizzando MSIX Packaging Tool

Per poter scaricare MSIX Packaging Tool è sufficiente effettuare una ricerca nel Microsoft Store. dopo aver trovato il tool procedete alla sua installazione come mostrato nelle figure sotto:

Figura 2: Ricerca dell’MSIX Packaging Tool nel Microsoft Store

Figura 3: Download e installazione dell’MSIX Packaging Tool

Figura 4: dell’MSIX Packaging Tool installato

Prima di poter procedere alla creazione di un nuovo package è necessario possedere un certificato digitale che verrà utilizzato per firmare il pacchetto MSIX. Nel caso in cui non può non possediate questo tipo di certificato è anche possibile crearlo in modalità self-signed utilizzando i comandi PowerShell mostrati sotto. Ho provveduto quindi alla creazione del certificato e alla esportazione sia della chiave privata che della chiave pubblica, che verranno successivamente utilizzate.

NOTA: È importante sottolineare che il certificato con la chiave pubblica dovrà essere presente sui client di destinazione, altrimenti l’installazione del pacchetto MSIX fallirà.

$certificate = New-SelfSignedCertificate -DNSName "Example Self-Signed Code Signing for Nicola Ferrini" -CertStoreLocation Cert:\CurrentUser\My -Type CodeSigningCert -Subject “Example Code Signing”

$SecurePassword = Read-Host -Prompt "Enter password for the .PFX file" -AsSecureString

Export-PfxCertificate -Cert "Cert:\CurrentUser\My\$($certificate.Thumbprint)" -FilePath "codesigning.pfx" -Password $SecurePassword

Export-Certificate -Cert "Cert:\CurrentUser\My\$($certificate.Thumbprint)" -FilePath "codesigning.cer"

Figura 5: Creazione del certificato self-signed per la firma del pacchetto MSIX

Figura 6: verifica della creazione del certificato self-signed

A questo punto possiamo procedere alla creazione di un nuovo package utilizzando MSIX Package Tool. Fate click sulla prima icona per far partire il wizard di creazione del package.

Figura 7: Lancio del wizard per la creazione di un nuovo package MSIX

Figura 8: Scelta della modalitò della creazione del wizard

È anche possibile utilizzare una macchina virtuale per creare i pacchetti MSIX, usando la funzionalità Creazione rapida di Hyper-V, disponibile a partire da Windows 10, versione 1709. L’ambiente MSIX Packaging Tool è una versione di valutazione personalizzata di Windows 10 (versione 1909) che include la versione più recente dello strumento per la creazione di pacchetti MSIX e altri prerequisiti che consentono di iniziare rapidamente a usare le attività di configurazione.

Figura 9: Utilizzo di una macchina virtuale dedicata per la creazione del pacchetto MSIX

Attendete l’installazione del MSIX Packaging tool driver e cliccate nella casella di controllo per disabilitare Windows Search. Fate click su Next per proseguire. Nel caso il tool vi chieda di riavviare , premete Cancel , effettuato il riavvio e ripetete il processo per la creazione di nuovo package subito dopo il reboot.

Figura 10: Installazione dell’ MSIX Packaging tool driver

Selezionate quindi l’installer del software di cui volete creare il package. In questo esempio ho deciso di distribuire Notepad++ ed ho provveduto a scegliere il file .PFX del certificato da utilizzare per la firma del pacchetto, che avevo creato pocanzi utilizzando PowerShell. Fate click su Next per proseguire nel wizard.

Figura 11: Scelta del pacchetto e del certificato di utilizzare per firmarlo

Inserite a questo punto le informazioni richieste dal wizard e decidete in quale cartella dovrà essere salvato il file .MSIX che verrà creato. Una volta che avrete cliccato su Next comincerà l’installazione del vostro software e non potrete tornare alla schermata precedente.

Figura 12: Inserimento delle informazioni del package

Procedete quindi all’installazione del software e alla successiva esecuzione (primo avvio). Personalizzate il software a vostro piacimento . Ricordatevi che qualsiasi operazione che farete verrà registrata dall’MSIX Packaging Tool. Se l’applicazione prevede componenti aggiuntivi o prerequisiti, installate tutto ciò che viene richiesto per la sua corretta esecuzione.

Figura 13: Avvio dell’installazione dell’applicazione da trasformare in package

NOTA: Ricordatevi di disabilitare gli aggiornamenti automatici dell’applicazione, perché gli MSIX app attach containers sono in sola lettura.

Avviate l’applicazione per verificare che tutto sia stato installato correttamente.

Figura 14: Esecuzione dell’applicazione ed eventuali personalizzazioni

Dopo aver completato l’installazione e la personalizzazione dell’applicazione è possibile chiuderla e proseguire con il wizard di creazione del nuovo package. Fate click su Next per proseguire.

Figura 15: Installazione dell’applicazione completata

L’MSIX Packaging Tool mostrerà tutte le applicazioni e gli entry point che è riuscito a catturare durante l’installazione. In questo caso viene mostrata l’applicazione in maniera corretta . Fate click su Next per continuare.

Figura 16: applicazioni registrate dall’MSIX Packaging Tool

Un prompt vi chiederà conferma dell’ avvenuta installazione e configurazione di tutte le applicazioni. Fate click su Yes, Move on.

NOTA: Se volete inserire nello stesso pacchetto MSIX altre applicazioni oppure un plug-in, cliccate su No, I’m not done e procedete con il wizard per l’installazione dei componenti aggiuntivi.

Figura 17:Prompt di conferma prima di proseguire con il wizard

Nella schermata successiva verranno mostrati eventuali servizi che sono stati installati dall’ applicazione. La possibilità di creare pacchetti di servizi in MSIX è stata introdotta in Windows 10 Client 2004 (10.0.19041.0). In questo caso non sono stati installati servizi. Fate click su Next per continuare.

Figura 18: Eventuali servizi installati dall’applicazione

Scegliete quindi la cartella di installazione e il nome del file .MSIX che volete creare. Fate click su Create per la creazione del package.

Figura 19: Scelta del percorso di installazione e del nome del file .MSIX

Dopo pochi secondi, il pacchetto sarà stato creato ed un messaggio vi avviserà dell’ avvenuta creazione.

Figura 20: Creazione del package completata con successo

Figura 21: File .MSIX creato dal Packaging Tool

Distribuzione del certificato self-signed

Poiché per firmare digitalmente il nostro pacchetto MSIX abbiamo utilizzato un certificato self-signed sarà prima necessario distribuire il certificato sulle nostre macchine client. Per farlo potete servirvi di una Group Policy, mettendo la chiave pubblica del certificato nel repository Trusted People delle macchine Session Host. Nelle figure sotto sono mostrati i diversi passaggi:

Figura 22: Distribuzione del certificato self-signed utilizzato per firmate il pacchetto MSIX utilizzando una GPO

Figura 23: Il certificato deve essere messo nel repository Trusted People

Preparazione di un package MSIX da utilizzare con Windows Virtual Desktop

Poiché MSIX app attach (preview) è una soluzione che permette di collegare dinamicamente le applicazioni da un pacchetto MSIX ad una sessione utente, è necessario che i pacchetti MSIX siano espansi in un VHD o VHDX (MSIX Image) per funzionare correttamente. La prima operazione necessaria da fare è creare un VHD o VHDx, montarlo nel sistema operativo, formattarlo e creare una cartella nel VHD montato. La creazione della cartella è obbligatoria e può avere qualsiasi nome. Trovate tutti i riferimenti alla pagina Windows Virtual Desktop prepare MSIX app attach image preview – Azure | Microsoft Docs

Io ho utilizzato una macchina Windows 10, versione 2004, in cui ho abilitato Hyper-V con il comando:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

Microsoft Hyper-V deve essere abilitato perché servono le cmdlet Mount-VHD e Dismount-VHD

Qui di seguito lo script che ho utilizzato io per creare il VHD e la cartella al suo interno:

New-VHD -SizeBytes 200MB -Path c:\temp\notepadplusplus.vhd -Dynamic -Confirm:$false

#Montaggio del file VHD
$vhdObject = Mount-VHD c:\temp\notepadplusplus.vhd -Passthru

#Inizializzazione del disco
$disk = Initialize-Disk -Passthru -Number $vhdObject.Number

#CReazione di una partizione
$partition = New-Partition -AssignDriveLetter -UseMaximumSize -DiskNumber $disk.Number

#Formattazione della partizione
Format-Volume -FileSystem NTFS -Confirm:$false -DriveLetter $partition.DriveLetter -Force

#Creazione di una cartella all'interno della partizione (obbligatorio)
New-Item -Path 'E:\Notepad++' -ItemType Directory

Figura 24: Esecuzione dello script per la creazione del VHD Package per MSIX

Terminata la creazione del VHD è necessario espandere i pacchetti MSIX all’interno del VHD (è possibile mettere più pacchetti nello stesso file VHD). Per farlo ci serviremo del tool MSIXMGR, che trovate al link Download the msixmgr tool. Estraete il tool in una cartella e da un prompt dei comandi, eseguito con privilegi elevati, lanciate il comando

msixmgr.exe -Unpack -packagePath <package>.msix -destination "f:\<name of folder you created earlier>" -applyacls

Nel mio caso i comandi che ho utilizzato sono:

cd C:\Users\administrator\Downloads\msixmgr\x64
msixmgr.exe -Unpack -packagePath "C:\msix\install\NotepadPlusPlus.msix" -destination "E:\Notepad++" -applyacls

NOTA: Effettuate la stessa operazione per tutti i pacchetti MSIX che volete aggiungere allo stesso VHD

Figura 25: Espansione del pacchetto MSIX nel VHD package

Copiate il nome del package perché ci servirà più tardi per effettuare dei test. Nel mio caso il nome è NotepadPlusPlus_1.0.0.0_x64__t0nrdm30b1zn4

Procuratevi anche il GUID del VHD Package perché ci servirà per l’esecuzione dei prossimi script di test. Per recuperare il GUID aprite un prompt dei comandi con privilegi elevati e lanciate il comando Mountvol. Nel mio caso il GUID è ade3aee5-7853-477f-9e84-71bc3b64b432

Figura 26: Recupero del GUID del VHD package

Procedete quindi ad effettuare l’unmount del VHD Package (MSIX Image) utilizzando la console Disk Management cliccando col tasto destro sul disco e scegliendo Detach VHD, oppure da Esplora risorse cliccando col tasto destro sulla lettera del disco e scegliendo Eject.

Figura 27: Unmount del VHD package

Condivisione del VHD Package (MSIX Image)

Io ho deciso di condividere i fiel VHD in una Azure File Share. Le Azure File Shares supportano l’autenticazione basata su due tipi di servizi di dominio: Active Directory Domain Services locale (AD DS) e Azure Active Directory Domain Services (Azure AD DS).

Quando si abilita Active Directory Domain Services (AD DS) per le Azure File Shares, i computer aggiunti ad un dominio possono montare le cartelle condivise usando le credenziali di dominio locale. Inoltre è possibile gestire meglio le autorizzazioni per consentire un controllo di accesso granulare alle cartelle e ai file condivisi.

Trovate maggiori informazioni sulla procedura di integrazione delle Azure File Share con Active Directory nella mia guida Integrare le Azure File Share con un dominio Active Directory locale – ICT Power

Dopo aver creato lo storage account in Azure l’ho integrati con il mio AD locale utilizzando i passaggi mostrati di seguito:

Figura 28: Script di integrazione dell’AD locale con un Azure Storage Account

Dopo aver effettuato la procedura, come si può vedere dall’immagine seguente, lo storage account può utilizzare gli utenti di AD locale per definire i permessi di accesso.

Figura 29: Lo storage account è integrato con AD locale

Ho creato una Azure File Share, che adesso può usare come metodo di autenticazione gli utenti, i gruppi e i computer di AD locale.

Figura 30: Creazione della Azure FIle Share, che adesso può utilizzare come metodo di autenticazione gli utenti, i gruppi e i computer di AD locale

Ho creato un gruppo di Active Directory all’interno del quale ci saranno gli Host di Windows Virtual Desktop che saranno autorizzati ad accedere alla Azure File Share. Questo semplificherà molto l’assegnazione dei permessi per l’accesso allo storage account.

Figura 31: Gruppo di AD locale con gli host che dovranno accedere alla Azure File Share

Dopo aver replicato in Azure AD il gruppo creato in locale, lanciando la sincronizzazione con il tool Azure AD Connect, procedete a concedere il privilegio di Storage File Data SMB Share Reader per lo storage account al gruppo replicato, come mostrato nella figura sotto:

Figura 32: Assegnazione del ruolo di Storage File Data SMB Share Reader per lo storage account al gruppo di Session Host

Montate la Azure File Share su una delle macchine del dominio, utilizzando il percorso \\storageaccountname\share. Nel mio caso il percorso è \\nicmsixapps.file.core.windows.net\applications

Figura 33: Aggiunta della Azure File Share alle risorse di rete

Provvedete a copiare nella Azure File Share i file VHD con gli MSIX Package. Io ho creato una sottocartella per raccoglierli e l’ho chiamata vhds. Successivamente provvedete a dare i permessi NTFS di sola lettura al gruppo di Session Host che avete creato in precedenza in AD locale, come mostrato nella figura sotto:

Figura 34: Modica dei permessi NTFS in modo tale che il gruppo di Session Host possa accedere alla Azure File Share

Il percorso completo in cui si trova il VHD package (MSIX Image) è nel mio caso \\nicmsixapps.file.core.windows.net\applications\vhds\notepadplusplus.vhd

Configurazione di MSIX app attach utilizzando il portale di Azure

Da qualche tempo è disponibile la possibilità di utilizzare il portale di Azure per aggiungere gli MSIX Packages. Selezionate il vostro Host Pool (se non lo avete già creato potete seguire la mia guida Configurare i Remote Desktop Services in Azure Windows Virtual Desktop – ICT Power)e dal nodo MSIX Packages fate clic su +Add. Inserite il percorso completo del vostro file VHD e dal menù a tendina scegliete l’applicazione che volete aggiungere. Vi ricordo che nello stesso file VHD è possibile inserire più applicazioni. Scegliete come Registration Type la voce On-demand e come State scegliete Active.

NOTA: Assicuratevi che i vostri Session Host siano attivi in un validation environment

Figura 35: Verifica che l’Host Pool sia in un validation environment

Figura 36: Aggiunta dell’MSIX Package all’Host Pool

Figura 37: Aggiunta dell’MSIX package completata

Selezionate l’Application group dell’Host Pool a cui volete aggiungere l’MSIX package e selezionate il nodo Applications per aggiungere la nuova applicazione MSIX.

Figura 38: Selezione dell’Application group dell’Host Pool

Figura 39: Aggiunta dell’applicazione MSIX all’Application Group

Figura 40: Aggiunta dell’applicazione MSIX all’Application Group completata

L’ultimo passaggio consiste nell’assegnare l’Application group agli utenti o ai gruppi di Azure AD (sincronizzati con l’on-premises) a cui volete concederne l’utilizzo. Cliccate sul nodo Assignments dell’Application group e procedete ad aggiungerli.

Figura 41: Aggiunta degli utenti o dei gruppi a cui verrà concesso l’utilizzo del gruppo di applicazioni

Figura 42: Gruppo di utenti di Azure AD abilitato all’utilizzo del gruppo di applicazioni

Test di MSIX app attach (preview) – OPZIONALE

Prima di fare il deployment delle applicazioni nella vostra infrastruttura di Windows Virtual Desktop, è consigliabile prima effettuare un test per simulare quello che sarà il comportamento nel vostro WVD Host Pool. Per farlo Microsoft ha messo a disposizione una serie di script PowerShell che potete recuperare dalla pagina Configurare gli script di PowerShell per la connessione di desktop virtuale Windows MSIX-Azure | Microsoft Docs

Se non volete effettuare il test o siete sicuri che l’applicazione funzioni correttamente, potete passare direttamente alla sezione Distribuzione di MSIX App Attach in Windows Virtual Desktop.

Creazione degli script per MSIX app attach (preview)

Prima di cominciare ad utilizzare il pacchetto MSIX che abbiamo creato è necessario lanciare una serie di script PowerShell per apportare alcune modifiche e prepararlo alla corretta esecuzione.

MSIX app attach ha 4 fasi ben distinte che devono essere effettuate in un preciso ordine:

1. Stage
2. Register
3. Deregister
4. Destage

Ogni fase crea degli script PowerShell, che possono essere recuperati alla pagina RDS-Templates/msix-app-attach at master · Azure/RDS-Templates · GitHub

Figura 43: Script per MSIX app attach

Stage PowerShell script

Modificate le variabili dello script di Stage RDS-Templates/1.stage-a.ps1 at master · Azure/RDS-Templates · GitHub in modo tale che riporti le informazioni corrette. Nel mio caso lo script è quello di seguito:

#MSIX app attach staging sample

#region variables
$vhdSrc="C:\temp\notepadplusplus.vhd"
$packageName = "NotepadPlusPlus_1.0.0.0_x64__t0nrdm30b1zn4"
$parentFolder = "Notepad++"
$parentFolder = "\" + $parentFolder + "\"
$volumeGuid = "ade3aee5-7853-477f-9e84-71bc3b64b432"
$msixJunction = "C:\temp\AppAttach\"
#endregion

#region mountvhd
try
{
      Mount-Diskimage -ImagePath $vhdSrc -NoDriveLetter -Access ReadOnly
      Write-Host ("Mounting of " + $vhdSrc + " was completed!") -BackgroundColor Green
}
catch
{
      Write-Host ("Mounting of " + $vhdSrc + " has failed!") -BackgroundColor Red
}
#endregion

#region makelink
$msixDest = "\\?\Volume{" + $volumeGuid + "}\"
if (!(Test-Path $msixJunction))
{
     md $msixJunction
}

$msixJunction = $msixJunction + $packageName
cmd.exe /c mklink /j $msixJunction $msixDest
#endregion

#region stage
[Windows.Management.Deployment.PackageManager,Windows.Management.Deployment,ContentType=WindowsRuntime] | Out-Null
Add-Type -AssemblyName System.Runtime.WindowsRuntime
$asTask = ([System.WindowsRuntimeSystemExtensions].GetMethods() | Where { $_.ToString() -eq 'System.Threading.Tasks.Task`1[TResult] AsTask[TResult,TProgress](Windows.Foundation.IAsyncOperationWithProgress`2[TResult,TProgress])'})[0]
$asTaskAsyncOperation = $asTask.MakeGenericMethod([Windows.Management.Deployment.DeploymentResult], [Windows.Management.Deployment.DeploymentProgress])
$packageManager = [Windows.Management.Deployment.PackageManager]::new()
$path = $msixJunction + $parentFolder + $packageName # needed if we do the pbisigned.vhd
$path = ([System.Uri]$path).AbsoluteUri
$asyncOperation = $packageManager.StagePackageAsync($path, $null, "StageInPlace")
$task = $asTaskAsyncOperation.Invoke($null, @($asyncOperation))
$task
#endregion

Figura 44: Esecuzione dello script di Stage

Register PowerShell script

Modificate le variabili dello script di Register RDS-Templates/2-a.register.ps1 at master · Azure/RDS-Templates · GitHub in modo tale che riporti le informazioni corrette. Nel mio caso lo script è quello di seguito:

#MSIX app attach registration sample

#region variables
$packageName = "NotepadPlusPlus_1.0.0.0_x64__t0nrdm30b1zn4"
$path = "C:\Program Files\WindowsApps\" + $packageName + "\AppxManifest.xml"
#endregion

#region register
Add-AppxPackage -Path $path -DisableDevelopmentMode -Register
#endregion

Figura 45: esecuzione dello script di Register

Dopo l’esecuzione dello script di Register vedrete che nel menu avvio della macchina sarà apparso il collegamento alla vostra app, che potrà essere lanciata e testata.

Figura 46: Lancio dell’app registrata

Deregister PowerShell script

Modificate le variabili dello script d Deregister RDS-Templates/3.deregister-a.ps1 at master · Azure/RDS-Templates · GitHub in modo tale che riporti le informazioni corrette. Nel mio caso lo script è quello di seguito:

#MSIX app attach deregistration sample

#region variables
$packageName = "NotepadPlusPlus_1.0.0.0_x64__t0nrdm30b1zn4"
#endregion

#region deregister
Remove-AppxPackage -PreserveRoamableApplicationData $packageName
#endregion

Figura 47: esecuzione dello script di Deregister

Destage PowerShell script

Modificate le variabili dello script d Destage RDS-Templates/4.destage-a.ps1 at master · Azure/RDS-Templates · GitHub in modo tale che riporti le informazioni corrette. Nel mio caso lo script è quello di seguito:

#MSIX app attach de staging sample

$vhdSrc="C:\temp\notepadplusplus.vhd"

#region variables
$packageName = "NotepadPlusPlus_1.0.0.0_x64__t0nrdm30b1zn4"
$msixJunction = "C:\temp\AppAttach"
#endregion

#region deregister
Remove-AppxPackage -AllUsers -Package $packageName
Remove-Item "$msixJunction\$packageName" -Recurse -Force -Verbose
#endregion

#region Detach VHD
Dismount-DiskImage -ImagePath $vhdSrc -Confirm:$false
#endregion

Figura 48: Esecuzione dello script di Destage

Questi script vi permettono di testare il comportamento dell’applicazione e possono essere eseguiti manualmente oppure possono essere eseguiti automaticamente, anche distribuendoli tramite una Group Policy in questo modo:

• Stage script eseguito durante lo Startup
• Rgister script eseguito durante il Logon
• Deregister script eseguito durante il Logoff
• Destage script eseguito durante lo Shutdown

Distribuzione di MSIX App Attach in Windows Virtual Desktop

Per poter accedere a Windows Virtual Desktop è possibile utilizzare il client web HTML 5 disponibile all’indirizzo https://rdweb.wvd.microsoft.com/arm/webclient oppure è possibile utilizzare i client Windows dedicati, che potete trovare alla pagina Connettersi a desktop virtuale Windows 10 o 7-Azure | Microsoft Docs. Potete installare il client per l’utente corrente, nel qual caso non sono richiesti diritti di amministratore, oppure l’amministratore può installare e configurare il client in modo che tutti gli utenti del dispositivo possano accedervi. Dopo l’installazione, il client può essere avviato dal menu Start cercando Desktop remoto.

Nel mio caso ho utilizzato il client web e dopo l’autenticazione mi sono collegato al WorkSpace che avevo creato durante il wizard. L’unica applicazione disponibile è quella che permette di collegarsi alla sessione desktop remota. In alternativa potete pubblicare le applicazioni e utilizzare le RemoteApp.

Figura 49: Connessione a Windows Virtual Desktop effettuata

Figura 50: Richiesta di consentire l’accesso alle stampanti locali e ai dischi del dispositivo da cui si sta effettuando la connessione

Inserite le credenziali per poter accedere al desktop remoto e sarete pronti per cominciare a lavorare!

i metodi di accesso attualmente supportati:

• Client desktop di Windows
  • Nome utente e password
  • Smart card
  • Windows Hello for business (solo attendibilità del certificato)
• Client Windows Store, Client Web, Android, iOS, macOS
  • Nome utente e password

NOTA: Windows Virtual Desktop non supporta attualmente Active Directory Federation Services (ADFS) per SSO. L’unico modo per evitare che vengano richieste le credenziali per il Session Host consiste nel salvarle nel client. È consigliabile eseguire questa operazione solo con i dispositivi protetti per impedire ad altri utenti di accedere alle risorse.

Figura 51: Inserimento delle credenziali per poter accedere al Session Host remoto

Figura 52: Creazione del profilo utente nel Session Host remoto

Adesso siete pronti per lavorare col vostro Desktop remoto e potrete accedere a tutte le risorse, anche a quelle on-premises grazie alle connessioni VPN Site-To-Site oppure grazie ad ExpressRoute.

Come potete vedere dalla figura sotto, al Session Host a cui si è collegato l’utente è stato montato il VHD che contiene l’applicazione MSIX. L’utente può lanciare l’applicazione del menu avvio di Windows, come qualsiasi altra applicazione.

Figura 53: Il VHD Package con le applicazioni MSIX è stato collegato al Session Host

Figura 54: Apertura dell’applicazione MSIX nel Session Host remoto

Conclusioni

MSIX app attach per Windows Virtual Desktop permette di distribuire facilmente le applicazioni e di poterle successivamente aggiornare in maniera molto rapida, in modo tale da offrire l’esperienza migliore all’utente. Questo permette di ridurre il re-imaging dei nostri Host Pool e di rendere le applicazioni indipendenti dal sistema operativo. La conversione di un’applicazione LOB in formato MSIX è un’operazione veloce, tanto quanto la sua successiva distribuzione nel nostro ambiente VDI.

Maggiori informazioni

Windows Virtual Desktop MSIX app attach glossary – Azure | Microsoft Docs

Risorse di MSIX – MSIX | Microsoft Docs

MSIX app attach Azure portal integration public preview – Page 2 – Microsoft Tech Community

MSIX app attach in WVD – YouTube

L'articolo Configurare MSIX app attach (preview) in Windows Virtual Desktop proviene da ICT Power.

Da Windows 10, versione 1709 è possibile utilizzare il Multi-factor device unlock estendendo la funzionalità di Windows Hello con quella di un segnale attendibile, che può essere il bluetooth del cellulare, un dispositivo indossabile, la rete WIFi o la configurazione IP.

Ho già avuto altre occasioni di parlarvi di Windows Hello for Business, perché accedere senza password è una delle funzionalità che ultimamente Microsoft sta promuovendo maggiormente. 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.

Attualmente Windows in modo nativo supporta solo l’utilizzo di credenziali singole (password, PIN, impronta digitale, rilevamento del volto e così via) per sbloccare un dispositivo. Pertanto, se una qualsiasi di queste credenziali viene compromessa (shoulder surfing), un utente malintenzionato potrebbe ottenere l’accesso al sistema.

Windows 10 offre lo sblocco del dispositivo a più fattori estendendo Windows Hello con segnali attendibili. Gli amministratori possono configurare Windows 10 per richiedere una combinazione di fattori e segnali attendibili per sbloccare i dispositivi.

Lo sblocco a più fattori viene abilitato tramite Criteri di gruppo e permette di definire tre componenti:

• Provider di credenziali del primo fattore di sblocco (che possono essere PIN, impronta digitale, riconoscimento facciale)
• Provider di credenziali del secondo fattore di sblocco (che possono essere il PIN oppure un segnale attembibile)
• Regole di segnale per lo sblocco del dispositivo

Il provider di credenziali del primo fattore di sblocco può essere uno dei fattori mostrati nella tabella seguente:

Il provider di credenziali del secondo fattore di sblocco può essere uno dei fattori mostrati nella tabella seguente:

Se volete usare più provider di credenziali è sufficiente aggiungere nella group policy i di versi GUID separati da virgole.

Per configurare le regole del segnale per il provider di credenziali del segnale attendibile è necessario invece utilizzare il formato XML.

Ad esempio se volete utilizzare il segnale bluetooth dovete utilizzare la notazione:

<rule schemaVersion="1.0">
<signal type="bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/>
</rule>

Trovate maggior informazioni sulle diverse regole permette all’indirizzo Unlock a più fattori – Microsoft 365 Security | Microsoft Docs

Distribuzione di Sblocco a più fattori

Per distribuire lo sblocco a più fattori è necessario attivare il provisioning di Windows Hello for Business e garantire il rinnovo automatico dei certificati di Windows Hello for Business. In più è bene ricordare che:

1. Il PIN deve essere in almeno uno dei gruppi.
2. Non è possibile utilizzare lo stesso fattore di sblocco per soddisfare entrambe le categorie.

Create quindi una nuova Group Policy e in Computer Configuration
à Administrative Templates à Windows Component
à Windows Hello for Business abilitate Configure device unlock factors.

In maniera predefinita vi verrà proposto di utilizzare il PIN come primo fattore, il Segnale attendibile come secondo fattore e il Bluetooth come Trusted Signal Credential Provider.

Figura 1: Configurazione del fattori per lo sblocco del dispositivo

Figura 2: Abilitazione di Windows Hello for Business

Se a questo punto provate a loggarvi su una macchina che subisce la GPO appena creata, riceverete il messaggio mostrato in figura, che vi avvisa che la vostra organizzazione richiede che è configurato il Windows Hello for Business.

Figura 3: Richiesta di configurazione di Windows Hello for Business

Nel pannello delle Sign-In options noterete anche che ci sarà un messaggio di avviso che vi notifica che l’organizzazione richiede che configuriate diverse opzioni per il Sign-In. Come prima operazione configurate il Windows Hello PIN.

Figura 4: Aggiunta del Windows Hello Pin

Figura 5: Creazione del Windows Hello PIN

Figura 6: Aggiunta del Windows Hello PIN

Potete quindi aggiungere il dispositivo bluetooth che volete utilizzare. Nel mio caso ho utilizzato lo smartphone.

Figura 7: Aggiunta di un nuovo dispositivo a Windows 10

Figura 8: Ricerca deli dispositivi bluetooth

Figura 9: Selezione dello smartphone

Figura 10: Smartphone aggiunto a Windows 10

Test di accesso con lo sblocco a due fattori

Dopo la disconnessione, al successivo tentativo di accedere al vostro PC windows 10, vi verrà chiesto il Windows Hello PIN e verrà effettuata la verifica della presenza del secondo fattore di autenticazione, cioè il bluetooth del vostro smartphone.

Figura 11: Accesso a Windows 10 con Windows Hello PIN

Figura 12: Verifica della presenza del secondo fattore di sblocco

Se invece avete il bluetooth dello smartphone spento o non avete il cellulare nelle vicinanze, non sarà possibile effettuare il logon a Windows 10.

Figura 13: In mancanza del segnale bluetooth non è possibile fare il logon a Windows 10

Abilitare Windows 10 Dynamic Lock

A partire da Windows 10, versione 1703 (Creators Update) è disponibile una funzionalità interessante chiamata Dynamic Lock. Questa funzionalità permette, dopo aver collegato il PC al proprio smartphone tramite collegamento bluetooth, di poter bloccare il computer.

La funzionalità, chiamata anche Windows Goodbye in contrapposizione a Windows Hello, è interessante perché permette di aumentare il livello di sicurezza quando si lavora su postazioni di lavoro sensibili. Basta infatti allontanarsi col proprio smartphone dalla postazione e in circa 30 secondi Windows si bloccherà automaticamente.

Per abilitare la funzionalità è prima di tutto necessario collegare il proprio smartphone al PC utilizzando una connessione bluetooth. Dopo aver abilitato il pairing andate nell’app Settings  > Accounts > Sign-in options e scorrete fino a trovare la voce Dynamic lock. Selezionate Allow Windows to automatically lock your device when you’re away per abilitare la funzionalità.

Allontanatevi dal PC portando con voi lo smartphone e dopo circa 30 secondi vedrete che il computer si bloccherà automaticamente.

Maggiori informazioni su questa funzionalità sono disponibili nella mia guida NicolaFerrini.it – Abilitare Windows 10 Dynamic Lock

Figura 14: Abilitazione di Windows 10 Dynamic Lock

Conclusioni

Windows 10 offre lo sblocco del dispositivo a più fattori estendendo Windows Hello con segnali attendibili. Gli amministratori possono configurare Windows 10 per richiedere una combinazione di fattori e segnali attendibili per sbloccare i dispositivi. Questo di fatto risolve il problema che Windows Hello PIN da solo non soddisfa le esigenze di sicurezza di diverse aziende e in più è possibile impedire agli utenti di condividere le credenziali di accesso.

Per maggiori informazioni vi invito a visitare la pagina Unlock a più fattori – Microsoft 365 Security | Microsoft Docs

L'articolo Configurare il Multi-factor Unlock con Windows Hello for Business e il proprio smartphone proviene da ICT Power.

Il mese di marzo è iniziato con una bellissima novità: Windows Admin Center versione 2103 GA!

Tante nuove funzionalità in questa versione, inclusi gli aggiornamenti in-app sia per la piattaforma Windows Admin Center che per le estensioni, migliorie sia all’accessibilità che ai tool principali, nuove estensioni e tanto altro.

Questa è la terza release rilasciata in GA dall’inizio del progetto e, come siamo già stati abituati, ci sono davvero tante novità. Approfondiamo le più importanti.

Supporto per Azure IoT Edge for Linux on Windows

IoT Edge per Linux on Windows funziona eseguendo una macchina virtuale Linux su un host Windows. La VM Linux viene messa a disposizione con lo IoT Edge runtime preinstallato. L’estensione IoT Edge per Windows Admin Center facilita l’installazione, la configurazione e la diagnostica di IoT Edge sulla VM. Windows Admin Center ne permette la distribuzione anche nei dispositivi locali, la connessione verso altri dispositivi e la relativa gestione.

Per approfondire IoT Edge for Linux on Windows è possibile consultare la documentazione ufficiale.

Windows Admin Center in Public Preview su Azure

Questa nuova funzionalità consente una gestione più specifica delle VM IaaS su Azure. L’interfaccia utente è la stessa utilizzata su Windows Admin Center e fornisce quelle funzionalità in cloud e per il cloud che prima erano disponibili solo per gli utenti locali.

Aggiornamenti automatici “In-app”

Questa nuova funzionalità è stata richiesta a gran voce e da molto tempo su User Voice (il portale dove Microsoft raccoglie feedback e suggerimenti dalla community). Gli aggiornamenti automatici sono abilitati sia per la componente gateway che per le estensioni.

Figura 1: WAC – Aggiornamenti

Figura 2: WAC – Aggiornamenti

Proxy

Una novità importante è la possibilità di configurare un proxy per il traffico in uscita.

Figura 3: WAC – Proxy

Pop-out

Con questa release tutti i tool messi a disposizione nella dashboard di Windows Admin Center possono essere aperti in un popup. Cliccando sull’apposito tasto, si aprirà una nuova finestra con la quale interagire

Figura 4: WAC – Popup

Figura 5: WAC – Popup

Privacy

La gestione delle impostazioni sulla privacy è una new-entry inserita all’interno di Windows Admin Center. In questa sezione è possibile specificare la quantità di informazioni che WAC invia a Microsoft. Per poter accedere alla sezione in oggetto è sufficiente aprire la dashboard delle impostazioni e cliccare su Diagnostica e feedback

Figura 6: WAC – Privacy

Eventi

Il visualizzatore degli eventi è uno degli strumenti più utilizzati. Dalla sua introduzione nel 1993 ad oggi non ha vissuto grossi cambiamenti. In questa versione di Windows Admin Center questo strumento è stato migliorato sia in termini grafici che funzionali. La velocità con la quale gli eventi vengono recuperati è stata ottimizzata ed è possibile creare una nuova area di lavoro dove raggruppare gli eventi e consultarli contemporaneamente.

Per abilitare questa nuova visualizzazione è sufficiente cliccare sul selettore che abilita la “modalità preview”

Figura 7: WAC – Eventi

Virtual Machine

Nella sezione di gestione di un Cluster HCI è possibile gestire le VM con l’apposito tool.

In questa release sono presenti tre macro aggiornamenti:

• Nel menu delle impostazioni delle VM è stata aggiunta la sezione delle configurazioni relative agli Integration Services, ovvero relative a sincronizzazioni, heartbeat e spegnimento;
• La dashboard può essere modificata in modo da raggruppare le VM in maniera differente e/o modificare le colonne delle tabelle per mostrare le informazioni desiderate o semplicemente quelle a cui si è interessati;
• Modificare i virtual switch durante lo spostamento di una VM. Nelle versioni precedenti se il nome del virtual switch sorgente fosse stato diverso da quello di destinazione, l’azione di migrazione della VM avrebbe fallito.

Azure Stack HCI

La procedura guidata per la creazione del Cluster HCI è stata migliorata, così come la detection di RDMA e S2D. La cosa più interessante è l’integrazione “snap-in” di alcune estensioni dei partner OEM direttamente con gli strumenti di WAC. Uno dei possibili scenari di utilizzo è il seguente: se un cluster HCI viene creato su hardware di un partner OEM, Windows Admin Center utilizzerà in autonomia firmware e driver più recenti per la creazione e gli aggiornamenti dei nodi del cluster.

Estensioni, partner e community

Windows Admin Center è progettato per essere una piattaforma che può estendere il suo raggio d’azione grazie all’utilizzo di estensioni sviluppate ad hoc, rilasciate dai partner e/o dalla community. Questo ecosistema cresce sempre di più ed è davvero interessante vedere che ci sono già estensioni contenenti snap-in.

Conclusioni

Questa release è davvero piena di interessantissime novità! Per coloro che volessero approfondire le funzionalità, vecchie e nuove, di Windows Admin Center è possibile consultare la documentazione ufficiale e guardare il video pubblicato nel Video Hub.

In attesa di ulteriori sviluppi, il link per effettuare il download di WAC è disponibile nella sezione su sito Microsoft. Come di consueto, qualsiasi feedback può essere rilasciato sul portale UserVoice. Infine, è possibile contribuire attivamente sullo spazio messo a disposizione sui forum delle Microsoft Tech Communities su Windows Admin Center.

Stay tuned!

L'articolo Windows Admin Center – Le novità della versione 2103 GA proviene da ICT Power.

Microsoft conferma i problemi apparsi con l’aggiornamento cumulativo di marzo 2021 su diversi PC connessi a specifiche stampanti e utilizzate in alcune applicazioni. Multiple e “fatali” schermate della morte blu (BSOD) come quella mostrata nell’immagine seguente con il codice di interruzione APC_INDEX_MISMATCH ed elemento Win32kfull.sys

Di seguito una lista delle versioni di Windows 10 affette dal problema con il riferimento KB:

• Windows 10 versione 1803 — KB5000809 (Build 17134.2087)
• Windows 10 versione 1809 — KB5000822 (Build 17763.1817)
• Windows 10 versione 1909 — KB5000808 (Build 18363.1440)
• Windows 10 versione 2004 e 20H2 — KB5000802 (Build 19041.867 e 19042.867).

Non è chiaro quante e quali stampanti siano interessate, ma leggendo i vari commenti degli utenti possiamo provare a stringere il cerchio soprattutto su Kyocera, Ricoh e altre.

Microsoft sta ancora investigando sul problema e ha aggiornato la relativa pagina (KB) dove saranno aggiunti ulteriori dettagli.

Come risolvere il problema su Windows 10?

La buona notizia è che esiste una soluzione relativamente semplice per questa serie di BSOD: disinstallare gli ultimi aggiornamenti cumulativi (rif. lista precedente) e sospendere gli aggiornamenti per almeno 7 giorni fino a quando il problema non verrà risolto ufficialmente da Microsoft.

Per disinstallare l’aggiornamento cumulativo di Windows 10

• Aprire Impostazioni di Windows
• Fare clic su Aggiornamento e sicurezza
• Fare clic su Windows Update
• Fare clic su Visualizza cronologia degli aggiornamenti
• Fare clic su Disinstallare gli aggiornamenti
• Nella schermata del “vecchio” Pannello di controllo, seleziona l’aggiornamento e fai clic su Disinstalla

Nell’immagine seguente un esempio

Per sospendere gli aggiornamenti per 7 giorni in Windows 10

• Apire Impostazioni di Windows
• Fare clic su Aggiornamento e sicurezza
• Fare clic su Windows Update
• Fare clic su Sospendi gli aggiornamenti per 7 giorni

Nell’immagine seguente un esempio

Come risolvere il problema tramite il Prompt dei comandi su Windows 10?

Se il processo non dovesse andare a buon fine tramite i metodi suggeriti precedentemente è possibile utilizzare anche il classico (è intramontabile) Prompt dei comandi.

Per la versione 2004 / 20H2:

wusa /Uninstall /kb:5000802

Per la versione 1903/1909:

wusa /Uninstall /kb:5000808

Il comando è utilizzabile per qualsiasi versione di Windows 10, ma assicuratevi di sostituire i numeri di aggiornamento KB1234567 con quelli corretti (rif. lista precedente).

Se ci saranno aggiornamenti ve li comunicheremo tempestivamente.

L'articolo Windows 10 e BSOD, fix problemi aggiornamento cumulativo di marzo 2021 proviene da ICT Power.

Nel nuovo mondo del lavoro flessibile, sempre più digitale, è chiaro quanto siano importanti strumenti e tecnologie orientate alla collaborazione, all’apprendimento, alla condivisione e soprattutto alla sicurezza.

Già nelle precedenti #POWERCON abbiamo tratto questi temi e ancora una volta vogliamo ribadire quali siano gli strumenti giusti per supportare persone e organizzazioni a crescere e migliorare in questo mondo del lavoro in cambiamento. Nel corso dell’ultimo anno abbiamo vissuto un’evoluzione accelerata degli ambienti di lavoro, nonché del nostro stile di vita e vogliamo sensibilizzare tutti, dai decision maker ai dipendenti, all’utilizzo corretto delle tecnologie e alla gestione degli aspetti relativi alla sicurezza informatica.

Durante la prima #POWERCON2021 dell’anno abbiamo deciso quindi di trattare i seguenti temi:

Roberto Tafuri e Nicola Ferrini ci mostreranno come pubblicare applicazioni aziendali utilizzando Azure AD Application Proxy. Azure Active Directory Application Proxy è un servizio che permette in modo semplice la fruizione delle applicazioni ad utenti esterni all’azienda. La protezione degli accessi è un fattore determinante per poter preservare le nostre informazioni e per poter essere sicuri che non siano accessibili da persone non autorizzate. È molto facile pubblicare applicazioni ospitate in server on-premises utilizzando Azure Active Directory Application Proxy, senza che sia necessario aprire alcuna porta in ingresso sul firewall della nostra infrastruttura e utilizzando l’autenticazione di Azure Active Directory per proteggere gli accessi e fornire condivisione business-to business.

Raffaele Valensise tratterà il tema della Protezione cloud-to-cloud per Microsoft 365 con Veeam. Veeam Backup for Microsoft Office 365 consente di proteggere i dati di Exchange Online, SharePoint Online, OneDrive for Business e Teams con policy personalizzabili anche dal punto di vista delle modalità di archiviazione, permettendone il ripristino granulare direttamente in produzione. In questa sessione vedrete come si può installare e configurare la soluzione Veeam direttamente in Azure per usufruire di tutti i vantaggi della piattaforma cloud Microsoft, in modo particolare della scalabilità e della convenienza economica degli spazi di archiviazione BLOB.

Luca Cavana affronterà il tema delle Retention Labels in Microsoft 365 – Come gestire la conservazione dei dati quando essi lasciano l’on-premises. Lo spostamento verso il Cloud aumenta gli strumenti a disposizione degli utenti, moltiplicando sia le tipologie di dato che le applicazioni in cui i dati possono risiedere. Se da un lato questo rende la collaborazione più efficace ed aumenta la produttività degli utenti, una mancanza di governance può rendere la situazione difficilmente gestibile nel lungo periodo ed esporci a rischi immotivati, sia di sicurezza che di aderenza alle normative. In questa sessione scoprirete come le Retention Labels siano una delle funzionalità offerte da Microsoft 365 per gestire questa crescente complessità.

Infine Vito Macina ci parlerà di Windows 10 – Road to the “Sun”. Un ulteriore aggiornamento di funzionalità “rapido” nella prima metà del 2021, ma è in arrivo il più importante aggiornamento di Windows degli ultimi dieci anni. In questa sessione osserverete le ultime novità e daremo uno sguardo al futuro.

AGENDA

Vi aspettiamo online!

La partecipazione al seminario è GRATUITA. Per registrarvi cliccate sull’immagine sotto:

L'articolo #POWERCON2021 – Innovazione digitale e sicurezza informatica – Evento online GRATUITO proviene da ICT Power.

Da qualche settimana è disponibile il primo aggiornamento di funzionalità dell’anno 2021, nome ufficiale Windows 10 May 2021 Update. Il rilascio globale è attivo da qualche giorno sui vari canali di distribuzione: Windows Update (a scaglioni), Windows Server Update Services (WSUS) e Windows Update for Business. Le immagini ufficiali posso essere scaricate e utilizzate tramite le sottoscrizioni di Visual Studio, il Software Download Center (Assistente Aggiornamento o Media Creation Tool), VLSC (Volume Licensing Service Center) e Azure Marketplace.

Questo aggiornamento presenta alcune nuove funzionalità minori, che troverete nel nostro articolo e annunciate a febbraio dal Blog ufficiale di Windows, in quanto è ormai imminente l’annuncio del futuro di Windows con il più importante aggiornamento degli ultimi anni.

Il processo è il medesimo utilizzato per l’aggiornamento di Windows 10 2004 alla versione 20H2, ovvero quello rapido. La versione 21H1 viene distribuita sui dispositivi che eseguono già Windows 10 2004 (May 2020 Update) o Windows 10 20H2 (October 2020 Update) tramite “enablement package” (pacchetto di abilitazione). Per coloro che aggiornano a Windows 10 May 2021 Update da versioni precedenti di Windows, il processo sarà simile agli aggiornamenti di funzionalità standard e relativo tempo di installazione.

La data di rilascio ufficiale è 18 maggio 2021 e la versione è identificata dal numero 21H1 build 19043. A partire da questo giorno Microsoft inizia a supportare la nuova versione del sistema operativo Windows 10, per 18 mesi, con le seguenti date di fine ciclo di vita:

• Edizioni Home, Pro, Pro Education, Pro for Workstations e IoT Core – 13 dicembre 2023
• Enterprise, Education and IoT Enterprise – 13 dicembre 2023

Pacchetto di abilitazione

Il pacchetto di abilitazione è ormai un’ottima opzione per installare un aggiornamento delle funzionalità di Windows 10, come la nuova versione 21H1, perché consente un aggiornamento dalla versione 2004 o 20H2 con un singolo riavvio, riducendo i tempi di inattività dipesi dagli aggiornamenti. In questo modo i dispositivi possono sfruttare subito le nuove funzionalità aggiunte.

A titolo informativo, Windows 10 2004, 20H2 e 21H1
condividono il medesimo core del sistema operativo con un set di file di sistema identico. Le nuove funzionalità della 21H1 sono state già incluse nell’ultimo aggiornamento qualitativo mensile per Windows 10 2004 e Windows 10 20H2 (KB5003173), ma esse sono inattive/disabilitate e in uno stato “dormiente”. Grazie all’ “enablement package” (pacchetto di abilitazione), ovvero un piccolo e rapido “interruttore master” che attiva le funzionalità di Windows 10 versione 21H1. Esso viene identificato dal (KB5000736).

Ulteriori informazioni sull’aggiornamento di funzionalità con enablement package

Evento What’s next for Windows – 24 giugno 2021 ore 17.00 (online)

Il 24 giugno 2021 alle ore 17.00, Microsoft annuncerà al mondo quale sarà il futuro di Windows. Tante ipotesi sono circolate in questi mesi e mancano davvero pochi giorni per scoprire quali saranno le novità per il sistema operativo più famoso (nel bene e nel male) di Microsoft.
Noi seguiremo l’evento in diretta e se siete interessati a partecipare trovate il livestream a questo link.

Novità di Windows 10 May 2021 Update

• Windows Update
  A partire da Windows 10 versione 20H2, inclusa questa ultima versione, gli ultimi aggiornamenti cumulativi (LCU) e gli aggiornamenti dello stack di manutenzione (SSU) sono stati combinati in un unico aggiornamento mensile cumulativo, disponibile tramite Microsoft Catalog o Windows Server Update Services. Per altre informazioni vi rimandiamo a questo articolo ufficiale.
  
• Windows Autopilot
  Una nuova azione remota di Intune: Collect diagnostics consente di raccogliere i log dai dispositivi aziendali senza interrompere o bloccare in attesa l’utente finale. Intune ha anche aggiunto funzionalità al Role-based access control (RBAC). Queste possono essere usate per definire ulteriormente le impostazioni del profilo per la Enrollment Status Page (ESP). Per ulteriori informazioni seguite questo link.
  
• Windows Assessment and Deployment Toolkit (ADK)
  Non è disponibile un nuovo ADK per Windows 10 21H1. L’ADK per Windows 10 versione 2004, funziona sia per Windows 10 20H2 e sia per 21H1. Per altre informazioni potete scaricare e installare Windows ADK da questo link.
  
• Gestione dei dispositivi
  Windows Management Instrumentation (WMI) Group Policy Service (GPSVC) presenta un miglioramento delle prestazioni per supportare gli scenari di lavoro remoto. È stato risolto un problema che causava la propagazione lenta delle modifiche da parte di un amministratore di Active Directory (AD) alle appartenenze a gruppi di utenti o computer. Anche se alla fine il token di accesso viene aggiornato, queste modifiche potrebbero non essere visualizzate quando l’amministratore usa i comandi gpresult /r o gpresult /h per creare un report.
• Windows Defender Application Guard (WDAG)
  Le prestazioni di WDAG sono state migliorate con tempi di apertura dei documenti ottimizzati:
  • È stato risolto un problema che poteva causare un minuto o più di ritardo all’apertura di un documento Office di Microsoft Defender Application Guard (WDAG). Ciò può verificarsi quando si prova ad aprire un file con un percorso UNC (Universal Naming Convention) o un collegamento di condivisione SMB (Server Message Block).
  • È stato risolto un problema di memoria che poteva far sì che un contenitore WDAG usasse quasi 1 GB di memoria del working set quando il contenitore era inattivo.
  • Sono state migliorate le prestazioni di Robocopy quando si copiano file di dimensioni superiori a 400 MB.
    
• Windows Hello
  È stato aggiunto il supporto multi-camera di Windows Hello, consentendo agli utenti di scegliere la fotocamera esterna come prioritaria quando sono presenti sia esterne che interne compatibili con Windows Hello.
  
• Microsoft Edge (basato sul motore Chromium)
  Windows 10 versione 21H1, come la versione 20H2, integra nativamente il nuovo browser Microsoft Edge.
  

Ulteriori informazioni sugli strumenti IT per Windows 10 21H1
Ulteriori informazioni su come ottenere Windows 10 21H1

Ulteriori informazioni sulla distribuzione di Windows 10

Caratteristiche rimosse o non più sviluppate (Windows 10 21H1)

Ogni nuova versione di Windows 10 contiene funzionalità aggiunte e/o migliorate, ma a volte alcune di esse vengono rimosse o non più sviluppate.

Rimosse da Windows 10 21H1

• Microsoft Edge. La versione legacy di Microsoft Edge non è più supportata dopo il 9 marzo 2021. Per ulteriori informazioni, far riferimento a questo link.
• Driver dello schermo remoto basato su XDDM. Il supporto di Windows a driver di visualizzazione remoti basati su XDDM (Display Driver Model) 2000 è stato rimosso in questa versione. I fornitori di software indipendenti che utilizzano un driver di visualizzazione remoto basato su XDDM devono pianificare una migrazione al modello di driver WDDM. Per ulteriori informazioni fate riferimento a Updates for IddCx versions 1.4 and later.

Non più sviluppate da Windows 10 21H1

• Strumento Windows Management Instrumentation Command line (WMIC). Lo strumento WMIC viene rimosso in Windows 10 versione 21H1 e nella versione 21H1 del canale semestrale di Windows Server. Questo strumento viene sostituito da Windows PowerShell for WMI. Nota: questa rimozione si applica solo agli strumenti di gestione a riga di comando. WMI non è interessato.
• Personalization roaming. Il roaming delle impostazioni di personalizzazione (inclusi sfondo, presentazione, colori primari e immagini della schermata di blocco) non è più in fase di sviluppo e potrebbe essere rimosso in una versione futura.
• Internet Explorer (IE) 11. Il supporto all’applicazione desktop IE11 terminerà per determinati sistemi operativi a partire dal
  15 giugno 2022. Per altre informazioni, vedere questo link.

Scaricare Windows 10 May 2021 Update

Per chi fosse interessato a scaricare le ISO ufficiali, strumenti e risorse legate a Windows 10 21H1 forniamo di seguito tutte le relative informazioni:

Windows 10 (business editions), version 21H1

All’interno del Media sono presenti le seguenti edizioni:

• Windows 10 Pro
• Windows 10 Pro N
• *Windows 10 Pro for Workstations
• *Windows 10 Pro N for Workstations
• Windows 10 Pro Education
• Windows 10 Pro Education N
• Windows 10 Education
• Windows 10 Education N
• Windows 10 Enterprise
• Windows 10 Enterprise N

*È richiesta l’installazione di Windows 10 Pro, versione 1709 o superiore, prima di poter attivare il product key di Window 10 Pro for Workstations.

• en_windows_10_business_editions_version_21h1_x64_dvd_ec5a76c1.iso
  SHA256: 0FC1B94FA41FD15A32488F1360E347E49934AD731B495656A0A95658A74AD67F
• en_windows_10_business_editions_version_21h1_x86_dvd_1495793c.iso
  SHA256: D6F70EB4F6A2BCD9F61553A9A4F643EC60BED9551DEDD95ED2989BCC638D71AB
• it_windows_10_business_editions_version_21h1_x64_dvd_748c579e.iso
  SHA256: 6B9A8278D7B93EA6DA6C9CA1607897E57DE21D83E83DA26848E5AE0357190034
• it_windows_10_business_editions_version_21h1_x86_dvd_9dd9074d.iso
  SHA256: 5CCF1384572B822CAD7E8A508A34B722FC02CB87094539A4D2845B0A19FB6D05

Windows 10 (consumer editions), version 20H2

All’interno del Media sono presenti le seguenti edizioni:

• Windows 10 Home
• Windows 10 Home N
• Windows 10 Core Single Language
• Windows 10 Pro
• Windows 10 Pro N
• *Windows 10 Pro for Workstations
• *Windows 10 Pro N for Workstations
• Windows 10 Pro Education
• Windows 10 Pro Education N
• Windows 10 Education
• Windows 10 Education N

*È richiesta l’installazione di Windows 10 Pro, versione 1709 o superiore, prima di poter attivare il product key di Window 10 Pro for Workstations.

• en_windows_10_consumer_editions_version_21h1_x64_dvd_540c0dd4.iso
  SHA256: 6911E839448FA999B07C321FC70E7408FE122214F5C4E80A9CCC64D22D0D85EA
• en_windows_10_consumer_editions_version_21h1_x86_dvd_68cee121.iso
  SHA256: 65CFEAA1ED3375012A4F11C7DEF5A2544B4338094760E2A9A79169136BB4A6BD
• it_windows_10_consumer_editions_version_21h1_x64_dvd_44dc3c74.iso
  SHA256: E35FDA8EB7A943D5A713FC32E7BFA1A060D770B79FEEAC21FB7DE4E7AE421901
• iit_windows_10_consumer_editions_version_21h1_x86_dvd_8c2f7584.iso
  SHA256: D6F9CB7939FEB0E0790FD012BCA4B554C09119B9732A30B0A96180117C019275

Versione di valutazione di Windows 10 Enterprise 21H1

Per chi volesse provare una versione di valutazione di 90 giorni (edizione Enterprise) può scaricarla direttamente dall’Evaluation Center:

Lingue disponibili

Cinese (Semplificato), Cinese (Tradizionale), Coreano, Francese, Giapponese, Inglese (Gran Bretagna), Inglese (Stati Uniti), Italiano, Portoghese, Spagnolo, Tedesco

Edizioni

• Windows 10 Enterprise, version 21H1 | 64-bit ISO
• Windows 10 Enterprise, version 21H1 | 32-bit ISO
• Windows 10 Enterprise LTSC 2019 | 64-bit ISO
• Windows 10 Enterprise LTSC 2019 | 32-bit ISO

Strumenti e risorse per il supporto IT di Windows 10 21H1

• Security baseline (FINALE) per Windows 10 21H1
• Template amministrativi (.admx) per Windows 10 21H1
• Foglio di lavoro relativo all’elenco delle Group Policy per Windows 10 21H1
• Problemi noti e notifiche in Windows 10 21H1
• Problemi risolti in Windows 10 21H1

Continuate a seguirci sui nostri canali per tutte le novità e gli approfondimenti su Windows 10 e tante altre tecnologie.

L'articolo Windows 10 May 2021 Update proviene da ICT Power.

Nel nuovo mondo del lavoro flessibile, sempre più digitale, è chiaro quanto siano importanti strumenti e tecnologie orientate alla collaborazione, all’apprendimento, alla condivisione e soprattutto alla sicurezza.

Già nelle precedenti #POWERCON abbiamo trattato questi temi e ancora una volta vogliamo ribadire quali siano gli strumenti giusti per supportare persone e organizzazioni a crescere e migliorare in questo mondo del lavoro in cambiamento. Nel corso dell’ultimo anno abbiamo vissuto un’evoluzione accelerata degli ambienti di lavoro, nonché del nostro stile di vita e vogliamo sensibilizzare tutti, dai decision maker ai dipendenti, all’utilizzo corretto delle tecnologie e alla gestione degli aspetti relativi alla sicurezza informatica.

Un ulteriore aggiornamento di funzionalità “rapido” nella prima metà del 2021 per Windows 10, ma è in arrivo il più importante aggiornamento di Windows degli ultimi dieci anni. In questa sessione osserverete le ultime novità e daremo uno sguardo al futuro.

Potete scaricare la presentazione della sessione al link https://www.ictpower.it/download/POWERCON2021 – Vito Macina – Windows 10 – Road to the Sun.pdf

Qui di seguito invece c’è la registrazione della sessione:

L'articolo #POWERCON2021 – Evento online dell’11 giugno – Vito Macina – Windows 10 – Road to the “Sun” proviene da ICT Power.