Quando un sistema RDS è articolato su più server ogni utente deve mantenere le proprie impostazioni a prescindere dal server di sessione sul quale viene ad essere collegato.

L’ambiente di configurazione RDS dalla versione 2012 prevede la possibilità di utilizzare gli “User Profile Disks”, in breve si tratta di un disco virtuale che viene agganciato alla sessione utente e dentro il quale è possibile prevedere che vengano redirette tutte o parte delle impostazioni del profilo utente.

Figura 1 Configurazione di User Profile Disks

Già con le precedenti versioni di Terminal Server era (ed è ancora) possibile redigere globalmente il profilo per le connessioni RDS dei singoli utenti verso un’area condivisa.

Questa impostazione è presente nel Tab “Remote Desktop Service Profile” in ADUC

Figura 2 impostazione Di RDS Profile Path

Nel caso ci si trovi a dover gestire una configurazione di questo tipo può essere necessario dover spostare fisicamente la posizione dei vari profili utente.

L’intera operazione deve essere completata in due passaggi

• Nel primo si devono migrare fisicamente le cartelle dei singoli utenti, che di norma sono ospitate su una share di rete
• Nel secondo è necessario variare il percorso impostato nel campo Profile Path della configurazione del tab Remote Desktop Service Profile in ADUC.

Migrazione dei Profili Utente per le connessioni in Remote Desktop

Per lo spostamento, o la copia dei profili utente è possibile utilizzare il tool ROBOCOPY, in modo da copiare l’intera struttura di ogni profilo, preservandone le impostazioni di sicurezza, condizione essenziale al fine del corretto funzionamento dell’ambiente RDS.

Robocopy è un tool disponibile dapprima nei Resource Kit dei vari sistemi operativi e successivamente, dalle versioni 2008 Server e Vista è stato integrato direttamente nel sistema operativo, permette una agevole gestione della copia, spostamento del contenuto di interi filesystem gestendo in modo agevole anche la copia delle ACL di protezione ai vari file e cartelle.

robocopy <PathSorgente> <PathDestinazione> /e /COPYALL /LOG:<PatLog>uprofiliutentits.txt /R:0 /W:1

• con l’opzione /E vengono copiate tutte le cartelle anche se vuota
• con l’opzione /COPYALL vengono copiate tutte le informazioni sui file ACL comprese

il comando deve essere eseguito in una sessione a privilegi elevati

Variazione del percorso per il profilo condiviso impostato in AD

tramite Powershell è possibile gestire la modifica in modo automatizzato e, tramite la definizione di un controllo nello script stesso, modificare esclusivamente le impostazioni relative ai profili ospitati in un percorso specifico.

Con lo script seguente è possibile rilevare il valore impostato per tutti gli utenti del dominio ICTPOWER.LOCAL , nel caso si voglia focalizzare la ricerca su una singola OU è necessario impostare il percorso corretto in SearchRoot

$Ricerca=New-Object DirectoryServices.DirectorySearcher
$Ricerca.Filter = ‘(&(objectCategory=person))’
$Ricerca.SearchRoot = ‘LDAP://DC=ICTPOWER,DC=LOCAL’
$Utenti = $Ricerca.FindAll()

foreach ($Utente in $Utenti) {
$Modifica = [ADSI] “$($Utente.Path)”
$Utente.path + ” ” + $Modifica.psbase.Invokeget(“terminalservicesprofilepath”)
}

Una volta individuati e verificati gli utenti a cui deve essere modificato il valore in AD è sufficiente utilizzare uno script come il seguente che permette di modificare esclusivamente i profili con un percorso preciso, sarà sufficiente definire le variabili $NuovoPath e $VecchioPath al fine di automatizzare completamente le impostazioni

$Ricerca = New-Object DirectoryServices.DirectorySearcher
$Ricerca.Filter = ‘(&(objectCategory=person))’
$Ricerca.SearchRoot = ‘LDAP://DC=ICTPOWER,DC=LOCAL’
$Utenti = $Ricerca.FindAll()
$NuovoPath = “\\dc02\newshare” # Imposta il nuovo valore per il percorso dei Roaming Profile
$VecchioPath = “\\dc01\olshare” # Ricerca/Filtra il percorso attualmente impostato

foreach ($Utente in $Utenti) {
$Modifica = [ADSI] “$($Utente.Path)”
$ValoreCorrente = $Modifica.psbase.Invokeget(“terminalservicesprofilepath“)

if ($VecchioPath -eq $ValoreCorrente)
{
$Modifica.psbase.Invokeset(“terminalservicesprofilepath”,$NuovoPath)
$Modifica.setinfo()
}
}

Terminati questi due passaggi, che è bene vangano eseguiti in rapida successione ogni utente al nuovo login tramite RDS utilizzerà le nuove impostazioni

Riferimenti

Panoramica sulla gestione degli User Profile Disk

Documentazione sul tool Robocopy

Il prossimo 4 Ottobre 2018 si terrà un evento gratuito presso la sede di Roma di Microsoft Italia.

L’evento sarà una tappa della edizione 2018 del ciclo di conferenze POWERCON, che storicamente rappresenta il marchio degli incontri formativi organizzati dalla Community ICTPower.

Durante la mattinata verranno affrontati da alcuni collaboratori della Community i temi più caldi di questo autunno: la prossima uscita di Windows Server 2019, le novità e i vantaggi offerti da Microsoft Azure ed uno sguardo al mondo open source.

Nicola Ferrini (Microsoft MVP Cloud e Datacenter Management), Gianluca Nanoia (Microsoft MVP Cloud e Datacenter Management) e Domenico Caldarelli (Senior Systems and Security Engineer) affronteranno in maniera dettagliata, offrendo le proprie esperienze sul campo, tematiche, problematiche e vantaggi nell’utilizzo delle ultime versioni dei software di casa Microsoft, con uno sguardo attento all’evoluzione di questi prodotti.

Vi aspettiamo il 4 Ottobre dalle 9:00 alle 13:00 presso la sede Microsoft in viale Avignone 10 a Roma.

La partecipazione è GRATUITA e la registrazione all’evento può essere effettuata al seguente link https://www.eventbrite.it/e/biglietti-powercon2018-evento-gratuito-il-4-ottobre-2018-presso-la-sede-microsoft-di-roma-50322001461

Agenda

In un’infrastruttura RDS, ma più in generale nelle connessioni in RDP, la sicurezza è più che mai importante, il fatto di poter identificare in modo univoco un server previene attacchi di tipo Man-in-the-Middle, e permette un accesso più lineare all’infrastruttura evitando all’utente una serie di fastidiose conferme per completare il logon.

In un perimetro Aziendale dove è disponibile una PKI configurata in modo da emettere certificati automaticamente secondo precisi template, è possibile definire una serie di impostazioni tramite Group Policy che automatizzano il processo di richiesta e rilascio dei certificati utilizzati dai vari server Session Host.

In questo articolo si assume che nel dominio in cui vengono installati i server RDS (Session Host) sia presente una PKI attivata secondo gli articoli che propongono le Best Practice di installazione e disponibili su ICTPower.

• Deploy PKI in Windows Server 2016 – Parte 1 Architettura di una PKI Two-Tier
• Deploy PKI in Windows Server 2016 – Parte 2 Installazione e configurazione di una Root CA Offline
• Deploy PKI in Windows Server 2016 – Parte 3 Installazione Subordinate CA

In un’installazione in cui il server RDS (Session Host) non è configurato per utilizzare una PKI Enterprise viene utilizzato un certificato autosegnato che è immagazzinato nello store macchina nel container Remote Desktop

Figura 1 Certificato Per RDS Session Host

All’atto della connessione, all’utente, è presentato un warning in quanto il certificato non è stato rilasciato da una Certification Authority attendibile, dove per attendibile in questo contesto si intende riconosciuta nell’ambito del perimetro del dominio aziendale.

Figura 2 Warning Client

È tuttavia possibile permettere il salvataggio locale di un hash del certificato in modo che per le successive sessioni di collegamento non venga riproposto il warning, questa impostazione ha valore esclusivamente nel contesto dell’utente che esegue la connessione.

Gestione automatizzata dei certificati RDS

L’ambiente Remote Desktop Services può essere configurato in modo da utilizzare un certificato pubblico per la cifratura delle connessioni, oppure può essere richiesto in modo automatico ad una CA interna, ed in questa modalità, tramite la configurazione di una GPO apposita l’intero processo può essere automatizzato in modo che il servizio RDS gestisca in autonomia richiesta e rinnovo del certificato stesso.

Creazione di un Template per RDS

Dopo aver installato e configurato la struttura PKI come descritto sopra, è necessario a partire da un template esistente crearne uno nuovo per l’utilizzo con RDS.

• Dalla console di management della Issuing CA nel ramo Templates è necessario duplicare un oggetto esistente e configurarne le proprietà in modo da essere utilizzato dal ruolo Session Host di RDS per la gestione dei certificati.

Facendo un click-destro su Certificate Template e selezionando Manage si apre l’intero elenco dei Template esistente

Figura 3 Gestione Template

• È da notare che l’elenco proposto posizionandosi sul ramo Certificate Template non è l’elenco completo di tutti gli oggetti di questo tipo presenti, ma solamente l’elenco di quelli che sono stati autorizzati al rilascio tramite l’opzione New/Certificate Template to Issue della console della PKI

Figura 4 Autorizzazione alla CA per Rilascio di Particolari Template

Procedendo con l’accesso alla gestione dei vari certificati tramite l’opzione Manage viene visualizzato l’elenco completo dei Template disponibili da cui, selezionato il Template Computer, si procede alla duplicazione.

Figura 5 Scelta e duplicazione del Certificato

• Il template di cui eseguire la copia non è vincolante, in generale è utile selezionarne uno che abbia già al suo interno una serie di impostazioni da non dover ridichiarare ex-novo. , in questa soluzione si propone di duplicare il Template Computer.
  

A questo punto è necessario procedere con la personalizzazione modificando via via i vari Tab necessari allo scopo

Compatibility TAB

La scelta della compatibilità dovrà essere coerente con la versione minima di CA del sistema operativo con cui verrà rilasciato e la versione minima di Sistema Operativo con cui potrà essere utilizzato.

Figura 6 Compatibilità del Template/Certificato

General TAB

Questo Tab permette l’impostazione del nome del nuovo template e della validità del certificato richiesto (ovviamente in coerenza con la validità massima impostata nella proprietà della PKI) è importante definire anche il Renewal Period ossia il tempo prima che scada il periodo di validità, cioè quanto la funzione di Auto Enroll richiedere nuovamente un certificato.

Figura 7 Definizione delle Proprietà Generali

Extension TAB

Nel nuovo Template dovremo anche modificare le opzioni di gestione delle estensioni disponibili in Extensions.

Le estensioni definiscono in modo puntuale come un certificato deve essere usato, secondo la RFC 5280

Nel Template che stiamo costruendo per RDS dovremo editare l’Extension Application Policy e rimuovere il riferimento a Client Authentication, in quanto questa estensione non verrà utilizzata.

Figura 7 Modifica dell’Extension Application Policy

Figura 8 Rimozione del Riferimento a Client Authentication

e successivamente aggiungere una nuova Application Policy con il riferimento all’OID 1.3.6.1.4.1.311.54.1.2 questo OID è specifico per gli scopi di autenticazione di RDS come è anche descritto nell’OID repository http://www.oid-info.com/

Figura 9 Descrizione OID relativo a RDS

Figura 10 Creazione dell’Application Policy Per RDS Authentication

Security TAB

Queste impostazioni relative alla sicurezza definiranno con precisione chi o cosa potrà utilizzare il Template dovremo quindi specificare quale gruppo di computer, normalmente questo permesso è concesso a tutti i computer che partecipano in join al dominio, ma a seconda delle esigenze è possibile ridurne l’accesso.

Figura 11 Verifica delle Sicurezza del Template

Dopo aver salvato il Template, si autorizza la CA alla pubblicazione di certificati in coerenza con i permessi di richiesta definiti sopra.

Figura 12 Abilizazione al Rilascio di Certificati

Figura 13 Selezione del Template Creato

A questo punto la parte relativa alla CA ed al template di gestione automatizzata è completata, è quindi necessario configurare una GPO affinché i server RDS utilizzino il template appena creato.

Configurazione della Group Policy per l’utilizzo del Template

Le impostazioni relative all’uso del Template per le connessioni RDS sono in

Computer Configuration -> Policies -> Administrative Template -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security,

è quindi necessario creare una GPO ed applicarla ai server RDS

Figura 14 Creazione GPO Dedicata

I settaggi da modificare saranno quindi la scelta del Template di certificato e la forzatura all’uso di uno specifico layer di sicurezza per le connessioni RDP.

Figura 15 Impostazione per l’uso di SSL

L’impostazione successiva prevede che si forzi RDS ad usare uno specifico template per la richiesta del certificato, il template sarà quello che è stato creato in precedenza

Figura 16 Definizione del Template nella GPO

Verifica delle configurazioni

Se le impostazioni sono corrette possiamo verificarne il funzionamento accedendo alle diverse componenti coinvolte

• Certification Authority
• Session Host
• Client

Controllo sulla CA

Collegandosi sulla Issuing-CA dovremmo trovare, nell’elenco dei certificati emessi, il corrispondente richiesto dal server RDS con il ruolo di Session Host.

Figura 17 Issuing-CA Verifica

E’ possibile notare che il certificato ha la validità specificata nel Template

In secondo luogo è possibile verificare che il server RDS Session HOST ha effettivamente il certificato rilasciato dalla CA nel proprio store di Macchina

Figura 18 Verifica del certificato sul server RDS

L’ultima componente che è possibile verificare è la sessione RDS client che dovrebbe riportare l’autenticazione tramite il certificato emesso.

La sessione risulta verificata anche tramite il certificato ed aprendone le proprietà si può rilevare il template da cui è stato generato il certificato stesso

Utilizzo di un nome differente dall’Host Name per la raggiungibilità del server RDS

La configurazione vista fin qui è indicata per un ambiente totalmente automatizzato e dove sono presenti uno o più RDS Session Host acceduti in modo diretto ognuno con il proprio FQDN.

In un ambiente dove sono comunque presenti più RDS Session Host acceduti con un nome FQDN unico o comunque differente dall’Host Name, la configurazione vista sopra non può essere utilizzata.

E’ il caso ad esempio dell’impiego del DNS come Sistema di bilanciamento di tipo Round Robin in cui un unico nome ha più di un indirizzo corrispondente.

La richiesta automatizzata dei singoli server, secondo quanto visto fin qui, avviene puntualmente secondo l’host name quindi verrebbe originato comunque un warning all’accesso.

Supponiamo di avere un Session Host che è raggiungibile oltre che con il proprio nome rdsh01srv.ictpower.local anche con un ulteriore CNAME ts.ictpower.local . Questa configurazione richiede che il certificato al suo interno disponga anche di un SAN (Subjetc Alternative Name) corrispondente alla CNAME, altrimenti all’accesso verrà visualizzato questo messaggio.

Figura 19 Warning per nome host non corrispondente

Tramite la soluzione vista sopra che mette assieme la PKI enterprise ed i relativi template è possibile creare un certificato che può essere utilizzato da RDS anche quando richiamato tramite una CNAME.

In uno scenario di questo genere non è possibile mantenere la totale automazione, ma si dovrà agire manualmente su ogni RDS server ed effettuare una richiesta “manuale” di certificato

Creazione del Template adatto per la definizione di SAN

Partendo dal Template duplicato in precedenza è necessario effettuare una nuova duplicazione (in modo da mantenere le impostazioni principali) avendo cura di modificare il tab Subject Name che dovrà essere variato, a differenza del Template creato in precedenza, impostandolo in modo da richiedere il nome host all’utente che genererà la richiesta.

Figura 20 Modifica del Tab apposito

Richiesta manuale del Certificato

Modificato il template è necessario impostare la CA in modo da emettere i certificati anche secondo questo nuovo modello seguendo i passi riportati in Fig. 12 e 13

Terminato questo secondo passaggio è necessario aprire lo store certificati macchina del Session HOST come in figura 18, e dal ramo Personal, si dovrà selezionare All Task/Request New Certificate

Figura 21 Richiesta Manuale

Confermando poi i passi successivi fin quando non vengono presentate le opzioni relative ai due Template creati, uno per il rilascio automatizzato ed un secondo per il rilascio manuale.

Dovremo selezionare quest’ultimo, che nel nostro esempio è stato creato con il nome di RdsSessionHostTemplate-SAN

Figura 22 Visualizzazione Template

In questa videata è anche indicato che sono richieste informazioni ulteriori per il rilascio del certificato, selezionando questa opzione verrà proposta una pagina dove potremo inserire manualmente i nomi alternativi, compreso il nome host nativo, per cui il certificato viene rilasciato.

Figura 23 Dichiarazione dei Nomi a Dominio

Terminata questa impostazione sarà sufficiente effettuare l’enroll del certificato che verrà sottoposto alla CA.

