Introduzione

Internet Explorer e Microsoft Edge possono essere usati per supportare le app Web legacy, infatti utilizzando l’elenco dei siti modalità Enterprise è possibile fare in modo che determinati siti Web si aprano automaticamente in Internet Explorer 11 anziché in Microsoft Edge oppure eseguirne il rendering con una configurazione del browser modificata, progettata per emulare Windows Internet Explorer 7 o Windows Internet Explorer 8.

Per informazioni sull’Enterprise Mode Internet Explorer 11 è possibile fare riferimento alla sezione Enterprise Mode for Internet Explorer 11 su Microsoft Docs, mentre nell’articolo Gestione della Modalità Enterprise di Internet Explorer Versione 11 pubblicato su ICTPower.it vengono illustrati i passi per implementare tale funzionalità.

In questo articolo analizzeremo più in dettaglio il funzionamento dell’Enterprise Mode di Internet Explorer 11 e come risolvere eventuali problematiche che possono verificarsi.

Argomenti

• Prerequisti per l’utilizzo dell’Enterprise Mode per Internet Explorer
• Creazione di una Enterprise Mode site list
• Modifica del rendering dei siti web tramite l’Enterprise Mode per Internet Explorer 11
• Testing dei i siti per la compatibilità
• Utilizzo della Enterprise Mode site list in Internet Explorer
• Utilizzo dell’Enterprise Mode per i Siti Intranet e Visualizzazione di Compatibilità

Prerequisti per l’utilizzo dell’Enterprise Mode per Internet Explorer

L’Enterprise Mode per Internet Explorer è supportata nei sistemi operativi Windows 7, Windows 8.1 e Windows 10 e per essere attivata richiede una site list che può essere impostata tramite Group Policy o tramite chiave di registro.

Per quanto riguarda la group policy esiste la seguente disponibile sia a livello computer che utente:

Administrative Templates\Windows Components\Internet Explorer\Use the Enterprise Mode IE website list

Mentre per quanto riguarda le chiavi di registro è possibile utilizzare la seguente chiave per specificare la site list per l’utente corrente:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode

Oppure utilizzare la seguente chiave per specificare la site list per tutti gli utenti:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode

La site list può essere memorizzata in una delle posizioni:

• Server web HTTPS (per esempio https://srvweb.ictpower.it/emie/sites.xml), questa è la posizione consigliata per una maggiore protezione da eventuali manomissioni dei dati.
• Share nella rete locale (per esempio \\ictpower.it\NETLOGON\emie\sites.xml)
• File locale (per esempio file:///c:\\Users\\<user>\\Documents\\emie\\sites.xml)

Si noti che tutte le configurazioni gestite centralmente avranno la priorità su quelle impostate localmente.

Per maggiori dettagli si veda Turn on Enterprise Mode and use a site list.

Creazione di una Enterprise Mode site list

Per la creazione di una Site List occorre utilizzare il tool Enterprise Mode Site List Manager di cui attualmente esistono due versioni l’Enterprise Mode Site List Manager (schema v.2) o l’Enterprise Mode Site List Manager (schema v.1) che permettono di creare file xml con due versioni di schema differenti:

Sia lo schema per la modalità Enterprise versione 1 (v.1) che lo schema per la modalità Enterprise versione 2 (v.2) supportato su Windows 7, 8.1 e 10, la versione 2 è stata introdotta con Windows 10 1511 e prevede una serie di miglioramenti quindi è consigliabile utilizzare la seconda versione, a riguardo si vedano i post New Enterprise improvements coming to IE11 on Windows 7 and 8.1 e How Microsoft Edge and Internet Explorer 11 on Windows 10 work better together in the Enterprise.

E’ anche possibile non utilizzare l’Enterprise Mode Site List Manager per creare il file XML per la Site List, ma utilizzare semplicemente il Blocco note o un’altra applicazione per modificare i file XML. Inoltre come indicato in Add multiple sites to the Enterprise Mode site list using a file and the Enterprise Mode Site List Manager (schema v.2) è anche possibile creare un file TXT che potrà poi essere utilizzato con l’Enterprise Mode Site List Manager (schema v.2) per aggiungere più siti contemporaneamente tramite la voce di menù Bulk add from file, ma si noti che tale file di testo consente solo di aggiungere più siti contemporaneamente e non è possibile utilizzarlo per distribuire l’Enterprise Mode per Internet Explorer.

Modifica del rendering dei siti web tramite l’Enterprise Mode per Internet Explorer 11

L’Enterprise Mode consente di eseguire il rendering dei siti usando versioni emulate di Internet Explorer 7 o Internet Explorer 8 sebbene i siti siano eseguiti in Internet Explorer 11.

L’IE7 Enterprise Mode attiva la Visualizzazione Compatibilità di Internet Explorer 7 o Internet Explorer 5 e la Visualizzazione Compatibilità sceglie la modalità documento da usare in base alla presenza del tag DOCTYPE nel codice della pagina con le seguenti regole:

• se è presente il tag DOCTYPE il rendering delle pagine Web viene eseguito utilizzando l’IE7 document mode;
• se il tag DOCTYPE è assente il rendering delle pagine Web viene eseguito utilizzando l’IE5 document mode.

L’IE8 Enterprise Mode offre il rendering di Internet Explorer 8 utilizzando la stringa user agent di Internet Explorer 8.

Il doctype contrazione di Document Type Declaration (DTD) è, o dovrebbe essere, la prima riga di codice di un documento HTML e consiste in una dichiarazione circa il linguaggio utilizzato, la versione di tale linguaggio, la lingua, etc ed indica al browser il tipo di documento di cui si tratta. Di seguito un esempio di doctype:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”
http://www.w3.org/TR/html4/loose.dtd>

Per ulteriori informazioni si veda Tips and tricks to manage Internet Explorer compatibility in cui viene indicato che oltre alle modalità IE7 Enterprise Mode e IE8 Enterprise Mode (<emie>) è possibile anche specificare il document mode (<docMode>) in cui eseguire il rendering della pagina:

Scendendo nel dettaglio, come indicato in Fix web compatibility issues using document modes and the Enterprise Mode site list quando Internet Explorer 11 usa una Site List il browser carica la pagina nella modalità documento specificata come se fosse specificata tramite un meta tag X-UA-Compatible sul sito. L’Enterprise Mode ha la precedenza sul document mode, questo fa sì che i siti che sono inclusi nella Site List dell’Enterprise Mode non siano interessati.

Di seguito un esempio di file XML in versione 2 per una Site List:

<site-list version="2">
<created-by>
<tool>EMIESiteListManager</tool>
<version>10.0.14357.1004</version>
<date-created>01/26/2019 17:09:33</date-created>
</created-by>
<site url="intranet.ictpower.it">
<compat-mode>IE8Enterprise</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="hrwebapp.ictpower.it">
<compat-mode>IE7Enterprise</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="intranet.ictpower.it/docs">
<compat-mode>IE7Enterprise</compat-mode>
<open-in>IE11</open-in>
</site>
</site-list>

Per capire se è meglio usare le modalità documento o la modalità Enterprise occorre tenere presente che la funzionalità Enterprise Mode (<emie>) offre i livelli di compatibilità di Internet Explorer8 o Internet Explorer7, mentre le funzionalità Document Mode (<docMode>) consentono di impostare la compatibilità indipendentemente dalla versione di Internet Explorer eseguita. In generale è possibile iniziare il processo di testing della compatibilità come segue:

• se vengono utilizzati principalmente Internet Explorer 8 o Internet Explorer 7 iniziare il testing usando l’Enterprise Mode;
• se vengono utilizzati principalmente Internet Explorer 9 o Internet Explorer 10 iniziare il testing usando il Document Mode.

Per eventuali errori di convalida del sito durante la creazione della Site List si faccia rifermento al documento Fix validation problems using the Enterprise Mode Site List Manager.

Attivando l’Enterprise Mode nella barra degli indirizzi è visualizzata un’icona, ciò non accade col Document Mode:

Nel documento Deprecated document modes and Internet Explorer 11 è possibile ricavare il flow chart in base a cui Internet Explorer 11 esegue il rendering, di seguito viene riportata la sezione relativa all’Enterprise Mode:

Di seguito invece la sezione del flow chart in base a cui Internet Explorer 11 esegue il rendering relativa all’Document Mode:

Testing dei i siti per la compatibilità

Come indicato nel documento Fix web compatibility issues using document modes and the Enterprise Mode site list è possibile eseguire un testing approfondito dei siti premendo F12 In Internet Explorer 11 per aprire gli Strumenti di sviluppo e selezionando il tab Emulazione:

Tramite la Group Policy a livello computer o a livello utente Administrative Templates\Windows Components\Internet Explorer\Let users turn on and use Enterprise Mode from the Tools menu è possibile consentire agli utenti di visualizzare e utilizzare l’opzione Modalità Enterprise dal menu Strumenti, in questo modo è possibile testare anche il profilo browser Enterprise.

Si tenga presente che se si imposta su un sito manualmente un profilo browser mentre è attiva la group policy Let users turn on and use Enterprise Mode from the Tools menu potrebbero verificarsi dei malfunzionamenti se su tale sito vengono poi configurate impostazioni di compatibilità abilitando l’Enterprise Mode tramite una Site List. In questo caso occorre impostare manualmente sul sito un profilo browser congruente con quello presente nella Site List e se l’Enterprise Mode era stata disabilitata manualmente è necessario ripristinare l’emulazione tramite CTRL+Maiusc+L eventualmente riabilitando temporaneamente la group policy Let users turn on and use Enterprise Mode from the Tools menu per consentire la riabilitaizone dell’Enterprise Mode.

Per trovare l’ipostazione di compatibilità più adatta per un determinato sito si tengano presenti le indicazioni contenute in Tips and tricks to manage Internet Explorer compatibility:

“Run the site in each document mode until you find the mode in which the site works.

You will need to make sure the User agent string dropdown matches the same browser version as the Document mode dropdown. For example, if you were testing to see if the site works in Internet Explorer 10, you should update the Document mode dropdown to 10 and the User agent string dropdown to Internet Explorer 10.

If you find a mode in which your site works, you will need to add the site domain, sub-domain, or URL to the Enterprise Mode Site List for the document mode in which the site works, or ask the IT administrator to do so. You can add the x-ua-compatible meta tag or HTTP header as well.”

Per semplificare la configurazione delle impostazioni di compatibilità dei siti utilizzati dagli utenti aziendali è anche disponibile l’Enterprise Site Discovery Toolkit che consente di raccogliere informazioni da Internet Explorer 8,9,10 e 11 sui siti visitati e di analizzarli per zona o per dominio. Il Toolkit fornisce inoltre informazioni su come il sito è progettato e utilizzato da Internet Explorer che possono essere quindi utilizzate per popolare la Site List dell’Enterprise Mode. Per impostazione predefinita Internet Explorer non raccoglie tali dati, ma occorre abilitare la raccolta, i dati verranno raccolti senza notifiche all’utente su tutti i siti visitati tranne durante la navigazione InPrivate Mode o per le zone o domini per cui è stata impostata l’esclusione.

Utilizzo della Enterprise Mode site list in Internet Explorer

Dopo aver configurato Internet Explorer per utilizzare l’Enterprise Mode tramite l’utilizzo di una site list centralizzata occorre tenere presente le seguenti:

• Internet Explorer 11 cerca una site list formattata correttamente circa 65 secondi dopo l’avvio;
• Internet Explorer 11 carica e usa una site list se ne questa ha un numero di versione diverso da quella correntemente attiva;
• Internet Explorer 11 ricerca una nuova site list solo al suo avvio.

Dopo aver scaricato la site list questa viene archiviata in locale nel computer in modo che la funzionalità Enterprise Mode possa essere utilizzata anche se il percorso del file centralizzato non è disponibile.

Come indicato in Check for a new Enterprise Mode site list xml file Internet Explorer cerca il file xml della site list nelle nella cache container, nella local cache e quindi sul server.

Se viene trovato un file xml della site list nella cache container Internet Explore attende 65 secondi e quindi controlla se esiste nella local cache una nuova versione del file xml della site list copiato dal server in base alle regole di caching standard e se tale file ha un numero di versione differente verrà copiato nella cache containter e utilizzato. Ciò significa che se esiste già un file xml della site list quanto Internet Explorer viene avviato nel caso esista anche una versione nuova di tale file per 65 secondi la funzionalità Enterprise Mode utilizzerà in file esistente invece di quello nuovo.

Se necessario è possibile forzare la ricerca di una site list eseguendo le seguenti operazioni:

1. Chiudere tutte istanze di Internet Explorer, ad esempio utilizzando il seguente comando:
   taskkill /F /IM iexplore.exe
   
2. Clear della cache di Internet Exoplorer, ad esempio utilizzando il seguente comando:
   RunDll32.exe InetCpl.cpl, ClearMyTracksByProcess 8
3. Eliminare la chiave di registro HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\EnterpriseMode\CurrentVersion, ad esempio con il seguente comando:
   REG DELETE “HKCU\Software\Microsoft\Internet Explorer\Main\EnterpriseMode” /v CurrentVersion /f

Nel caso in cui si riscontrino problemi con l’Enterprise Mode è possibile tentare di risolverli rimuovendo le Group Policy di abilitazione, ad esempio spostando temporaneamente il computer in una Organizational Unit (OU) in cui tali group policy non sono applicate, è possibile eliminare le seguenti chiavi di registro e riavviare il computer:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache\EmieModeList

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache\EmieSiteList

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache\EmieUserList

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\EmieModeList

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\EmieSiteList

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\EmieUserList

Utilizzo dell’Enterprise Mode per i Siti Intranet e Visualizzazione di Compatibilità

Per impostazione predefinita i siti che appartengono alla Intranet vengono visualizzati in Visualizzazione Compatibilità una funzionalità introdotta con i Internet Explorer 8 che consente di eseguire il rendering di una pagina Web in modo quasi identico a Internet Explorer 7. Scendendo nel dettaglio Visualizzazione compatibilità modifica il modo in cui il browser interpreta il codice scritto in CSS, HTML e DOM (Document Object Model) per fare in modo che l’interpretazione sia come quella che viene eseguita da Internet Explore 7. Tuttavia non tutto il codice subisce questo cambio di interpretazione questo significa che le modifiche introdotte in Internet Explorer 8 relative alla gestione degli ActiveX, del parser, AJAX, JavaScript, networking e sicurezza potrebbero causare un rendering della pagina web in modo differente da Internet Explorer 7, per maggiori informazioni si veda What Is Compatibility View?

Se si desidera utilizzare l’Enterprise Mode per i Siti Intranet conviene disabilitare la Visualizzazione di Compatibilità per i siti Intranet. Infatti è preferibile a controllare le impostazioni di compatibilità esclusivamente tramite l’Enterprise Mode in quanto è più duttile rispetto la Visualizzazione Compatibilità che consente di gestire esclusivamente dominii e non dominii secondari o URL.

E’ possibile disabilitare la Visualizzazione Compatibilità per la zona Intranet abilitando la seguente group policy a livello computer o utente:

Administrative Templates\Windows Components\Internet Explorer\compatibility view\Turn on Internet Explorer Standards Mode for local intranet

“If you enable this policy setting, Internet Explorer uses the current user agent string for local intranet content. Additionally, all local intranet Standards Mode pages appear in the Standards Mode available with the latest version of Internet Explorer. The user cannot change this behavior through the compatibility view Settings dialog box.”

Inoltre sono disponibili anche le seguenti Group Policy a livello computer o utente che possono essere utilizzate per gestire la Visualizzazione Compatibilità e il rilevamento della zona Intranet:

Administrative Templates\Windows Components\Internet Explorer\compatibility view\Turn off compatibility view

“If you enable this policy setting, the user cannot use the compatibility view button or manage the compatibility view sites list.”

Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\Turn on automatic detection of Intranet

“If you disable this policy setting, automatic detection of the Intranet is Turned off, and Intranet mapping rules are applied however they are configured.”

Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\Intranet Sites: Include all local (intranet) sites not listed in other zones

“If you disable this policy setting, local sites which are not explicitly mapped into a zone will not be considered to be in the intranet Zone (so would typically be in the Internet Zone).”

A riguardo si vedano anche il post The Intranet Zone e le indicazioni contenute nella KB303650 Intranet site is identified as an Internet site when you use an FQDN or an IP address di cui vengono riportati alcuni passaggi, ma si legga l’intera KB per ulteriori informazioni e suggerimenti:

“When you access a local area network (LAN), an intranet share, or an intranet Web site by using an Internet Protocol (IP) address or a fully qualified domain name (FQDN), the share or Web site may be identified as in the Internet zone instead of in the Local intranet zone.”

“This behavior may occur if an FQDN or IP address contains periods. If an FQDN or IP address contains a period, Internet Explorer identifies the Web site or share as in the Internet zone.”

“To work around this issue, add the appropriate IP address range or fully qualified domain names (FQDNs) to your local intranet. Or change the security level of the Internet zone.”

“This behavior is by design.”

Conclusioni

Sebbene l’Enterprise Mode sia un ottimo strumento per risolvere eventuali compatibilità di alcuni siti con i browser di nuova generazione come Internet Explorer 11 o Edge va precisato che questa funzionalità nasce per risolvere problematiche relative a codice legacy. Di conseguenza se possibile occorre risolvere i problemi di incompatibilità nei siti coinvolti eventualmente ricorrendo all’uso di meta tag x-ua-compatible o HTTP header, a riguardo si veda Use the Meta Tag to Ensure Future Compatibility.

Riferimenti

• Use Enterprise Mode to improve compatibility
• Enterprise Mode for Internet Explorer 11
• Enterprise Mode for Internet Explorer 11 Deep Dive

Negli ultimi anni l’Internet of Things (IoT) o “Internet delle cose” si sta diffondendo come insieme di tecnologie integrate, nuove soluzioni e servizi che hanno come obbiettivi l’aumento della qualità della vita delle persone, il miglioramento dei processi produttivi e dell’utilizzo di beni e servizi. In altre parole l’IoT è una possibile evoluzione dell’uso della Rete in cui gli oggetti (ovvero le “cose”) si rendono riconoscibili e acquisiscono intelligenza grazie alla possibilità di poter comunicare dati e accedere ad informazioni aggregate da parte di altri.

Stando all’ultimo Ericsson Mobility Report di Novembre 2018 si stima che nel 2024 i dispositivi IoT connessi in rete saranno 22.3 miliardi contro gli 8.6 miliardi del 2018 con tasso annuo di crescita o CAGAR (Compound Annual Growth Rate o ) del 17%. Diversi sono i fattori chiave che determineranno la diffusione dell’IoT ovvero il costo dei dispositivi, il consumo energetico dei dispositivi e reti in grado di supportare un numero elevato di dispositivi con un’elevata copertura.

Applicazioni IoT e tecnologie LPWAN

In generale le tipiche applicazioni IoT non necessitano di trasmissioni dati continue, ma solo a fronte di variazioni delle grandezze misurate e non richiedono bitrate elevati. Tali caratteristiche vengono soddisfatte dalle tecnologie di rete LPWAN (Low Power Wide Area Networks) che richiedono una ridotta potenza di trasmissione e garantiscono una buona copertura e scalabilità

Al momento si stanno diffondendo due tecnologie LPWAN: LoRa basa su standard aperto aperto e SIGFOX basata su tecnologia proprietaria. Di seguito un confronto tra le tecnologie LPWAN e le altre tecnologie a radiofrequenza pubblicato sul sito Techplayon nell’articolo Low Power Wide Area Networks (LPWAN) del 12 giugno 2017 da cui emerge come le tecnologie LPWAN al momento offrano il miglior compromesso in termini di copertura, consumo energetico e costi dei dispositivi.

Di seguito una classificazione delle principali caratteristiche delle tecnologie abilitanti per l’IoT in base all’efficienza energetica rispetto al costo per terminale di trasmissione (a) e in base alla velocità di trasmissione rispetto alla distanza di trasmissione (b) (fonte State of the Art in LP-WAN Solutions for Industrial IoT Services):

Nella seguente tabella la previsione della diffusione delle tecnologie abilitanti per l’IoT pubblicata dal SNS Research nel report The LPWA (Low Power Wide Area) Networks Ecosystem: 2017 – 2030 pubblicato a novembre 2016:

Di seguito un sintetico confronto delle principali caratteristiche delle varie tecnologie LPWAN:

Panoramica sulla tecnologia LoRa

LoRa (Long Range) è una tecnologia che fa riferimento ad uno stack composto da due livelli. Il primo livello dello stack LoRa è il physical layer (PHY) ovvero lo strato fisico che utilizza una modulazione proprietaria derivata dal Chirp Spread Spectrum (CSS) mentre il secondo livello è il protocollo per il livello MAC (Media Access Control) chiamato LoRaWAN.

Physical Layer di LoRa

La tecnologia del physical layer è stata sviluppata e brevettata da Cycleo, una società francese, che nel 2012 è stata acquisita dalla californiana Semtech, per i dettagli sulla modulazione LoRa si veda il documento AN1200.22 – LoRa Modulation Basics.

La modulazione CSS codifica i dati con un segnale sinusoidale con la frequenza variabile nel tempo, in questo modo si trasmette un segnale di base su una banda più ampia ottenendo un aumento della resistenza al rumore. Una caratteristica della modulazione CSS è l’utilizzo dello Spreading Factor (SF) che in base alla Bandwidth (BW), ovvero la larghezza di banda, permette di regolare il Bit Rate (Rb), ovvero la velocità in bit, e quindi la durata della trasmissione e di conseguenza anche i consumi di energia tramite la seguente formula:

Durante la comunicazione le frequenze utilizzate ed il Data-Rate vengono modificate in base alle esigenze e alla distanza utilizzando il meccanismo dell’Adaptive Data Rate (ADR) che permette di aumentare l’efficienza energetica e di conseguenza la durata delle batterie. L’ADR può essere utilizzato solo da nodi statici in quanto in assenza di movimento è possibile determinare se la comunicazione a radiofrequenza è instabile.

Inoltre il canale selezionato viene cambiato in maniera casuale ad ogni nuova comunicazione, in modo da rendere la rete meno soggetta alle interferenze e se il nodo è servito da più gateway riduce la potenza di trasmissione in modo che il segnale sia ricevuto da meno gateway.

LoRa utilizza le bande di frequenza ISM (Industrial, Scientific and Medical) riservate alle applicazioni di radiocomunicazioni non commerciali, ma per uso industriale, scientifico e medico. In particolare, a seconda dell’area geografica e delle relative regolamentazioni, le due frequenze più diffuse sono 868 MHz in Europa e 915 MHz in Nord America.

Di seguito le specifiche di LoRa per l’Italia e l’Europa (a riguardo si vedano le LoRaWAN Regional Parameters v1.1rB):

Protocollo LoRaWAN

Il protocollo per il livello MAC che usa LoRa come livello fisico e di tipo aperto ed è denominato LoRaWAN. Le specifiche di LoRaWAN sono redatte dalla LoRa Alliance, un’associazione no-profit fondata da varie aziende nata nel marzo 2015 che al momento conta circa 500 membri tra cui IBM, Cisco, HP, Foxconn, Semtech e Sagemcom con l’obbiettivo di standardizzare il protocollo e diffonderlo.

Al momento le specifiche LoRaWAN hanno raggiunto la versione 1.1, ma va precisato che una rete LoRaWAN 1.1 è retro compatibile ed in grado di interoperare anche con device legacy LoRaWAN 1.0.x. La LoRa Alliance prevede anche una certificazione LoRaWAN per i dispositivi che ne garantisce l’interoperabilità e la conformità su qualsiasi rete LoRaWAN confermando che il dispositivo soddisfa i requisiti funzionali delle specifiche del protocollo LoRaWAN.

L’architettura di rete LoRaWAN utilizza una topologia a stella in cui ciascun nodo finale comunica con più gateway che comunicano con il server di rete. Gli elementi principali della rete sono: i nodi, i gateway, il Network Server e l’Application Server. Di seguito uno schema dell’architettura di rete LoRaWAN:

La tecnologia LoRa prevede una comunicazione di tipo bidirezionale, ma la trasmissione da nodo a gateway o messaggio di Uplink è quella più frequente rispetto a quella da gateway a nodo o messaggio di
Downlink dal momento che solitamente lo scopo dei nodi è quello di raccogliere dati per poi mandarli al Network Server e quindi all’Application Server.

I nodi inviano messaggi di Uplink ai gateway in radiofrequenza attraverso la modulazione LoRa. I gateway inoltrano i messaggi al Network Server aggiungendo informazioni riguardanti la qualità della comunicazione attraverso una connessione IP instradata su Ethernet, Wi-Fi o 3G.

I nodi inviano messaggi in Uplink a tutti i gateway nel loro raggio di trasmissione in modalità broadcast, il Network Server si occupa della gestione dei messaggi di Uplink duplicati e della selezione del miglior gateway da utilizzare nel caso debba essere invito un messaggio di Downlink al nodo.

Il Network Server si occupa anche di gestire la velocità di trasmissione dei nodi tramite il meccanismo dell’ADR (Adaptive Data Rate) per massimizzare la capacità della rete ed estendere la durata della batteria del nodo. Ad esempio il Network Server TTN utilizza i 20 messaggi di Uplink più recenti, a partire dal momento in cui viene impostato il bit ADR, per determinare il Data Rate ottimale, tali misurazioni contengono il frame counter, il rapporto segnale-rumore (SNR) e il numero di gateway che hanno ricevuto ciascun messaggio di Uplink.

L’Application Server si occupa invece di ricevere e analizzare i dati inviati dai nodi e di determinare le azioni che dovranno essere eseguite dai nodi.

Classi LoRaWAN

Il livello MAC implementato originariamente su ogni dispositivo LoRa si basa sul protocollo ALOHA puro, ovvero, come detto precedentemente, i nodi inviano messaggi in Uplink a tutti i gateway in ascolto instaurando una comunicazione di tipo broadcast.

Quando un messaggio di Uplink viene ricevuto da un gateway questo invia un messaggio di acknowledgement che conferma la ricezione del messaggio. Se due messaggi in Uplink vengono inviati nello stesso canale nello stesso istante si verifica una collisione e
entrambi i messaggi di Uplink vengono persi, anche se i frame non si sovrappongono completamente. Quando si verifica una collisione il gateway non invia alcun messaggio di acknowledgement e quindi i nodi attendono un tempo casuale prima di tentare di inviare nuovamente il messaggio in Uplink.

Partendo dalla comunicazione basata sul protocollo ALOHA puro il protocollo LoRaWAN è stato sviluppato in modo da garantire maggiore elasticità nella trasmissione. Le specifiche di LoRaWAN definiscono tre tipologie di nodi: nodi di classe A, di classe B e di classe C. Tutti i dispositivi compatibili LoRaWAN devono implementare la classe A, mentre le classi B e C rappresentano delle estensioni.

Nodi di classe A

Rappresenta la modalità di default dei nodi in cui i nodi supportano la comunicazione bidirezionale con il gateway, ma questa viene sempre inizializzata dai nodi in maniera asincrona.

I messaggi in Uplink, dal nodo al gateway, possono essere inviati in qualsiasi momento. A seguito di un messaggio di Uplink il nodo apre due finestre di ricezione. Il Network server può rispondere tramite un gateway con un messaggio in Downlink in una delle due finestre. Solitamente la prima finestra è aperta sullo stesso canale utilizzato nella trasmissione in Uplink, mentre la seconda finestra viene aperta su un canale differente, accordato in precedenza con il Network Server, per migliorare la resistenza alle interferenze.

Questa classe è la più efficiente dal punto di vista energetico ed è utilizzata da quei nodi che cercano di rimanere inattivi per un tempo più lungo tempo possibile, ed in cui le comunicazioni in Uplink sono le più frequenti, come ad esempio nei sensori.

Nodi di classe B

I nodi in classe B estendono le funzionalità della classe A implementando delle finestre di ricezione programmate per i messaggi di Downlink inviati da Network Server tramite i gateway. Tramite l’utilizzo di segnali temporizzati trasmessi dal gateway, i nodi aprono periodicamente delle finestre di ricezione consentendo quindi l’invio di messaggi in Downlink ai nodi indipendentemente dal fatto che siano stati inviati messaggi in Uplink dai nodi.

Scendendo nel dettaglio i nodi sono sincronizzati con il Network Server attraverso un meccanismo che sfrutta dei pacchetti beacon trasmessi dai gateway ogni 128 secondi. Un pacchetto beacon contiene uno specifico tempo di riferimento in cui far aprire ai nodi della rete una finestra di ricezione extra, chiamata ping slot.

Questa classe è utilizzata da quei nodi che hanno la necessità di ricevere dei comandi, come ad esempio gli attuatori.

Nodi in classe C

I nodi in classe C estendono le funzionalità della classe A implementando una finestra di ricezione sempre aperta, a meno che il nodo non stia trasmettendo. Questo permette una comunicazione con bassa latenza, ma va ad aumentare molto il consumo di energia rispetto ai nodi in classe A.

Questa classe è utilizzata da quei nodi che in cui la ricezione di comandi deve rispettare vincoli dal punto di vista temporale. Questa operatività si traduce in un elevato consumo energetico che rende solitamente necessario che questi nodi siano connessi alla rete elettrica.

Attivazione dei nodi in una rete LoRaWAN

Ogni nodo di una rete LoRaWAN dispone delle seguenti informazioni:

• l’indirizzo identificativo del device denominato DevAddr (Device Address) che identifica il nodo nella rete e si compone di 32 bit, di cui i sette più significativi identificano la rete mentre i rimanenti sono assegnati in maniera arbitraria dal Network Server;
• un identificativo di applicazione denominato AppEUI (Application Identifier) composto da 64 bit. Questo è l’identificativo esclusivo dedicato al proprietario dell’applicazione a cui è assegnato il dispositivo, l’AppEUI è conservato all’interno del dispositivo
• una chiave di sessione di rete denominata NwkSKEY (Network Session Key), questa chiave AES-128 bit è specifica per il nodo ed è utilizzata dal Network Server e dal device per generare il MIC (Message Integrity Code) per il controllare l’integrità del messaggio e per criptare e decriptare il FRMPayload (Frame Payload).
• una chiave di sessione per l’applicazione denominata AppSKey (Application Session Key), questa chiave AES-128 bit è specifica per il dispositivo ed è utilizzata dall’Application Server e dal nodo per criptare e decriptare il payload dei messaggi specifici di un’applicazione in modo da creare un canale di comunicazione sicuro end-to-end

LoRaWAN rende disponibili due modalità per associare un nodo alla rete: la modalità Over-The-Air Activation (OTAA) e la modalità Activation By Personalization (ABP).

Modalità Over-The-Air Activation (OTAA)

Nella modalità Over-The-Air Activation (OTAA) i nodi devono eseguire una procedura di join prima di poter scambiare dati con il Network Server. La procedura di join deve essere eseguita nuovamente ogniqualvolta le informazioni riguardo la sessione vengano perse.

Per eseguire la procedura di join il nodo deve possedere:

• un DevEUI di 64 bit che identifica globalmente il nodo;
• un AppEUI di 64 bit che identifica l’applicazione;
• una chiave AES-128 denominata AppKey;

La chiave AppKey sarà utilizzata per generare la chiave di sessione di rete NwkSKEY e la chiave di sessione per l’applicazione AppSKey.

La procedura di join consiste in un messaggio MAC di join request tramite cui un nodo invia anche il proprio DevEUI e l’AppEUI, di seguito la struttura del messaggio di join request:

Al messaggio MAC di join request il Network Server risponde con un messaggio MAC di join accept inviando al nodo il DevAddr e un valore casuale chiamato AppNonce utilizzato dal nodo per ricavare l’AppSKey e la NwkSKEY. Di seguito la struttura del messaggio di join accept:

Modalità Activation By Personalization (ABP)

Nella modalità Activation By Personalization (ABP), i nodi non devono eseguire una procedura di join inviando messaggi MAC request-join accept, come descritto precedentemente, perché l’indirizzo identificativo del device DevAddr, la chiave di sessione di rete NwkSKey e la chiave di sessione per l’applicazione AppSKey sono memorizzate direttamente nel nodo. In altre parole in questa modalità il nodo possiede già le informazioni necessarie per associarsi ad una rete LoRaWAN.

Attivazione dei nodi e sicurezza

E’ importante che ogni nodo abbia un set di chiavi NwkSKey e AppSKey uniche in modo che le chiavi di un nodo vengono compromesse non venga anche compromessa la sicurezza degli altri nodi della rete come riportato nelle LoRaWAN Specification v1.0:

“Each device should have a unique set of NwkSKey and AppSKey. Compromising the keys of one device shouldn’t compromise the security of the communications of other devices.

The process to build those keys should be such that the keys cannot be derived in any way from publicly available information (like the node address for example).”

Inoltre occorre tenere presente sebbene la modalità di attivazione Activation By Personalization (ABP) sia più semplice da implementare, l’hardcode nel dispositivo del DevAddr e delle chiavi di sicurezza NwkSKey e AppSKey implica una
minor sicurezza. I nodi infatti sono spesso posizionati in ambienti fisici non controllabili e quindi potrebbero essere oggetto di furto col conseguente rischio che le chiavi vengano estratte dal noto. Nel caso in cui le chiave siano derivate in base al nodo ad esempio basandosi sul suo indirizzo la compromissione di tali chiavi tramite reverse engineering implica anche la compromissione delle chiavi degli altri nodi. A riguardo si veda ad esempio la whitepaper LoRa Security Building a Secure LoRa Solution pubblicata da MWR Labs:

“Key extraction from Node devices is probable given that they will likely be physically outside of controlled environments. It is important therefore that the theft of keys from one Node does not compromise other Nodes in the system.
One potential vulnerability is where Nodes use Activation-By-Personalisation (ABP) for joining, but use keys derived by the Node based on features such as the device address. If this could be worked out through reverse engineering of one Node, then all other communications to any Node would then be compromised.”

Di seguito l’architettura di sicurezza di LoRaWAN tratto dalla LoRa Alliance Security Whitepaper:

Geolocalizzazione

Come descritto nella LoRa Alliance Geolocation Whitepaper pubblicata dalla LoRa Alliance, LoRaWAN fornisce nativamente la funzionalità di geolocalizzazione che è supportata da ogni tipo di nodo senza richiedere ulteriore potenza di calcolo.

Sono disponibili due metodologie per la geolocalizzazione:

• un primo metodo basato sul Received Signal Strength Indication (RSSI), ovvero sulla misurazione della potenza del segnale ricevuto, che fornisce un rilevamento della posizione indicativa con un’accuratezza compresa tra 1000-2000m;
• un secondo metodo basato sul Time Difference Of Arrival (TDOA), ovvero sulla misurazione della differenza del tempo di arrivo del segnale, che fornisce un rilevamento della posizione precisa con un’accuratezza 20-200m.

Nel seguente grafico un confronto tra le vare tecnologie di localizzazione e un confronto tra localizzazione tramite GPS con LoRaWAN TDOA tratto da un caso reale:

Un nodo di una rete LoRaWAN può essere localizzato se le sue trasmissioni in Uplink sono ricevute da tre o più gateway, in generale la precisione della geolocalizzazione migliora al crescere del numero di gateway.

Quando diversi gateway ricevono contemporaneamente lo stesso messaggio di uplink possono rilevare la posizione del nodo tramite tecniche di multilaterazione.

Affinchè sia possibile geolocalizzare i nodi tramite TDOA è necessario che I gateway abbiano una sincronizzazione temporale accurata ottenuta tramite un GPS sui gateway o con un altro mezzo che consenta di sincronizzare il clock dei gateway con differenze di poche decine di nanosecondi.

Network Server e Application Server offerti da The Things Network (TTN)

Uno dei primi progetti che ha avuto come obbiettivo quello creare un LoRaWAN network server stack, ovvero un’infrastruttura di gestione per reti LoRa e un Frontend applicativo, è The Things Network (TTN). TTN è nato nell’agosto 2015 con una prima sperimentazione ad Amsterdam in un progetto per la cura e la gestione delle imbarcazioni nei canali, di seguito lo schema del Things Network LoRaWAN Stack:

Come enunciato nel Manifesto della comunità The Things Network si propone di costruire una rete per l’IoT completamente aperta, decentralizzata, posseduta e gestita dagli utenti. Per realizzare tale obbiettivo i codici, i firmware, i progetti e le conoscenze per la produzione dei dispositivi fisici necessari alla rete sono open source.

E’ possibile eseguire il deploy del Things Network LoRaWAN Stack in 4 modalità:

• Public Community Network: in questa modalità è possibile utilizzare una rete decentralizzata e collaborativa a cui sono connessi migliaia di gateway in tutto il mondo, utilizzati da sviluppatori e aziende per creare use cases. E’ possibile utilizzare i gateway già installati o aggiungere gateway aggiuntivi se è necessaria una copertura aggiuntiva. Al link The Things Network in Italy è possibile avere l’elenco delle community TTN italiane, al momento vi sono in Italia 28 community e 170 gateway.
• Software as a Service: in questa modalità è possibile creare una rete LoRaWAN privata con la possibilità interconnettersi con la rete pubblica, ovvero il peering con la Public Community Network. Questa modalità è fornita a pagamento da The Things Industries con un Service Level Agreement (SLA) e un uptime guarantito nei livelli di servizio Professional e Service Provider.
• Private Cloud: in questa modalità è possibile mantenere il Network Server in un’infrastruttura privata on-premises per poter mantenere il controllo sulla distribuzione, la qualità del servizio (SLA e uptime) e il livello di sicurezza e per evitare che i dati abbandonino il proprio dominio. Questa modalità è fornita a pagamento da The Things Industries nei livelli di servizio Enterprise e Service Provider.
• On-Site: in questa modalità è possibile creare reti carrier-grade on-site in cui i dati non abbandonano mai il sito fisico installando il Network server sul gateway stesso o realizzare reti offline. Questa modalità è fornita a pagamento da The Things Industries nei livelli di servizio Enterprise e Service Provider.

Al momento il Things Network LoRaWAN Stack è giunto alla terza versione (V3) in cui è stato reso disponibile il supporto nativo a LoRaWAN 1.1, la possibilità di utilizzare lo stack per l’implementazione di reti private sia in private cloud o on-premises, la possibilità di eseguire il peering tra reti pubbliche e private, servizi aggiuntivi come LoRaWAN FOTA (LoRa Firmware-over-the-Air), monitoring e alerting, multi-tenancy, multi-region private deployments.

Nel post The Things Network Stack V3 Update sono stati fornite maggiori informazioni sulle novità della V3 e la previsione di quando alcune di esse saranno disponibili:

• Hosted is our flagship V3 SaaS offering; fully featured, hosted and SLA backed
  
• Private Cloud is the V3 Stack in your own AWS, Azure or GCP account, with integrations with their IoT platforms
  
• Images and Binaries allow for deploying the V3 Stack on-premises, on various architectures, enabling single binary deployments on gateways to custom Kubernetes deployments in the cloud
  
• Open Source allows you to compile from source and run the Stack on your development machine
  
• Community Network is the free to use The Things Network public community network
  

Per quanto riguarda la creazione di Applicazioni in TTN questo è possibile tramite vari approci:

• Data API: consentono di ricevere eventi e messaggi dai device e di inviare messaggi ai device. E’ possibile utilizzare le Data API tramite:
  • SDKs & Libraries che mettono a disposizione TTN Client per Go, Java, Node-RED, Node.js e Python
  • MQTT (Message Queue Telemetry Transport) un protocollo per connettività machine-to-machine (M2M) / IoT che è stato progettato per il trasporto in modo leggero di messaggi publish/subscribe. TTN è in grado di utilizzare MQTT per la pubblicazione dell’attivazione dei device, dei messaggi dei device e dei messaggi di risposta a device tramite librerie MQTT Client disponibili per ogni linguaggio e piattaforma (a riguardo si veda MQTT.org Wiki e i progetti Eclipse Paho, Eclipse Mosquitto e MQTTBox)
• Application Manager API: che consentono la gestione di applicazioni, gateway e device tramite:
  • SDKs & Libraries che mettono a disposizione TTN Client per Go, Java, Node-RED, Node.js e Python
  • HTTP: ovvero tramite Community endpoints esposti con gRPC API o HTTP API

Firmware-over-the-Air (FOTA)

La LoRa Alliance nella pagina introduttiva About LoRaWAN prevede il supporto alla funzionalità Firmware Over-The-Air (FOTA) per l’aggiornamento dei firmware dei dispositivi mediante il supporto a multicast disponibile per i nodi in classe B e C (in cui è possibile avere un a finestra di ricezione indipendente da quella di trasmissione) descritto nelle specifiche LoRaWAN Specification v1.1 in cui viene evidenziato che le specifiche non descrivono un modo per configurare il multicast group e le chiavi di cifratura demandando questa configurazione al livello applicativo o ad una configurazione manuale sul nodo:

11.2 Unicast & Multicast MAC messages

Messages can be “unicast” or “multicast”. Unicast messages are sent to a single end-device and multicast messages are sent to multiple end-devices. All devices of a multicast group must share the same multicast address and associated encryption keys. The LoRaWAN Class B specification does not specify means to remotely setup such a multicast group or securely distribute the required multicast key material. This must either be performed during the node personalization or through the application layer.

17.2 Class C Multicast downlinks

Similarly to Class B, Class C devices may receive multicast downlink frames. The multicast address and associated network session key and application session key must come from the application layer.

Nel documento tecnico LoRaWAN Remote Multicast Setup Specification v1.0.0, che definisce un application layer per lo scambio di messaggi su LoRaWAN per nodi in classe B e C, viene ribadito come una sessione multicast può essere utilizzata, ad esempio, per l’upgrade dei firmware:

For example, the multicast session might be used to broadcast a firmware upgrade file. In that case the end-device might end the multicast session has soon as the full file is received without waiting for TimeOut.

Sebbene specifiche LoRa forniscano un’indicazione su come gestire il Firmware-over-the-Air with tramite LoRaWAN, va precisato che tale funzionalità presenta una serie di difficoltà:

• le trasmissioni dei Gateway non sono coordinate, questo significa che se il gateway invia messaggi in Downlink del firmware non può ricevere messaggi in Uplink dai nodi che andranno persi;
• non esiste un la possibilità a livello MAC di fare in modo che i nodi in classe A possano ricevere frame multicast, questo dipende dal fatto che il supporto multicast era stato aggiunto per i nodi in classe B e C per consentire applicazioni come il controllo dei lampioni stradali e non per trasferire aggiornamenti firmware;
• i gateway hanno un duty cycle limitato ovvero possono trasmettere solo per 1% del tempo, in base alla regolamentazione EU863-870 ISM ETSI (European Telecommunications Standards Institute) come riportato in LoRaWAN Regional Parameters v1.1rB per le bande di frequenza EU863-870 ISM, quindi buona parte delle risorse di trasmissione per i messaggi di Downlink sono usati per gli acknowledgements e i messaggi di controllo MAC e di conseguenza le risorse utilizzabili per il FOTA sono limitate.

La problematica dell’implementazione della funzionalità FOTA è stata anche oggetto dell’articolo Firmware Updates over Low-Power Wide Area Networks che illustra come il Nerwork Server di The Things Network (TTN) ha approcciato il problema concentrandosi su come inviare l’immagine del firmware ottimizzando il duty cycle del dispositivo e il consumo energetico sfruttando il Multicast per l’aggiornamento contemporaneo di più device per ottimizzare il duty cycle del gateway.

Un altro aspetto evidenziato nell’articolo Firmware Updates over Low-Power Wide Area Networks è quello relativo alla sicurezza. Infatti quando più dispositivi partecipano ad una sessione multicast temporanea in cui tutti i dispositivi condividono le stesse chiavi di sessione ci si espone ad un potenziale rischio per la sicurezza se uno dei dispositivi viene compromesso in quanto tramite le chiavi di sessione multicast un attaccante potrebbe inviare pacchetti come se provenissero dal server permettendo un attacco di tipo packet injection. Per proteggere il processo di aggiornamento l’implementazione di FOTA fatta da The Things Network (TTN) prevede tre misure di protezione:

1. quando il file viene ricevuto il dispositivo calcola il checksum dei dati ricevuti e lo invia al server nella sessione privata del dispositivo, il server confronta il checksum ricevuto con il checksum dei dati inviati, per verificare se i dati sono stati ricevuti correttamente o meno a causa di errori di trasmissione o manomissioni, e risponde ad ogni dispositivo in modo individuale nella sessione privata circa la correttezza del checksum;
2. quando il server invia al dispositivo la risposta sulla correttezza del checksum invia anche il message integrity code (MIC) per garantire l’integrità del checksum inviato al dispositivo, il MIC non può essere falsificato da nessuno che non conosca le chiavi di sicurezza della sessione sicure del dispositivo, in questo modo il server controlla il checksum del dispositivo e il dispositivo il MIC del server trasmessi nella sessione privata per convalidare il file;
3. quando un attaccante inietta pacchetti casuali il dispositivo potrebbe non essere in grado di ricostruire l’immagine originale, inoltre i dispositivi potrebbero esaurire l’alimentazione perché continuano a ricevere checksum che indicano che i dati ricevuti non sono corretti, per evitare ciò la sessione multicast ha una durata ovvero un limite fisso sul numero di messaggi e se il limite viene raggiunto il dispositivo tornerà alla sessione privata eliminando i dati.

Riferimenti

• LoRa Alliance – resource HUB
• The Things Network – Learn

Quando dobbiamo gestire un’infrastruttura RDS, soprattutto se le connessioni avvengono tramite reti poco performanti, è probabile che gli utenti lamentino malfunzionamenti generalizzati.

A volte la causa può essere imputata alla connessione, ma anche il comportamento degli utilizzatori può determinare situazioni che necessitano di approfondimento. Ad esempio, gli utenti che “chiudono” la finestra relativa alla sessione RDP senza effettuare una disconnessione corretta generano un numero elevato di sessioni disconnesse.

Per verificare il funzionamento dell’infrastruttura è utile interrogare il registro eventi in modo da individuare gli eventi significativi, soprattutto in caso di problemi di connessione.

Una RDS Farm può essere strutturata in diversi modi. L’esempio che prenderemo in considerazione in questo articolo si basa su una configurazione con accesso per mezzo di un portale Web e di un Connection Broker che ridirige le sessioni di connessione su più Session Host.

Prima di passare all’analisi vera e propria degli eventi è utile rivedere quali sono i flussi e le interazioni tra i vari componenti l’intera Farm RDS

I 5 ruoli che compongono una Farm RDS sono:

• Remote Desktop Web Access
  
• Remote Desktop Connection Broker
  
• Remote Desktop Session Host
  
• Remote Desktop Gateway
  
• Remote Desktop Licensing
  

Nel contesto analizzato in questa guida il ruolo RD Gateway non è installato e quindi non verrà considerato

Figura 1 schema dei ruoli RDS

Lo schema di figura 1 riporta in modo semplificato le relazioni tra i vari ruoli, l’uso del Web Access è utile in quanto permette da un unico portale l’accesso alle risorse che vengono rese disponibili

Configurazione della Farm tramite Server Manager

L’immagine qui sotto riporta la configurazione dell’ambiente utilizzato per l’analisi degli eventi

Figura 2 configurazione della farm RDS

Ruoli RDS

Il ruolo di Connection Broker che ha il compito di orchestrare gli accessi coordinando la distribuzione delle risorse in base al carico ed alla disponibilità degli host di sessione.

Il ruolo di Session Host, definisce i server dove fisicamente sono disponibili ed installate le applicazioni che vengono accedute tramite RDS.

Questo caso di studio non prevede la gestione di risorse di tipo Virtual Desktop (VDI)

Dal pannello di configurazione di RDS sono definiti 2 Session Host con uguale peso che verranno orchestrati tramite il Broker

Figura 3 infrastruttura Session Host

Analisi del flusso delle connessioni

Web Access

Il collegamento verso una farm RDS inizia dal ruolo di Web Access, quando l’utente ha effettuato il login viene generato e firmato digitalmente un file .RDP che permette la connessione sul Session Host

Il server Web essendo basato su IIS, ha i file di log che di default sono in “C:\inetpub\logs\LogFiles\W3SVC1”

In questa cartella, all’interno è presente un log testuale di tutte le attività. Analizzandolo è possibile identificare l’IP di provenienza della connessione ed anche l’utente che si è identificato

2019-05-19 21:32:29 10.0.1.81 GET /RDWeb/Pages/rdp/mstsc256_32x32.png – 443 dominio\utente
10.0.1.81 Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko https://ts.ictpower.it/RDWeb/Pages/it-IT/Default.aspx 200 0 0 31

Ruolo Connection Broker

Il ruolo di Broker ha la responsabilità di assicurare la connessione, ossia di fare sì che sulla base delle regole configurate, ogni utente riceva le risorse corrette siano esse Sessioni Terminal, Remote App o VM in un ambiente VDI.

Il Broker si occupa anche di gestire le sessioni interrotte riconnettendole al Session Host corretto

All’interno del Registro Eventi il ruolo di Broker archivia le informazioni in:

“Microsoft-Windows-TerminalServices-SessionBroker/Operational“

“Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational”

Registro Eventi

“Microsoft-Windows-TerminalServices-SessionBroker/Operational”

Le informazioni disponibili in questo ramo del registro permettono di rilevare le attività del broker durante la connessione verso le risorse che questo espone.

Una connessione che avviene in modo normale, senza errori, riporta i seguenti eventi in ordine cronologico

Figura 4 Sessione di login

Event ID 800

Event ID 801

Event ID 787

Event ID 818

Dettaglio di singoli eventi

Event ID 800

Figura 5 event ID 800

Questo evento riporta le richieste di connessione ed è utile per identificare le richieste di da parte degli utenti

Event ID 801

Figura 6 event ID 801

In questo evento sono riportate informazioni di dettaglio relativamente alla sessione ed in particolare il Session Host di destinazione e l’informazione su eventuali sessioni disconnesse su cui il Broker ha riconnesso la sessione in ingresso

Disconnected Session Found 0x0 indica che non erano presenti sessioni disconnesse su cui l’utente è stato indirizzato

Figura 7 event ID 801 con riconnessiona ad una sessione disconnessa

Il dettaglio dell’evento sopra informa che il collegamento in ingresso è stata assegnato ad una sessione disconnessa che non ha ancora raggiunto i limiti impostati per il reset.

Disconnected Session Found 0x1 è il dettaglio dell’evento che evidenzia questo comportamento

La condizione sopra si verifica per ogni singolo utente, non verranno mai riassegnate sessioni disconnesse ad utenti differenti

Event ID 787

Figura 8 event ID 787

Con l’interrogazione dell’evento ID 787 è possibile conoscere il nome della farm per cui l’utente ha richiesto l’accesso, viene identificata come “farm” il nome della Collection (figura 2).

Il Session ID è invece utile per identificare puntualmente la sessione utente anche sul session Host in quanto identificata in entrambe i ruoli con lo stesso ID

Event ID 818

Figura 9 event ID 818

È l’informazione ultima delle attività relative al Broker, da questo momento gli eventi dovranno essere seguiti direttamente sul Session Host su cui l’utente ha fatto accesso.

l’evento ID 818 riporta testualmente

“This connection request has resulted in a successful session logon (User successfully logged on to the end point). Remote Desktop Connection Broker will stop monitoring this connection request.”

Registro Eventi

“Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational”

In questo registro si trovano le informazioni relative alla gestione e reindirizzamento delle connessioni che il broker riceve in ingresso e ridirige verso i Session Host

Gli eventi che sono presenti per una sessione che avviene in modo normale, senza disconnessioni, sono

Event ID 1301

Event ID 1307

Figura 10 event ID 1301 versione del client RDP

Questo evento riporta il nome utente che accede alla farm RDS e l’indicazione della versione del client

Event ID 1307

Figura 11 event ID 1307

In questo evento è riportata l’informazione del Session Host di destinazione

La sequenza di eventi descritta sopra è presente anche se si accede ad una Remote App anziché ad una sessione desktop come in questo caso

Ruolo Session Host

Su questo server viene indirizzata la connessione ed è il ruolo che ospita le applicazioni, i registri eventi utili per la diagnostica delle connessioni RDP sono

“Microsoft-Windows-TerminalServices-LocalSessionManager/Operational”

“Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational”

Registro Eventi

“Microsoft-Windows-TerminalServices-LocalSessionManager/Operational”

Analogamente a quanto visto con il ruolo di Broker questo registro riporta gli eventi relativi alle connessioni che il Session Host riceve.

L’esempio sotto riporta la sequenza di eventi che è rilevabile per una connessione che inizia e viene terminata in modo normale, senza disconnessioni forzate

Figura 12 sequenza completa degli eventi su un Session Host Server

La sequenza degli eventi è la seguente e sono elencati nell’ordine quelli relativi alla connessione e successivamente quelli relativi alla disconnessione

Eventi Relativi alla connessione

Event ID 41

Event ID 42

Event ID 21

Eventi relativi alla disconnessione

Event ID 22

Event ID 23

Event ID 40

Event ID 24

Dettaglio di singoli eventi

Event ID 40/41

Figura 13 eventi 40 e 41 arbitraggio delle sessioni

Questi due eventi in successione temporale, indicano che il Session Host ha gestito l’arbitraggio della connessione ed è riportato l’ID della sessione che come abbiamo visto in precedenza, ha la sua corrispondenza sul Broker nell’evento ID 787

Event ID 21

Figura 14 event ID 13 logon utente

Questo evento riporta il dettaglio della connessione verso il Session Host con il nome utente e l’ip del client da cui è stata richiesta la connessione

Event ID 22

Figura 15 event ID 22 assegnazione della Shell

È l’ultimo degli eventi relativi al login ed all’accesso dell’utente, i tre eventi che seguono sono relativi alla disconnessione

Event ID 23

Figura 16 logoff utente

Quando viene richiesta la disconnessione “pulita” della sessione il primo evento che viene registrato è relativo all’ID 23

Event ID 40

Figura 17 event ID 40 e Reason Code 12

Questo è l’evento più significativo in caso di diagnostica, rilevarne la presenza, ma soprattutto il “Reason Code” può aiutare a diagnosticare problemi di connessione, evidenziare problemi di autenticazione o di risorse del Session Host

Figura 18 event ID 40 e reason code 5

Reason code 5 indica una disconnessione non richiesta dall’utente e tipicamente è indice di due possibili cause

Chiusura della sessione in modo anomalo della sessione RDS con la funzione “Chiudi Finestra”

Cadute della connessione di rete, questo evento è comune nel caso di connessioni particolarmente degradate

Reason code 3 indica che una sessione ha raggiunto il limite di inattività ed è stata terminata

La tabella seguente riporta i codici possibili relativi agli eventi di disconnessione

Figura 19 reason codes di disconnessione

Event ID 24

Figura 20 conclusione della sessione e completamento della disconnessione

Questo, in ordine temporale è l’ultimo evento e informa della conclusione della sessione.

Considerazioni

L’ambiente RDS è molto complesso e le variabili con cui può essere implementato sono molteplici, il caso analizzato in questo articolo prende spunto da una installazione reale dove si sono presentati problemi di gestione delle connessioni, problemi in parte dovuti alle reti di connessione ed in parte alla scelta di utilizzare alcuni utenti comuni per l’accesso al desktop e di demandare l’autenticazione dell’utente all’applicativo.

Questa modalità operativa, ha amplificato il “problema” delle sessioni disconnesse in quanto il tempo minimo impostabile per il reset di queste sessioni è di 1 minuto, l’individuazione di determinati eventi ha permesso di correggere alcune configurazioni e di implementare le modalità di accesso in modo differente

Individuazione degli eventi tramite PowerShell

Al fine di agevolare la ricerca degli eventi descritti nell’articolo, è proposto qui un semplice script PowerShell che con poche modifiche può aiutare nella ricerca dei vari eventi all’interno del registro

Per operare lo script deve aver popolata la varibile $RdsShServers con il nome di tutti i Session Host, quando eseguito verranno riportati gli eventi di disconnessione con Reason Code 5

#Rilevazione degli eventi di disconnessione non corretti

$RdsShServers = 'rdsh01srv','rdsh02srv','rdsh04srv','rdsh03srv'
foreach ($RdsShServer in $RdsShServers )

{
$NotCorrectDisconnection = Get-WinEvent -ComputerName $RdsShServer -FilterHashtable @{logname='Microsoft-Windows-TerminalServices-LocalSessionManager/Operational';ID=40 ;StartTime=(Get-Date).Date } | where-object  { $_.Message -like '*reason code 5' }
Write-Host $RdsShServer " " $NotCorrectDisconnection.Count
} 



{


$NotCorrectDisconnection
=
Get-WinEvent
-ComputerName
$RdsShServer
-FilterHashtable @{logname='Microsoft-Windows-TerminalServices-LocalSessionManager/Operational';ID=40 ;StartTime=(Get-Date).Date } |
where-object { $_.Message -like
'*reason code 5' }


Write-Host
$RdsShServer
" "
$NotCorrectDisconnection.Count


}

Il reset delle sessioni in stato disconnesso può essere gestito in modo alternativo come descritto in questo articolo

https://massarobi.wordpress.com/2019/05/10/gestione-delle-sessioni-rds-disconnesse/

Circa un anno fa in ICTPower è comparso il primo articolo sulla nuova console di gestione centralizzata di Windows Server chiamata Windows Admin Center (WAC). Gli articoli ripropongono approfondimenti sulle versioni, sugli scenari di utilizzo e sui metodi di implementazione.

In questo approfondimento vogliamo analizzare la gestione del certificato di accesso al Portale, che utilizza di default un certificato di tipo Self-Signed. Lo scenario che riproponiamo di seguito si basa, in un ambiente Enterprise, sulla diponibilità di una CA integrata in AD e configurata secondo le guide proposte anch’esse su ICTPower

Di norma l’installazione di WAC consente la scelta di un certificato già presente nello store macchina.

Se questo certificato non fosse già disponibile, è possibile indicare all’installer di generarne uno di tipo Self-Signed che avrà una scadenza di 60 giorni. Per la peculiarità di una connessione di questo tipo ai vari utenti verrà proposto un warning relativo alla connessione non sicura

Il certificato generato dall’installer è visualizzabile con il comando certlm.msc eseguito sul server dove avete installato la console di gestione di Windows Admin Center.

Figura 1 certificato Self- Signed creato durante l’installazione di Windows Admin Center

Questa guida propone i passi necessari alla modifica di una installazione già funzionante in cui è necessario sostituire il certificato auto firmato con uno “ufficiale” rilasciato dalla CA interna

I passi da eseguire sono:

• Creazione di un template ad hoc, se non già presente; il template che si utilizza è quello disponibile nella CA come “Web Server”
• Richiesta del certificato secondo il template creato, la richiesta deve essere effettuata come Account Macchina
• Riconfigurazione del WAC affinché usi il certificato ottenuto dalla CA interna

Creazione del Template sulla CA

Accedendo alla console di gestione della Issuing CA è necessario individuare il ramo Certificate Template e successivamente Manage

Figura 2 gestione template del certificato

Dall’elenco è necessario individuare il template Web Server

Figura 3 selezione del template certificato da duplicare

Con il tasto DX selezionare Duplicate Template e proseguire con le impostazioni
modificando alcuni Tab

Figura 4 definizione del nome e della validità del nuovo template certificato

Nel tab General bisogna impostare il nome del nuovo Template ed eventualmente la validità

Figura 5 impostazione della sicurezza per l’utilizzo del nuovo template certificato

Nel tab Security è necessario definire i permessi di Enroll al fine di permettere al server di Windows Admin Center di poter richiedere ed ottenere il certificato. Nell’esempio sopra la security è più “ampia” del necessario, permettendo a tutti gli utenti autenticati di usare questo template; in caso fosse necessario, potrebbero essere definiti permessi più stretti, ad esempio soltanto per l’account macchina relativo al server WAC

Terminata la configurazione del template, dalla gestione della CA, è necessario abilitarne il rilascio.

È sufficiente selezionare Certificate Template/New/ Certificate Template to Issue e dall’elenco abilitare il template duplicato in precedenza.

Figura 6 distribuzione del template duplicato

Figura 7 abilitazione del template duplicato

A questo punto la configurazione della CA è terminata ed è necessario operare sullo store di certificati macchina del WAC Server in modo da ottenere un certificato secondo il Template creato

Generazione della richiesta ed Enroll del certificato

Con il comando certlm.msc è possibile accedere direttamente allo store Certificati Macchina del Windows Admin Center e dal ramo Personal/Certificate operare come segue

Figura 8 Richiesta del certificato da utilizzare in Windows Admin Center

Con il tasto DX selezionare All Tasks e Request
New Certificate e proseguire per i passi successivi con le impostazioni predefinite

Figura 9 Wizard per la richiesta di un nuovo certificato

Figura 10 utilizzo delle Policy dichiarate in AD

Selezionando Active Directory Enrollment Policy viene visualizzato l’elenco completo dei template abilitati, e tra questi è presente anche quello creato in precedenza per WAC

Figura 11 selezione del template certificato da utilizzare per WAC

Selezionato quest’ultimo e cliccando sulla richiesta di ulteriori informazioni necessarie per l’Enroll, si deve fornire l’informazione relativa all’FQDN del server WAC

Figura 12 impostazione del nome da inserire nel certificato

Per completare questo passo è necessario modificare Subject Name ed Alternative Name in modo coerente con l’ambiente di installazione del WAC e successivamente premere Add per entrambe i campi, proseguendo con OK la richiesta può essere successivamente completata con Enroll

Figura 13 completamento dell’enrollment del certificato

Figura 14 rilascio del certificato

A questo punto nello Store Macchina del server è presente il certificato richiesto

Figura 15 visualizzazione del certificato rilasciato

Anche la parte di configurazione/richiesta del certificato dal lato del server WAC è completata, a questo punto della procedura è necessario fare si che l’applicazione utilizzi il nuovo certificato disponibile

Per Prima cosa è necessario individuare il Thumbprint del Certificato, e questo valore può essere rilevato con il comando certutil -store my oppure direttamente in modalità grafica con l’utility certlm.msc

Figura 16 Thumbprint del certificato creato per WAC

Figura 17 Thumbprint tramite certutil -store my

Tra le due possibilità, se si vuole copiare tramite “copia incolla” il valore del Thumbrint è preferibile la seconda in quanto se si utilizza la GUI vengono copiati alcuni caratteri nascosti che all’atto della validazione dell’Hash, da parte dell’installer, fanno sì che la procedura non si concluda correttamente generando il seguente errore

Figura 18 errore in fase di “lettura” del thumbrint copiato dalla GUI

Riconfigurazione dell’Installazione di Windows Admin Center per l’utilizzo del nuovo certificato

Ottenuta l’informazione sul certificato da utilizzare è sufficiente accedere al pannello di controllo nella sezione programmi e funzionalità e modificare WAC

Figura 19 modifica dell’installazione di WAC

Verrà avviato l’installer che presenterà le opzioni possibili

Figura 20 scelta delle opzioni di modifica

Selezionando Cambia e fornendo il valore del thumbprint rilevato in precedenza l’accesso al portale WAC avverrà tramite una connessione SSL cifrata con il certificato scelto

Figura 21 dichiarazione del certificato da utilizzare in sostituzione di quello self-signed

A questo punto il browser non presenta più il classico Warning relativo all’utilizzo di un certificato non valido, ed è possibile verificare che la connessione SSL avviene per mezzo del certificato impostato prima

Figura 22 accesso al portale e verifica dell’utilizzo del certificato rilasciato dalla Ca interna

La procedura vista qui è da utilizzare per una installazione di Windows Admin Center già operativa e funzionante, ma con un certificato self-signed generato in fase di installazione, tuttavia disponendo già da subito di un certificato da utilizzare per WAC sarebbe sufficiente impostarne il valore, da rilevare nelle modalità descritte sopra o con metodi alternativi, e variare le opzioni di default come evidenziato in figura 21 durante la fase di prima installazione.

La procedura riportata in questa guida è stata seguita ed implementata per una installazione in produzione con CA versione 2012R2, Windows Admin Center versione 1904 installato su Windows Server 2016. Come è rilevabile dalla documentazione relativa a WAC sono possibili altri scenari di installazione, ma la parte che è oggetto di questa guida rimane pressoché invariata.

Riferimenti

Windows Admin Center Documentazione Ufficiale

IctPower Documentazione su Windows Admin Center

IctPower Documentazione sulla implementazione di CA di tipo Enterprise

Introduzione

In questo articolo faremo alcune considerazioni sul licensing dei Remote Desktop Services tratte dall’analisi dell’EULA (End-User License Agreement) ovvero l’accordo di licenza con l’utente finale di Windows Server e Windows. Occorre infatti prestare attenzione quando è necessario acquistare le RDS CAL per non incorrere in fraintendimenti soprattutto quando si utilizzano prodotti di terze parti per la gestione della multiutenza.

Windows Server EULA e RDS

Gli accordi di licenza finale dei prodotti Microsoft tradotti nelle varie lingue sono disponibili al seguente link Microsoft License Terms da cui è possibile ricercare l’EULA per Windows Server 2019 Datacenter e Standard in lingua italiana disponibile anche al seguente link diretto https://www.microsoft.com/en-us/Useterms/Retail/WindowsServer2019/DatacenterAndStandard/Useterms_Retail_WindowsServer2019_DatacenterAndStandard_Italian.htm.

Sebbene di seguito di citerà l’EULA per Windows Server 2019 Datacenter e Standard le considerazioni valgono in linea di principio anche per le versioni precedenti di Windows Server.

Una prima considerazione risaputa è che i servizi Windows Server Remote Desktop richiedono licenze CAL Aggiuntive (punto 4 lettera a) ovvero richiedono la versione corrispondente della licenza CAL per Servizi Windows Server Remote Desktop (RDS CAL).

Il punto 4 lettera b dell’EULA specifica in modo più dettagliato quando occorre possedere l’RDS CAL:

“Servizi Windows Server Remote Desktop. In aggiunta a una licenza CAL per Windows Server, il licenziatario dovrà acquistare la corrispondente versione della licenza CAL per Servizi Windows Server Remote Desktop per ciascun utente o dispositivo che (i) accede, in modo diretto o indiretto, alla funzionalità Remote Desktop Services, (ii) accede, in modo diretto o indiretto, al software server per ospitare un’interfaccia utente grafica (utilizzando la funzionalità Servizi Windows Server Remote Desktop o altra tecnologia) o (iii) accede alla funzionalità Servizi Multipoint. Per ulteriori informazioni sulle licenze CAL per Servizi Desktop Remoto Windows Server, visitare la pagina (aka.ms/windowsrds).”

In particolare si noti che viene specificato che l’RDS CAL è necessaria se si accede in modo diretto o indiretto al software server per ospitare un’interfaccia utente grafica (utilizzando la funzionalità Servizi Windows Server Remote Desktop o altra tecnologia). In altre parole la necessità dell’RDS CAL è legata al fatto non solo di utilizzare la funzionalità Remote Desktop Services, ma anche al fatto di accedere a software server che ospita un’interfaccia utente grafica. Questo significa che se si implementano soluzioni di terze parti che offrono la possibilità di accedere all’interfaccia grafica del server in modalità simile a quanto offerto dalla funzionalità Remote Desktop Services è comunque necessaria l’RDS CAL.

Questo aspetto è anche chiarito più esplicitamente nel documento di maggio 2017 Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS relativo a Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 e Windows Server 2016 in cui viene indicato:

“Server RDS CAL for each user or device that (i) directly or indirectly accesses any of the RDS functionality and/or (ii) directly or indirectly accesses the server software to interact with a graphical user interface (GUI) using RDS functionality or any other third-party technology.

Remote Desktop Services functionality is defined as those features or services that are running when enabling the Remote Desktop Services role and/or role service(s) in Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016. This includes, but is not limited to, Remote Desktop Gateway, Remote Desktop Web Access, Remote Desktop Connection Broker, Remote Desktop Session Host, and Remote Desktop Virtualization Host.”

Sempre nel documento Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS è possibile trovare la seguenti FAQ da cui risulta che l’RDS CAL è necessaria se si fa uso di una qualunque tecnologia che permette l’interazione con la GUI.

“Do I need an RDS CAL if I am using a third-party technology like Citrix XenApp, Citrix XenDesktop, Ericom PowerTerm WebConnect, Quest Virtual Access Suite, GraphOn Go-Global, and so on to directly or indirectly access the server software to interact with the GUI?

Yes. An RDS CAL is required for any technology used to directly or indirectly interact with the GUI. This includes (but is not limited to) using Microsoft Remote Desktop Services or other third-party software that enables multiuser scenarios on Windows Server.”

Un’altra interessante FAQ presente nel documento Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS è quella che riporta che la versione della RDS CAL deve corrispondere alla versione del sistema operativo server (indicazione che era anche fornita nel punto 4 lettera b dell’EULA):

“What version of the RDS CALs do I need?

The CAL version must correspond to the server software version it accesses. Older version of CALs cannot be used with the newer version of the server software, but newer version RDS CALs can be used with an older version of the server software as defined in the interoperability matrix at http://social.technet.microsoft.com/wiki/contents/articles/14988.rds-and-ts-cal-interoperability-matrix.aspx.

The only exception to this rule are the R2 server releases where the older CALs can sometimes work with the newer R2 release of server software. For example, Windows Server 2012 RDS CALs can be used with Windows Server 2012 R2, and there are no new Windows Server 2012 R2 RDS CALs required.”

Una terza FAQ presente nel documento Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS riporta inoltre che l’RDS CAL è necessaria anche quando si usa una qualunque funzionalità dei Remote Desktop Services indipendentemente dal fatto che si implementi o meno un ambiente multiutente:

“Do I need an RDS CAL if I am not running a multiuser environment but use functionality in Remote Desktop Services—for example, Remote Desktop Gateway?

Yes. An RDS CAL is required to use any functionality included in the Remote Desktop Services role in Windows Server. For example, if you are using RDS Gateway and/or Remote Desktop Web Access to provide access to a Windows client operating system on an individual PC, both an RDS CAL and Windows Server CAL are required.”

Il punto 4 lettera a dell’EULA specifica le eccezioni per le quali il licenziatario non necessita di CAL e una di queste eccezioni riguarda un massimo di due dispositivi o utenti che accedono alle istanze del software server esclusivamente per tali istanze. Ciò implica che non sono necessarie CAL e RDS CAL per un massimo di due dispositivi o utenti che accedono a istanze sul server per scopi amministrativi.

Tale aspetto è chiarito più esplicitamente sempre nel documento Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS con indicazione specifica e una FAQ dedicata:

“No RDS CALs are required for up to two users to access instances of the server software for administration purposes.”

“Do I have to acquire RDS CALs if I am only remotely administering Windows Server operating systems by using Remote Desktop for Administration?

No. Up to two users may connect to the Windows Server operating system simultaneously to perform administrative functions without needing any RDS CALs. Additional administrative users need the appropriate RDS CALs.”

Windows 10 EULA e RDS

Sempre dal link Microsoft License Terms è possibile ricercare l’EULA per Windows 10 in lingua italiana disponibile anche al seguente link diretto https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/Useterms_Retail_Windows_10_Italian.htm.

Dalla lettura dell’EULA di Windows 10 è possibile concludere che nel caso si voglia accedere remotamente al sistema in modalità multiutenza per scopi diversi dall’assistenza remota, anche con strumenti di terze parti, occorre possedere una licenza per ogni utente che esegue l’accesso.

L’accesso multiutente viene disciplinato in maniera più precisa nelle seguenti opzioni multiutente contenute nel punto 2 lettera d dell’EULA:

“(ii) Connessioni multiple o in pool. L’hardware o il software utilizzato dal licenziatario per eseguire il multiplexing o il pooling delle connessioni oppure per diminuire il numero di dispositivi o utenti che accede al software o lo usa non riduce il numero di licenze necessarie. Il licenziatario potrà utilizzare tale hardware o software solo nel caso in cui disponga di una licenza per ciascuna istanza del software in uso.

(iii) Connessioni dei dispositivi. Il licenziatario potrà consentire a un massimo di 20 ulteriori dispositivi di accedere al software installato sul dispositivo con licenza per utilizzare le seguenti funzionalità software: servizi file, servizi stampa, servizi di informazioni Internet, Condivisione connessione Internet e servizi di telefonia sul dispositivo con licenza. Il licenziatario potrà consentire a un numero qualsiasi di dispositivi di accedere al software sul dispositivo con licenza per sincronizzare i dati tra i dispositivi. Il presente Articolo non indica, tuttavia, che il licenziatario abbia il diritto di installare il software o di utilizzare la funzione principale del software (diversa dalle funzionalità ivi elencate) su uno qualsiasi di questi altri dispositivi.

(v) Accesso remoto. Non più di una volta ogni 90 giorni, il licenziatario potrà designare un singolo utente che utilizzerà fisicamente il dispositivo con licenza quale utente autorizzato. L’utente autorizzato potrà accedere al dispositivo con licenza da un altro dispositivo tramite le tecnologie di accesso remoto. Altri utenti, in momenti diversi, potranno accedere al dispositivo con licenza da un altro dispositivo tramite le tecnologie di accesso remoto, ma solo su dispositivi dotati di una licenza specifica per eseguire un’edizione identica o superiore di questo software.

(vi) Assistenza remota. Il licenziatario potrà utilizzare le tecnologie di assistenza remota per condividere una sessione attiva senza dover ottenere ulteriori licenze per il software. Assistenza remota consente a un utente di connettersi direttamente al computer di un altro utente, in genere per correggere eventuali problemi.”

Inoltre occorre tenere in considerazione anche le seguenti restrizioni riportate nel punto 2 lettera c dell’EULA:

“(i) utilizzare o virtualizzare alcune funzionalità del software separatamente;

(iv) aggirare le restrizioni o le limitazioni tecniche presenti nel software;

(v) utilizzare il software come software server, per l’hosting di servizi commerciali, renderlo disponibile per l’uso simultaneo da parte di più utenti su una rete, installarlo su un server e consentire agli utenti di accedervi da remoto o installarlo su un dispositivo per l’utilizzo solo da parte di utenti remoti;”

Conclusioni

Concludendo possiamo riassumere che in ambiente Windows Server è necessaria una RDS CAL ogni volta che si utilizza una qualunque funzionalità dei Remote Desktop Services (indipendentemente dal fatto che si implementi o meno un ambiente multiutente) o si se si fa uso di una qualunque tecnologia che permette l’interazione con la GUI.

Mentre per quanto riguarda Windows 10 solo l’utente a cui è stata assegnata la licenza può accedere al dispositivo da un altro dispositivo tramite le tecnologie di accesso remoto, mentre altri utenti, in momenti diversi, potranno accedere al dispositivo da altri dispositivi tramite le tecnologie di accesso remoto solo se tali dispositivi sono dotati di una licenza specifica per eseguire un’edizione identica o superiore a quella del dispositivo a cui si connettono.

Riferimenti

• Microsoft License Terms
• Windows Server2019 Datacenter and Standard EULA Italian.htm
• Windows 10 EULA Italian
• Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS

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

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

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

Server Manager\Remote Desktop Services\Collections\Desktop1

Identificata la sessione, con il dato DX selezionare Shadow

Figura 1 selzione della sessione connessa

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

Figura 2 modalità di connessione

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

Figura 3 prompt di conferma della richiesta di accesso

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

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

Gestione dei permessi di Shadowing

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

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

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

Impostazioni tramite Wmic (WMI)

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

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

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

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

Per verificare le impostazioni correnti è possibile utilizzare il comando

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

il cui output sarà simile a questo

Caption DenyAdminPermissionForCustomization Description InstallDate Name PolicySourceDenyAdminPermissionForCustomization Status StringSecurityDescriptor TerminalName

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

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

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

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

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

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

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

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

Impostazioni tramite Group Policy (GPO)

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

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

Figura 4 impostazione delle modalità di shadowing

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

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

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

Figura 5 impostazioni modalità di shadowing nel contesto utente

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

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

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

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

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

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

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

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

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

(Get-Process -PID $pid).SessionID

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

Scenario di utilizzo delle funzioni di Shadow

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

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

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

Identificazione della sessione RDS

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

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

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

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

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

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

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

Figura 6 informazioni di sessione

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

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

Gestione guidata del di Mirror della sessione RDS

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

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

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

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

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

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

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



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

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


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


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

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

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

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

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


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


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

    $TsSessionControl = "/Control"
       }


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

Figura 7

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

Considerazioni

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

Introduzione

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

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

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

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

Requisti di sistema e note di installazione

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

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

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

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

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

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

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

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

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

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

Installazione di SQL Server 2016 SP2

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

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

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

Installazione di SQL Server Management Studio (SSMS) 16.5.3

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

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

Al termine dell’installazione installare gli aggiornamenti necessari.

Installazione di System Center DPM 1801

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

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

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

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

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

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

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

Installazione dell’aggiornamento a System Center DPM 1807

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

Scaricare i file di cui è composto l’aggiornamento:

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

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

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

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

Upgrade di SQL Server 2016 a SQL Server 2017

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

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

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

Conclusioni

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

Riferimenti

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

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

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

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

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

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

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

Autorizzazione del servizio DHCP

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

Figura 1 autorizzazione con GUI

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

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

Figura 2 autorizzazione con PowerShell

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

Figura 3 get-DhcpServerInDC

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

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

PS C:\Users\Administrator.DC01> netsh

netsh>dhcp

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

for DHCP Server.

Microsoft recommends that you transition to Windows PowerShell if you currently

use netsh to configure and manage DHCP Server.

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

a list of commands to manage DHCP Server.

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

about PowerShell commands for DHCP Server.

netsh dhcp>

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

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

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

Export delle configurazioni e dati del DHCP server attivo

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

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

Figura 4 Opzioni di export del DHCP

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

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

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

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

Figura 5 Dhcp Server Attivo da migrare

Figura 6 Esecuzione cmdlet Export-DhcpServer

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

Import delle configurazioni e dati nel nuovo server

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

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

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

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

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

Figura 7 Esecuzione CmdLet Import-DhcpServer

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

Figura 8 Ripristino delle configurazioni

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

Riferimenti

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

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

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

Introduzione

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

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

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

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

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

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

Configurazione di MBS

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

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

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

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

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

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

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

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

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

Passo 4: Creazione di un volume nel disco virtuale.

Aggiunta del volume allo storage di DPM

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

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

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

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

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

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

Conclusioni

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

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

Riferimenti

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

Nel meetup del 26 settembre 2019, organizzato da Torino Technologies Group in collaborazione con ICTPower.it, Ermanno Goletto (Microsoft MVP Reconnect) e Roberto Massa (Microsoft MVP Reconnect) approfondiranno i fondamenti e le funzionalità dell’IPv6 dal punto di vista dell’ammistratore di sistema esaminando quali sono i passi da seguire per la sua adozione valutando sia i vantaggi che le problematiche da affrontare.

La diffusione di Internet e il proliferare dei dispositivi connessi (smartphone, tablet, smartwatch) hanno portato alla luce i limiti dell’IPv4 costringendo provider e organizzazioni ad adottare nel prossimo futuro una nuova versione dell’Internet Protocol denominata IPv6.

Per iscrivervi cliccate sul’immagine sotto:

Sono disponibili le slides utilizzate durante l’evento, che potete scaricare dal link https://github.com/torinotechnologiesgroup/docs/raw/master/20190927_IPv6.pdf

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

La diffusione di Internet e il proliferare dei dispositivi connessi (smartphone, tablet, smartwatch) hanno portato alla luce i limiti dell’IPv4 costringendo provider e organizzazioni ad adottare nel prossimo futuro una nuova versione dell’Internet Protocol denominata IPv6.

Nella sessione approfondiremo i fondamenti e le funzionalità dell’IPv6 dal punto di vista dell’amministratore di sistema esaminando quali sono i passi da seguire per la sua adozione valutando sia i vantaggi che le problematiche da affrontare.

Nel meetup del 26 settembre organizzato da Torino Technologies Group in collaborazione con ICTPower.it Ermanno Goletto (MVP Reconnect) e Roberto Massa (MVP Reconnect ) hanno approfondito i fondamenti e le funzionalità dell’IPv6 dal punto di vista dell’amministratore di sistema esaminando quali sono i passi da seguire per la sua adozione valutando sia i vantaggi che le problematiche da affrontare.

Grazie a tutti i partecipanti all’Meetup e arrivederci al prossimo appuntamento!

Le possibilità offerte da Azure sono decisamente molte, una di queste è il servizio che permette l’archiviazione di log eventi dalle diverse macchine monitorate sia in cloud che on-prem e permette successivamente di creare report ed analisi di eventi con strumenti di ricerca molto potenti e veloci ma soprattutto con sintassi intuitive ed un autocompletamento delle query che consente anche a chi si avvicina a questo ambiente per la prima volta, di apprezzarne la sua potenza.

Log Analytics è il prodotto che conosciamo ora, ma inizialmente era stato sviluppato e proposto con il nome di OMS (Operations Management Suite) e disponeva di un proprio portale di accesso separato da Azure Portal. Dall’inizio del 2019 il vecchio portale è stato deprecato e recentemente completamente dismesso. Tutte le funzionalità sono ora presenti nel Portale unico di Azure.

L’architettura è veramente molto semplice e si basa su agenti installati sulle singole macchine e connessi poi al Workspace presente in Azure. Naturalmente gli agenti possono essere sia Windows che Linux in modalità per così dire nativa, ma un agente Linux può integrarsi senza nessuna difficoltà con un servizio Syslog presente sul sulla stessa macchina e quindi ricevere flussi di messaggi in arrivo da altri sistemi che usano questo protocollo e veicolarli verso Log Analitycs in modo del tutto indipendente dall’agent.

Questa modalità operativa è ad esempio molto utile per ricevere ed archiviare messaggi provenienti da apparati di rete, firewall o sistemi di altro genere ed iniettare i vari eventi in Log Analytics.

Attivazione del Portale Log Analytics (Azure)

Vediamo come è possibile con pochi passi attivare un Workspace Gratuito per 30 giorni che ci permetterà di valutare ed apprezzare la potenza di questo ambiente.

In pratica dobbiamo attivare una sottoscrizione Azure di valutazione o meglio gratuita per 12 mesi.

Dal portale https://azure.microsoft.com/it-it/pricing/details/monitor/ selezioniamo “Prova Gratuitamente”

Figura 1 portale di accesso

Loggatevi con il vostro Microsoft Account per creare una nuova sottoscrizione Azure. Se non possedete un Microsoft Account potete crealo gratuitamente al link https://account.microsoft.com/

Figura 2 creazione accesso al portale

Figura 3 login con l’account Microsoft

Effettuato l’accesso dovremo fornire informazioni personali, necessarie alla conferma dell’identità

Figura 4 procedura di identificazione

Procedendo con Avanti ci verrà chiesto di confermare la nostra “identità” mediante Telefono

Figura 5 attivazione mediante SMS

E potremo indicare se ricevere un SMS od una chiamata in modo da completare la verifica

Figura 6

Scegliendo una verifica tramite SMS ci verrà inviato un codice, che dovrà essere digitato nel campo di corrispondente. Procedendo nell’attivazione dovremo fornire i dati di una carta di credito, su cui non verrà addebitato alcun costo, se non prima di aver accettato e confermato, (alla scadenza del periodo di un anno) di voler autorizzare gli addebiti.

Figura 7 caricamento dei dati della Carta di Credito

Terminata la fase di autorizzazione/verifica tramite Carta di Credito, l’ultimo passaggio è quello dell’accettazione del contratto per il quale è sufficiente selezionare solamente la sottoscrizione e non l’invio di informazioni offerte etc.

Figura 8 accettazione del contratto

Dopo l’ultima conferma possiamo accedere direttamente al portale

Figura 9 completamento della procedura di attivazione dell’account Azure

Cliccando su “Vai al portale” accediamo direttamente al Dashboard della sottoscrizione

Figura 10

A questo punto la sottoscrizione Azure è pronta ed attiva per 30 giorni e possiamo procedere ad attivare il workspace di Log Analytics e connettere gli elementi da monitorare.

Attivazione del Workspace di Log Analytics

Esistono vie diverse per creare un Workspace, la più semplice è quella di selezionare Create Resource in alto a destra nel portale

Figura 11 Creazione della Risorsa

E successivamente digitale Log Analytics nel campo di ricerca delle varie risorse disponibili

Figura 12

Proseguendo viene richiesta un’ulteriore conferma

Figura 13 Creazione della Risorsa Log Analytics

Successivamente con Create dobbiamo fornire una serie di informazioni per consentire l’avvio del Workspace

Figura 14 Informazioni necessarie per la creazione del Workspace

Nell’ordine è richiesto un nome per il Workspace, la definizione di un Resource Group ( è preferibile crearne uno ad hoc ) e la posizione geografica delle risorse, mentre il tipo di pricing di default è creato con un prezzo per GB secondo il modello del 2018. Questa impostazione sarà modificabile successivamente.

L’opzione disponibile gratuitamente è utilizzabile con il limite di conservazione di 30 giorni e per un limite di upload di 500 GB al giorno, mentre il Workspace creato non avrò scadenza e sarà utilizzabile per sempre.

Al termine della creazione, quando viene notificato il completamento dell’attività, possiamo accedere al Workspace e proseguire con le attività di deploy degli agenti.

Per poter avere un accesso più rapido alla nuova risorsa, possiamo inserirla come preferita nella parte sinistra del portale, è sufficiente digitare Log Analytics Workspace nella casella di ricerca delle risorse dopo essersi posizionati su All Services e successivamente selezionare la stella in corrispondenza

Figura 15 Ricerca della Risorsa

Collegamento di una risorsa sul portale Log Analitycs

Possiamo procedere ora con l’installazione vera e propria dell’agente sui vari server che possono essere sia Windows che Linux. A questo link è possibile trovare l’elenco delle distribuzioni compatibili https://docs.microsoft.com/it-it/azure/security-center/security-center-os-coverage

I passi da seguire per installare l’agente sono i seguenti

• Accesso al portale Azure
• Accesso alla risorsa Log Analytics creata in precedenza
• Selezionare Avvio Rapido
• Scegliere il tipo di risorsa da connettere al servizio

Figura 16 individuazione della risorsa da connettere a Log Analytics

In questo esempio sceglieremo di connettere un singolo computer on-premises e più specificatamente un Domain Controller.

Nel passo successivo dobbiamo selezionare il tipo di sistema operativo su cui installare l’agente e recuperare le informazioni relative all’area di lavoro ed alle chiavi di accesso che permettono l’autenticazione del sistema

Figura 17 download agente ed informazioni di autenticazione all’Area di Lavoro

Installazione dell’Agente

Dopo aver effettuato il download dell’agente coerente con la versione del sistema operativo in uso, si procede con l’avvio dell’installazione.

Figura 18 installazione Agente

Figura 19 accettazione Licenza

Figura 20 selezione percorso di installazione

Figura 21 selezione del collettore a cui connettersi

Figura 22 impostazione delle informazioni di connessione

Figura 23 utilizzo di Microsoft Update per gli aggiornamenti dell’agent

Figura 24 avvio dell’installazione

Figura 25 conferma termine dell’installazione

Terminata l’installazione è possibile dal Pannello di Controllo verificare se l’agente è installato ed in comunicazione con il Workspace di Log Analytics

Figura 26 stato dell’agent sul server connesso

Mentre sul Portale Log Analytics troveremo le informazioni relative al numero di server connessi ed al loro stato

Esistono più modi per visualizzare lo stato dei vari agent connessi, è anche possibile iniziare a familiarizzare con la ricerca all’interno dell’archivio log con una semplice query che rileva lo stato degli Heartbeat dei vari Agenti

È sufficiente posizionarsi nella sezione LOG e digitare

Heartbeat

| where OSType == ‘Windows’

| summarize arg_max(TimeGenerated, *) by SourceComputerId

In modo da ottenere il resoconto del numero di agenti Windows connessi

Figura 27 rilevazione degli agenti connessi

A questo punto della configurazione il Workspace è pronto ed è possibile attivare tutta una serie di soluzioni di monitoraggio ed analisi della sicurezza. Le varie soluzioni sono attivabili direttamente dal Marketplace di Azure.

Ad esempio, la soluzione Antimalware Assesment consente di rilevare gli eventi tipici dall’ambiente di protezione del sistema, quale ad esempio il Defender e Treath Protection, nel caso riportato qui sotto è presente la rilevazione del Test File Eicar

Figura 28 report di stato della soluzione antimalware

Mentre l’apertura del workspace ed alcune funzioni sono gratuite, l’utilizzo di altre soluzioni presuppone un pagamento che di norma è per nodo/mese.

Riferimenti:

https://docs.microsoft.com/it-it/azure/azure-monitor/log-query/get-started-portal

https://docs.microsoft.com/it-it/azure/azure-monitor/log-query/log-query-overview

Poco più di un anno fa, Microsoft ha annunciato che il suo browser Microsoft Edge sarebbe stato “ricreato” basandosi sul progetto open source Chromium (su cui è basato il famoso browser Google Chrome) con l’obiettivo di offrire una migliore compatibilità ed esperienza, portando meno frammentazione per gli sviluppatori e una partnership con la comunità di Chromium utile a migliorare il “motore” stesso.

Dal 15 gennaio 2020 il nuovo browser è finalmente disponibile per il download in versione stabile (79.x) per tutti i sistemi operativi (Windows, macOS, Android e iOS) e con più di 90 lingue supportate. Per approfondimenti potete leggere l’articolo Nuovo anno, nuovo browser. Arriva il nuovissimo Microsoft Edge

Tuttavia in ambienti di produzione (School or Business) come vengono definiti dal portale da cui è possibile scaricare il nuovo Browser, il deploy massivo risulta particolarmente complesso con l’installazione non automatizzata ed utilizzando l’installer on-line.

Per poter ovviare a questo limite è disponibile un download compatto in formato MSI del browser stesso. In questo modo, anche senza particolari tool di deploy, ma con la funzionalità di Software Installation disponibile in AD, è possibile installare il nuovo browser in un ambiente di dominio esteso e complesso.

Download del Pacchetto di Installazione

Per prima cosa è necessario accedere al portale di Download della versione Business di Edge, da cui è necessario identificare puntualmente la versione e la piattaforma da installare

Figura 1 Selezione del Download di Edge

Come possiamo notare è disponibile anche una versione per macOS, mentre è anche possibile eseguire il Download dei file ADM(x) per il completo governo del browser tramite GPO.

Effettuato il download del file .msi dal portale, lo posizioneremo all’interno di una share raggiungibile in sola lettura anche dagli account macchina

Figura 2 permessi della share

Nel nostro esempio il file è stato salvato in una cartella condivisa raggiungibile tramite il path UNC \\dc01\supporto

Creazione della GPO di installazione tramite Software Distribution

Quando abbiamo a disposizione il pacchetto .MSI possiamo procedere alla creazione di una GPO apposita per il Deploy

Accedendo alla Group Policy Management Console dobbiamo creare una nuova Group Policy e possiamo scegliere se definire una GPO di macchina o di utente per l’installazione. Nel primo caso l’installazione sarà effettuata al riavvio della postazione, mentre nel secondo caso all’atto del login utente. In questo esempio vedremo una installazione per postazione.

A questo punto dobbiamo decidere dove applicare la GPO. Di default ogni account macchina viene creato nel Container “Computers” al quale non sono applicabili Group Policy, per cui creeremo una OU nella quale andremo a spostare le postazioni su cui installare il nuovo Edge, a cui agganceremo la GPO.

Figura 3 creazione della GPO applicata alla OU

Figura 4 edit della GPO

In questo passaggio dovremo specificare il percorso UNC definito in precedenza

Figura 5 selezione del pacchetto

Proseguendo ci verrà proposto se l’installazione dovrà essere di tipo assegnato od avanzato; la modalità assegnata è la più indicata nel caso di primo deploy di un pacchetto, nel caso invece di modifiche a pacchetti già presenti potremo usare la modalità avanzata, ma non è oggetto di questa guida.

Figura 6 modalità di deploy

Confermando con OK si conclude la procedura ed il pacchetto è pronto per essere installato.

Figura 7configurazione del deploy del pacchetto

Connettendosi ad una postazione ed attendendo o forzando la ricerca di nuove impostazioni, vediamo con il comando gpresult /R /SCOPE COMPUTER che la group policy è pronta per l’installazione, che verrà eseguita al riavvio successivo del sistema.

Figura 8 Installazione di Edge completata

Questa modalità di installazione è anche utilizzabile su sistemi windows10 edizioni LTSC o LTSB che non hanno Edge Installato nativamente.

Riferimenti:

https://support.microsoft.com/it-it/help/4501095/download-the-new-microsoft-edge-based-on-chromium

Tutti sappiamo quanto sia importante la sicurezza informatica e da molto tempo siamo sensibilizzati a questo argomento.

Ma siamo in grado di applicarla realmente?

Il cloud ci permette di essere più o meno sicuri rispetto all’on-premises?

Siamo in grado di gestire in maniera corretta gli accessi, i dispositivi, i file e le risorse informatiche aziendali?

La nostra è un’azienda moderna che sa stare al passo coi tempi?

A tutte queste domande cercheremo di rispondere nel seminario online del 27 marzo 2020

Nicola Ferrini affronterà il tema della sicurezza delle autenticazioni degli utenti.
“Identity is the new perimeter” è la sintesi dell’importanza di proteggere gli accessi degli utenti. L’autenticazione sicura passwordless è ormai una realtà che offre un livello di sicurezza superiore rispetto alla tradizionale combinazione di password e autenticazione a più fattori (MFA).

Durante la sessione verrà mostrato qual è lo stato dell’arte della passwordless authentication e analizzeremo le diverse funzionalità offerte: Windows Hello for Business, Microsoft Authenticator app e FIDO2 Security Keys.

Roberto Tafuri affronterà invece il tema del Modern management con Microsoft Intune.
Poiché le aziende hanno bisogno che i propri dipendenti siano sempre più “mobili”, il ruolo dell’IT Admin è diventato molto più complesso rispetto al passato e non è più limitato a gestire i desktop, ma anche i dispositivi mobili.
L’utilizzo di Microsoft Intune, uno strumento di management cloud-based, permette di semplificare il lavoro degli amministratori di sistema.

Durante la sessione saranno analizzati i vantaggi e le funzionalità principali della soluzione.

Luca Cavana ci aiuterà a capire come gestire i permessi degli amministratori tramite Azure AD Privileged Identity Management

Assegnare il privilegio corretto, solo quando necessario e per un motivo documentato, è un obiettivo di compliance alle normative ed anche un potente strumento di sicurezza. Un amministratore compromesso, anche un semplice operatore di Help Desk, può avere impatti devastanti su una azienda.

Durante la sessione verrà mostrato come configurare Azure AD Privileged Identity Management e come avviene il processo di richiesta, approvazione e rilascio di un ruolo amministrativo su Microsoft Azure e Office 365.

Ermanno Goletto e Roberto Massa mostreranno come adeguare l’infrastruttura IT a normative e regolamenti per la sicurezza ICT

Gli articoli 25 e 32 del GDPR relativi alla protezione dei dati e la sicurezza del trattamento implicano l’adozione di misure tecniche e organizzative adeguate a garantire la sicurezza dei dati personali.
Nella sessione verranno analizzate le indicazioni tecniche che possono guidare aziende private, pubbliche amministrazioni e fornitori di servizi per intraprendere un percorso volto alla cybersecurity e alla protezione dei dati coerente con i regolamenti stessi. L’approccio della discussione sarà di taglio tecnico e analizzerà come il Framework Nazionale per la Cybersecurity e la Data Protection e le Misure minime di sicurezza ICT per le pubbliche amministrazioni possono essere impiegati per l’adeguamento alle normative in ambito di protezione dei dati personali e cybersecurity.

Vito Macina ci indicherà la strategia migliore per prepararci ad aggiornare Windows 10 alla prossima versione che, presumibilmente, sarà Windows 10 May 2020 Update.

Windows 10 festeggia i suoi primi 5 anni e continua ad evolversi con nuovi cambiamenti dal punto di vista degli aggiornamenti di funzionalità e della loro distribuzione. In questa sessione analizzeremo le ultime novità in vista del primo grande aggiornamento del 2020, includendo concetti pratici, terminologie, definizioni e tabelle riepilogative.

AGENDA

Vi aspettiamo online!

La partecipazione al seminario è GRATUITA. Per registrarvi cliccate sull’immagine sotto:

Tutti sappiamo quanto sia importante la sicurezza informatica e da molto tempo siamo sensibilizzati a questo argomento.

Ma siamo in grado di applicarla realmente?

Il cloud ci permette di essere più o meno sicuri rispetto all’on-premises?

Siamo in grado di gestire in maniera corretta gli accessi, i dispositivi, i file e le risorse informatiche aziendali?

La nostra è un’azienda moderna che sa stare al passo coi tempi?

A tutte queste domande abbiamo cercato di rispondere nel seminario online del 27 marzo 2020.

Gli articoli 25 e 32 del GDPR relativi alla protezione dei dati e la sicurezza del trattamento implicano l’adozione di misure tecniche e organizzative adeguate a garantire la sicurezza dei dati personali.
Nella sessione abbiamo analizzato le indicazioni tecniche che possono guidare aziende private, pubbliche amministrazioni e fornitori di servizi per intraprendere un percorso volto alla cybersecurity e alla protezione dei dati coerente con i regolamenti stessi. L’approccio della discussione è stata di taglio tecnico e abbiamo analizzato come il Framework Nazionale per la Cybersecurity e la Data Protection e le Misure minime di sicurezza ICT per le pubbliche amministrazioni possono essere impiegati per l’adeguamento alle normative in ambito di protezione dei dati personali e cybersecurity.

Potete scaricare la presentazione della sessione al link https://www.ictpower.it/download/POWERCON2020 – Goletto – Massa – Come adeguare l’infrastruttura IT a normative regolamenti per la sicurezza ICT.pdf

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