Al termine nello Store di macchina sarà disponibile il certificato richiesto, che sarà valido per entrambe i nomi specificati in precedenza

Figura 24 Certificato con i nomi richiesti tramite Template

Configurazione del Servizio RDS per l’uso del Certificato

Contrariamente a quanto è avvenuto nell’esempio precedente, dove tramite GPO è stato dichiarato il Template da Utilizzare, con questa procedura, si dovrà impostare manualmente il certificato nella configurazione del registry all’interno del ramo

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Dovrà essere creata una chiave di tipo BINARY con nome SSLCertificateSHA1Hash contenente il valore del Thumbprint del certificato emesso, valore che è rilevabile nelle proprietà del certificato stesso come illustrato nella figura successiva

Figura 25 Thumbrint del Certificato

Ottenuto il valore Esadecimale è necessario ripulirlo degli spazi ed impostarlo nella chiave di registro indicata sopra

Create the following registry value containing the certificate’s SHA1 hash to configure this custom certificate to support TLS instead of using the default self-signed certificate.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Value name:  SSLCertificateSHA1Hash
Value type:  REG_BINARY
Value data:  <certificate thumbprint>

Per impostare questo valore è possibile creare la chiave manualmente oppure per mezzo del seguente comando VMIC

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=”thumbrint del certificato“

prima di procedere con il riavvio del servizio RDS è utile controllare gli accessi alla chiave privata del certificato, di norma il servizio RDS è avviato con “Network Service” quindi questo servizio dovrà poter accedere alla lettura della chiave.

Figura 26 Accesso alla Chiave Privata

Verificata questa ultima impostazione è possibile eseguire il riavvio di RDS

net stop “Remote Desktop Services” && net start “Remote Desktop Services”

A questo punto la configurazione è terminata e richiamando il server RDS sia con il proprio nome host che con la CNAME vedremo che l’accesso è verificato tramite il certificato richiesto e configurato sopra.

Figura 27 Verifica del Funzionamento

Controllo del certificato in uso su RDS

Genericamente se si vuole verificare quale certificato è in uso dal servizio RDS è possibile utilizzare questo comando powershell che ne riporta il Thumbrint

Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”

Nota: l’intera procedura presentata qui è realizzata su un ambiente omogeneo CA-DC-RDS server di versione 2016, tuttavia è stata verificata anche in ambiente di produzione con CA di versione 2012R2-ed RDS server di versione 2008 R2.

Considerazioni

Apparentemente l’impiego di una CA configurata secondo i canoni presentati nelle guide riportate sopra, e la configurazione descritta qui, possono apparire superflue.

Tuttavia la realizzazione di un ambiente dove gli utenti non devono quotidianamente confermare inutili messaggi, da un lato fa si che, anche se di poco, l’accesso diventi più rapido, ma soprattutto nel momento in cui si presenti realmente il caso di una compromissione (di qualunque tipo) l’utente non sia assuefatto e abbia un atteggiamento più critico nei confronti di avvisi che non è abituato a considerare usuali.

Vedremo in un prossimo articolo, a completamento dell’intero sistema di firma e certificazione delle sessioni RDP come è possibile, sempre utilizzando una PKI firmare un file RDP in modo da fornire assoluta garanzia all’utente della sicurezza della connessione di lavoro.

Nell’articolo Gestione automatizzata dei certificati su connessioni RDS Session Host ed RDP abbiamo analizzato tutta la catena di impostazioni al fine di realizzare una sessione RDP verso un Session Host in modo cifrato e verificato tramite certificati generati da una PKI interna di livello enterprise.

In questo contesto tuttavia, quando l’utente attiva la sessione verso un RDS Session Host a partire da un file .RDP riceve ancora un avviso, un warning, relativo al fatto che il file che sta utilizzando non è proveniente da un autore attendibile.

Figura 1 Warning Autore Sconosciuto

A questo punto l’ultimo tassello che completa tutta la catena coinvolta nell’accesso ad un server in Remote Desktop è la Firma del file di connessione, questa firma avviene mediante l’utility RDPSIGN.EXE ed un certificato, rilasciato dalla CA interna, in grado di essere impiegato per il “Code Signing”

Generazione del certificato per il Code Signing

Come visto nell’articolo citato in precedenza anche per questo tipo di certificato è necessario utilizzare un Template disponibile sulla CA e già predisposto per la Firma del Codice, si consiglia di duplicare e modificare il template con un nuovo riferimento, eventualmente aumentando il periodo di validità, anche perché normalmente questi file vengono utilizzati da molti utenti per tempi abbastanza lunghi, di default la validità del certificato segnato con questo Template è di 1 anno.

TAB General

in questa videata dovremo impostare il nome del nuovo template e la validità del certificato

Figura 2 Generazione del Template

TAB Request Handling

Verifica dello scopo del certificato, non è necessario modificarne le impostazioni.

Figura 3 Scopo del Certificato

TAB Extensions

In questo TAB ritroviamo, analogamente alle impostazioni modificate per il certificato usato dalla connessione, la dichiarazione dell’OID. In questo caso non si modifica nulla, ma è possibile verificare comunque la dichiarazione

Figura 4 Descrizione dell’Estensione

Figura 5 Visualizzazione OID

Autorizzazione all’emissione del Certificato

Come per ogni altro oggetto, è possibile impostare una serie di opzioni di sicurezza per definire chi potrà richiedere un certificato mediante questo template, in questo esempio si ipotizza l’uso da parte di un gruppo di utenti incaricati della gestione delle connessioni RDP

Figura 6 Impostazione della Sicurezza

Conclusa la duplicazione del Template, ed autorizzata l’emissione dalla CA, è possibile richiedere un certificato UTENTE di tipo Code Signing con cui firmare il il file RDP di connessione.

La richiesta, avviene da una qualunque postazione connessa al dominio accedendo alla gestione certificati utente richiedendone uno personale

Figura 7 Richiesta Certificato

Ottenuto il certificato dalla CA (nello store Utente ) è necessario recuperare il Thumbprint e con questo procedere alla firma del file RDP che deve essere precedentemente creato con le informazioni di connessione.

Recupero del Thumbprint

Aprendo certificato nelle proprietà, è possibile rilevare il valore che dovremo usare successivamente per “firmare” il file .RDP di connessione

Figura 8 Individuazione del valore di Thumbprint

Individuato e trascritto (la copia negli appunti può dar luogo a malfunzionamenti dovuti a caratteri spuri) il Thumbprint dovremo creare il File di connessione con l’utility MSTSC.EXE

Figura 9 Salvataggio del file di connessione

A questo punto da una Shell comandi è sufficiente richiamare il seguente comando

Rdpsign /sha256 <valore-del-thumbprint> <nome-del-file-rdp>

Nel nostro caso il comando completo sarà

Rdpsign /sha256 5211a2f1f124d42bacd12e1178f735c75e3a9e35 rdsh01srv.rdp

Figura 10 firma del file .RDP

La connessione avverrà a questo punto indicando in modo preciso l’utente che ha creato il file di accesso e l’utilizzatore può verificarne l’attendibilità, ed eventualmente fare in modo che non venga richiesta questa ulteriore verifica.

Figura 11 Messaggio riportante in nome utente che ha firmato il file

Creazione di una GPO per la dichiarazione di certificati “Attendibili”

La procedura vista fin qui, assieme a quella riportata nell’articolo precedente, è utilizzabile per realizzare un accesso lineare all’infrastruttura RDS, tuttavia come abbiano visto, all’utente è ancora presentato un ultimo Warning come in figura 11.

Tramite la creazione di una GPO utente è possibile dichiarare uno o più Thumbprint di firma in modo che le sessioni originate dai file segnati con questi certificati propongano direttamente l’autenticazione. Il percorso per la configurazione della GPO è User Configuration–>Policies–>Administrative Templates–>Windows Components–>Remote Desktop Services–>Remote Desktop Connection Client e i parametri andranno inseriti nella configuraziobe Specify SHA1 thumbprints of certificates representing trusted .rdp publishers

Figura 12 Creazione della GPO

Terminata la Configurazione della Group Policy, ed applicata all’utente, l’accesso avverrà in modo lineare richiedendo direttamente l’autenticazione.

Note

Il file RDP di connessione, quando segnato, presenta al suo interno la firma eseguita dall’utility RDPSIGN e qualora venisse alterato nelle componenti “critiche” come ad esempio il nome host, il file risulterebbe invalido a prescindere dalla GPO applicata, in quanto la firma non sarebbe più valida e quindi verrebbe riproposto il warning di fig.1

Riferimenti:

installazione e configurazione di una PKI Enterprise

Deploy PKI in Windows Server 2016 – Parte 1 Architettura di una PKI Two-Tier

Deploy PKI in Windows Server 2016 – Parte 2 Installazione e configurazione di una Root CA Offline

Deploy PKI in Windows Server 2016 – Parte 3 Installazione Subordinate CA

Rdpsign

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/rdpsign

Windows Admin Center è un’applicazione basata su browser, distribuita a livello locale per la gestione di server, cluster, infrastrutture iper-convergenti e client. Un’evoluzione delle console di gestione, Server Manager o MMC, facile da installare e senza costi aggiuntivi.

Durante la #POWERCON2018 che si è tenuta in Microsoft Italia il 4 Ottobre, ho analizzato le funzionalità della nuova applicazione e ne ho enfatizzato l’utilizzo con tutte le versioni dei sistemi operativi supportati, da Windows Server 2008 R2 a Windows Server 2019. Di seguito un video che descrive in dettaglio come Windows Admin Center cambierà il modo di gestire le nostre infrastrutture.

Sono disponibili anche le slides della sessione all’indirizzo https://www.ictpower.it/download/Windows_Admin_Center_La_rivoluzione_della_gestione_di_Windows_Server.pptx

• Proteggere le macchine virtuali Hyper-V con Windows Admin Center e Azure Site Recovery
• Backup di Windows Server in Microsoft Azure con Windows Admin Center
• Windows Server 2019 e Windows Admin Center: le novità previste per il prossimo autunno

Windows Admin Center (WAC) è la nuova console di gestione basata su HTML5 che Microsoft ha rilasciato gratuitamente per Windows Server 2008 R2 e successive versioni di Windows Server. Invito chi di voi non abbia ancora dimestichezza con questa nuova interfaccia o ne volesse conoscere le potenzialità a visualizzare il video Windows Admin Center: la rivoluzione della gestione di Windows Server

In questo articolo vi mostrerò come effettuare il backup del System State di Windows Server 2019 utilizzando Windows Admin Center (WAC) e Azure Backup.

La versione di WAC utilizzata è la 1809, che ci permette una facile integrazione con il Cloud con pochi clic e offre la possibilità di utilizzare l’autenticazione di Azure Active Directory, la multi-factor authentication e la protezione delle VM con Azure Site Recovery, oltre al Backup di Windows Server di cui tratteremo in questa guida. Per scaricare l’ultima versione di Windows Admin Center potete visitare la pagina Introduzione a Windows Admin Center

Integrazione con Microsoft Azure

La prima operazione da effettuare è integrare la vostra installazione di Windows Admin Center con Microsoft Azure. Per poterlo fare è necessario possedere una Sottoscrizione di Azure. I passaggi da effettuare sono davvero semplici e sono:

• Posizionarsi nei Settings cliccando sul pulsante a forma di ingranaggio
• Cliccare sul nodo Azure
• Cliccare suk tasto Register
• Copiare il codice generato e incollarlo nella pagina di Device Login
• Loggarsi in Azure
• Effettuare la registrazione del dispositivo
• Autorizzare il dispositivo aggiunto alla lettura degli account di Azure AD per le successive autenticazioni

Nelle schermate sottostanti potete visualizzare tutti i passaggi:

Figura 1: Integrazione di Windows Admin Center con Microsoft Azure

Figura 2: Creazione del codice per la registrazione del Device

Figura 3: Device Login in Microsoft Azure

Figura 4: Autenticazione alla sottoscrizione di Microsoft Azure

Figura 5: Registrazione del Device effettuata

Figura 6: Autorizzazione dell’applicazione alla lettura degli account di Azure AD per le autenticazioni

Figura 7: Integrazione con Azure AD completata

Backup di Windows Server con Microsoft Azure Backup e Windows Admin Center

Una volta completata la procedura di integrazione con Microsoft Azure (che si effettua una volta sola), possiamo utilizzare la funzionalità di Backup offerta da Windows Admin Center.

Anche in questo caso le operazioni da effettuare sono semplici:

• Dopo aver selezionato il server da proteggere, collegatevi al nodo Backup
• Cliccate su Set up Azure Backup
• Fate clic su Login per effettuare la connessione ad Azure
• Scegliete dal menù a tendina la sottoscrizione da utilizzare
• Scegliete un Backup Vault (esistente o createne uno nuovo) che ospiterà i vostri dati
• Scegliete Resource Group e Region dove trasferire i vostri dati
• Scegliete quale disco proteggere (se il vostro server ne ha più di uno)
• Scegliete la Retention Policy e la Encryption
  Passphrase per proteggere il vostro backup

Figura 8: Backup di un server con Azure Backup

Figura 9: Login al portale di Microsoft Azure

Figura 10: Configurazione del disco da proteggere, della Retention Policy e della Encryption Passphrase

Al termine delle configurazioni, sul server verrà automaticamente installato e configurato l’Azure Backup Agent e verrà creato il job per la protezione del vostro server.

Figura 11: Creazione di Azure Recovery Vault che ospiterà il nostro backup

Figura 12: Download, installazione e configurazione di Azure Backup Agent sul server da proteggere

Figura 13: Crazione delle policy e del job di backup sul server da proteggere

Dopo qualche minuto di attesa, sarà possibile visualizzare dalla console di Windows Admin Center lo stato di protezione del nostro server ed eventualmente procedere alla configurazione della Backup Policy tramite i link presenti. Potete anche visualizzare nel portale di Azure il Backup Vault che avete creato e tra i Backup Items potrete vedere il server aggiunto, come mostrato nelle figure sotto:

Figura 14: Schermata di Azure Backup in Windows Admin Center

Figura 15: Visualizzazione del Backup Vault dal portale di Azure

Figura 16: Backup Items protetti da Azure Backup Agent

In qualsiasi momento potrete lanciare un backup direttamente dal portale, senza aspettare la schedulazione impostata. Cliccando sul pulsante Backup now potrete infatti effettuare un backup manuale e seguirne poi l’andamento. Dalla console saranno visibili i Job in esecuzione e la durata degli stessi. Nel mio caso l’upload del System State è durato in nedia 45 minuti.

Figura 17: Lancio di un Backup manuale dalla console di Windows Admin Center

Figura 18: Notifiche sullo stato di Backup e sui Job in esecuzione

Figura 19: Modifica della programmazione del Backup e modifica della Retention Policy

Figura 20: Backup effettuato ed Overwiew dello stato dei backup della macchina

Figura 21: la console offre una panoramica di tutte le operazioni effettuate

Ripristino dei dati

Per effettuare il ripristino dei dati al momento non è possibile utilizzare Windows Admin Center. Nella versione 1809 di WAC infatti non è ancora disponibile nessun pulsante per il Restore. L’operazione deve essere effettuata collegandosi direttamente al server protetto e lanciando la console di Microsoft Azure Backup.

Dalla console è possibile gestire tutte le funzionalità ed è possibile lanciare il wizard Recover Data per il ripristino del System State.

Figura 22: console di gestione di Microsoft Azure Backup sul server protetto

Figura 23: Opzione Recover Data e lancio del wizard per il ripristino del System State

Figura 24: Scelta del ripristino del System State

Figura 25: Scelta del punto di ripristino del System State

Figura 26: Scelta della cartella dove effettuare il download del System State presente in Azure

Figura 27: Schermata di conferma del wizard di ripristino del System State

Figura 28: Ripristino del System State in corso

Conclusioni

L’integrazione di Windows Admin Center con Microsoft Azure Backup permette di poter effettuare in maniera molto semplice il backup nel Cloud e di allontanare i nostri dati in maniera sicura e pratica. Al momento la funzionalità è in Preview e non c’è ancora il Restore, ma ormai è ben chiaro qual è il trend tecnologico che Microsoft sta offrendo alle nostre infrastrutture. Il Cloud Ibrido diventerà con Windows Admin Center ancora più semplice.

Il 24 settembre 2018 è stato rilasciato Office 2019 che come indicato nel post Office 2019 is now available for Windows and Mac pubblicato sul blog di Microsoft 365 prevede una serie novità per quanto riguarda versioni e distribuzione. Innanzi tutto con Office 2019 si intende la versione on-premises di Word, Excel, PowerPoint, Outlook, Project, Visio, Access e Publisher, mentre è anche disponibile ovviamente la versione cloud-connected Office 365 ProPlus. Office 2019 è indicato per clienti che non sono ancora pronti per il cloud o che necessitano per qualsivoglia motivo di avare l'applicazione on-premises.

Va precisato però che Office 2019 non ha tutte le nuove features che sono state rese disponibili in Office 365 ProPlus negli ultimi tre anni, Office 2019 è infatti una versione unica e non riceverà aggiornamenti per le future funzionalità, mentre Office 365 ProPlus verrà aggiornato mensilmente con nuove funzionalità (come collaborazione innovativa, intelligenza artificiale , sicurezza e altro). Office 2019 non riceverà aggiornamenti che introducono nuove funzionalità ma solo security e stability updates.

Per una panoramica delle nuove funzionalità rese disponibili in Office 2019 si veda il post Office 2019 is now available for Windows and Mac e la KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions mentre per il confronto delle edizioni disponibili per il mercato Business, ovvero Office Standard 2019 e Office Professional Plus 2019, si veda Compare suites available through volume licensing.

Informazioni generali sulla suite Office 2019

Office 2019 è disponibile a partire dal 2 ottobre 2019, per ulteriori informazioni si veda la KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions in cui sono riportate tra le altre anche alcune informazioni relative alle modifiche della suite

La suite Office 2019 per Windows è composta dalle seguenti applicazioni Word, Excel, PowerPoint, Outlook, Publisher, Access, Project e Visio e riceverà solo aggiornamenti per correggere bug di sicurezza e di funzionamento:

“Office 2019 is now available as a one-time purchase for commercial users. Office 2019 is available for both Windows and macOS, and includes classic versions of Word, Excel, PowerPoint, and Outlook. The Windows version also includes Publisher 2019, Access 2019, Project 2019, and Visio 2019. Office 2019 applications don’t receive feature updates but do receive regular security and stability updates.”

OneNote è stato sostituito da OneNote for Windows 10 ovvero dalla app:

“With the introduction of Office 2019, OneNote for Windows 10 replaces OneNote 2016 as the default OneNote experience on Windows for Office 365 and Office 2019. OneNote for Windows 10 is included with Windows 10. If you’d prefer to use OneNote 2016, you can install it at any time, including as part of a volume install with the Office Deployment Tool. There are no similar changes for OneNote for Mac: it will install as part of Office 2019, if it is not already present, and includes additional functionality for Office 2019 customers. It also remains available as a free download from the Apple App Store.”

“When you install Office 365 or Office 2019, you’ll get OneNote for Windows 10 by default. If you’d prefer to use OneNote 2016, you can install it at any time. We’ll soon be sharing more details about how to do this.”

“OneNote 2016 is available together withOffice 2019 and is governed by the Office 2016 Lifecycle Support Policy.”

Per ulteriori informazioni si vedano anche What’s the difference between OneNote and OneNote 2016? e Frequently Asked Questions about OneNote in Office 2019.

Sebbene la strategia di Microsoft sia quella di puntare Office 365 e quindi sul cloud, si intende comunque supportare i clienti che necessitano dell’applicazione on-premises e sono state pianificate anche versioni successive a Office 2019:

“Most of our cloud-powered innovation is coming to Office 365 and Microsoft 365. However, we recognize that some customers can’t move to the cloud in the near term. We want to support all our customers in their journey to the cloud, at the pace that makes the most sense to them.”

“Moving to the cloud is a journey with many considerations along the way. Therefore, we remain committed to on-premises customers and plan to do additional releases post Office 2019.”

I documenti creati con versioni precedenti di Office saranno compatibili con Office 2019:

“People who use Office 365, Office 2016, Office 2013, and Office 2010 applications can open documents created by using Office 2019 without any additional action.”

Office 2019 non necessita della connessione Internet per il suo utilizzo e anche gli aggiornamenti possono essere eseguiti in modalità disconnessa:

“No, you don’t have to be connected to the Internet to use the Office 2019 applications, such as Word 2019, Excel 2019, and PowerPoint 2019, because the applications are fully installed on your computer.”

“Although updates for Office 2019 are made available through the Internet, they can be hosted on-premises for disconnected networks.”

Per ulteriori approfondimenti si vedano anche:

• Overview of Office 2019 (for IT Pros)
• What’s New in Office 2019
• What’s new in Access 2019
• What’s new in Excel 2019 for Windows
• What’s new in Outlook 2019 for Windows
• What’s new in PowerPoint 2019 for Windows
• What’s new in Project 2019
• What’s new in Visio 2019
• What’s new in Word 2019 for Windows

Requisiti di sistema e politiche di supporto

Come indicato nella KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions
Office 2019 godrà di 5 anni di supporto mainstream più 2 di supporto extended e l’installazione sarà supporta su Windows 10 Semi-Annual Channel, Windows 10 Enterprise Long-Term Servicing Channel (LTSC) 2018 e sulla prossima release LTSC di Windows Server (non sarà possibile eseguire su un computer contemporaneamente Office 2019 e Office 2016):

“Microsoft Office 2019 for Windows provides 5 years of mainstream support plus two 2 years of extended support as an exception to the 10-year Fixed Lifecycle Policy term. This seven-year term aligns with the support period for Office 2016.

Office 2019 is supported on the following:

• Any supported Windows 10 Semi-Annual Channel
  
• Windows 10 Enterprise Long-Term Servicing Channel (LTSC) 2018
  
• The next LTSC release of Windows Server”
  

“Office 2019 is not supported on Windows 7 or Windows 8.

For Office 365 installed on Windows 7 or Windows 8:

• Windows 7 with Extended Security Updates (ESU) is supported through January 2023.
  
• Windows 7 without ESU is supported through January 2020.
  
• Windows 8.1 is supported through January 2023.”
  

“No. Office 2019 and Office 2016 cannot run concurrently on either Windows or Mac.”

Come indicato nelle Search product lifecycle per Office 2019 il Mainstream Support terminerà il 10 ottobre 2023 e l’Extended Support il 14 ottobre 2025.

Per quanto riguarda i requisiti hardware e software, come indicato in System requirements for Office, le suite Office Standard 2019 e Office Professional Plus 2019 richiedono:

• Processore: 2.0 GHz o superiore con 2 core
• Memoria: 4 GB per la versione a 64 Bit e 2 GB per la versione a 32 Bit
• Spazio su disco: 4 GB
• Sistema operativo: Windows 10 o Windows Server 2019
• Requisiti video: risoluzione dello schermo 1280 x 768
• Requisiti grafici: DirectX 9 successivo con WDDM 2.0 o superiore per Windows 10 o WDDM 1.3 o superiore per Windows 10 Fall Creators Update
• Browser: Microsoft Edge, Internet Explorer, Chrome o Firefox
• .NET Framework: alcune feature possono richiedere .NET 3.5 o 4.6 e superiore

Office 2019 è disponibile sia a 32 bit che a 64 bit, per un’analisi sui motivi che possono indurre ad installare la versione a 64 bit o 32 bit si veda Choose between the 64-bit or 32-bit version of Office, in ogni caso se non vi sono motivi specifici, come indicato anche nella sessione sessione What’s new in Microsoft Office 2019 for IT deployment (BRK3260) tenuta in occasione di Microsoft Ignite Content 2018, è raccomandato l’utilizzo della versione a 64 bit. A riguardo si veda anche Overview of Office 2019 (for IT Pros) in cui viene indicato che la versione a 64 bit è raccomandata in computer con più di 4 GB di RAM:

“All products in the Office 2019 are available in both 32-bit and 64-bit versions. We recommend 64-bit on computers that have 4 gb or more of memory. But you should assess application compatibility and other factors that might require you to use the 32-bit version.”

Deploy

Come indicato nella KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions
Office 2019 utilizzerà soltanto la tecnologia Click-to-Run e non sarà disponibile un file MSI d’installazione:

“The Office 2019 client applications use Click-to-Run installation technology only. We will not provide an MSI file as a deployment method for Office 2019 clients. We will continue to provide an MSI file for Office Server products.”

Per quanto riguarda il deploy la novità principale è che non sarà più disponibile un file MSI, ma verrà utilizzata la tecnologia Click-to-Run (C2R) introdotta in Office 2013 che permette sia upgrade path verso Office 365 ProPlus che in-place upgrade di versioni di Office precedenti basate su MSI. Inoltre C2R offre vantaggi in termini di sicurezza grazie ai predictable monthly security updates e riduce il traffico di rete perché si basa sulla tecnologia Windows 10 download optimization. Per ulteriori informazioni si veda la KB4086177 Office 2019 perpetual volume license products available as Click-to-Run.

Scendendo nel dettaglio per gestire il deploy è possibile utilizzare l’Office Deployment Tool (ODT), mentre l’Office Customization Tool (OCT) che era utilizzato in gestire l’installazione tramite Windows Installer (MSI) non è più utilizzato. Questo significa che i file di installazione di Office 2019 sono disponibili in Internet sull’Office Content Delivery Network (CDN) anziché nel Volume Licensing Service Center (VLSC). Di conseguenza è possibile installare Office 2019 direttamente dalla rete CDN Office oppure è possibile scaricare i file di installazione dalla rete CDN Office in un percorso nella rete locale come, ad esempio, una cartella condivisa e installare poi Office 2019 da tale posizione. Sebbene sia consigliata l’installazione direttamente dalla rete CDN Office che richiede un minimo overhead amministrativo vi possono essere scenari in cui sono presenti vincoli che impediscono l’installazione direttamente da Internet come assenza di connettività a Internet o larghezza di banda limitata.

A riguardo si veda anche Overview of Office 2019 (for IT Pros) in cui viene indicato che Office 2019 sarà installato sul drive di sistema e on sarà possibile modificare questa impostazione, mentre per quanto riguarda gli aggiornamenti non sarà possibile il download granulare di security update o bug fix:

“Office 2019 is installed on the system drive, which is usually the C:\ drive. The installation location can’t be changed.”

“Updates to Office 2019, such as security updates and bug fixes, can be configured to be automatically downloaded and installed from the Office CDN. Individual downloads for each security update or bug fix aren’t available.”

Per scaricare i file di installazione di Office 2019 dalla rete CDN Office ed installare il prodotto è possibile utilizzare la seguente procedura.

Passo 1: Scaricare lo strumento di distribuzione di Office dall’area Download Microsoft

E’ possibile scaricare lo strumento di distribuzione di Office (ODT) aggiornato dal seguente link Office Deployment Tool disponibile come download gratuito, in alternativa l’ODT è anche disponibile nel Volume Licensing Service Center (VLSC). E’ consigliabile scaricare e utilizzare sempre la versione più recente di ODT, al momento è disponibile la versione 10810.33603 del 8/17/2018. L’ODT può essere eseguito su sistemi operativi client Windows 7 e successivo o su sistemi operativi server Windows Server 2008 R2 e successivi.

Una volta scaricato l’eseguibile dell’ODT eseguirlo per estrarre i file in esso contenuti ovvero setup.exe, EULA e i file di configurazione XML configuration-Office365-x86.xml e configuration-Office365-x64.xml.

Il file setup.exe è l’ODT ed è uno strumento da riga di comando tramite cui è possibile eseguire il download e installazione di Office 2019, mentre i file di configurazione XML sono degli esempi introduttivi. Il file di configurazione XML viene utilizzato per fornire le impostazioni all’ODT da utilizzare per il download o l’installazione di Office 2019. Il file di configurazione XML può essere semplicemente modificato in un editor di testo come ad esempio Blocco note, inoltre è possibile modificare il nome del file purché venga mantenuta l’estensione xml del file. Per informazioni ed esempi relativi al file xml si veda Sample configuration.xml file to use with the Office Deployment Tool.

Passo 2: Impostare i file xml di configurazione per il download di Office 2019

Per creare un file di configurazione xml per il download di Office 2019 a 64 bit in una cartella è possibile copiare il file di modello configuration-Office365-x64.xml e modificarlo opportunamente, il file di configurazione XML da utilizzare verrà specificato quando si esegue l’ODT da un prompt dei comandi con privilegi elevati.

Di seguito il contenuto di un file di configurazione di esempio per il download di Office Pro Plus 2019 a 64 bit in lingua italiana che verrà denominato download-Office2019ProPlusITA-x64.xml:

<Configuration>
<Add SourcePath=”C:\Downloads\OfficeProPlus2019x64IT” OfficeClientEdition=”64″ Channel=”PerpetualVL2019″>
<Product ID=”ProPlus2019Volume”>
<Language ID=”it-it” />
</Product>
<Product ID=”ProofingTools”>
<Language ID=”it-it” />
</Product>
</Add>
</Configuration>

Per avviare il download è possibile eseguire il seguente comando con privilegi elevati:

setup.exe /download download-Office2019ProPlusITA-x64.xml

Si noti che quando si scarica Office 2019 dalla rete CDN Office il prodotto comprende gli aggiornamenti cumulativi rilasciati fino a quel momento.

Passo 3: Impostare i file xml di configurazione per installare Office 2019

Per creare un file di configurazione xml per il download di Office 2019 a 64 bit in una cartella è possibile copiare il file di modello configuration-Office365-x64.xml e modificarlo opportunamente, il file di configurazione XML da utilizzare verrà specificato quando si esegue l’ODT da un prompt dei comandi con privilegi elevati.

Di seguito il contenuto di un file di configurazione di esempio per l’installazione di Office Pro Plus 2019 a 64 bit in lingua italiana che verrà denominato configure-Office2019ProPlusITA-x64.xml, nell’esempio verrà esclusa dall’installazione l’applicazione Publisher, verranno disinstallate le eventuali versioni precedenti che utilizzano Windows Installer (MSI) come la tecnologia di installazione e verrà visualizzata l’interfaccia grafica durante l’installazione, ma le condizioni di licenza saranno accettate automaticamente senza essere visualizzate:

<Configuration>
<Add SourcePath=”C:\Downloads\OfficeProPlus2019x64IT” OfficeClientEdition=”64″ Channel=”PerpetualVL2019″>
<Product ID=”ProPlus2019Volume”>
<Language ID=”it-it” />
<ExcludeApp ID=”Publisher” />
</Product>
<Product ID=”ProofingTools”>
<Language ID=”it-it” />
</Product>
</Add>
<Display Level=”Full” AcceptEULA=”TRUE” />
<RemoveMSI All=”True” />
</Configuration>

Per avviare l’installazione è possibile eseguire il seguente comando con privilegi elevati:

setup.exe /configure configure-Office2019ProPlusITA-x64.xml

Per ulteriori approfondimenti sull’upgrade a Office 2019 si veda Overview of Office 2019 (for IT Pros) in cui viene indicato che è raccomandata la rimozione versioni precedenti che fanno uso di Windows Installer (MSI) come la tecnologia di installazione (a riguardo si veda Remove existing MSI versions of Office when upgrading to Office 365 ProPlus):

“We recommend that you uninstall existing versions of Office before you deploy Office 2019. If you’re uninstalling previous versions of Office products that were installed with Windows Installer (MSI), the Office Deployment Tool can remove most of those for you as part of the installation of Office 2019.”

Analoghe considerazioni sono state fatte nella sessione What’s new in Microsoft Office 2019 for IT deployment (BRK3260) tenute in occasione di Microsoft Ignite Content 2018.

Per ulteriori informazioni sullo strumento di distribuzione di Office (ODT) si vedano anche Overview of the Office Deployment Tool e Configuration options for the Office Deployment Tool.

Aggiornamento

Dopo l’installazione di Office 2019 occorrerà mantenerlo aggiornato per installare gli aggiornamenti della protezione e quelli qualitativi, ovvero gli aggiornamenti che forniscono miglioramenti della stabilità o delle prestazioni per Office, come detto precedentemente per Office 2019 non verranno rilasciati aggiornamenti per quanto riguarda nuove funzionalità. Generalmente gli aggiornamenti di Office 2019 verranno rilasciati una volta al mese, il secondo martedì del mese.

Come indicato in Update Office 2019 (for IT Pros) l’adozione della tecnologia Click-to-Run comporta anche alcune modifiche nella gestione degli aggiornamenti rispetto a quanto avveniva con Windows Installer (MSI):

• Quando sono disponibili aggiornamenti per Office 2019 Microsoft rilascia una build di Office 2019 che include tutti gli aggiornamenti più recenti qualità e sicurezza e la rende disponibile tramite l’Office Content Delivery Network (CDN) su Internet. Ciò significa che non esistono download separati per aggiornamenti della protezione e/o qualitativi in quanto gli aggiornamenti sono cumulativi e l’ultima versione di Office 2019 disponibile nell’Office Content Delivery Network (CDN) e include tutti gli aggiornamenti rilasciati nelle versioni precedenti di Office 2019.
• Per impostazione predefinita Office 2019 è configurato per essere aggiornato automaticamente direttamente dall’Office Content Delivery Network (CDN), ma tale impostazione può essere modificata.
• Sui computer in cui è installato Office 2019 esiste un’attività pianificata denominata ” Office Automatic Updates 2.0″ che ricerca eventuali aggiornamenti ad intervalli regolari.
• Gli aggiornamenti vengono scaricati automaticamente quando disponibili senza che sia necessario alcun intervento da parte dell’utente, durante il processo di download vengono confrontate la versione di Office presente sul computer e quella presente in nell’Office Content Delivery Network (CDN) e sulla base di tale confronto viene eseguito il download soltanto dei componenti necessari.
• Durante il download gli utenti possono continuare ad utilizzare le applicazioni di Office, mentre quando vengono installati gli aggiornamenti se le applicazioni di Office sono aperte agli utenti verranno richiesto di salvare il proprio lavoro e chiudere le applicazioni.
• Dal momento che gli aggiornamenti cumulativi sono inclusi nella build più recente di Office 2019 disponibili nell’Office Content Delivery Network (CDN) non si utilizza Microsoft Updates o Windows Server Updates Services (WSUS) per aggiornare Office 2019. Per aggiornare e gestire gli aggiornamenti di Office 2019 è possibile usare System Center Configuration Manager che consente di controllare quando e dove vengono applicati gli aggiornamenti.

Quindi in sintesi se la connettività di rete e non vi sono impedimenti dovuti all’organizzazione dell’infrastruttura IT è consigliabile che Office 2019 venga aggiornato automaticamente dall’Office Content Delivery Network (CDN) come da impostazione predefinita.

Se invece non si desidera aggiornare Office 2019 tramite l’Office Content Delivery Network (CDN) è possibile configurare Office 2019 per ottenere gli aggiornamenti da una cartella condivisa dalla rete interna, ma sarà comunque necessario che un computer acceda all’Office Content Delivery Network (CDN) e scarichi l’ultima versione di Office 2019 nella cartella condivisa nella rete interna. Questo tipo di approccio basato sull’utilizzo di una cartella condivisa nella rete interna richiede ovviamente un carico amministrativo maggiore in quanto è necessario tenere traccia di quando le nuove versioni di Office 2019 sono disponibili e scaricare la versione aggiornata di Office 2019 nella cartella condivisa, anche in questo caso durante il download in una cartella condivisa in rete locale viene scaricata sempre una copia completa della versione aggiornata di Office 2019. Per informazioni sulle versioni di Office 2019 rilasciate si veda Update history for Office 2019.

Come anticipato precedentemente è possibile utilizzate System Center Configuration Manager per aggiornare Office 2019 e la posizione di ricerca degli aggiornamenti da parte di Office 2019 può essere specificata tramite il file di configurazione xml utilizzato per eseguire il deploy tramite lo strumento di distribuzione di Office (ODT), oppure tramite i criteri di gruppo di Office 2019 che possono essere scaricati al seguente Administrative Template files (ADMX/ADML) and Office Customization Tool for Office 365 ProPlus, Office 2019, and Office 2016.

Per ulteriori approfondimenti si veda la sessione What’s new in Microsoft Office 2019 for IT deployment (BRK3260) tenuta in occasione di Microsoft Ignite Content 2018 in cui sono state fornite una serie di informazioni più approfondite su come gestire gli aggiornamenti analizzando i tre scenari:

• Cloud Managed Deployment (ovvero l’utilizzo dell’Office CDN);
• Locally Managed Deployment (ovvero l’utilizzo di una File Share o DFS);
• Enterprise Managed Deployment (ovverol’utilizzo di System Center Configuration Manager).

Di seguito gli schemi di funzionamento dei tre scenari:

L’utilizzo di System Center Configuration Manager, come anticipato precedentemente, consente un maggior controllo sull’aggiornamento della versione configurando opportunamente la Detection Rule in base al valore della chiave di registro HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\VersionToReport.

Attivazione

Come indicato nella la KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions è possibile attivare Office 2019 tramite chiavi KMS o MAK (sia via Internet che offline per telefono), ovvero il processo rimane invariato rispetto ad Office 2016:

“The activation methods for Office 2019 are the same as they were for Office 2016:

• If you use KMS keys, then you have to set up a 2019 KMS Host to activate against.
  
• If you use MAK keys, then you can either activate over the Internet (recommended) or if offline, activate over the telephone.”
  

Per maggiori dettagli si veda Overview of volume activation of Office in cui sono fornite maggiori informazioni sui tre scenari di attivazione prodotto disponibili per l’attivazione di licenze a volume di Office 2019:

• Key Management Service (KMS) in cui l’attivazione avviene contattando un host KMS nella rete locale;
• Multiple Activation Key (MAK) in cui l’attivazione avviene contattando i server di attivazione Microsoft tramite Internet o via telefono;
• Active Directory-based tramite cui è possibile attivare le copie di Office installate in computer a dominio.

Conclusione

Per ulteriori approfondimenti si vedano le sessioni What’s new in Microsoft Office 2019 for IT deployment (BRK3260), What’s new in Office 2019 for features and deployment (BRK1077), Delivery Optimization deep dive: How to reduce internet bandwidth impact on your network (BRK3019) tenutesi in occasione di Microsoft Ignite Content 2018 (il catalogo delle sessioni è disponibile al seguente https://myignite.techcommunity.microsoft.com/sessions).

Per Office 365 è disponibile in Preview il tool Office 365 Customization Tool per la creazione online dei file XML di configurazione utilizzati dallo strumento di distribuzione di Office (ODT) per la gestione del download, deploy e configurazione di Office 365, stando ai feedback nella pagina Overview of Office 2019 (for IT Pros) tale tool dovrebbe supportare anche Office 2019 entro la fine del 2018.

Windows Admin Center (WAC) è la nuova console di gestione basata su HTML5 che Microsoft ha rilasciato gratuitamente per Windows Server 2008 R2 e successive versioni di Windows Server. Invito chi di voi non abbia ancora dimestichezza con questa nuova interfaccia o ne volesse conoscere le potenzialità a visualizzare il video Windows Admin Center: la rivoluzione della gestione di Windows Server

In questo articolo vi mostrerò come proteggere macchine virtuali create in Hyper-V con Windows Server 2019 utilizzando Windows Admin Center (WAC) e Azure Site Recovery.

La versione di WAC utilizzata è la 1809, che ci permette una facile integrazione con il Cloud con pochi clic e offre la possibilità di utilizzare l’autenticazione di Azure Active Directory, la multi-factor authentication e il Backup di Windows Server, oltre alla protezione delle VM con Azure Site Recovery di cui tratteremo in questa guida. Per scaricare l’ultima versione di Windows Admin Center potete visitare la pagina Introduzione a Windows Admin Center

Se volete approfondire le funzionalità di Azure Site Recovery vi invito alla lettura degli articoli sulla protezione delle macchine fisiche e delle macchine virtuali con Azure Site Recovery

IMPORTANTE: Le macchine virtuali locali replicate in Azure devono soddisfare i requisiti per le VM di Azure riepilogati in questa tabella: https://docs.microsoft.com/it-it/azure/site-recovery/hyper-v-azure-support-matrix#azure-vm-requirements

Figura 1: Architettura della replica da Hyper-V ad Azure (senza VMM)

Integrazione con Microsoft Azure

La prima operazione da effettuare è integrare la vostra installazione di Windows Admin Center con Microsoft Azure. Per poterlo fare è necessario possedere una Sottoscrizione di Azure. I passaggi da effettuare sono davvero semplici e sono:

• Posizionarsi nei Settings cliccando sul pulsante a forma di ingranaggio
• Cliccare sul nodo Azure
• Cliccare suk tasto Register
• Copiare il codice generato e incollarlo nella pagina di Device Login
• Loggarsi in Azure
• Effettuare la registrazione del dispositivo
• Autorizzare il dispositivo aggiunto alla lettura degli account di Azure AD per le successive autenticazioni

Nelle schermate sottostanti potete visualizzare tutti i passaggi:

Figura 2: Integrazione di Windows Admin Center con Microsoft Azure

Figura 3: Creazione del codice per la registrazione del Device

Figura 4: Device Login in Microsoft Azure

Figura 5: Autenticazione alla sottoscrizione di Microsoft Azure

Figura 6: Registrazione del Device effettuata

Figura 7: Autorizzazione dell’applicazione alla lettura degli account di Azure AD per le autenticazioni

Figura 8: Integrazione con Azure AD completata

Protezione delle macchine virtuali con Microsoft Azure Site Recovery e Windows Admin Center

Una volta completata la procedura di integrazione con Microsoft Azure (che si effettua una volta sola), possiamo utilizzare la funzionalità di protezione delle VM offerta da Windows Admin Center.

Anche in questo caso le operazioni da effettuare sono semplici. La prima operazione consiste nel configurare un Recovery Services Vault dentro il quale saranno replicate le macchine virtuali. Selezionate il nodo Virtual Machines dal Windows Admin Center e cliccate sul link Set Up Now. Scegliete la Sottoscrizione da utilizzare, il Resource Group e il Recovery Services Vault, come mostrato in figura:

Figura 9: configurazione dell’host Hyper-V con Azure Site Recovery

Dopo qualche minuto, quando si sarà installato il Recovery Services Provider, il vostro host Hyper-V sarà configurato per replicare le VM in Azure. Il completamento dell’operazione viene notificato in Windows Admin Center.

Figura 10: Configurazione dell’host Hyper-V completata

Protezione delle macchine virtuali

Per proteggere le macchine virtuali è sufficiente selezionare la VM e dal menù More scegliere la voce Protect VM. La prima volta che proteggete una macchina vi verrà chiesto in quale Storage Account volete salvare i vostri dati. Potete utilizzare uno storage account esistente o creare uno nuovo.

Figura 11: Protezione della macchina virtuale da Windows Admin Center

Figura 12: Creazione dello Storage Account per conservare i dati della VM

Una volta avviata la protezione della VM i dati cominceranno ad essere inviati al Recovery Services Vault. È possibile monitorare la replica sia dall’Hyper-V Manager che dal portale di Azure.

Figura 13: Monitoraggio della replica della VM direttamente dall’Hyper-V Manager

Figura 14: Site Recovery Jobs visualizzati dal portale di Azure

Per visualizzare l’infrastruttura creata potete selezionare il Recovery Services Vault e dalla scheda Overview selezionare il tab Site Recovery e mostrare l’infrastructure view Hyper-V, come mostrato in figura:

Figura 15: Hyper-V Replica Site creato in Azure

Terminata la sincronizzazione iniziale, la cui durata dipenderà dalla banda a vostra disposizione, sarà possibile verificare la replica dal Windows Admin Center, dall’Hyper-V Manager che dal portale di Azure. Dal Windows Admin Center potete cliccare, nell’area Disaster Recovery Status sul link View in Azure per poter essere reindirzzati al blade corretto nel portale di Azure.

Figura 16: Protezione della VM effettuata e visualizzazione in Windows Admin Center

Collegatevi al portale Azure e verificate che non ci siano dei problemi e degli errori, sia per la replica che per la configurazione della VM in Azure. Visualizzate gli eventuali errori e seguite le raccomandazioni per la risoluzione. Riceverete sicuramente almeno due errori, uno relativo al Resource Group dentro il quale verrà posizionata la macchina virtuale e l’altro relativo alla VNET a cui collegarla quando vorrete effettuarne il Failover, come mostrato in figura:

Figura 17: È necessario completare le configurazioni della VM in Azure

Per poter effettuare il failover della VM è necessario prima risolvere i problemi di configurazione che sono evidenziati nel portale. Cliccate sul link You need to configure virtual machine’s resource group before doing a
failover e dal blade Compute and Network , cliccando su Edit, modificate le informazioni richieste (Resource Group, Size della VM, Virtual Network e Network interfaces). Non è possibile creare la VNET ed il Resource Group al momento della configurazione, quindi devono essere già esistenti e si devono necessariamente trovare nella stessa Region del Recovery Services Vault. Terminata la configurazione fate clic su Save.

Figura 18: Problemi di configurazione evidenziati nel portale

Figura 19: Modifica del Resource Group, della Target Newtork e del tipo di interfaccia di rete

La configurazione della VM è completata e da questo momento in poi la vostra macchina potrà essere accesa in Azure in caso di disastro.

Failover Test

È buona norma testare il Failover per verificare che la macchina sia stata replicata correttamente. Dal portale di Azure cliccate sul pulsante Test Failover e scegliete il Recovery Point da testare e la VNET a cui collegare la macchina virtuale, come mostrato in figura:

Figura 20: Test Failover della VM

Collegatevi alla VM che sarà stata creata (NomeDellaVM-test) ed effettuate tutti i controlli del caso per verificare che la macchina possa essere avviata in Azure e che tutti i servizi e le applicazioni installate siano funzionanti.

Figura 21: Verifica delle funzionalità della VM

Al termine delle operazioni potete eseguire il Cleanup Test Failover, che cancellerà la VM di test.

Figura 22: Cleanup Test Failover ed eliminazione della VM di test

Conclusioni

L’integrazione di Windows Admin Center con Microsoft Azure Site Recovery permette di poter effettuare con molta facilità il Disaster Recovery della nostra infrastruttura e delle nostre macchine virtuali. L’implementazione nativa di questa funzionalità permette di poter costantemente proteggere le nostre VM e di poter rimediare facilmente ai disastri, oltre alla possibilità di poter testare periodicamente che i nostri dati si siano replicati con successo e che siano sempre disponibili.

Una delle funzionalità più interessanti che riguardano i dischi gestiti delle macchine virtuali utilizzate in Azure è la possibilità di catturarne uno snapshot da poter poi successivamente riutilizzare. Ho già parlato dei dischi gestiti in un precedente articolo intitolato Migrazione dei dischi delle macchine virtuali in Azure a Managed Disks

Lo snaphost dei dischi gestiti (managed disks) può essere fatto sia per il disco del sistema operativo sia per gli eventuali dischi dei dati aggiunti alla VM e può essere catturato anche a macchina accesa.

La cattura dura pochissimi secondi e subito dopo lo snapshot potrà essere scaricato dal cloud per dei test oppure potrà essere riutilizzato per creare delle nuove VM o per riprisitnare la VM esistente.

Lo snapshot può anche essere riutilizzato per ricreare la stessa macchina virtuale. Basterà associare un nuovo disco gestito allo snapshot creato.

Creazione dello snapshot

In questa guida voglio mostrarvi come ripristinare il disco di sistema di una Azure VM accesa. Selezionate la VM nel portale di Azure e successivamente selezionate il ramo Disks. Selezionate il disco di cui volete catturare lo snapshot (nel mio caso è il disco del sistema operativo) e fate clic sul pulsante Create Snapshot. Nel blade che si aprirà date un nome allo snapshot, scegliete il Resource Group dove inserirlo e scegliete l’Account type.

Figura 1: Creazione dello snapshot del disco del sistema operativo

Figura 2: Configurazione del disco di snapshot

Dopo pochissimi secondi lo snapshot del disco sarà disponibile nel portale di Azure. Potete visualizzarlo tramite le risorse di tipo Snapshot.

Figura 3: Lo Snapshot è visibile e gestibile dal portale di Azure

Se volete esportare lo snapshot è sufficiente cliccare su Export e generare un URL per il download del disco, come mostrato in figura

Figura 4: Esportazione del disco di Snapshot

La creazione dello snapshot può ovviamente essere effettuata anche da PowerShell:

#Connessione ad Azure
Connect-AzureRmAccount

#Impostazione dei parametri
$resourceGroupName = ‘NESTED’
$location = ‘francecentral’
$vmName = ‘TRAINER’
$snapshotName = ‘OSbackup’

#Selezione della VM
$vm = get-azurermvm -ResourceGroupName $resourceGroupName -Name $vmName

#Creazione della configurazione dello snapshot. In questo esempio verrà eseguito uno snapshot del disco del sistema operativo
$snapshot = New-AzureRmSnapshotConfig -SourceUri $vm.StorageProfile.OsDisk.ManagedDisk.Id -Location $location -CreateOption copy

#Creazione dello snapshot
New-AzureRmSnapshot -Snapshot $snapshot -SnapshotName $snapshotName -ResourceGroupName $resourceGroupName

Figura 5: Creazione dello snapshot del disco di sistema di una VM tramite PowerShell

Gli snapshot sono visibili dal portale di Azure visualizzando il nodo Snapshots.

Utilizzo degli Snapshot come hard disk secondari per le VM esistenti

Se volete collegare uno snapshot ad una VM per poter accedere al contenuto o per effettuare il troubleshooting o semplicemente perché si tratta di un disco dati che volete clonare, potete effettuare le seguenti operazioni:

1. Collegarvi al nodo Disks della macchina virtuale
2. Cliccare su Add data disk e selezionare un Managed disk esistente oppure crearne uno nuovo cliccando su Create Disk
3. Se volete creare un nuovo Managed Disk, nel blade che vi si aprirà scegliete il Nome e mettete come Source
   Type Snapshot, scegliendo dal menù a tendina lo snapshot esistente

È importante ricordare che lo snapshot si deve trovare nella stessa sottoscrizione e nella stessa Region della VM

Figura 6: Aggiunta di un disco dati alla Azure VM accesa

Figura 7: Creazione di un Managed Disk partendo da uno Snapshot

Cliccate sul pulsante Save e in pochi secondi il disco sarà stato aggiunto alla vostra Azure VM accesa. Andando in Gestione Dischi vedrete che il disco è offline. Portatelo online e assegnategli una lettera, per poter accedere al contenuto del disco

Figura 8: Disco dati aggiunto alla VM

Figura 9: Il nuovo disco aggiunto è visibile all’interno della VM in gestione disco

Ripristino del disco del sistema operativo partendo da uno Snapshot

Può capitare che a volte torni utile ripristinare una VM ad uno stato precedente del sistema. Prima di fare delle operazioni rischiose molto spesso catturiamo dei checkpoint della VM, in modo tale da poter annullare modifiche che abbiano compromesso il sistema.

Purtroppo in Azure non abbiamo accesso all’Hyper-V e quindi non possiamo catturare un checkpoint della VM per poi farne il revert in caso di problemi. È possibile però avere lo stesso risultato utilizzando gli snapshot dei dischi.

I passaggi sono molto semplici:

1. Catturare uno snapshot dei dischi da proteggere (a VM accesa)
2. Creare un managed disk utilizzando lo snapshot catturato (tramite portale o tramite PowerShell)
3. Applicare il managed disk creato come disco del sistema operativo della VM (tramite PowerShell) nel caso sia necessario tornare indietro nel tempo (revert)

L’operazione viene fatta senza dover cancellare la VM e ricrearla.

Prima di tutto ho catturato uno snapshot del disco di sistema della VM chiamata TRAINER (a VM accesa) e subito dopo ho creato dal Portale di Azure un disco gestito chiamato Snapshot Trainer collegato allo snapshot

Figura 10: Creazione del disco gestito associato allo snapshot

Ho effettuato alcune operazioni all’interno della VM, disinstallando dei programmi ed eliminando dei file.

Per ripristinare lo stato della VM (revert) ho eseguito lo script PowerShell che sostituisce il disco del sistema operativo della macchina TRAINER. Lo script è stato eseguito a macchina virtuale accesa, ma sarà necessario un riavvio della VM per il suo completamento. L’operazione è durata meno di un minuto.

#Connessione ad Azure
Connect-AzureRmAccount

#Impostazione dei parametri
$resourceGroupName = ‘NESTED’
$location = ‘westeurope’
$vmName = ‘TRAINER’
$diskName = ‘SnapshotTrainer’
$vm = Get-AzureRmVM -ResourceGroupName $resourceGroupName -Name $vmName
$disk = Get-AzureRmDisk -ResourceGroupName $resourceGroupName -Name $diskName

Set-AzureRmVMOSDisk -VM $vm -ManagedDiskId $disk.Id -Name $disk.Name

Update-AzureRmVM -ResourceGroupName $resourceGroupName -VM $vm

Figura 11: Ripristino del disco di sistema partendo da uno snapshot

Ripristino della VM effettuato!!!

Clonazione di una Azure VM partendo dallo snapshot di un disco di sistema

Se avete necessità di clonare una macchina virtuale in Azure, perché avete bisogno di fare dei test oppure dovete fare troubleshooting senza voler toccare la macchina in produzione è possibile utilizzare questi semplici passaggi:

1. Catturare uno snapshot del disco di sistema da clonare (a VM accesa o spenta)
2. Creare un managed disk utilizzando lo snapshot catturato (tramite portale o tramite PowerShell)
3. Utilizzare il managed disk creato come disco del sistema operativo di una nuova (tramite portale o tramite PowerShell)

Come prima operazione quindi catturate lo snapshot del disco di sistema. Come ho già detto, per poter utilizzare uno snapshot è necessario associarlo ad un disco gestito (Managed Disk). Create una nuova risorsa dal portale di Azure e scegliete Managed Disks. Dal blade che si aprirà date un nome al disco e come Source type scegliete Snapshot, selezionando dal menù a tendina il Source Snapshot che desiderate associare.

Figura 12: Creazione di un disco gestito (managed disk) associato allo snapshot creato

Il disco gestito creato è adesso nello stato Unattached. Per poter visualizzare i dischi non collegati potete aggiungere la colonna Disk State dopo aver visualizzato i dischi nel portale di Azure, come mostrato nelle 2 figure sotto:

Figura 13: Visualizzazione della colonna Disk State

Figura 14: Il disco creato ha il disk state Unattached

Creazione di una nuova VM partendo da un disco Unattached

Dopo aver selezionato il disco creato è possibile creare una nuova macchina virtuale facendo clic sul pulsante Create VM. Completate le informazioni richieste per la creazione della VM e attendete l’avvio. Avrete clonato la macchina di partenza

Figura 15: Creazione della VM partendo da un disco gestito

Figura 16: L’immagine da cui parte la VM è il disco gestito da cui abbiamo creato dallo snapshot

Nel giro di pochi minuti la vostra VM sarà avviata e vi potrete loggare. Trattandosi di una macchina clonata, prestate attenzione a quale virtual network la collegate, per non avere problemi di nomi duplicati nella rete.

Figura 17: La macchina virtuale clonata è avviata

Conclusioni

La clonazione di una VM in Azure è un’operazione veramente semplice. Gli snapshot dei dischi gestiti ci permettono di poter clonare un disco del sistema operativo o un disco dati in pochissimi secondi, dandoci la possibilità anche di esportarli e di collegarli alle nostre VM. In questo modo abbiamo la possibilità di fare troubleshooting o test sulle nostre VM, senza toccare la produzione e senza dare downtime. Se invece abbiamo bisogno di ripristinare velocemente uno stato precedente del sistema, possiamo sfruttare la stessa funzionalità offerta dai checkpoint creati con gli hypervisor on-premises.

Da un paio di giorni è stato rilasciato ufficialmente Exchange Server 2019, il sistema di messaggistica on-premises di Microsoft. Tra le novità più evidenti c’è certamente quella di poterlo installare in Windows Server 2019 e successivi e poterlo installare in Windows Server Core, che è anche l’installazione consigliata. L’installazione di Exchange Server 2019 in un computer che esegue Nano Server non è invece supportata.

Per maggiori informazioni sulle novità di Exchange Server 2019 vi rimando alla lettura dell’annuncio Exchange Server 2019 Now Available

Figura 1: Novità di Exchange Server 2019

Prerequisiti

Verificate alla pagina https://docs.microsoft.com/it-it/exchange/plan-and-deploy/prerequisites?view=exchserver-2019 che abbiate tutti prerequisiti per l’installazione:

• Verificare che il livello di funzionalità della foresta di Active Directory sia Windows Server 2012 R2 o versioni successive
• Verificare i requisiti per il sistema operativo Windows
• Verificare che il computer faccia parte del dominio
• Installare gli aggiornamenti di Windows più recenti

Procedete al download della ISO di Exchange Server 2019 dal Volume Licensing Service Center oppure da MSDN

Figura 2: Download della ISO di Exchange Server 2019 da MSDN

Installazione e configurazione di Windows Server 2019 Core

Procuratevi la ISO di Windows Server 2019 è installatelo in modalità Core. Potete installare sia la versione Windows Server 2019 Standard che la versione Windows Server 2019 Datacenter.

NOTA: Al momento della stesura di questo articolo (25/10/2018) la ISO di Windows Server 2019 non è disponibile per il download, perché Microsoft ne ha sospeso il rilascio il 12/10/2019. Per maggiori informazioni potete leggere l’annuncio Windows Server 2019 – now generally available!

Io avevo già scaricato la ISO , che userò in questa guida.

Figura 3: Installazione di Windows Server in modalità Core

Terminata l’installazione di Windows Server in modalità Core nella macchina dentro la quale vorremo installare Exchange Server 2019 abbiamo bisogno di assegnare un indirizzo IP statico e di aggiungere il server ad un dominio esistente. Do per scontato che abbiate già un Domain Controller ed un dominio (nel mio caso il dominio è ictpower.lab).

Per configurare la scheda di rete è necessario prima individuare il suo InterfaceIndex. Per farlo è sufficiente lanciare il seguente comando PowerShell:

Get-NetIPAddress

Figura 4: Schede di rete installate sul server

Nel mio caso la scheda da configurare ha un InterfaceIndex=2. Ho quindi eseguito questi comandi PowerShell per configurare l’indirizzo IP, la subnet mask, il default gateway ed il DNS:

New-NetIPAddress -InterfaceIndex 2 -IPAddress 10.10.10.11 -PrefixLength 8 -DefaultGateway 10.0.0.254

Set-DNSClientServerAddress -InterfaceIndex 2 -ServerAddress 10.10.10.10

Figura 5: Configurazione della rete di Windows Server Core

Ho anche aggiunto la macchina al dominio con il comando PowerShell:

Add-Computer -DomainName ictpower.lab -NewName EX1 -DomainCredential ictpower\administrator -Restart

Figura 6: Aggiunta della macchina server Core al dominio

Ovviamente le stesse configurazioni è possibile effettuarle utilizzando il tool sconfig.exe disponibile in Windows Server.

Figura 7: Per configurare server Core è anche possibile utilizzare il tool sconfig.exe

Installazione delle funzionalità di Windows Server e del software aggiuntivo necessario all’installazione di Exchange

Prima di installare Exchange Server 2019 è necessario installare alcuni ruoli di Windows, in particolare i Media Services e i tools per gestire Active Directory, che contengono anche i moduli PowerShell di AD.

Loggatevi come amministratore e lanciate il comando PowerShell:

Install-WindowsFeature Server-Media-Foundation, RSAT-ADDS

Figura 8: Installazione dei Media Services e dei tools per gestire Active Directory

Il passo successivo consiste nell’installare UCMA (Microsoft Unified Communications Managed API 4.0), che si trova nel cd di installazione di Exchange Server 2019. Se state utilizzando una macchina virtuale potreste montare la ISO di Exchange Server 2019 direttamente alla VM. Io ho invece scaricato la ISO sul domain controller e la monterò in Server Core con il comando:

#Monto la ISO di Exchange Server 2019, che si trova in una share di rete
Mount-DiskImage \\DC1\c$\mu_exchange_server_2019_x64_dvd_5fa4d915.iso

Al virtual drive che ha collegato l’immagine ISO, nel mio caso, è stata assegnata la lettera E:

Spostatevi nella cartella E:\UCMARedist e lanciate il setup.exe per installare UCMA (Microsoft Unified Communications Managed API 4.0)

Figura 9: Installazione di UCMA (Microsoft Unified Communications Managed API 4.0)

Installazione di Exchange Server 2019

Terminata l’installazione dei prerequisiti possiamo passare all’installazione di Exchange Server 2019. Portatevi nella root dell’immagine e lanciate il comando PowerShell

.\Setup.exe /m:install /roles:m /IAcceptExchangeServerLicenseTerms /OrganizationName:ICTPower /InstallWindowsComponents

L’installazione proseguirà senza problemi. Vi ricordo che Exchange Server 2019 si può installare solo in Windows Server 2019, quindi se non verranno rispettati i prerequisiti riceverete un messaggio di errore.

Figura 10: Installazione di Exchange Server 2019

Installazione tramite GUI

Anche se state utilizzando Windows Server 2019 Core potrete installare Exchange Server 2019 con un wizard grafico, come fareste nella versione Desktop Experience di Windows Server. Lanciate dalla root del disco di Exchange il comando setup.exe e seguite il wizard. Nelle schermate sotto potete visualizzate tutti i passaggi:

Figura 11: lancio del wizard grafico per l’installazione di Exchange Server 2019

Figura 12: Accettazione della licenza d’uso

Figura 13: Utilizzo della configurazione predefinita

Figura 14: Selezione dei ruoli di Exchange Server 2019 da installare

Figura 15: Scelta della cartella d’installazione

Figura 16: Scelta del nome dell’organizzazione di Exchange

Figura 17: Abilitazione dell’anti Malware

Figura 18: Configurazione dei prerequisiti

L’installazione prosegue senza errori. Se non verranno rispettati i prerequisiti riceverete un messaggio di errore, come quello mostrato in figura:

Figura 19: L’analisi dei prerequisiti riporta i messaggi di errore, da correggere per completare l’installazione

Conclusioni

L’installazione di Exchange Server 2019 In Windows Server 2019 Core è molto semplice e lineare e permette di poter evitare di utilizzare la versione Desktop Experience, che avendo molti più software a bordo, richiede anche maggiori patch e maggiori riavvii in caso di aggiornamenti.

Il prossimo 14 marzo 2018 si terrà un evento gratuito nell’Aula 2 del Palazzo delle Aule presso il Campus universitario “Ernesto Quagliariello” in via Orabona 4 – Bari.

Organizzato dalla Community ICT Power, con la partecipazione di DotNetSide, in collaborazione con Studenti Indipendenti, Università di Bari e Microsoft Student Partner, vedrà la partecipazione di studenti, professionisti e curiosi.

L’evento apre di fatto il primo ciclo di conferenze POWERCON, che storicamente rappresenta il marchio degli incontri formativi organizzati dalla Community ICTPower.

• Vito Macina (Microsoft Most Valuable Professional e Digital Strategist) e Gianluca Nanoia (Microsoft Most Valuable Professional e Security Expert), membri della Community ICT Power, vi faranno conoscere Windows 10 oltre ogni limite, dando particolare rilievo alle ultime novità introdotte nell’ultima versione Fall Creators Update e mostrandovi qualche anteprima della prossima
• Fabio Cozzolino, fondatore della Community DotNetSide, ci mostrerà le Connected Mobile Apps attraverso l’utilizzo di Microsoft Azure
• Giulio Mallardi (Solution Architect), anch’egli membro di ICT Power, ci parlerà di come il Cloud sia diventato un punto fondamentale per lo sviluppo di soluzioni innovative.

Vi aspettiamo quindi il 14 marzo dalle 15:00 alle 18:30 al Campus universitario.

Non mancate!

ISCRIZIONE NON RICHIESTA

E’ già passato qualche mese da quando sul Windows Store è disponibile KALI Linux, una distribuzione creata per contenere tutti i tools utilizzati durante un Penetration Test. Avevo sicuramente sottovalutato le sue potenzialità, perché immaginavo fosse più un giocattolino che un vero e proprio ambiente di lavoro per PenTesters. Dopo averla provata a fondo, però, mi sono completamente ricreduto, e posso garantirvi che questa particolare distribuzione installata come APP grazie a WSL non ha nulla da invidiare ad un sistema operativo installato nativamente su macchina virtuale. Non sarà forse paragonabile ad un’installazione su macchina fisica, ad esempio per la mancanza di controllo sui driver delle schede di rete, ma è sicuramente uno strumento dalle grandissime potenzialità.

Vediamo come installare tutto il necessario per trasformare la nostra macchina Windows 10 in una PenTest Box oltre ogni limite!

Il primo passo è quello di abilitare la funzionalità WSL, di cui abbiamo ampiamente parlato in altre occasioni, ma ripassarne i passaggi è più veloce che rimandarvi agli articoli precedenti.

Utilizzando il menu start apriamo “Attiva o disattiva funzionalità di Windows”

Selezioniamo quindi “Sottosistema Windows per Linux” e confermiamo con OK

Al termine dell’operazione sarà necessario un riavvio

Dopo il riavvio possiamo aprire Microsoft Store e cercare KALI

Selezioniamo quindi “Ottieni” per iniziare il download di circa 170MB

Ed una volta completato possiamo avviare l’installazione del pacchetto selezionando “Avvia”

Sarà avviato un processo di installazione, che si concluderà con un breve wizard

Verranno richiesti un nome utente ed una password, che costituiranno la coppia di credenziali per l’utente di default della sessione Linux. Questo utente è completamente separato dall’utente Windows e sarà quello che effettuerà il login al momento dell’apertura dell’APP KALI.

Avviando Kali non sarà necessario inserire la password dell’utente se non al momento di eseguire operazioni che prevedano privilegi amministrativi (su Linux). Tali operazioni, come ad esempio l’installazione di pacchetti software) dovranno essere quindi eseguite attraverso il comando sudo (superuser do).

Lo screenshot seguente mostra l’esecuzione del wizard, al termine del quale eseguiamo il comando

cat /etc/os-release

che per convenzione su tute le distribuzioni Linux ci restituisce informazioni sulla distribuzione in uso.

A questo punto abbiamo un vero KALI linux a disposizione sulla nostra macchina Windows 10, ma sono necessarie un po’ di operazioni prima di poter iniziare ad effettuare i nostri penetration test.

Aggiorniamo subito le informazioni disponibili online circa i repository utilizzati dal tool apt-get che ci permetterà di installare in modo automatico i pacchetti software disponibili per KALI da noi scelti. Eseguiamo per questo scopo il comando

sudo apt-get update

Come anticipato poco fa, l’utente con cui siamo loggati sulla macchina non ha privilegi amministrativi (lo capiamo perché il prompt termina con il simbolo $) e quindi per eseguire l’operazione anteponiamo il comando sudo. Il sistema si occuperà di verificare la nostra identità chiedendoci di inserire la password, ed eseguirà quindi il comando

Ora che i repository sono aggiornati possiamo avviare l’aggiornamento completo della distribuzione. Utilizziamo sempre sudo prima del comando, anche se questa volta non ci sarà chiesta la password, poiché in questa sessione ormai siamo stati autorizzati. Il comando che aggiornerà l’intera distribuzione è

sudo apt-get dist-upgrade

Poco dopo il sistema è a nostra disposizione per l’utilizzo.

Bene, siamo arrivati al momento del disclaimer: testare la sicurezza di un sistema è sicuramente un processo molto utile a tutti quelli che erogano servizi in rete, e che gestiscono sistemi all’interno dei quali sono custodite informazioni a volte anche molto riservate. Il Penetration testing prevede l’esecuzione di tool che se utilizzati in maniera non responsabile possono causare danni anche molto gravi, ed è fondamentale che chi gestisce l’obiettivo di questi test sia a conoscenza del processo in corso. Probabilmente per questo motivo la pubblicazione di KALI sul Windows store è stata limitata ad una macchina “vuota”, senza cioè alcun software preinstallato; in questo modo l’utente non troverà migliaia di programmini pronti all’uso ma sarà costretto ad installare ognuno di essi al momento del bisogno. Per avere idea del numero di tool disponibili su KALI è possibile visualizzare il contenuto di questa pagina https://tools.kali.org/tools-listing.

A questo proposito, infatti, tutti i tools di penetration testing vengono considerati nocivi da parte dei software antivirus ed antimalware, così se vogliamo installare qualcuno di questi pacchetti sulla nostra KALI su WSL dobbiamo prima escludere la cartella che contiene il filesystem di KALI dall’analisi del nostro antivirus. Non completando questa operazione gli eseguibili verranno immediatamente cancellati dal sistema antivirus. Per aggiungere l’eccezione necessaria se utilizziamo Windows Defender possiamo procedere in questo modo:

In primo luogo individuiamo la cartella che contiene il sistema operativo linux con un piccolo trucchetto. Sappiamo che le app dello store vengono installate in %localappdata%\Packages, ma per evitare confusione e risparmiare un po’ di tempo possiamo ricavare il percorso con questa procedura:

Dopo aver aperto una qualsiasi shell di KALI, cerchiamo nel task manager il processo bash.exe e selezioniamo “Apri percorso file” dopo aver fatto click col tasto destro su quel processo

Sapremo immediatamente il percorso del file bash, che utilizzeremo per ricavare la root del filesystem, che si trova due livelli più in basso. Copiamo quindi dalla barra degli indirizzi il percorso della cartella fermandoci alla cartella “rootfs“, come visibile in questo screenshot. Facciamo attenzione a non selezionare anche le sottocartelle successive usr e bin altrimenti non escluderemo dal controllo dell’antivirus l’intero filesystem.

Nel mio caso il percorso è C:\Users\PenTest\AppData\Local\Packages\KaliLinux.54290C8133FEE_ey8k8hqnwqnmg\LocalState\rootfs

Andiamo quindi ad aggiungere questa cartella alle esclusioni del Windows Defender, iniziando da impostazioni:

Aggiornamento e sicurezza

Apri Windows Defender Security Center

Protezione da virus e minacce

Impostazioni di Protezione da virus e minacce

Aggiungi un’esclusione -> Cartella

Incolliamo il percorso del filesystem che abbiamo ricavato in precedenza e clicchiamo su Selezione cartella

E verifichiamo che il percorso sia ora presente tra le eccezioni

A questo punto siamo davvero pronti per installare i nostri software ed iniziare a testare la sicurezza dei nostri sistemi. Ricordiamo che solo i package utilizzabili da riga di comando sono supportati, anche se installando un server grafico sarà possibile installare una interfaccia. Non ritengo questa funzione interessante perché, almeno personalmente, l’unico tool di KALI che utilizzo da interfaccia grafica è BurpSuite, per il quale esiste un ottimo porting per Windows.

Alcuni esempi di pacchetti utilizzabili con WSL sono whatweb (information gathering sui domini), dirb e nikto (discovery di cartelle sui siti web), hydra (brute force), john the ripper (password cracking), sqlmap (sql injection tool), joomscan (scansione vulnerabilità di un sito joomla), wpscan (scansione vulnerabilità di un sito wordpress), e soprattutto metasploit, un framework sempre aggiornatissimo che contiene tools per effettuare scansioni di vulnerabilità ed eventualmente exploitarle.

Una nota particolare va fatta per nmap, il tool di scanning di porte e servizi per eccellenza: essendo le APP linux eseguite in user mode non abbiamo la possibilità di creare i RAW socket, caratteristica fondamentale per questo tool; non sarà quindi possibile utilizzare la versione per KALI. Nulla ci vieta però di installare nmap per Windows, che ha le stesse funzionalità. Effettuiamo il download dal sito ufficiale (https://nmap.org/download.html) e lo installiamo come un qualsiasi software per Windows. Creiamo poi un alias da KALI per richiamare da shell l’eseguibile presente nel filesystem Windows con il comando

alias nmap="/mnt/c/Program\ Files\ \(x86\)/Nmap/nmap.exe"

in questo modo possiamo eseguire nmap da KALI come se fosse installato su linux.

L’installazione di altri pacchetti è molto semplice, installiamo ad esempio dirb con

sudo apt-get install dirb

Ed installiamo l’intero framework metasploit con

sudo apt-get install metasploit-framework

Ora siamo davvero pronti ad effettuare il nostro Penetration Test e ricordiamo sempre che questi tool permettono di attaccare un sistema remoto, quindi utilizziamoli esclusivamente con l’autorizzazione del gestore di quel sistema.

Se siete all’inizio e per ora volete solo divertirvi a capire e scoprire l’arte del Penetration Testing esistono molti siti che propongono delle vere e proprie sfide, mettendo alla prova i provetti PenTesters dando loro accesso ad applicativi o macchine virtuali volutamente vulnerabili.

Il mio preferito è senza dubbio www.vulnhub.com, dal quale è possibile scaricare delle macchine virtuali in formato OVA, quindi per VirtualBox o VMware e provare a penetrarle. Inizialmente sembrerà una missione impossibile ma iniziando da uno sguardo attento alle soluzioni di gente più esperta potremo pian piano imparare i metodi di attacco utilizzati dagli hacker, in modo tale da poterci difendere in qualunque situazione. In rete infatti cercando i “walkthrough” delle relative macchine è possibile trovare sempre qualcosa di molto interessante.

Un altro sito interessante è www.hackthissite.org, una community che previa registrazione gratuita mette a disposizione script e applicativi vulnerabili da provare a forzare.

Mai come alla fine di questo articolo auguro buon divertimento e buon lavoro a tutti!

Per il 2° anno consecutivo, grazie ai tanti feedback positivi manifestati nelle edizioni precedenti, Accademia del Levante, in collaborazione con la Community ICT Power, ospiterà il prossimo 12 dicembre 2018, a partire dalle ore 15:00, un seminario completamente gratuito dedicato a Windows 10. Verrà analizzato il primo triennio dell’ultimo sistema operativo di Microsoft, le principali novità dell’October 2018 Update e le novità del Windows Subsystem for Linux, il quale ora ci permette di trasformare il nostro Windows 10 in una preziosa PentTest Box.

Concludiamo il 2018 con questo evento in presenza per testimoniare ancora una volta l’importanza dell’essere presenti sui territori e realizzare momenti aperti a tutti coloro che hanno sete di conoscenza.

Per tutti i presenti all’evento ci sarà, come sempre, la possibilità di ricevere un attestato di partecipazione e degli utili gadget.

Agenda

Per le iscrizioni potete fare riferimento a questo modulo online.

Ci vediamo prestissimo a Bari!

Visto il successo dell’articolo Windows Server 2016 – Quali sono le differenze tra la Standard Edition e la Datacenter Edition, ho pensato di raccogliere in questo estratto le novità più salienti di Windows Server 2019 e descrivere le differenze tra le due versioni dei sistema operativo: La Standard e la Datacenter.

Tra le novità introdotte in questa versione vi descrivo solo quelle che ritengo più interessanti:

Esperienza desktop

La funzionalità Esperienza desktop (Desktop Experience) è nuovamente disponibile in Windows Server 2019. Non è stata infatti inserita in Windows Server, versione 1709, Windows Server, versione 1803 e Windows Server, versione 1809, le versioni del Canale Semestrale che sono state rilasciate nei mesi passati e che come probabilmente saprete, sono solo in versione Core, senza Desktop Experience.
Come per Windows Server 2016, durante l’installazione del sistema operativo è possibile scegliere tra le installazioni Server Core o Server con Esperienza desktop.

Informazioni dettagliate di sistema

Informazioni dettagliate di sistema (System Insights) è una nuova funzionalità disponibile in Windows Server 2019 che offre la possibilità di effettuare analisi predittive per Windows Server, grazie alla gestione effettuato con Windows Admin Center. Queste funzionalità predittive, ognuna abbinata a un modello di apprendimento automatico, analizzano localmente i dati di sistema di Windows Server, ad esempio i contatori delle prestazioni e gli eventi, fornendo dati approfonditi in merito al funzionamento dei server e contribuendo a ridurre i costi operativi associati alla gestione reattiva delle problematiche di Windows Server.

Windows Defender Advanced Threat Protection (ATP)

Sensori avanzati e azioni di risposta di ATP sono capaci di intercettare gli attacchi a livello di memoria e kernel e rispondono eliminando i file dannosi e terminando i processi dannosi.

• Per altre informazioni su Windows Defender ATP, vedi Panoramica delle funzionalità di Windows Defender ATP
• Per ulteriori informazioni sull’onboarding di server, vedi Eseguire l’onboarding dei server al servizio Windows Defender ATP

Windows Defender ATP Exploit Guard è un nuovo gruppo di funzionalità di prevenzione delle intrusioni. I quattro componenti di Windows Defender Exploit Guard sono progettati per proteggere il dispositivo da un’ampia gamma di vettori di attacco utilizzati in attacchi di malware:

• Riduzione della superficie di attacco
• Protezione di rete
• Accesso controllato alle cartelle
• Protezione dagli exploit

Spazi di archiviazione diretta (Storage Spaces Direct)

Ecco un elenco delle novità in Spazi di archiviazione diretta:

• Deduplicazione e compressione dei volumi ReFS
• Supporto nativo per la memoria persistente
• Resilienza annidata per l’infrastruttura iperconvergente a due nodi periferica
• Cluster a due server con un’unità flash USB di controllo
• Supporto di Windows Admin Center
• Cronologia delle prestazioni
• Scalabilità fino a 4 PB per ogni cluster
• Parità accelerata con mirroring 2 volte più veloce

Per altre informazioni, si veda Novità in Spazi di archiviazione diretta.

Contenitori di Linux in Windows

Ora è possibile eseguire contenitori basati su Linux (Linux Containers) e Windows (Windows Containers) nello stesso host Windows Server, utilizzando lo stesso daemon docker. Questo consente di disporre di un ambiente molto flessibile, utile agli sviluppatori di applicazioni. Le novità introdotte sono

• Realizzazione del supporto per Kubernetes
• Identità integrata avanzata
• Migliore compatibilità delle applicazioni
• Dimensioni ridotte e prestazioni superiori
• Esperienza di gestione con Windows Admin Center (preview)

Confronto tra le edizioni Standard e Datacenter di Windows Server 2019

Entriamo quindi nel merito del confronto vero e proprio tra le diverse edizioni di Windows Server 2019, come da titolo dell’articolo.

Nelle tabelle sottostanti ho racchiuso e confrontato i principali Limiti, i Ruoli Server disponibili e le diverse Funzionalità delle due versioni di Windows Server 2019.

Ruoli server

Funzionalità

Canali di manutenzione di Windows Server 2019: LTSC e SAC

Non poteva mancare anche una descrizione dei due principali canali di supporto di Windows Server 2019 offerte da Microsoft. Qui di seguito trovate le differenze:

Long-Term Servicing Channel (LTSC)

Questo modello di rilascio, in precedenza denominato “Long-Term Servicing Branch“, è già noto agli utenti (è disponibile anche per Windows Server 2016 e Windows 10) e offre il rilascio di una nuova versione principale di Windows Server ogni 2 o 3 anni. Gli utenti hanno diritto a cinque anni di supporto mainstream e cinque anni di supporto esteso (5anni +5anni ). Questo canale è appropriato per i sistemi che richiedono tempi di manutenzione più lunghi e una maggiore stabilità funzionale.
Il Long-Term Servicing Channel continuerà a ricevere sia aggiornamenti di sicurezza sia aggiornamenti non relativi alla sicurezza, ma non riceverà le nuove funzioni e funzionalità, a differenza del Canale Semestrale.

Canale semestrale (Semi-Annual Channel)

Il Canale semestrale è ideale per i clienti che desiderano attuare le innovazioni rapidamente, con l’opportunità di sfruttare le nuove funzionalità del sistema operativo, sia nelle applicazioni, in particolare quelle basate su Containers e Microservices, sia nei Software-defined Hybrid Datacenter. Per i prodotti Windows Server in Canale semestrale saranno disponibili nuovi rilasci due volte l’anno, in primavera e in autunno. Ogni versione rilasciata in questo canale verrà supportata per 18 mesi a partire dal rilascio della versione.

La maggior parte delle funzionalità rilasciate nel Canale semestrale verrà introdotta nel successivo rilascio del Long-Term Servicing Channel di Windows Server.

Canale semestrale sarà disponibile per i clienti con contratti multilicenza con Software Assurance, nonché tramite Azure Marketplace o altri provider di servizi cloud/di hosting.

Nella tabella seguente sono riepilogate le differenze principali tra i canali:

Conclusioni

Tantissime le novità introdotte in Windows Server 2019 e tante anche le novità per il supporto. Spero in questo articolo di aver raccolto la maggior parte delle informazioni che possano aiutarvi a scegliere e successivamente a gestire la nuova versione del sistema operativo Server di casa Microsoft.

Features on Demand (FOD) è un set di applicativi, che sono già presenti nella versione di Windows Server 2019 con Desktop Experience, che serve a migliorare la compatibilità delle applicazioni da installare su Windows Server 2019 Core, senza la necessità di aggiungere l’interfaccia grafica. Il pacchetto Server Core App Compatibility Feature on Demand (FOD) è disponibile sotto forma di ISO, deve essere scaricato a parte e si può installare solo su Windows Server 2019 Core.

Se avete un contratto multilicenza potete scaricare il file ISO dallo stesso portale da cui scaricate la ISO del sistema operativo: Volume Licensing Service Center. È anche possibile scaricare da  Microsoft Evaluation Center o dal portale di Visual Studio. Nel mio caso la ISO di Windows Server 2019 Features on Demand è stata scaricata dal portale della mia sottoscrizione di Visual Studio.

Figura 1: Download della ISO di Windows Server 2019 Features on Demand disponibile nel portale della sottoscrizione di Visual Studio

All’interno della ISO troverete una serie di componenti che vi aiuteranno ad aumentare la compatibilità delle applicazioni e una serie di strumenti utili alla diagnostica e al troubleshooting:

• Microsoft Management Console (mmc.exe)
• Event Viewer (Eventvwr.msc)
• Performance Monitor (PerfMon.exe)
• Resource Monitor (Resmon.exe)
• Device Manager (Devmgmt.msc)
• File Explorer (Explorer.exe)
• Windows PowerShell (Powershell_ISE.exe)
• Failover Cluster Manager (CluAdmin.msc) – è necessario prima installare la feature di Failover Clustering

Installazione di Features on Demand

IMPORTANTE: App Compatibility Features on Demand può essere installato solo in Windows
Server Core

Procedete all’installazione di Windows Server Core scegliendo una delle due versioni presenti nella ISO di Windows Server 2019 : Standard o Datacenter

Figura 2: Installazione di Windows Server 2019 Standard Core

Terminata l’installazione del sistema operativo e configurato le diverse opzioni (nome macchina, jojn al dominio, configurazione di rete) potete procedere all’installazione delle diverse Features on Demand.

Montate la ISO di Server Core App Compatibility Feature on Demand (FOD) all’interno della vostra installazione di Windows Server Core. Se utilizzate una VM potete montare la ISO come virtual drive, altrimenti potete mettere la ISO in una share di rete e montarla con comandi PowerShell.  Io ho scaricato la ISO in un file server e l’ho montata in Server Core con il comando PowerShell:

#Monto la ISO di App Compatibility Features on Demand, che si trova in una share di rete
Mount-DiskImage \\192.168.11.24\msdn\en_windows_server_2019_features_on_demand_x64_dvd_c6194375.iso

Al virtual drive che ha collegato l’immagine ISO, nel mio caso, è stata assegnata la lettera E:

Eseguite quindi il seguente comando per procedere all’installazione dell’ App Compatibility pack:

#Installazione di App Compatibility
DISM /Online /Add-Capability /CapabilityName:"ServerCore.AppCompatibility~~~~0.0.1.0" /Source:E: /LimitAccess

Figura 3: Installazione di Features on Demand

Procedete quindi al riavvio del sistema operativo per completare l’installazione.

Dopo il riavvio saranno disponibili i tools che vi ho elencato precedentemente.

Figura 4: Tools installati da Server Core App Compatibility Feature on Demand (FOD)

Installazione di Internet Explorer 11

È anche possibile installare in Windows Server 2019 Core il browser Internet Explorer 11. L’installazione (opzionale) è molto facile: procedete a rimontare la ISO e lanciate il comando per l’aggiunta del package corretto

#Monto la ISO di App Compatibility Features on Demand, che si trova in una share di rete
Mount-DiskImage \\192.168.11.24\msdn\en_windows_server_2019_features_on_demand_x64_dvd_c6194375.iso

#Installazione di Internet Explorer 11
Dism /online /add-package:E:"Microsoft-Windows-InternetExplorer-Optional-Package~31bf3856ad364e35~amd64~~.cab"

Figura 5: Installazione di Internet Explorer 11 in Windows Server 2019 Core

Procedete nuovamente al riavvio di Windows Server 2019 Core per completare l’installazione.

Al riavvio potrete lanciare Internet Explorer 11 direttamente dal suo percorso di installazione “C:\Program Files\internet explorer\iexplore.exe” oppure potrete aprire i file HTML utilizzando il menù contestuale (tasto destro) da Esplora Risorse.

NOTA: Se cliccate due volte sull’icona di un file HTML non verrà lanciato il browser. È necessario utilizzare il tasto destro e la voce “Apri con…”

Figura 6: Internet Explorer 11 installato in Windows Server 2019 Core

Conclusioni

Grazie al Server Core App Compatibility Feature on Demand è possibile dotare, per la prima volta, la versione Core di Windows Server 2019 di strumenti utili per aumentare la compatibilità delle applicazioni server già presenti su mercato e che vengono sviluppate dai diversi Independent Software Vendor. In più possiamo dotarci anche di strumenti utili per la diagnostica, il troubleshooting ed il debugging. Ben fatto!

Nelle moderne infrastrutture informatiche la gestione dei certificati digitali è una delle attività che stanno alla base di una corretta politica della sicurezza informatica.

Nella prima parte meetup del 13 dicembre organizzato da Torino Technologies Group in collaborazione con ICTPower.it
Ermanno Goletto (MVP Cloud and Datacenter Management) e Roberto Massa (MVP Cloud and Datacenter Management) verranno analizzati le architetture di installazione di una Certification Autority in ambiente Windows Server per piccole, medie e grandi aziende e saranno discusse le best practices di gestione della Security e del Backup di una CA.

Inoltre verrà invece approfondito come utilizzare la Certification Authority Pubblica gratuita Lets’encrypt per la gestione automatizzata del ciclo di vita dei certificati digitali.

Di seguito l’agenda del meetup:

• Architettura di una PKI
  
• Installazione PKI a due livelli in Windows Server 2016
  
• Utilizzo di Let’s Encrypt in Windows Server 2016
  

Il meetup inizierà alle 18 e terminerà alle 20 e si terrà presso il Toolbox Coworking Via Agostino da Montefeltro, 2 10134 Torino. Dopo le 20.00 per chi desidera continuare a chiacchierare può concludere la serata in pizzeria.

E’ possibile registrarsi all’evento al seguente link http://www.torinotechnologiesgroup.it/eventi/20181213

Recentemente nell’articolo Implementazione del protocollo LDAPS in Active Directory è stata proposta una soluzione per la gestione di LDAP su protocollo cifrato.

Questa implementazione si basa sulla disponibilità di una CA di tipo Enterprise all’interno di un dominio Active Directory la cui installazione aziendale è stata analizzata nell’articolo Windows Server 2016 Deploy PKI pubblicato su ICTPOWER.

Tuttavia, si possono verificare casi in cui è disponibile una foresta e quindi uno o più domini AD completamente disgiunti dalla struttura in cui è presente la PKI e, in questi domini “secondari”, non è prevista l’installazione di una Certification Autority.

In uno scenario di questo tipo la gestione tramite GPO e l’automazione vista in precedenza non è utilizzabile.

È comunque possibile gestire l’abilitazione del protocollo LDAPS chiedendo ad una PKI installata in un dominio completamente separato i certificati necessari ai Domain Controller per l’abilitazione del protocollo LDAPs

In questo articolo partiamo da uno scenario in cui sono presenti due Domini ictpower.local e contoso.local e nessuno dei due domini ha relazioni di dipendenza o trust. Sono, per essere più chiari, due foreste separate:

• il dominio ictpower.local ospita l’intera struttura della CA , così come descritto negli articoli menzionati sopra
• Il dominio contoso.local non ha alcuna CA al suo interno, ma necessita per ragioni di sicurezza, di aver implementato il protocollo LDAPs sui DC
• I due domini sono completamente a sé stanti, in due foreste distinte, senza trust

I passi da seguire per fare sì che i DC del dominio contoso.local possano utilizzare i certificati della Certification Authority in ictpower.local sono i seguenti

• Deploy sui DC della foresta contoso.local dei certificati delle root ed Issuing CA
• Creazione di un template che preveda gli stessi OID del template usato per l’autoenroll, sulla CA di Issuing,
• Creazione della CSR sul server DC del dominio contoso. local
• Sottomissione della richiesta e successivo rilascio del certificato, sulla CA di Issuing nel dominio ictpower.local
• Installazione del certificato sul domain controller dc02.contoso. local
• Generazione ed export del certificato in formato .pfx

Lo schema della struttura usata per il test è il seguente

Dominio/Foresta AD ictpower.local

DC01 (Domain Controller)

CAROOT (Server Stand-Alone con CA Root stand-alone)

CASUB (Server Domain Member con la CA di Issuing integrata in AD)

WEB01 (Server Domain Member di pubblicazione della CRL)

Dominio/Foresta AD contoso.local

DC02 (Domain Controller)

1. Deploy sui DC della foresta contoso.local dei certificati delle root root ed Issuing CA della PKI
   

Per fare sì che il dominio contoso.local possa utilizzare la CA del dominio ictpower.local è necessario esportare il certificato della root CA del dominio ictpower.local e distribuirlo su contoso.local tramite una GPO oppure installarlo sul Domain Controller, è sufficiente distribuire questo certificato, nello store “Trusted Root Certification Authority” in quanto il certificato della Issuing CA viene automaticamente installato nello store “Intermediate Certification Authority” nel momento in cui viene installato il certificato richiesto dal DC

Figura 1: certificato della Issuing CA e store di archiviazione

L’export del certificato della CA Root è possibile tramite la console di gestione della CA oppure per mezzo di certutil.exe con il comando certutil -ca.cert <nome_file.cer>

Figura 2: export del certificato CA Root

2 ) Creazione di un template per il rilascio del certificato

Questo passaggio è necessario, in quanto, come detto sopra, dal Domain controller della foresta contoso.local, non essendo disponibile una CA, bisogna generare una richiesta da sottomettere alla CA in ictpower.local.

Per la creazione del Template sulla Issuing CA di ictpower.local, è sufficiente duplicare il template Domain Controller Authentication

Figura 3: duplicazione del template

Una volta duplicato il template è necessario impostare nel Tab Subject Name la proprietà che specifica se il nome host per cui rilasciare il certificato deve essere reperito da AD o se deve essere specificato nella generazione della richiesta. In questo caso imposteremo il template in modo da inserire questa informazione nella richiesta che genereremo più avanti.

Figura 4: modalità di assegnazione del Subject Name

Terminata questa impostazione si dovrà, nel Tab Compatibility, definire i livelli di compatibilità del certificato relativamente a CA e Sistema Operativo, tale compatibilità dovrà essere coerente con l’ambiente in cui dovrà essere gestito il certificato.

Figura 5: compatibilità

Nel Tab General dovremo identificare il nuovo Template con il nome, che dovrà essere utilizzato in fase di generazione della richiesta sul DC del dominio contoso.local e del periodo di validità dei certificati emessi secondo questo template

Figura 6: definizione del nome

Nell’ultimo passo, ritornati allo snap-in di gestione della CA, dovremo autorizzare quest’ultima all’emissione di certificati secondo il nuovo Template accedendo a Certificate Template\New\Certificate Template to Issue ed abilitando così il nuovo Template.

Figura 7: abilitazione del template

3) Creazione della CSR sul server DC del dominio contoso.local

Il passo successivo prevede che si faccia accesso al domain controller del dominio contoso.local e si generi la Certificate Signing Request da sottomettere alla CA, la CSR dovrà essere generata a partire da un file di configurazione che oltre al nome host dovrà anche indicare alla CA quale template dovrà essere utilizzato per il rilascio del certificato e

Figura 8: compilazione del file .inf

Subject = dc02.contoso.local

È il nome host richiedente il certificato

[RequestAttributes]

CertificateTemplate=”DomainControllerAuthentication-ExternalDomain”

È la dichiarazione che viene inserita per la richiesta secondo il nome del Template

Avendo a disposizione il file .inf è sufficiente tramite il comando certreq.exe generare la richiesta

certreq -new DcCertificateRequest.inf 20181117-dc02.contoso.local.req

non essendo presente il template su DC02 viene proposto il warning

Figura 9: Warning per il template non esistente

E la procedura di generazione completa comunque la richiesta

Figura 10: geneazione della CSR

1. Sottomissione della richiesta e successivo rilascio del certificato, sulla CA di issuing
   

A questo punto è necessario copiare il file generato dal comando certreq e copiarlo sulla Issuing CA del dominio ictpower.local da cui con il comando certreq -submit <nome-file>.req viene sottomessa la richiesta alla CA

Figura 11: richiesta alla CA

La quale, per le impostazioni generali del template e di sicurezza proposte qui, rilascerà il certificato per dc01.contoso. local

Figura 12 rilascio del certificato

Dalla Management Console della CA è visibile il certificato emesso che riporta il nome del template definito al punto 2

Figura 13: gestione della CA

1. Installazione del certificato sul domain controller dc02.contoso.local
   

L’ultimo passaggio prevede che il certificato venga copiato sul server dc02.contoso.local ed importato nello store macchina del server, questa operazione viene eseguita tramite certlm.msc

Figura 14: importazione certificato nello store macchina

Figura 15: importazione certificato nello store macchina

Figura 16: certificato correttamente installato nello Store

È da notare che il certificato presenta il simbolo della chiave, che significa che è a disposizione la chiave privata, a questo punto è possibile esportare in un pfx l’intero certificato e la chiave in modo da poterlo archiviare o riutilizzare

Ad importazione completata il certificato è installato nello store macchina ed è utilizzato immediatamente dal server per abilitare il protocollo LDAPs, la verifica può essere fatta con l’utility LDP.EXE

Figura 17: Verifica del protocollo LDAPS

1. Generazione ed export del certificato in formato .pfx
   

Quest’ultimo passaggio in realtà non è necessario all’attivazione del protocollo LDAPs da parte del DC ma è utile per “Archiviare” il certificato con la sua chiave privata, che è necessaria per un uso di questo tipo, in modo da essere eventualmente riutilizzato in futuro.

Per effettuare l’export è possibile utilizzare certlm.msc oppure tramite powershell effettuare un’operazione di export molto più rapida.

Figura 18: export Pfx con Powershell

L’esportazione proposta con Powershell con l’opzione -ProtectTo permette esclusivamente all’utente indicato per il dominio per cui è stato generato il certificato la sua apertura e riutilizzo

Conclusioni:

La procedura vista qui è indicata in ambienti dove i domain controller non sono molti, in quanto le interazioni manuali hanno una certa rilevanza. Tuttavia deve essere anche considerato il tempo di gestione ed amministrazione di una PKI in relazione al tempo impiegato per l’installazione del certificato su più server.

Come sempre non esiste un’unica possibilità ma l’adozione di una soluzione piuttosto che un’altra deve essere messa in stretta relazione con l’ambiente in cui viene utilizzata.

Elenco dei comandi utilizzati nella procedura e descrizione breve:

certutil -ca.cert <nome_file.cer> # Export del certificato della CA

certreq -new <nome_file.inf> <nome_file.req> # Generazione della Signing Request

certreq -submit <nome-file.req> # Sottomissione della richiesta alla CA di Issuing

certlm.msc # Apertura della MMC direttamente sui certificati Macchina

# Export in formato PFX del Certificato DC

# Export in formato PFX del Certificato DC 
$DCCert = (Get-ChildItem -Path 'Cert:\localmachine\my')
Export-PfxCertificate $DCCert  -FilePath C:\Contoso-DC02.pfx -ProtectTo "contoso\administrator"

Riferimenti:

Articoli pubblicati si ICTPower riferiti alla gestione delle PKI aziendali

https://www.ictpower.it/?s=pki

Articolo Technet Relativo a Ldaps

https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

Introduzione

Nel precedente articolo Adozione di Windows 10 e scelta tra Current Branch for Business (CBB) o Long-Term Servicing Branch (LTSB) avevamo analizzato, per quanto riguarda Windows 10 Enterprise, le differenze tra i services models Current Branch for Business (CCB) o Long Term Servicing Branch (LTSB) diventati poi a luglio 2017 rispettivamente Semi-Annual Channel (SAC) e Long-Term Servicing Channel (LTSC).

In questo articolo analizzeremo le novità per quanto riguarda Windows 10 Enterprise LTSC 2019 rilasciato il 13 novembre 2018.

Funzionalità di Windows 10 Enterprise LTSC 2019 e requisiti

Come riportato nel Microsoft Volume Licensing Service Center Windows 10 Enterprise LTSC 2019 si sviluppa su Windows 10 Pro, versione 1809 (aggiornamento novembre 2018), con l’aggiunta di funzionalità ideate per rispondere ai bisogni di aziende di medie e grandi dimensioni (inclusi istituti accademici di grandi dimensioni), quali protezione avanzata contro le moderne minacce alla sicurezza, completa flessibilità di distribuzione dei sistemi operativi, opzioni di aggiornamento e supporto, come anche funzionalità complete di gestione e controllo di dispositivi e applicazioni.

Windows 10 Enterprise LTSC 2019, come indicato nella Volume Licensing guide for Windows 10, è progettato per
scenari che hanno policies di gestione rigorose che prevedono solo aggiornamenti di sicurezza e bug fixing per un periodo esteso (10 anni) senza che siano necessarie nuove funzionalità:

“Windows 10 Enterprise LTSC is designed for systems that have strict change management policies with only security and critical bug fixes. By using a Long Term Servicing Channel, you can apply regular Windows 10 security updates for specialized devices while holding back new-feature updates for an extended period of time, up to 10 years.”

Nel seguente Overview of Windows as a service vengono forniti ulteriori dettagli sugli scenari in cui LTSC è particolarmente indicato come device che devono essere stabili, sicuri senza modifiche all’interfaccia utente come ad esempio, ma non solo, i PC utilizzati per il controllo di strumenti medicali, sistemi POS e bancomat:

“Specialized systems—such as PCs that control medical equipment, point-of-sale systems, and ATMs—often require a longer servicing option because of their purpose. These devices typically perform a single important task and don’t need feature updates as frequently as other devices in the organization. It’s more important that these devices be kept as stable and secure as possible than up to date with user interface changes. The LTSC servicing model prevents Windows 10 Enterprise LTSB devices from receiving the usual feature updates and provides only quality updates to ensure that device security stays up to date. With this in mind, quality updates are still immediately available to Windows 10 Enterprise LTSB clients, but customers can choose to defer them by using one of the servicing tools mentioned in the section Servicing tools.”

Sebbene Microsoft non pubblichi aggiornamenti delle funzionalità tramite Windows Update per i dispositivi che eseguono Windows10 Enterprise LTSC, ogni anni 2-3 anni vengono rilasciate nuove versioni che possono essere installate come in-place upgrade:

“Microsoft never publishes feature updates through Windows Update on devices that run Windows 10 Enterprise LTSB. Instead, it typically offers new LTSC releases every 2–3 years, and organizations can choose to install them as in-place upgrades or even skip releases over a 10-year life cycle.”

Per quanto riguarda le funzionalità disponibili in Windows 10 Enterprise LTSC 2019 non sono presenti le seguenti applicazioni: Microsoft Edge, Microsoft Store, Microsoft Mail, Calendar, OneNote, Weather, News, Sports, Money, Photos, Camera, Music e Clock. Tali applicazioni non sono supportate neanche se installate tramite utilizzando sideloading. Per quanto riguarda Cortana sono disponibili funzionalità di ricerca limitate.

Sempre in Overview of Windows as a service viene indicato che è possibile passare dal LTSC a SAC senza perdita dei dati dell’utente:

“If an organization has devices currently running Windows 10 Enterprise LTSB that it would like to change to the Semi-Annual Channel, it can make the change without losing user data. Because LTSB is its own SKU, however, an upgrade is required from Windows 10 Enterprise LTSB to Windows 10 Enterprise, which supports the Semi-Annual Channel.”

a riguardo vi veda anche Windows 10 upgrade paths e Windows 10 edition upgrade:

Requisiti di Windows 10 Enterprise LTSC 2019

I downloads per Windows 10 Enterprise LTSC 2019 sono disponibili nel Microsoft Volume Licensing Service Center in cui compaiono i seguenti con le relative descrizioni:

Per quanto riguarda i requisiti di sistema alcune indicazioni vengono fornite sempre nel Microsoft Volume Licensing Service Center dove sono riportate le seguenti indicazioni:

• Processore: 1 GHz o superiore
• Memoria: 2 GB RAM per 32-bit e 64-bit (1 GB per la versione Features on Demand)
• Spazio su disco: 20 GB di spazio disponibile

In Overview of Windows as a service vengono forniti ulteriori dettagli circa il supporto dei processori e dei chipset indicando che Windows 10 LTSC supporta i processori e i chipset disponibili al momento del rilascio della build LTSC, mentre le future generazioni di CPU saranno supportate nelle future versioni di Windows 10 LTSC:

“Windows 10 LTSB will support the currently released processors and chipsets at the time of release of the LTSB. As future CPU generations are released, support will be created through future Windows 10 LTSB releases that customers can deploy for those systems. For more information, see Supporting the latest processor and chipsets on Windows in Lifecycle support policy FAQ – Windows Products.”

Per quanto riguarda i requisiti relativi al processore è possibile fare rifermento al seguente Windows Processor Requirements, in cui per quanto riguarda Windows 10 Enterprise LTSC 1809 viene specificato quanto segue:

Intel Processors

Up through the following 9th Generation Intel Processors (Intel Core i3/i5/i7/i9-9xxxK), Xeon E3-xxxx v6***, Intel Atom (J4xxx/J5xxx and N4xxx/N5xxx), Celeron and Pentium Processors
*** Intel Xeon processors are supported on Windows 10 Pro for Workstations and Windows 10 Enterprise only

AMD Processors

Up through the following AMD 7th Generation Processors (A-Series Ax-9xxx & E-Series Ex-9xxx & FX-9xxx); AMD Athlon 2xx processors, AMD Ryzen 3/5/7 2xxx, AMD Opteron**** and AMD EPYC 7xxx****
**** AMD Opteron and AMD EPYC processors are supported on Windows 10 Pro for Workstations and Windows 10 Enterprise only

Se si desidera provare Windows 10 Enterprise LTSC 2019 è possibile scaricare la versione di valutazione 90 giorni al seguente Microsoft Evaluation Center – Windows 10 Enterprise.

Compatibilità con Windows 10 Enterprise LTSC 2019

Prima di decidere se adottare o meno Windows 10 Enterprise LTSC 2019 su determinate postazioni di lavoro vanno valutare anche le politiche di supporto di determinati device, applicazioni e servizi. Di seguito alcune considerazioni per quanto riguarda device, applicazioni e servizi Microsoft.

Surface

L’utilizzo di Windows 10 LTSC su device Surface potrebbe comportare un’esperienza d’uso ridotta o la necessità di aggiornare il device a versioni LTSC successive, a riguardo si veda Surface device compatibility with Windows 10 Long-Term Servicing Channel (LTSC):

“The use of the Windows 10 Enterprise LTSC environment on Surface devices results in sub-optimal end-user experiences and you should avoid using it in environments where users want and expect a premium, up-to-date user experience.”

“Before you choose to use Windows 10 Enterprise LTSC edition on Surface devices, consider the following limitations:
Ÿ Driver and firmware updates are not explicitly tested against releases of Windows 10 Enterprise LTSC.
Ÿ If you encounter problems, Microsoft Support will provide troubleshooting assistance. However, due to the servicing nature of the Windows LTSC, issue resolution may require that devices be upgraded to a more recent version of Windows 10 Enterprise LTSC, or to Windows 10 Pro or Enterprise with the SAC servicing option.
Ÿ Surface device replacements (for example, devices replaced under warranty) may contain subtle variations in hardware components that require updated device drivers and firmware. Compatibility with these updates may require the installation of a more recent version of Windows 10 Enterprise LTSC or Windows 10 Pro or Enterprise with the SAC servicing option.”

“Surface devices running Windows 10 Enterprise LTSC edition will not receive new features. In many cases these features are requested by customers to improve the usability and capabilities of Surface hardware. For example, new improvements for High DPI applications in Windows 10, version 1703. Customers that use Surface devices in the LTSC configuration will not see the improvements until they either update to a new Windows 10 Enterprise LTSC release or upgrade to a version of Windows 10 with support for the SAC servicing option.

Office 2019 e Office 365 ProPlus

Come indicato nella KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions
Office 2019 può essere installato su Windows 10 Enterprise LTSC 2019, ma non sulle versioni precedenti. Per ulteriori informazioni si veda anche l’articolo Novità di Office 2019 per IT Pro.

Mentre come indicato nella KB4076504 Changes to the Office 365 ProPlus system requirements (February 1, 2018)
Office 365 ProPlus sarà supportato su Windows 10 LTSB/LTSC fino al 14 gennaio 2020, dopo tale data il supporto cesserà anche per Windows Server 2012 / 2012 R2 / 2016 e per Windows 8.1.

Visual Studio 2019

Come riportato in Visual Studio 2019 System Requirements
Windows 10 LTSC non è supportato per lo sviluppo di applicazioni tramite Visual Studio 2019, ma è possibile usare Visual Studio 2019 per sviluppare applicazioni destinate a Windows 10 LTSC:

“Visual Studio 2019 will install and run on the following operating systems (64 bit recommended):
Ÿ Windows 10 version 1703 or higher: Home, Professional, Education, and Enterprise (LTSC and S are not supported)
Ÿ Windows Server 2016: Standard and Datacenter
Ÿ Windows 8.1 (with Update 2919355): Core, Professional, and Enterprise
Ÿ Windows Server 2012 R2 (with Update 2919355): Essentials, Standard, Datacenter
Ÿ Windows 7 SP1 (with latest Windows Updates): Home Premium, Professional, Enterprise, Ultimate”

“Windows 10 Enterprise LTSC edition and Windows 10 S are not supported for development. You may use Visual Studio 2019 to build apps that run on Windows 10 LTSC and Windows 10 S.”

Windows Analytics

Windows Analytics è una suite di soluzioni per Microsoft Operations Management Suite (OMS) che forniscono dati sullo stato dei dispositive, attualmente sono disponibili tre soluzioni che è possibile utilizzare singolarmente o in qualsiasi combinazione:

• Device Health che permette l’identificazione dei device che presentano problemi dovuti ad arresti anomali, driver, errate configurazioni
• Update Compliance che permette di visualizzare lo stato dei dispositive relativamente agli aggiornamenti di Windows, allo stato di Windows Defender Antivirus e alle versioni del Sistema Operativo
• Upgrade Readiness che offre una serie di strumenti per pianificare e gestire il processo di aggiornamento dei device per verificare la compatibilità dei driver e delle applicazioni con le nuove versioni

Per quanto riguarda il supporto della suite Windows Analytics con Windows 10 LTSC va precisato che la funzionalità Upgrade Readiness non consente di gestire l’aggiornamento tra le diverse versioni LTSC ma solo tra LTSC e SAC come riportato in Upgrade Readiness requirements:

“While Upgrade Readiness can be used to assist with updating devices from Windows 10 Long-Term Servicing Channel (LTSC) to Windows 10 Semi-Annual Channel, Upgrade Readiness does not support updates to Windows 10 LTSC. The Long-Term Servicing Channel of Windows 10 is not intended for general deployment, and does not receive feature updates, therefore it is not a supported target with Upgrade Readiness.”

Licensing di Windows 10 Enterprise LTSC 2019

LTSC è una versione dell’edizione Enterprise di Windows 10 è utilizzabile solo da clienti che hanno la possibilità di utilizzare l’edizione Windows 10 Enterprise, quindi occorre avere Windows volume licenses con Software Assurance o avere acquistato delle Enterprise volume licenses, a riguardo si veda Windows 10 Enterprise: FAQ for IT professionals:

“If you have Windows volume licenses with Software Assurance, or if you have purchased licenses for Windows 10 Enterprise volume licenses, you can download 32-bit and 64-bit versions of Windows 10 Enterprise from the Volume Licensing Service Center. If you do not have current Software Assurance for Windows and would like to purchase volume licenses for Windows 10 Enterprise, contact your preferred Microsoft Reseller or see How to purchase through Volume Licensing.”

Scendendo nel dettaglio dei programmi di licensing, come riportato nella Volume Licensing guide for Windows 10 di ottobre 2018, Windows 10 Enterprise LTSC 2019 è acquistabile tramite tre programmi di licensing: Open License (riservato a piccole e medie organizzazoni), Microsoft Products and Services Agreement (MPSA) (MPSA riservato a clienti con almeno 250 utenti o device) o Select Plus (riservato a clienti Government e Academic).

Sempre nella nella Volume Licensing guide for Windows 10 viene riportato che Windows 10 Enterprise LTSC gode delle Perpetual Use Rights for Windows Enterprise che consentono di continuare ad utilizzare Windows 10 Enterprise LTSC anche dopo la scandenza della Software Assurance:

“The use rights for Windows 10 Enterprise LTSC are perpetual for the licensed device at the point that Windows 10 Enterprise coverage ends (unless the Windows 10 Enterprise upgrade is acquired under a subscription license).

If Windows 10 Enterprise expires, the perpetual use rights will be for the LTSC that was current at the time that the Software Assurance coverage expired, as well as any past LTSCs.

Windows 10 Enterprise per User doesn’t have an underlying Windows Enterprise upgrade license with Software Assurance, therefore perpetual use rights aren’t granted.”

Ciclo di vita di Windows 10 Enterprise LTSC 2019

Come indicato nella KB13853 Windows lifecycle fact sheet
Windows 10 Enterprise LTSC 2019 godrà del supporto Mainstream fino al 9 gennaio 2024 e del supporto Extended fino al 9 gennaio 2029.

Per quanto riguarda le differenze tra supporto Mainstream ed Extended è possibile fare riferimento alla KB14085 Microsoft Business, Developer and Desktop Operating Systems Policy in cui viene indicato che nel supporto Extended le funzionalità non correlate ad aspetti di sicurezza prevedono limitazioni nel supporto, per esempio non sono disponibili supporto telefonico, online o support incidents previsti dalla Software Assurance.

Conclusioni

Negli ultimi mesi Microsoft ha accolto le segnalazioni delle aziende circa la difficoltà di gestire un cambio di release di sistema operativo ogni 18 mesi e come indicato nella KB13853 Windows lifecycle fact sheet il 6 settembre 2018 sono stati annunciati una serie di cambiamenti nel supporto sintetizzabili nella seguente tabella:

Nonostante ciò molte organizzazioni potrebbero ancora avere difficoltà a gestire un cambio tassativo di versioni del sistema operativo ogni 30 mesi a causa sia di un organico IT ridotto, sia un iter complesso per il testing delle applicazioni e configurazioni al fine validare l’adozione di una versione di Windows 10.

Inoltre anche le attuali normative europee e nazionali quali la Direttiva NIS (Direttiva UE 2016/1148 recepita in Italia col Decreto Legislativo 18 maggio 2018, n.65), il GDPR (Regolamento UE 2016/679) e le Misure minime di sicurezza ICT (pubblicate nella CIRCOLARE 17 marzo 2017, n. 1/2017 sulla Gazzetta Ufficiale che recepisce la Direttiva del Presidente del Consiglio dei ministri 1° agosto 2015 – 17A02399.) impongono una sempre maggiore attenzione agli aspetti di sicurezza prima che a quelli legati alle funzionalità.

Da queste considerazioni appare evidente che Windows 10 LTSC diventa una versione che permette di gestire in sicurezza l’adeguamento tecnologico dei sistemi operativi dei device o di una porzione di esso.

Ad esempio per quanto riguarda l’adempimento delle Misure minime di sicurezza ICT per le pubbliche amministrazioni dove viene richiesto le seguenti la versione LTSC può semplificare l’adozione di Windows 10 nelle Pubbliche Amministrazioni e la relativa gestione nel rispetto dei criteri di economicità, efficacia ed efficienza secondo un’Amministrazione Pubblica è chiamata ad operare nel rispetto dell’Art.1 della Legge 241/90:

ABSC = Agid Basic Security Control

Ovviamente come hanno fatto notare alcuni dipendenti Microsoft Windows 10 LTSC non dovrebbe essere utilizzato se l’infrastruttura IT è matura per gestire il cambio delle versioni di Window 10 secondo le tempistiche dettate dalla durata del supporto per beneficiare delle nuove funzionalità, a riguardo si vedano LTSC: What is it, and when should it be used? e Say No to Long Term Servicing Channel (LTSC).

Riferimenti

• Volume Licensing guide for Windows 10
• KB13853 Windows lifecycle fact sheet
• Windows 10 Enterprise: FAQ for IT professionals
• Windows Processor Requirements
• Gartner – Rethink Windows 10 Long Term Servicing Branch Deployment Based on Microsoft’s Updated Guidance

Nelle moderne infrastrutture informatiche la gestione dei certificati digitali è una delle attività che stanno alla base di una corretta politica della sicurezza informatica.
Nel meetup del 13 dicembre organizzato da Torino Technologies Group in collaborazione con ICTPower.it Ermanno Goletto (MVP Cloud and Datacenter Management) e Roberto Massa (MVP Cloud and Datacenter Management) ) hanno analizzato le architetture di installazione di una Certification Autority in ambiente Windows Server per piccole, medie e grandi aziende e saranno discusse le best practices di gestione della Security e del Backup di una CA. Inoltre è stato approfondito come utilizzare la Certification Authority Pubblica gratuita Lets’encrypt per la gestione automatizzata del ciclo di vita dei certificati digitali.

Sono disponibili le slides utilizzate durante l’evento, che potete scaricare dal link https://github.com/torinotechnologiesgroup/docs/blob/master/20181213_Public%20Key%20Infrastructure%20Windows%20e%20Lets%20Encrypt.pptx.

Qui di seguito invece c’è la registrazione della sessione:

Da pochissimi giorni è stata annunciata la versione 1809.5 Insider Preview di Windows Admin Center, che potete scaricare dal link https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewserver .

Abbiamo già avuto modo di parlare di Windows Admin Center in diversi articoli apparsi su ICTPower.it

Non è propriamente una nuova release bensì una sorta di cumulative update della versione 1809 rilasciata a settembre.

Per verificare le nuove funzionalità dichiarate ho utilizzato Windows Server 2019 il quale, in apertura del Server Manager, propone di gestire la propria infrastruttura attraverso Windows Admin Center!

Figura 1: Server Manager – Popup su Windows Admin Center

Le migliorie introdotte riguardano diversi aspetti. In questo articolo parleremo di quelle a maggiore impatto.

A livello generale:

• Nuovo splash screen durante il caricamento di Windows Admin Center;
• Funzionalità di accesso migliorate;
• Migliorata la gestione delle notifiche;
• Migliorata la gestione dei certificati per gli aggiornamenti.

Figura 2: Windows Admin Center – Nuovo Splash Screen

Tra le funzionalità di accesso migliorate possiamo sicuramente notare nella dashboard principale la gestione con utenza differente di un server

Figura 3: Windows Admin Center – Dashboard

Figura 4: Windows Admin Center – Definizione Amministratore

Clustering

Gli aggiornamenti per questa sezione sono principalmente a livello UI, ad esempio :

• Aggiunta la possibilità di selezionare ed eliminare volumi multipli con un solo click;
• Aggiunto il supporto per l’utilizzo di shortcut;
• Migliorata la gestione delle notifiche specifiche del cluster iper-convergente;
• Aggiunta una nuova dashboard per il monitoraggio dello storage (Get-StorageJob);
• Migliorato il monitoraggio della rete, sia RDMA sia non-RDMA (SMB-Direct, Storage Spaces Direct, ecc…).

Hyper-V

Per quanto riguarda Hyper-V:

• Aggiunta la possibilità di aggiungere dischi o drive a macchine virtuali accese;
• Lo stato di protezione in ambito Azure Site Recovery adesso viene mostrato per tutte le VM che di tutti i nodi del cluster;
• Per i cluster iper-convergenti su Windows Server 2019 sono stati migliorati i tempi di refresh delle VM;
• Per tutti i cluster, invece, è stata resa disponibile la web console per la connessione alle VM;

Estensioni

Un miglioramento importante riguarda la persistenza delle estensioni installate dagli utenti anche in caso di aggiornamento di Windows Admin Center. Cosa utilissima anche a seguito del rilascio di una nuova estensione da parte di Microsoft, relativa a Windows Server 2019 ed i container:

Figura 5: Windows Admin Center – Lista estensioni disponibili

Questa nuova estensione permette la gestione di Docker direttamente dalla console di Windows Admin Center. Terminata l’installazione il browser effettuerà un refresh automaticamente al fine di rendere subito disponibile ciò che si è installato.

Figura 6: Windows Admin Center – Contenitori

Conclusioni

Con il rilascio di questa versione Microsoft dichiara chiaramente che la strada intrapresa resta invariata: Cluster HCI, Hyper-V ed estensioni saranno il cardine di Windows Admin Center. Considerando le nuove funzionalità di Windows Server 2019, anche Docker e Kubernetes possono essere gestite dalla console web. Tutte queste novità fanno ben sperare soprattutto dopo il tempo intercorso tra la versione 1809 e la 1809.5. Restiamo in attesa dei nuovi sviluppi fiduciosi di essere stupiti ancora da questo fantastico prodotto gratuito.