Con l’uscita di Windows Server 2016 molte infrastrutture prenderanno la decisione di aggiornare i propri Domain Controller in particolar modo se ancora ne hanno alcuni basati su Windows Server 2003. La dismissione dei Domain Controller Windows Server 2003 consente infatti di trarre vantaggio dalle numerose funzionalità che sono state introdotte in Active Directory rispetto a Windows Server 2003 che rappresenta la versione di sistema operativo più datata da cui è ancora possibile eseguire la migrazione. Nel quarto dei quattro articoli sull’analisi le problematiche relative all’aggiornamento di un’infrastruttura Active Directory basata su Domain Controller Windows Server 2003 verrà analizzata la migrazione della replica SYSVOL da FRS a DFS.

Il primi tre articoli sono disponibili ai seguenti:

• Upgrade domain controller a Windows Server 2016 Parte 1 di 4
• Upgrade domain controller a Windows Server 2016 Parte 2 di 4
• Upgrade domain controller a Windows Server 2016 Parte 3 di 4

Argomenti

• Vantaggi della replica SYSVOL tramite DFS e pianificazione della migrazione da FRS a DFS
• Verifica dei prerequisiti e della funzionalità della replica FRS
• Migrazione del dominio nello stato Prepared
• Migrazione del dominio nello stato Redirect
• Migrazione del dominio nello stato Eliminated
• Conclusioni

Vantaggi della replica SYSVOL tramite DFS e pianificazione della migrazione da FRS a DFS

I Domain Controller utilizzano la directory condivisa SYSVOL per replicare tra loro gli script di logon e i file delle Group Policy. In Windows Server 2000 e Windows Server 2003 la replica della directory SYSVOL avviene tramite File Replication Service (FRS). A partire da Windows Server 2008 viene utilizzata invece la replica DFS se il livello funzionale del domino è Windows Server 2008, in caso contrario si continua ad utilizzare FRS.

Questo significa che nell’infrastruttura di esempio dal momento che il livello funzionale è Windows Server 2003 la replica della directory SYSVOL avviene tramite FRS e non tramite la nuova replica DFS che offre maggior efficienza, maggior scalabilità, utilizza l’algoritmo Remote Differential Compression (RDC) che riduce l’utilizzo della banda di rete e ha un meccanismo di auto ripristino da eventuali corruzioni.

Di seguito lo schema dell’infrastruttura a cui faremo rifermento in cui è presente un DC Windows Server 2016 VSDC2016 e la replica della SYSVOL avviene tramite l’FRS.

In scenari come quello dell’esempio risulta quindi necessario eseguire manualmente la migrazione dalla replica FRS alla replica DFS, sino a che la migrazione non è terminata non devono essere apportate modifiche a script di logon e Group Policy. Durate la migrazione gli utenti possono continuare aa operare e la durata della migrazione è correlata alla replica di AD in quanto la SYSVOL DFSR avviene durante una schedulazione della replica AD, questo significa che la DFRS legge e scrive gli stati ogni 5 min su ogni Domain Controller. Quindi la migrazione può impiegare pochi minuti in piccoli domini, ma alcune ore o giorni in domini estesi.

Per consentire la diagnostica del DFS è consigliabile installare il tool DFS Management la funzionalità Remote Server Administration Tools – Feature Administration Tools – Role Administration Tools – File Services Tools – DFS Management Tools.

Per maggiori informazioni si veda SYSVOL Replication Migration Guide: FRS to DFS Replication e i seguenti post dello Storage Team:

• SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process
• SYSVOL Migration Series: Part 2 – Dfsrmig.exe: The SYSVOL migration tool
• SYSVOL Migration Series: Part 3 – Migrating to the Prepared State
• SYSVOL Migration Series: Part 4 – Migrating to the ‘REDIRECTED’ state
• SYSVOL Migration Series: Part 5 – Migrating to the ‘ELIMINATED’ state

Per le novità introdotte nella replica DFS in Windows Server 2012 si veda DFS Replication Improvements in Windows Server 2012, mentre in Windows Server 2016 e Windows 10, come indicato in What’s New in File and Storage Services in Windows Server 2016 Technical Preview, è stato implementato un hardening dell’SMB per le connessioni a SYSVOL e NETLOGON su Domain Controller richiedendo l’SMB signing e la mutua autenticazione, come ad esempio Kerberos, per ridurre la probabilità di attacchi man-in-the-middle (per maggiori informazioni si vedano la KB3000483 – MS15-011: Vulnerability in Group Policy could allow remote code execution: February 10, 2015 e il post MS15-011 & MS15-014: Hardening Group Policy).

Verifica dei prerequisiti e della funzionalità della replica FRS

Per verificare che la replica FRS funzioni correttamente è possibile eseguire i seguenti controlli:

1. Verificare la funzionalità delle share NETLOGON e SYSVOL su ogni Domain Controller mediante i comandi:
   1. net share
   2. dcdiag /test:frssysvol
      
   3. dcdiag /test:netlogons
      
   4. dcdiag /e /test:sysvolcheck /test:advertising
      
2. Verificare su ogni Domain Controller che il volume su cui risiede la share SYSVOL abbia almeno lo spazio necessario pari alla dimensione della SYSVOL più 10%.
3. Controllare la funzionalità della replica FRS tramite il tool FRSDIAG (si vedano le indicazioni nel seguente Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style)
4. Verificare su ogni Domain Controller (nell’esempio esiste solo VMDC2016) che la replica Active Directory funzioni correttamente tramite il comando repadmin /ReplSum.
5. Verificare su ogni Domain Controller che la chiave di registro HKLM\System\CurrentControlSet\Services\Netlogon\Parameters contenga il valore SysVol impostato a [drive:\]Windows_folder\SYSVOL\sysvol e che contenga il valore SysvolReady impostato a 1.
6. Controllare che su ogni Domain Controller il servizio Replica DFS (DFSR) sia avviato e impostato per l’avvio automatico.
7. Il built-in Administrators group deve avere i privilegi di “Manage Auditing and Security Log” su tutti i Domain Controller, come da impostazione di default (a rigaurdo si veda la KB2567421 DFSR SYSVOL Fails to Migrate or Replicate, SYSVOL not shared, Event IDs 8028 or 6016).

Per poter utilizzare la replica DFS occorre aumentare il livello funzionale portandolo almeno a Windows Server 2008, ma se si suppone di inserire nell’infrastruttura solo Domain Controller Windows Server 2016 o superiori conviene portare a Windows Server 2016 il livello funzionale della foresta per beneficiare di tutte le novità introdotte. E’ possibile elevare il livello funzionale del dominio e della foresta tramite il tool i Servizi di dominio di Active Directory come visto precedentemente oppure usare i seguenti comandi PowerShell:

#Raise livello funzionale del dominio a Windows 2016
Set-ADDomainMode -Identity devadmin.local -DomainMode Windows2016

#Verifica livello funzionale del dominio corrente
(Get-ADDomain).DomainMode

#Raise livello funzionale della foresta a Windows 2016
Set-ADForestMode -Identity devadmin.local -ForestMode Windows2016

#Verifica del livello funzionale della foresta corrente
(Get-ADForest).ForestMode

Per verificare che l’aumento del livello funzionale di dominio sia avvenuto correttamente è possibile controllare che sia stato registrato il seguente evento:

• Registro Directory Services – Evento d’informazioni ActiveDirectory_DomainService 2039

Per verificare che l’aumento del livello funzionale della foresta sia avvenuto correttamente è possibile controllare che sia stato registrato il seguente evento:

• Registro Directory Services – Evento d’informazioni ActiveDirectory_DomainService 2040

Migrazione del dominio nello stato Prepared

Prima di eseguire la migrazione del dominio nello stato Prepared eseguire un backup del system state dei Domain Controller nell’infrastruttura (nell’esempio esiste solo VMDC2016). Terminato il backup dei system state dei Domain Controller nell’infrastruttura, che consentirà di rispristinare la situazione precedente nel caso subentrassero problemi, è possibile impostare il global migration state a Prepared eseguendo da un Domain Controller (preferibilmente il PDC Emulator e comunque non un Read Only Domain Controller) il comando:

dfsrmig /setglobalstate 1

Per verificare che il global migration state è stato impostato a Prepared è possibile utilizzare il seguente comando:

dfsrmig /getglobalstate

Per verificare che tutti i Domain Controller abbiano raggiunto lo stato Prepared è possibile utilizzare il seguente comando:

dfsrmig /getmigrationstate

Per verificare che il global migration state è stato impostato a Prepared è possibile controllare che sia stato registrato il seguente evento:

• Registro DFS Replication – Evento d’informazioni DFSR 8014

Verificare che su ogni Domain Controller sia stata creata la directory %SystemRoot%\SYSVOL_DFSR e che il contenuto delle directory domain e sysvol in %SystemRoot%\SYSVOL sia stato copiato in %SystemRoot%\SYSVOL_DFSR.

Utilizzate il tool DFS Management per creare un report diagnostico per la directory SYSVOL_DFSR tramite la seguente procedura:

1. Selezionare il nodo Replication – Domain System Volume
2. Verificare nel Tab Memeberships che per tutti i Domain Controller sia abilitata la replica per il path %SystemRoot%\SYSVOL_DFSR\domain.
3. Selezionare Actions – Create Diagnostics Report.
4. Creare un Health report, un
   Propagation test e un Propagation report verificando che non vi siano errori.

Nello stato di Prepared FRS e DFSR hanno le proprie copie della SYSVOL, le shares SYSVOL e Netlogon si referenziano alla copia FRS, ma è ancora possibile eseguire il rollback tramite il comando:

dfsrmig /setglobalstate 0

Migrazione del dominio nello stato Redirect

Per impostare il global migration state a Redirect eseguire da un Domain Controller (preferibilmente il PDC Emulator e comunque non un Read Only Domain Controller) il comando:

dfsrmig /setglobalstate 2

Per verificare che il global migration state è stato impostato a Redirect è possibile utilizzare il seguente comando:

dfsrmig /getglobalstate

Per verificare che tutti i Domain Controller hanno raggiunto lo stato Redirect è possibile utilizzare il seguente comando:

dfsrmig /getmigrationstate

Per verificare che il global migration state è stato impostato a Redirect è possibile controllare che sia stato registrato il seguente evento:

• Registro Replica DFS – Evento d’informazioni DFSR 8017

Verificare su ogni Domain Controller tramite il comando net share che le share NETLOGON e SYSVOL mappino rispettivamente le directory:

• %SystemRoot%\SYSVOL_DFSR\sysvol\NomeDominioDNS\SCRIPTS
  (nell’esempio C:\Windows \ SYSVOL_DFSR\sysvol\devadmin.local\SCRIPTS)
• %SystemRoot%\SYSVOL_DFSR\sysvol

Usare il tool DFS Management per creare un report diagnostico per la directory SYSVOL_DFSR utilizzando la procedura descritta precedentemente.

Controllare la funzionalità della replica FRS tramite il tool FRSDIAG (si vedano le indicazioni nel seguente Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style). La replica FRS deve continuare ad essere funzionante per garantire la possibilità di un eventuale roll back.

Nello stato di Redirect FRS e DFSR hanno le proprie copie della SYSVOL e le shares SYSVOL e Netlogon si referenziano alla copia DFS, ma è ancora possibile eseguire il rollback allo stato di Prepared tramite il comando:

dfsrmig /setglobalstate 1

oppure è possibile eseguire il rollback allo stato iniziale tramite il comando:

dfsrmig /setglobalstate 0

Migrazione del dominio nello stato Eliminated

Prima di eseguire la migrazione del dominio nello stato Eliminated eseguire le seguenti operazioni:

1. Verificare tramite il comando repadmin /ReplSum che la replica di Active Directory funzioni correttamente.
2. Eseguire un backup del system state dei Domain Controller nell’infrastruttura che consentirà di rispristinare la situazione precedente nel caso subentrassero problemi.

Per impostare il global migration state a Eliminated eseguire da un Domain Controller (preferibilmente il PDC Emulator e comunque non un Read Only Domain Controller) il comando:

dfsrmig /setglobalstate 3

Per verificare che il global migration state è stato impostato a Eliminated è possibile utilizzare il seguente comando:

dfsrmig /getglobalstate

Per verificare che tutti i Domain Controller hanno raggiunto lo stato Eliminated è possibile utilizzare il seguente comando:

dfsrmig /getmigrationstate

Per verificare che il global migration state è stato impostato a Eliminated è possibile controllare che sia stato registrato il seguente evento:

• Registro Replica DFS – Evento d’informazioni DFSR 8019

Verificare su ogni Domain Controller tramite il comando net share che le share NETLOGON e SYSVOL mappino rispettivamente le directory:

• %SystemRoot%\SYSVOL_DFSR\sysvol\NomeDominioDNS\SCRIPTS
  (nell’esempio C:\Windows \ SYSVOL_DFSR\sysvol\devadmin.local\SCRIPTS)
• %SystemRoot%\SYSVOL_DFSR\sysvol

Usare il tool DFS Management per creare un report diagnostico per la directory SYSVOL_DFSR utilizzando la procedura descritta precedentemente.

Verificare che su ogni Domain Controller sia stata rimossa la directory % SystemRoot%\SYSVOL.

Arrestare e disabilitare il servizio FRS su tutti Domain Controller, tranne nel caso in cui l’FRS venisse utilizzato per repliche diverse dalla directory SYSVOL. E’ possibile eseguire tale configurazione tramite i comandi:

sc stop ntfrs
sc config ntfrs start=disabled

Per ulteriori informazioni sulla procedura di migrazione si vedano i post sul blog del team di Directory Services:

• Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style
• The Case for Migrating SYSVOL to DFSR

Conclusioni

La migrazione della replica SYSVOL da FRS a DFS è un’operazione caldamente consigliata dal momento che con Windows Server 2016 l’File Replication Service (FRS) e i livelli funzionali Windows Server 2003 sono deprecati. Inoltre una volta dismessi controller di dominio Windows Server 2003 per avere nell’infrastruttura solo controller di dominio Windows Server 2008 non vi è più alcuna ragione di utilizzare l’FRS per la replica della SYSVOL dal momento che il DFS, come spiegato precedentemente, offre maggiori prestazioni e robustezza.

Tra le domande più frequenti di chi scopre la possibilità di utilizzare un intero sottosistema linux su una macchina Windows c’è di certo la seguente:

“Si, carino, ma cosa ci faccio?”

Negli articoli precedenti abbiamo visto come è possibile utilizzare alcuni tool di cui un amministratore di sistema abituato a lavorare con linux non riuscirebbe a fare a meno, e fino ad ora era costretto ad installare emulatori o software di terze parti per poter sopperire alla mancanza della sua command line preferita. Oggi vediamo come Windows Subsystem for Linux non è solo editing di testo, e scopriamo come poter installare uno dei webserver più utilizzati al mondo. In particolare installeremo un webserver Apache con supporto php e MariaDB (il nuovo MySql), una soluzione completa per trasformare la nostra macchina in un webserver che non ha nulla da invidiare a quelli noleggiati in giro per il web.

L’installazione richiede un minimo di conoscenza dei servizi di cui stiamo parlando ma è tecnicamente molto semplice; per prima cosa è necessario aver installato Windows 10 Bash. Se la vostra macchina non soddisfa questo requisito potete correre ai ripari seguendo la guida riportata in questo articolo (https://www.ictpower.it/guide/installazione-di-windows-10-subsystem-for-linux-windows-10-bash.htm).

Il tool che ci viene incontro in questo caso è apt-get, il tool predefinito di Ubuntu per la gestione dei pacchetti di installazione, che permette di installare i servizi occupandosi per noi di scaricare e configurare ogni eventuale prerequisito.

La sintassi per installare un pacchetto è molto semplice:

apt-get install nomepacchetto

Per installare più pacchetti è sufficiente indicare i pacchetti separandoli con uno spazio

apt-get install nomepacchetto1 nomepacchetto2 nomepacchetto3

Iniziaremo proprio con guadagnare i privilegi di root (amministratori del sistema linux, con la possibilità di installare pacchetti), e procederemo all’installazione del db

sudo bash

Questo comando esegue una bash lanciandola con privilegi amministrativi (sudo = super user do). Verrà richiesto di immettere la password scelta in fase di installazione della bash. Riconosceremo di essere root perché il prompt terminerà con il carattere #, diversamente dal prompt utente che termina con il $.

Per esserne certi possiamo eseguire il comando whoami (chi sono io) per chiedere al sistema con che utente siamo loggati.

Per installare MariaDB utilizzeremo quindi

apt-get install mariadb-server mariadb-client

Il wizard chiederà di assegnare una password ed inizierà ad installare tutti i requisiti necessari.

Successivamente installerà ed avvierà il servizio MariaDB. Non preoccupatevi di eventuali errori che vedrete scorrere sullo schermo durante l’installazione, il servizio verrà installato correttamente.

Proviamo ad accedere al motore database con il comando

mysql –p

utilizzando la password fornita durante il wizard, e proviamo a creare un database di nome test.

Ora è il momento di installare il webserver Apache2; nulla di più semplice eseguendo il comando:

apt-get -y install apache2

Anche qui ignoriamo qualche messaggio di errore ed attendiamo meno di un minuto per l’installazione. Al termine possiamo aprire un browser e provare a navigare sull’indirizzo 127.0.0.1 o localhost. Quello che vedremo ci sorprenderà, ma in effetti abbiamo un vero e proprio webserver Ubuntu funzionante!

Anche navigando da LAN sull’indirizzo IP della macchina vedremo comparire la pagina del webserver, ed ovviamente configurando il nostro router saremo in grado di pubblicare questo webserver su internet. L’operazione è sconsigliata poiché essendo una versione beta potremmo rilevare dei problemi relativi alla sicurezza, ma è assolutamente possibile.

Non ci rimane ora che installare il supporto php, anche qui una sola riga di comando:

apt-get -y install php5 libapache2-mod-php5

Apache verrà automaticamente riavviato con il supporto php attivo. Facciamo subito una prova per assicurarcene. Creiamo un file php per eseguire la funziona phpinfo, che ci restituirà dettagli sulla versione di php in uso.

nano /var/www/html/ictpower.php

inseriamo queste righe di codice php e salviamo con CTRL+x, confermando con y

<?php
phpinfo();
?>

Navighiamo sulla pagina http://127.0.0.1/ictpower.php ed avremo la conferma che il nostro Apache ha pieno supporto a php:

Ora il nostro webserver è pronto, ma se vogliamo utilizzarlo per qualche sviluppo di test abbiamo la necessità di aggiungere qualche libreria di supporto al php, compresi i connettori al database MariaDB che abbiamo installato in precedenza. Niente paura, apt-get farà tutto il lavoro per noi. Aggiungiamo un –y al comando per dare conferma automatica all’installazione di tutti i pacchetti

apt-get -y install php5-mysqlnd php5-gd php5-xmlrpc php5-intl php-pear php5-imagick php5-curl php5-mcrypt php5-ming php5-snmp php5-sqlite php5-imap php5-tidy php5-xsl php5-ps php5-pspell php5-recode php5-memcache

Dopo l’installazione è necessario riavviare apache con il comando

service apache2 restart

Possiamo quindi verificare sulla pagina phpinfo l’aggiunta di tutti i supporti:

A questo punto possiamo preparare il nostro sito web, e dire a tutti che questo gira su un webserver apache Linux su Windows 10. Magari non vi crederanno, ma sarà solo questione di tempo. J

Questo articolo è stato scritto da Vincenzo Tenisci, Microsoft Certified Trainer

Vincenzo Tenisci ha venti anni di esperienza nello sviluppo di applicazioni con tecnologie Microsoft. Quindici anni fa ha iniziato la sua carriera di freelance e adesso collabora con varie societa in Italia come Senior Solution Architect e Trainer MCT. Programma in .NET sin dalla prima beta, ha iniziato a lavorare con SQL Server sin dalla versione 6.5 dal 1996 e SharePoint a partire dal 2003.

Negli ultimi anni si è specializzato nella BI Microsoft e collabora con numerose aziende cercando di far adottare il modello Tabular e Power BI. Come trainer eroga corsi in Italia e all’estero su SharePoint, SQL Server, Business Intelligence, programmazione .NET e ultimamente Microsoft Azure.

Introduzione

Tenendo corsi mi capitano spesso delle domande ricorrenti. Nel caso di Sharepoint una di queste è: è possibile mappare direttamente sul file system una document library? Naturalmente la risposta è sì ed è anche molto semplice da fare, ma cosa centra questo con OneDrive? Beh, forse non lo sapete, o forse si, ma dietro l’interfaccia di OneDrive, si nasconde proprio una document library!

Il vantaggio di mappare direttamente OneDrive consiste nel non dover necessitare del client di sincronizzazione, soprattutto nel caso in cui abbiate OneDrive for Business che vi da 1 TB di storage a disposizione e sul vostro pc non avete altrettanto spazio per sincronizzare tutti i file.

In questo articolo vi spiegherò passo passo come mappare un drive sulla library di OneDrive e OneDrive for business.

Mappatura di un disco di rete collegato a OneDrive

Mappare un disco di rete su OneDrive è veramente semplice:

1. Collegarsi a OneDrive e copiare il CID number come da figura 1

1. Mappare un Network Drive e digitare l’indirizzo: https://d.docs.live.net/CIDNumber selezionando l’opzione Connect Using a different credential, come da figura 2 e 3. NOTA: sostituire a CIDNumber il vostro numero CID.

1. Digitate le vostre credenziali di accesso inserendo il nome che usare per il vostro Microsoft Account (ad esempio trainer@outlook.com) e la password. Se però avete abilitato la verifica in due passaggi dovete prima creare una App password collegandovi al Microsoft Account web site e modificare i  Security settings. Dopo aver creato la Password dell’app inseritela quando vi vengono chieste le credenziali di accesso.

Mappatura di OneDrive for Business

In OneDrive for Business, bisogna effettuare degli step preliminari prima di mappare il disco di rete.

Praticamente il trucco sta nel riconvertire la user interface di OneDrive a quella classica di Sharepoint in modo tale da mostrare il menu ribbon ed utilizzare la voce Open With Explorer, di seguito vengono elencati i vari step da eseguire:

1. Entrare in OneDrive for Business e selezionare il link Return to Classic OneDrive in basso a sinistra:

1. A questo punto avrete la classica visualizzazione di una document library di Sharepoint, manca solo il Ribbon Menu. Per visualizzarlo basta selezionare l’icona a forma di ingranaggio ed impostare a On la voce Ribbon del menu (prima voce di menu)

1. A questo punto apparirà il classico menu Ribbon della document library, selezionate il menu Library e successivamente selezionate il menu Open With Explorer

1. Il menu Open with Explorer, aprirà la finestra di explorer che vi mostrerà nella sua barra l’indirizzo da copiare (Fig. 7)

1. Una volta copiato l’indirizzo selezionate il menu Network con il tasto destro del mouse, dopodichè selezionate Map Network Drive (Fig. 8)

1. Incollate l’indirizzo copiato dalla barra di explorer e selezionate l’opzione reconnect at sign-in

1. Et voilà. Adesso avete il vostro drive mappato sulla document library di One Drive for Business. Se utilizzate la Multi-Factor Authentication for Office 365 ricordatevi di creare anche qui la App password. Nel link è descritta la procedura per farlo.

Come potete notare ho copiato una semplice cartella con due file e questi sono stati subito uploadati a OneDrive.

Hope this helps!

Vincenzo

Si è concluso il primo ciclo di conferenze della PowerCon2016, che ha impegnato i membri della nostra Community in una serie di conferenze tra Bari, Mosciano (TE) e Roma.

Grande affluenza di pubblico, tanto interesse e numerose domande hanno reso fortemente interattivi i nostri incontri, permettendoci di interagire in maniera efficace con i partecipanti.

Tanti i giovani presenti, innamorati delle nuove tecnologie e delle funzionalità offerte da Windows 10, Windows Server 2016 e Microsoft Azure.

Un ringraziamento particolare a Fabio Cozzolino e alla Community DotNetSide che hanno collaborato con noi nella tappa del 19 Settembre a Bari. La collaborazione ITPro – DEV ha funzionato alla grande e sarà sicuramente un’esperienza da ripetere in futuro!

Stiamo già preparando i nuovi incontri per i prossimi mesi, quindi rimanete sintonizzati sul sito per essere informati appena saranno confermate le date.

Grazie a tutti per aver partecipato!

Durante il Tour POWERCON 2016, da poco conclusosi nella sua prima tornata, molti di voi ci hanno chiesto di informarvi sulle novità che riguardano le build Insider di Windows 10. Come noto, non tutte le build introducono novità sostanziali, ma, a partire da quella rilasciata ieri – build 14942 – abbiamo pensato di pubblicare un recap delle novità più interessanti che vengono introdotte, sia dal punto di vista della User Experience che IT Pro (se presenti).

Novità di Windows 10 build 14942

Nascondi la lista delle app nel menu Start

Grazie ai numerosissimi feedback inviati dagli utenti Insider, tramite l’Hub di Feedback, viene introdotta la possibilità di nascondere la lista delle app nel menu Start (Figura 2). Per attivare l’opzione basta andare in Impostazioni > Personalizzazione > Start e attivare il relativo interruttore (Figura 1).

Figura 1 – Nuova personalizzazione in Start “Nascondi la lista delle app nel menu Start”

Figura 2 – Attivando l’opzione “Nascondi la lista delle app nel menu Start” si ottiene questo risultato

Microsoft Foto

L’app viene aggiornata a livello d’interfaccia, eliminando il menu hamburger in favore di una barra Pivot e introducendo il tema chiaro. La cosa più interessante, nell’ottica delle UWA (Universal Windows App), è il rilascio dell’app sullo Store di Xbox One. Quindi ne deriva la piena compatibilità con la piattaforma convergente Windows 10.

Figura 3 – La nuova applicazione Microsoft Foto disponibile nella build 14942 di Windows 10

Miglioramenti nell’esperienza di aggiornamento del PC

Partendo dalla build 14926, Microsoft ha annunciato che se si disinstalla una delle app preinstallate su Windows, questo stato sarà preservato dopo l’aggiornamento di funzionalità del sistema operativo. Con la nuova build Microsoft ha fatto un ulteriore passo avanti estendendo la funzionalità agli IT Pro. Infatti, dopo aver aggiornato dalla 14942, se un sistemista rimuove un’app dall’immagine di sistema (e non la reinstalla autonomamente), lo stato di provisioning sarà preservato dopo l’aggiornamento e l’app non verrà reinstallata. Anche in questo caso sono stati decisivi i feedback degli utenti tramite l’Hub di Feedback.

Nuova icona di Windows Update

A partire da questa build viene introdotta una nuova icona di Windows Update in coerenza con la nuova iconografia di Windows 10. Quando ci saranno delle notifiche, da Windows Update, vedremo la nuova icona nel Centro Notifiche (o Action Center).

Figura 4 – Nuova icona di Windows Update presente dalla build 14942

Host di servizio suddivisi in processi separati su PC con RAM maggiore di 3.5 GB

Se il PC possiede più di 3.5 GB di memoria, noterete un aumento del numero di servizi attivi, presenti nel Task Manager (o Gestione attività). A prima vista può essere una modifica relativa, poiché il numero di servizi preinstallati è cresciuto notevolmente negli anni ed essi vengono raggruppati in altri conosciuti (o temuti) come svchost.exe, a partire sin da Windows 2000. A tal proposito, Microsoft ci fornisce le motivazioni di questo cambiamento a fronte di quantitativi di RAM disponibile sempre maggiori:

• Migliore affidabilità: quando un servizio, caricato nell’Host di servizio, si blocca, si blocca l’intero Host di servizio. In altre parole, se il processo Host di servizio viene “terminato”, saranno terminati tutti quei servizi in esecuzione all’intero di quel processo. Solo successivamente vengono eseguite dell’azioni individuali a seguito dell’interruzione del servizio. Come avrete notato nel Task Manager (Figura 5), gli Host di servizio possono contenere diversi servizi:

Figura 5 – Servizi raggruppati all’interno del processo Host di servizio: sistema locale (build 14393)

• Migliorata la trasparenza: il Task Manager ora mostrerà una vista migliore di quello che accade dietro le quinte del PC. Nella schermata seguente (Figura 6) è possibile osservare la quantità di CPU, Memoria, Disco e Rete occupata da ogni singolo servizio, cliccando sulla rispettiva freccetta.

Figura 6 – Servizi del processo Host di servizio: sistema locale, suddivisi in più processi (build 14942)

Inoltre, cliccando con il tasto destro su una colonna e aggiungendo quella denominata Riga di comando, i nomi dei servizi saranno elencati nel formato ‘svchost.exe -k <svchost name> -s <service name>’ in maniera individuale (Figura 7).

Figura 7 – Nomi dei singoli servizi elencati in formato ‘svchost.exe -k <svchost name> -s <service name>’

• Riduzione dei costi di manutenzione: da questa build in avanti, a seguito di segnalazioni inerenti problemi tecnici e/o instabilità di un sistema, gli amministratori IT e gli ingegneri Microsoft saranno in grado di individuare più rapidamente il problema legato a un preciso servizio e risolverlo. A nostro parere è un punto davvero importante nel processo di troubleshooting.
• Maggiore sicurezza: l’isolamento dei processi e la possibilità di assegnare i permessi, a livello di singolo servizio, aumenteranno la sicurezza in modo notevole.

NOTA IMPORTANTE: I servizi critici di sistema (il cui recupero richiede necessariamente il riavvio del sistema), così come una selezione di Host di servizio, rimarranno raggruppati.

Aumentato il range temporale delle Active Hours (o Orario di attività)

L’opzione Orario di attività (configurabile all’interno di Windows Update in Windows 10) serve ad indicare al sistema operativo qual è l’arco temporale in cui viene utilizzato il dispositivo. Questa informazione è molto utile al sistema operativo, perché nel periodo indicatogli non riavvierà automaticamente il sistema operativo per completare l’installazione di un aggiornamento. Dalla build 14942, nelle sole versioni Pro, Education ed Enteprise, l’orario di attività viene esteso fino a 18 ore dell’ora di inizio (Figura 8). Infatti, nelle build precedenti era settabile solo fino a 12, così come rimane nella versione Home di Windows 10.

Questa estensione è stata richiesta a gran voce dalle aziende, in quanto, il precedente range di 12 ore, era un po’ troppo limitante su alcuni PC. Ovviamente sarà possibile configurare Orario di attività tramite Group Policy o MDM.

Figura 8 – Orario di attività aggiornato per le versioni Pro ed Enterprise di Windows 10 a partire dalla build 14942

Navigazione nei form migliorata per l’Assistente vocale

Con l’assistente vocale attivo e in modalità Scansione, vengono introdotte nuove scorciatoie da tastiera per navigare i form presenti in una pagina o applicazione:

• F e Shift + F: passa al prossimo/precedente campo
• C e Shift + C: passa alla prossima/precedente box combo
• E e Shift + E: passa alla prossima/precedente box di modifica
• X e Shift + X: passa alla prossima/precedente box di controllo
• R e Shift + R: passa al prossimo/precedente pulsante di opzione (radio o option button)
• B e Shift + B: passa al prossimo/precedente pulsante

In sostanza, la lettera sposta in avanti e Shift + lettera sposta nel senso inverso.

Conoscere l’esatto percorso all’interno del Registro di sistema

Per gli utenti esperti è stata aggiunta una funzione molto richiesta all’interno di un programma che tutti conosceranno: Editor del Registro di sistema (o regedit). Finalmente viene introdotta la barra degli indirizzi, consentendo di individuare facilmente il percorso corrente di una chiave di registro selezionata e di poterlo copiare se necessario. Ovviamente è possibile copiare. digitare e incollare i percorsi, e con un semplice Invio raggiungere istantaneamente la posizione corretta. Inoltre con la scorciatoia da tastiera Alt + D è possibile evidenziare l’intera stringa presente nella nuova barra degli indirizzi.

Altre informazioni in merito a ulteriori miglioramenti e fix per PC introdotti in questa build li trovate nel post ufficiale del Blog di Windows consultabile a questo link.

In ultimo, vi ricordiamo che le build Insider di Windows 10 non sono stabili e quindi è consigliabile utilizzarle in ambienti di test e non direttamente in produzione.

Si è concluso da poche ore il Future Decoded 2016 che si è tenuto a Milano il 6-7 Ottobre ed è tempo di bilanci. Questa per me è stata la seconda esperienza dopo il Future Decoded 2015 & Community Days che si è tenuto a Roma. Ma è stata anche la prima edizione in cui la Community ICTPower ha partecipato con delle sessioni tenute dei suoi membri.

La grande affluenza di pubblico, la bellissima location del Palazzo del Ghiaccio di Milano, i contenuti di altissimo profilo degli speech e la presenza di Scott Guthrie, Executive Vice del Microsoft Cloud and Enterprise Group, hanno reso l’evento davvero un’esperienza incredibile.

La keynote tenuta da Guthrie è durata un’ora e mezza, di cui almeno l’80% del tempo l’ha passata a far vedere prodotti e codice! Meraviglioso che una persona con quel ruolo sia così “sul pezzo”, ma del resto ha contribuito personalmente a creare i progetti di cui ha parlato perciò massimo rispetto per Scott!

In più abbiamo festeggiato i 10 anni di Community Days, il maggiore evento community italiano organizzato da community e user group italiani dedicati ai prodotti e alle tecnologie Microsoft. Rivedere i migliori professionisti della scena nazionale e internazionale riuniti tutti insieme fa decisamente un certo effetto!

Tantissimi gli MVP presenti, che si sono alternati tra le sessioni e gli Ask The Expert, dove hanno incontrato i partecipanti e hanno avuto modo di rispondere a tantissime domande. Curiosità sui nuovi prodotti e suoi framework, ma anche richieste di approfondimento specifiche su alcune tematiche, sono state le domande più richieste.

Che dire? È stata un’esperienza incredibile e assolutamente da rifare. Grazie mille per averci reso partecipi! Al prossimo anno!

Qualche mese fa vi abbiamo parlato di come Microsoft non avesse abbandonato gli utenti di Windows 7 SP1 e Windows 8.1 (compresi Windows Server 2008 R2 SP1, Windows Server 2012 e Windows Server 2012 R2), semplificando gli aggiornamenti degli stessi. Una parte importante, infatti, riguarda l’introduzione degli aggiornamenti cumulativi mensili anche per le edizioni precedenti di Windows. Un aggiornamento cumulativo, nello specifico, è una collezione di aggiornamenti software contenente tutte le correzioni rilasciate precedentemente per un determinato prodotto. Attualmente, lo ricordiamo, Windows 10 segue questo modello sin dalla sua prima versione 1507 – build 10240.

Dopo diversi mesi, e un articolo di Nathan Mercer del 15 agosto 2016, Michael Niehaus di Microsoft annuncia finalmente che, a partire da oggi 11 ottobre 2016, questo “nuovo” metodo di rilascio mensile degli aggiornamenti sarà operativo, dettagliando in maniera molto precisa cosa accadrà ogni mese e offrendo diversi scenari di utilizzo agli utenti. Tuttavia, con questo notevole cambiamento, gli amministratori di sistema non avranno più la possibilità d’intervenire sulla singola patch installata ma su tutto l’aggiornamento cumulativo. Ad esempio, in caso di rollback a causa d’instabilità del sistema, non si potrà più disinstallare una singola patch ma solo tutto il pacchetto cumulativo.

In questo articolo cercheremo di evidenziare i punti salienti dell’articolo originale per una più facile e rapida comprensione.

Figura 1 – Il nuovo piano di Microsoft per il rilascio degli aggiornamenti di Windows 7 e 8.1 (numeri e lettere)

Definizione degli aggiornamenti

Microsoft offre diversi tipi di aggiornamenti dei propri sistemi operativi in modo da poter essere distribuiti a seconda della strategia di una singola organizzazione. Michael ci fornisce definizione e tempi per questo nuovo processo di aggiornamento:

Tabella 1 – “B week” rappresenta l’aggiornamento del 2° martedì del mese. “C week” rappresenta quello del 3° martedì del mese.

Dalla tabella precedente è facile comprendere quale sia l’obiettivo di Microsoft, ovvero quello di rendere il rollup mensile pienamente cumulativo, infatti gli aggiornamenti di questo tipo inizieranno a includere tutte le patch precedenti entro l’inizio del 2017. Del resto possiamo identificare 3 tipi di aggiornamenti principali:

1. Security-only quality update. Includerà tutti i nuovi aggiornamenti di sicurezza del mese; sarà pubblicato solo per Windows Server Update Services (WSUS) e utilizzato da System Center Configuration Manager (SCCM) e dal catalogo di Windows Update.
2. Security monthly quality update (aka “monthly rollup”). Includerà tutti gli aggiornamenti di sicurezza del mese (come il tipo precedente) oltre a contenere tutte le correzioni introdotte con i rollup precedenti. Questo sarà pubblicato su Windows Update per i PC degli utenti consumer e professionali, WSUS e il catalogo di Windows Update.
3. Anteprima del security monthly quality rollup (aka “preview rollup”). Includerà un’anteprima dei nuovi fix (non di sicurezza) che saranno introdotti con l’aggiornamento del mese successivo oltre a contenere quelli già introdotti con i rollup precedenti. Il rilascio avverrà il 3° martedì del mese (C week), mentre il secure-only quality update rimane al 2° martedì del mese (B week).

In concomitanza saranno rilasciati aggiornamenti cumulativi anche per il .NET Framework e Internet Explorer.

Gli amministratori di sistema avranno diverse opzioni per gestire questi aggiornamenti. Microsoft, dal canto suo, consiglia d’installare tutti gli aggiornamenti di sicurezza e non, appena vengono rilasciati. Le altre possibili opzioni sono: installare solo gli aggiornamenti di sicurezza e non quelli correttivi, oppure installare tutti gli aggiornamenti di sicurezza non appena vengono rilasciati da Microsoft e solo alcuni di quelli correttivi.

Molti si staranno già chiedendo come gestire eventuali problematiche derivanti dal non avere più aggiornamenti singoli da dover amministrare, ma uno unico e solo. Anche in questo caso Microsoft raccomanda di implementare un approccio “ad anelli” (diverso dai “rami”, resi più visibili con Windows 10), iniziando dal reparto IT. Esso permetterebbe di distribuire gli aggiornamenti a vari gruppi all’interno dell’organizzazione – in cui ogni anello rappresenta un altro gruppo – per ottenere un maggiore controllo del processo di implementazione degli aggiornamenti.

Senza dubbio si tratta di un importante cambiamento e per i primi tempi andrà sicuramente monitorato, ma va dato atto a Microsoft di aver ascoltato tutti quei clienti che utilizzano ancora i “vecchi” sistemi operativi e non vogliono il sistema carente dal punto di vista della sicurezza. Come sempre, se volete approfondire, trovate a questo link il lungo e completo articolo pubblicato sul Blog di Technet.

Microsoft ha rilasciato ieri, nel Ramo Veloce (Fast Ring), una nuova build di Windows 10 per i Windows Insider. I più attenti si saranno accorti che il 13 ottobre 2016 è stata rilasciata la build 14946, ma non ha introdotto sostanziali novità a parte l’aver aggiunto la possibilità di personalizzare l’esperienza d’uso dei più moderni touchpad. Se siete curiosi vi rimandiamo al link del blog ufficiale dedicato alla build citata.

Nella build 14951, invece, abbiamo riscontrato delle novità interessanti, lato UE (User Experience) e lato IT, così abbiamo pensato di presentarvele in questo articolo sintetico.

Novità di Windows 10 build 14951

Miglioramenti nell’Area Windows Ink

Gli utenti che hanno installato Windows 10 Anniversary Update (1607), rilasciato il 2 agosto 2016, si saranno accorti che Microsoft ha deciso di integrare nel sistema operativo un’area dedicata alle applicazioni che utilizzano maggiormente, come metodo di input, l’inchiostro digitale. A partire dalla build 14951 vengono introdotte le seguenti novità:

• Nel menu a tendina (Figura 1), ad esempio della penna, sarà possibile settare contemporaneamente colore e dimensione senza dover necessariamente cliccare una seconda volta sullo strumento.

Figura 1 – Menu a tendina dello strumento penna presente in Blocco da disegno

• Vengono introdotti gli Stencil, nello specifico di questa build il Goniometro (Figura 2). Esso va ad affiancare il già esistente Righello, il quale riceve un piccolo aggiornamento riguardante la visualizzazione numerica dell’angolo d’inclinazione in gradi (Figura 3).

Figura 2 – Goniometro introdotto con la build 14951 di Windows 10

Figura 3 – Righello con indicazione numerica dell’angolo di inclinazione in gradi

Introduzione dell’inchiostro digitale nell’app Foto

A partire dalla versione 16.1017.10000.0 dell’app Foto, rilasciata sempre nel Fast Ring, la piattaforma Windows Ink viene integrata con le immagini attraverso un’esperienza molto simile dell’Area Windows Ink con i suoi comandi di base (Figura 4). Sarà possibile, inoltre, salvare le proprie creazioni sia come immagini che come video in cui sarà replicato il disegno sovraimpresso – quest’ultima funzione non sembra ancora funzionare correttamente.

Figura 4 – Windows Ink introdotto nell’app Foto di Windows 10

Migliorata l’esperienza per gli Sviluppatori

Generalmente, chi sviluppa un’app per Windows 10 utilizza un software che sicuramente è abbastanza conosciuto: Visual Studio. L’app, una volta creata, non può essere avviata liberamente come se fosse scaricata dal Windows Store (verificata e certificata per l’utilizzo con Windows 10), senza aver precedentemente abilitato la cosiddetta Modalità Sviluppatore. Nelle build precedenti veniva richiesto – una volta attivata – di riavviare il sistema, mentre da questa nuova build non sarà più necessario.

Per attivarla basta andare in Impostazioni > Aggiornamento e sicurezza > Per sviluppatori e cliccare sul pallino Modalità sviluppatore (Figura 5).

Figura 5 – Modalità sviluppatore in Windows 10

Windows Subsystem for Linux

Una delle novità più grosse nel mondo Windows, in particolare da Windows 10 Anniversary Update, è stata l’introduzione del Windows Subsystem for Linux (WSL). Questa graditissima sorpresa, accolta positivamente dagli utenti, introduce il componente che, una volta attivato, permette di avere un vero e proprio ambiente in grado di eseguire strumenti, comandi e servizi in modalità nativa, senza necessità di utilizzare emulatori o macchine virtuali. Ricordiamo che il tutto è stato sviluppato grazie alla collaborazione di Microsoft con Canonical, società che lavora su progetti legati al software libero tra cui il famoso Ubuntu.

Cosa succede a partire dalla build 14951 di Windows 10? Vengono introdotti due nuovi aggiornamenti importanti per WSL:

• Supporto ufficiale a Ubuntu 16.04 (Xenial). L’ultima versione LTS di Ubuntu viene installata per tutte le istanze di Bash su Windows 10. Essa va a sostituire la versione presente nella build 14393, ovvero la 14.04 (Trusty).
• Interoperabilità tra Windows / WSL. Gli utenti saranno in grado di lanciare i binari di Windows direttamente dalla shell di WSL (Figura 6 e 7). Questa possibilità è stata richiesta a gran voce nella pagina User Voice di WSL.

Alcuni esempi di interoperabilità includono:

$ export PATH=$PATH:/mnt/c/Windows/System32
$ notepad.exe
$ ipconfig.exe | grep IPv4 | cut -d: -f2
$ ls -la | findstr.exe foo.txt
$ cmd.exe /c dir

Figura 6 – Paint lanciato dalla shell di Bash

Figura 7 – Comando Ping lanciato dalla shell di Bash

Altre informazioni potete trovarle nel Blog di WSL o nella pagina MSDN dedicata. Altri dettagli sui vari cambiamenti introdotti li trovate nella pagina delle note di rilascio di WSL.

Ma se io ho già installato Bash nella build Insider precedente di Windows 10 e ora aggiorno a quest’ultima riceverò automaticamente l’aggiornamento a Ubuntu 16.04 dalla 14.04? La risposta è no. Gli utenti che sono iscritti al programma Insider di Windows posso aggiornare manualmente usando questa semplice guida:

• Avviare la shell di Bash (Figura 8).

Figura 8 – Bash avviata e verifica attuale versione di Ubuntu

• Lanciare il comando do-release-upgrade e inserire la password dell’utente corrente per avviare l’operazione con i privilegi di root (Figura 9).

Figura 9 – Procedura di aggiornamento di Ubuntu

• Dopo una serie di operazioni preliminari ci viene chiesto se siamo pronti ad Avviare l’avanzamento di versione? (Figura 10). Digitiamo Si e diamo Invio per avviare l’aggiornamento di Ubuntu all’interno di WSL.

Figura 10 – Schermata di avvio dell’aggiornamento di versione

• Dopo circa una mezz’oretta – dipende anche dalla vostra connessione – e altre schermate, la procedura sarà completata e ci verrà richiesto di riavviare il sistema (Figura 11). Se ci dovessero essere dei problemi per confermare il riavvio noni preoccupatevi, infatti basterà chiudere la finestra e procedere con un riavvio manuale di Windows.

Figura 11 – Aggiornamento di Ubuntu completato

• Dopo il riavvio avviamo nuovamente Bash e con il comando lsb_release -r verifichiamo l’avvenuto aggiornamento a Ubuntu 16.04 (Figura 12).

Figura 12 – Nuova versione di Ubuntu aggiornata correttamente

Se siete curiosi di installare e testare questa nuova funzionalità del Windows Subsystem for Linux in Windows 10, vi rimandiamo all’ottimo articolo del nostro Gianluca Nanoia che trovate a questo link.

Altre informazioni in merito a ulteriori miglioramenti e fix per PC e Mobile introdotti in questa build li trovate nel post ufficiale del Blog di Windows consultabile a questo link.

In ultimo, vi ricordiamo che le build Insider di Windows 10 non sono stabili e quindi è consigliabile utilizzarle in ambienti di test e non direttamente in produzione.

Windows Server 2016 introduce una serie di novità in vari ambiti per rispondere alle nuove esigenze di sicurezza, virtualizzazione di infrastrutture e utilizzo del cloud.
Nel meetup del 17 novembre organizzato da Torino Technologies Group in collaborazione con ICTPower.it Ermanno Goletto (MVP Cloud and Datacenter Management e MVP Enterprise Mobility) e Roberto Massa (MVP Cloud and Datacenter Management) dopo un’overview delle principali novità approfondiranno quelle legate agli Active Directory Domain Services e l’impatto che la deprecazione, in Windows Server 2016, del File Replication Service e dei Windows Server 2003 functional levels avrà sulle infrastrutture.

A tal riguardo verranno analizzate in modo approfondito la procedura e le best practices di migrazione dei domain controller Windows Server 2003, ormai fuori supporto, o da versioni precendenti di Windows Server in modo da adeguare l’infrastruttura ai requisiti del nuova versione del sistema operartivo server e beneficiare delle nuove funzionalità introdotte con i successivi livelli funzionali di dominio e di foresta.
L’evento inizia alle 18 e termina alle 20 e si terrà presso il Microsoft Innovation Center (MIC) di Torino in c/o ISMB Via Pier Carlo Boggio 61 10138 Torino. Dopo le 20.00 per chi desidera continuare a chiacchierare può concludere la serata in pizzeria.

Di seguito l’agenda della sessione:

• Novità in Windows Server 2016
• Deploy di un DC WS2016
• Demote DC WS 2003
• Operazioni post migrazione

Il 20 ed il 21 Marzo 2017 si terrà il Microsoft Tech Summit Milano, una conferenza gratuita di 2 giorni con oltre 50 sessioni tecniche che affronteranno il tema del cloud ibrido fatto con Microsoft Azure. Durante la conferenza verranno trattati temi come sicurezza, rete, dati, storage, management, DevOps e collaboration.

La keynote sarà tenuta da Ron Markezich, Corporate Vice President of Microsoft Online, responsabile della crescita del business online di Microsoft.

L’agenda è davvero ricca ed interessante e ci sarà la possibilità di fare anche degli Hands-on-lab sulle ultime tecnologie di Azure, Office 365 e Windows 10. Inoltre sarà allestita anche un’area Ask The Expert, in cui diversi Microsoft Engineers and Most Valuable Professional (MVP) potranno rispondere alle vostre domande e curiosità tecniche.

La conferenza si terrà presso il MiCo – Milano Congressi Piazzale Carlo Magno, 1  – 20149 Milano.

Per maggiori informazioni ed iscrizioni visitate la pagina https://www.microsoft.com/it-it/techsummit/milan.aspx

Con il rilascio dell’Anniversary update è stata aggiunta a Windows 10 una funzionalità molto particolare, chiamata Windows Subsystem for Linux (WSL), che consente di eseguire dei binari di tipo ELF64 (eseguibili compilati in modalità nativa Linux), direttamente su Windows, senza l’ausilio di macchine virtuali o emulatori di terze parti.

In questo articolo (https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm) abbiamo visto come abilitare questa funzionalità, e come durante l’installazione il sistema scarichi dal Windows Store il pacchetto Ubuntu for Linux, distribuzione prodotta da Microsoft e Canonical appositamente per l’integrazione su Windows.

L’aggiunta di questa funzionalità, passata forse in sordina nei primi tempi, sta ora suscitando qualche gelosia da parte di chi produce distribuzioni Linux a livello commerciale, che vede la possibilità di far conoscere la propria distribuzione ad un pubblico più ampio, sfruttando la popolarità di Windows 10 a livello client. E’ il caso di Hannes Kühnemund, senior Product Manager di SUSE, che in una recente dichiarazione ha affermato che Microsoft per il suo WSL stesse utilizzando la distribuzione errata di Linux, sostenendo che SUSE esiste da molto più tempo rispetto ad Ubuntu, e per questo sicuramente avrebbe meritato maggiore attenzione.

La dichiarazione è stata opportunamente accompagnata dal rilascio, in versione non ufficiale, del pacchetto openSUSE Leap 24.2 integrabile in WSL. OpenSUSE Leap è la versione Open della distribuzione commerciale SUSE Enterprise, ed è quindi possibile scaricarla ed installarla liberamente su qualsiasi client Windows, a patto che sia stata precedentemente attivata la funzionalità WSL, e che durante il relativo wizard di installazione sia stato creato un utente con password.

Non ci rimane che mettere alla prova questa nuova distribuzione, iniziando in primis a capire se questo pacchetto rispetta le promesse circa la possibilità di utilizzarlo senza problemi con Windows 10. Ci aspettiamo, quindi, di poter avviare openSUSE bash, ed utilizzare il gestore dei pacchetti Zypper così come utilizziamo apt-get su Ubuntu.

Per comprendere tutti i passaggi dell’installazione è importante analizzare il filesystem di Windows, individuando la cartella in cui lavora WSL, ossia la cartella dove sono presenti tutti i file relativi al sottosistema linux. Il sistema è composto da due parti fondamentali: la prima comprende tutti i binari e i file di configurazione della distribuzione, la seconda comprende tutto il resto, tra cui ad esempio i dati utente o il path in cui sono montati i dischi Windows. Il tutto si trova nella cartella (nascosta) %localappdata%\lxss. Nel mio caso, ad esempio, il sottosistema Linux si trova nella cartella:

C:\Users\ICTPower\AppData\Local\lxss

Qui troviamo la cartella rootfs, all’interno della quale c’è il sistema operativo Linux vero e proprio insieme ad altre cartelle, tra cui quelle relative agli utenti (home) e quella in cui vengono montati i volumi di Windows (mnt). Notiamo la presenza del file bash.ico, che andremo a modificare in seguito. Lo screenshot seguente mostra come si presenta la cartella %localappdata%\lxss vista dal sistema operativo Windows.

Vediamo, inoltre, che all’interno della cartella rootfs è presente il sistema operativo base:

La cartella %localappdata%\lxss\rootfs\home è vuota, poiché il profilo dell’utente Linux, nel mio caso chiamato gnanoia, si trova nella cartella home al livello superiore, cioè %localappdata%\lxss\home

Ho preferito essere un po’ puntiglioso per questo semplice chiarimento perché è di fondamentale importanza per eseguire correttamente i passaggi seguenti dell’installazione.

L’idea è infatti quella di sostituire la cartella base del sistema operativo (la cartella rootfs con Ubuntu per intenderci), con la corrispondente openSUSE, presente nel pacchetto rilasciato pochi giorni fa.

Iniziamo quindi scaricando il pacchetto openSUSE-42.2.tar.xz, che è l’immagine di un “container” basato su openSUSE. Non approfondiremo in questa sede il concetto di container, rimandando i più curiosi al video presente su questa pagina (https://www.nicolaferrini.it/ita/blog/871-techeroes-come-funzionano-i-container-con-docker.html), ma teniamo solo presente che stiamo effettuando il download di una distribuzione Linux “pronta all’uso”, come se avessimo “catturato” l’immagine base di una macchina openSUSE già installata.

Per iniziare, quindi, apriamo Windows Bash (bash on Ubuntu on Windows) ed eseguiamo:

wget -O openSUSE-42.2.tar.xz https://github.com/openSUSE/docker-containers-build/blob/openSUSE-42.2/docker/openSUSE-42.2.tar.xz?raw=true

Notiamo che all’avvio di Windows bash la cartella di lavoro corrente corrisponde alla home dell’utente Linux, e quindi il download sarà eseguito nella cartella \home\<nomeutente>, e quindi il percorso completo del file scaricato nel mio caso sarà: \home\gnanoia\openSUSE-42.2.tar.xz

Ora creiamo con permessi di root (quindi utilizzando il comando sudo) una cartella chiamata rootfs all’interno della nostra home, estraiamo l’immagine scaricata all’interno di questa cartella, e chiudiamo la shell.

sudo mkdir rootfs

sudo tar -C rootfs -Jxf openSUSE-42.2.tar.xz

exit

A seconda della release di WSL in uso potrebbero essere visualizzati degli errori relativi alla syscall MKNOD, che potrebbe risultare non supportata. Possiamo tranquillamente ignorare gli errori poiché la nostra necessità è semplicemente quella di scompattare l’archivio.

A questo punto dobbiamo sostituire la cartella rootfs originale (quella con Ubuntu) con quella appena creata; poiché questa operazione viene eseguita su cartelle in uso da WSL è necessario stoppare il relativo servizio per proseguire. Eseguiamo quindi da un prompt di DOS con privilegi elevati:

net stop lxssmanager

Possiamo quindi rinominare la cartella %localappdata%\lxss\rootfs in %localappdata%\lxss\rootfs.ubuntu, e copiare al suo posto la cartella con il pacchetto openSUSE appena estratto (la troviamo su %localappdata%\lxss\home\rootfs).

Questa operazione può ovviamente essere eseguita con Windows Explorer o con i seguenti comandi da un prompt di DOS:

cd %localappdata%\lxss\


rename rootfs rootfs.ubuntu


move .\home\<nomeutente>\rootfs .\

Lo screenshot seguente mostra le operazioni eseguite per la sostituzione della cartella rootfs

Possiamo quindi avviare nuovamente il servizio lxssmanager:

net start lxssmanager

L’ultimo passo è quello di settare l’utente predefinito della nuova distribuzione. Non essendo presenti utenti oltre a root sull’immagine openSUSE possiamo eseguire da DOS:

lxrun /setdefaultuser root

Per finire il lavoro con eleganza possiamo sostituire l’icona %localappdata%\lxss\bash.ico (preferibilmente rinominandola ubuntu.ico) con quella di openSUSE scaricabile da:

http://www.iconarchive.com/download/i46667/saki/nuoveXT/Apps-suse.ico

e rinominare con “bash in openSUSE on Windows” il collegamento presente in

C:\Users\<nomeutente>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs

O crearne uno nuovo sul Desktop

Per lo screenshot finale accompagnato dagli applausi del pubblico scegliamo di eseguire il comando

cat /etc/os-release

che ci mostrerà distribuzione e release attualmente in uso

Come promesso vediamo come si comporta il manager di pacchetti, provando ad installare apache utilizzando zypper; se tutto è a posto dovrebbe bastare un semplice comando:

zypper in apache2

Creiamo ora un semplice file index:

echo "Hello World" > /srv/www/htdocs/index.html

Avviamo apache:

httpd

E navighiamo su http://127.0.0.1

Direi che è proprio quello che ci aspettavamo, solo ora mi sento di affermare che è possibile utilizzare anche un userspace openSUSE, e quindi SUSE Linux Enterprise Server su Windows Subsystem for Linux.

Preferire Ubuntu o SUSE a questo punto è una scelta puramente personale, se non fosse così d’altro canto non si chiamerebbero sistemi open

Se invece siete arrivati fin qui per sapere cosa preferisco io… beh… sono in attesa del rilascio di CentOS

Il DHCP (Dynamic Host Configuration Protocol) è un ruolo che può essere installato in Windows Server 2016. Utilizzando questo ruolo potete configurare tutti i client in modo tale che ricevano indirizzi IP e tutte le informazioni relative alle configurazioni di rete.

I client DHCP possono essere computer, dispositivi mobili, stampanti oppure switch. Il DHCP può dare anche informazioni sugli indirizzamenti IP a tutti quei client che fanno boot da rete (ad esempio i client che fanno PXE boot).

Tramite gli Scope del DHCP, l’amministratore di sistema configura il range degli indirizzi IP e tutte le informazioni da distribuire ai client che richiedono un indirizzo di rete. È possibile associare gli Scope soltanto ad una singola subnet. Lo Scope generalmente consiste nel range di indirizzi che il server DHCP distribuisce, una subnet mask, tutta una serie di opzioni ed ovviamente la durata degli indirizzi.

Quando assegnate un indirizzo IP ad un client, infatti, potete contemporaneamente assegnare anche altri parametri relativi alla configurazione di rete. In genere i parametri più diffusi sono il default gateway, il server DNS e il suffisso DNS.

Come client acquisiscono indirizzo IP

I client richiedono gli indirizzi IP utilizzando un processo chiamato DORA (Discover, Offer, Request, ACKnowledgement), come mostrato in figura:

Figura 1: Processo di richiesta dell’indirizzo IP da parte dei client DHCP

Funzionalità DHCP nuove e migliorate Windows Server 2012 R2

Windows Server 2012 R2 ha introdotto delle nuove importanti funzionalità nel ruolo di DHCP server:

• Miglioramento della registrazione DNS. Gli amministratori di sistema possono configurare delle differenti DHCP policy in base all’FQDN del client. Il server DHCP può registrare i client con un diverso suffisso DNS e fare l’override dei suffissi DNS configurati sul client.
• Opzione per la registrazione dei record PTR. Il server DHCP registra solo record host A verso i DNS server ma non il record pointer PTR. Questo scenario è interessante per le organizzazioni che non hanno una Reverse Lookup Zone creata nel server DNS, in modo tale che solo i record A vengano registrati nel DNS. È possibile disabilitare la registrazione dei record PTR per tutti I client DHCP o soltanto per alcuni client specifici. Potete selezionare il client per i quali volete disabilitare la registrazione dei record PTR in base a differenti criteri, come ad esempio la sottorete, la location del client oppure alcuni attributi specifici del client stesso.

Novità delle funzionalità DHCP Windows Server 2016

Il ruolo DHCP in Windows Server 2016 non ha nuove funzionalità o miglioramenti rispetto a Windows Server 2012 R2. Tuttavia c’è un grossissimo cambiamento che può interessare le organizzazioni che hanno implementato NAP. In Windows Server 2016 infatti il ruolo DHCP non sopporta più NAP (Network Address Protection).

Che cos’è il DHCP failover?

Il DHCP failover è una funzionalità di Windows Server 2016 che serve a rendere altamente disponibile il servizio DHCP. Questa funzionalità è stata introdotta in Windows Server 2012 e permette di poter configurare due diversi server DHCP in modo tale che distribuiscano gli indirizzi IP all’interno dello stesso Address Pool.

Quando il servizio DHCP non funziona, i client perdono la connettività verso la rete e verso tutte le risorse. I client DHCP rinnovano il proprio Lease di indirizzo IP ad intervalli regolari e configurabili. Se il servizio DHCP non funziona oppure il Lease scade, il client non possiede più un indirizzo IP. Il DHCP failover permette di gestire questo tipo di problematiche.

In passato per rendere altamente disponibile il ruolo DHCP bisognava configurare 2 server DHCP uguali e tenerne uno acceso ed uno pronto in stand-by nel caso il primo non fosse disponibile. Un’altra opzione era configurare il DHCP in cluster, ma questo richiedeva uno sforzo di configurazione notevole.

Con la funzionalità di DHCP failover invece è possibile configurare il 2 server DHCP in modo tale che replichino le stesse configurazioni e le stesse informazioni relative al Lease. Se uno dei due server non funziona l’altro server in grado di continuare a offrire lo stesso servizio all’intera rete.

Figura 2: Failover-enabled DHCP Scope

Come configurare il DHCP failover

Per configurare il DHCP failover è necessario stabilire una Failover relationship tra due server DHCP. Il nome di queste relationship deve essere univoco. I partner si scambiano questo nome durante la configurazione e questo permette ad un singolo server DHCP di poter avere diverse failover relationship con altri server DHCP.

È possibile configurare solo due server DHCP per il failover per ognuna delle Failover relationship che si possono creare e solo per Scope e Subnet IPv4.

È importante sottolineare che il DHCP failover è time-sensitive. Per questo motivo dovete sincronizzare l’orario dei due partner. Se la differenza di tempo è superiore a un minuto allora il processo di failover si bloccherà.

Il Failover può essere configurato in due modi: Hot
Standby e Load
sharing. Nella modalità Hot
Standby un server sarà il server primario e l’altro il server secondario. Il server primario assegna attivamente le configurazioni IP per lo Scope per la Subnet. Il server DHCP secondario interviene solo se il server primario non è disponibile. Un server DHCP può essere contemporaneamente il primario per uno Scope per una Subnet ed il secondario per un altro Scope per un’altra Subnet. Potete configurare la percentuale degli indirizzi IP che dovranno essere assegnati al server di Standby. Se il server principale è down, il server di Standby ricevere questi indirizzi durante il Maximum Client Lead Time Interval. Per default il 5% degli indirizzi disponibili sono riservati per il server secondario. Il server secondario prende il controllo dell’intero range di indirizzi IP nel momento in cui il Maximum Client Lead Time Interval scade.

La modalità Load
Sharing, che è quella di default, invece fa in modo tale che entrambi i server rilascino gli indirizzi IP ai client contemporaneamente. Potete configurare questa modalità in modo tale da stabilire la Load
Distribution
Ratio, cioè la percentuale di indirizzi IP dello Scope che ogni server DHCP dovrà rilasciare. La Default Distribution Ratio è 50:50, cioè ognuno dei due server rilascia la metà degli indirizzi IP disponibili nello Scope.

Per impostare il DHCP Failover vi basta aprire la console del DHCP e cliccare col tasto destro sullo Scope da mettere in alta disponibilità. Seguite le indicazioni del wizard, che sono davvero semplici, e procedete nella configurazione.

Figura 3: Creazione della relazione di Failover per lo scope

Figura 4: Scelta dello scope da mettere in Failover

Figura 5: Scelta del server DHCP partner da usare per creare la Failover Relationship

Figura 6: Scelta dei parametri della relazione

Il Maximum Client Lead Time è un parametro che determina per quanto tempo un server deve aspettare, quando il proprio partner non è disponibile, prima di assumere il controllo del Range. Questo valore non può essere uguale a 0.

L’ Auto State Switchover Interval è invece l’intervallo di tempo dopo il quale il server si mette nello stato di Partner-down. Quando un server non riesce più a comunicare con il proprio partner, non ha modo di sapere quale motivo ha causato la perdita di comunicazione. Il server pertanto rimane in questo stato fino a quando non viene messo in modalità Partner-down manualmente dall’amministratore. Questa transizione “di stato” si può automatizzare tramite il parametro Auto State Switchover Interval.

Il Message authentication serve ad autenticare il traffico che avviene tra i due server partner. Per farlo potete mettere una password durante il wizard di creazione della relazione.

Figura 7: Conferma dell’avvenuta relazione tra i due server DHCP

Una volta creata la relazione, vengono replicate tutte le informazioni relative allo Scope dal primo al secondo server. Nel mio esempio ho scelto la modalità Load Balance. Una volta creata la relazione lo Scope sul secondo server viene attivato. Se aggiungete il secondo server alla console potete verificare che tutte le informazioni si sono replicate, come mostrato in figura:

Figura 8: Lo scope ed i parametri sono replicati sul secondo server

È possibile rimuovere la relazione di Failover in qualsiasi momento, semplicemente cliccando sullo Scope e scegliendo Deconfigure Failover, come mostrato in figura:

Figura 9: Eventuale rimozione della relazione di Failover

Conclusioni

Il servizio DHCP è uno dei più importanti servizi di rete e la funzionalità di DHCP Failover ci permette di metterlo in alta disponibilità con pochissimi passaggi, semplificando di molto la gestione dei server e impedendo gravi disservizi per i client.

Il prossimo 3 Marzo 2017, a partire dalle ore 9:00 presso l’Hotel A.ROMA Via Giorgio Zoega 59 a Roma, Speditamente, in collaborazione con la Community ICTPower, ospiterà un seminario completamente gratuito che illustrerà le principali novità e funzionalità di Windows Server 2016, Exchange Server 2016, Veeam Availability Suite 9.5 e Panda Security.

La moderna gestione dei servizi IT dipende da una strategia legata a due parole chiave: evoluzione e protezione.
Valutare e selezionare le nuove tecnologie più adatte è il primo passo verso l’attuazione di tale strategia, il cui focus è quello di migliorare il proprio datacenter in un regime di elevata sicurezza.

Seguiteci in quattro momenti di approfondimento dedicati alle novità di Microsoft, Panda e Veeam in tema di iperconvergenza, disaster recovery e protezione da malware in compagnia dei nostri speaker!

CONTENUTI

Windows Server 2016 – Evolutions & Innovations

[Nicola Ferrini, Microsoft Regional Director & Raffaele Valensise, Microsoft Certified Trainer]

A 16 anni di distanza dall’uscita di Windows 2000, Microsoft rilascia la nuova versione del sistema operativo server destinato a diventare uno dei pilastri delle infrastrutture informatiche di milioni di aziende nel mondo. Windows Server 2016 non rappresenta nella timeline di Windows un semplice refresh tecnologico; si tratta piuttosto di una versione completamente “ripensata”, il cui lungo percorso di sviluppo ha tratto grande ispirazione dai feedback dei clienti in tema di sicurezza, di flessibilità e di integrazione col mondo applicativo.

La sessione è dedicata ad illustrare alcune fra le più importanti evoluzioni e innovazioni presenti in Windows Server 2016:

• Hyper-V – Focus su scalabilità, gestione e integrazione
• Storage, Nano Server & Containers – L’iperconvergenza per tutti
• Microsoft  Linux – Notes from the field

Panda Security Systems Management: Gestire, monitorare e supportare tutti i sistemi IT attraverso il cloud in modo semplice e centralizzato

[Alessandro De Simone – Panda Security]

Nell’era del Cloud, arrivare a semplificare la gestione delle componenti infrastrutturali senza gravare ulteriormente sul personale IT sembrava una chimera. Vieni a scoprire come riprendere il controllo dei tuoi dispositivi migliorandone la gestione attraverso il Cloud.

Exchange hybrid: architecture and deployment

[Alberto Panicali, Microsoft Certified Trainer]

La distribuzione ibrida offre alle organizzazioni la possibilità di estendere al cloud le numerose funzionalità e il controllo amministrativo che già hanno nell’organizzazione Microsoft Exchange locale. Inoltre una distribuzione ibrida consente una migrazione trasparente e a fasi ad Exchange Online offrendo una completa coesistenza (Exchange Rich Coexistence) tra l’architettura Exchange on-premise e quella online. Nel corso della sessione si vedranno le procedure step-by-step per integrare un’infrastruttura Exchange on-premise con Office 365 ed Exchange Online.

Availability per ambienti cloud e fisici: la workload mobility secondo Veeam

[Danilo Chiavari, Team Lead Systems Engineering Veeam]

Dopo essersi affermata come leader nell’Availability per le infrastrutture virtuali, Veeam aggiunge supporto per i workload fisici ed in cloud. In questa sessione presenteremo le nuove funzionalità Veeam e le nuove integrazioni tecnologiche per la protezione, il ripristino e la migrazione dei dati – ovunque essi siano.

Novità di Windows 10

[Nicola Ferrini, Microsoft Regional Director]

Windows 10 migliora la produttività aziendale semplificando le attività di gestione e distribuzione e proteggendo i dati aziendali in modo più efficace che mai. Per gestire con successo i computer client in un ambiente aziendale è necessario però utilizzare gli strumenti giusti. In questa sessione verrà mostrato come ottimizzare la gestione di Windows 10 tramite Group Policy, Windows Update for Business, Microsoft Azure Active Directory e Microsoft App-V.

AGENDA

ISCRIZIONE

L’iscrizione al seminario è assolutamente gratuita. La disponibilità di posti è limitata. Le richieste di partecipazione saranno accettate in base all’ordine di iscrizione.

Premessa

Fino alla versione 2010, SharePoint Server ha sempre rappresentato una spina nel fianco dell’amministratore di sistema quando si arrivava al punto di dover sincronizzare i dati degli utenti gestiti da SharePoint (i cosiddetti “User Profiles”) con un sistema di Identity Management esterno, ad esempio Active Directory.

L’obiettivo di popolare automaticamente tutti i campi SharePoint relativi alle proprietà anagrafiche delle utenze richiedeva una serie di operazioni estremamente coreografata (per usare un delicato eufemismo), tra le quali anche l’inserimento dell’account di servizio della Farm nel gruppo amministrativo locale di ogni server SharePoint, azione che – sebbene temporanea – contrasta con le best practices Microsoft.

La maggior parte dei problemi di implementazione era legata alla dipendenza dello User Profile Synchronization Service di SharePoint dal servizio Windows Forefront Identity Manager (FIM), dipendenza che spesso costringeva gli amministratori a combattere contro il famigerato status perennemente in “starting”.

Figura 1 – Attendere, prego…

Per maggiori info sullo User Profile Synchronization Service si rimanda a questo articolo: https://technet.microsoft.com/en-us/library/ee662538.aspx.

La buona notizia è che nelle versioni successive di SharePoint sono stati apportati sensibili miglioramenti ai meccanismi di sincronizzazione con Active Directory e in questa serie di articoli ne andremo a scoprire i dettagli:

• Active Directory Import (ADI),
• Microsoft Identity Management Server 2016.

SharePoint 2013: Welcome ADI!

A partire da SharePoint 2013 è stata introdotta la feature chiamata Active Directory Import (ADI), che consente di importare utenti da Active Directory nella User Profile Service Application di SharePoint.

Con ADI, l’amministratore ha la possibilità di evitare FIM per accedere ad Active Directory, sebbene con qualche limitazione:

• FIM può sincronizzare la User Profile Service Application di SharePoint con Active Directory e (tramite i Business Connectivity Services, BCS) con sistemi esterni, mentre ADI parla solo con Active Directory;
• FIM può effettuare una sincronizzazione “bidirezionale”, ADI è “one-way”;
• FIM può sincronizzare dati da più origini in parallelo, ADI può importare solo da un repository alla volta;
• ADI non permette la sincronizzazione delle foto del profilo.

Figura 2 – SharePoint 2013 FIM vs ADI

Ci sono comunque numerosi punti a favore di ADI rispetto a FIM:

• Performance;
• Facilità di configurazione;
• Possibilità di schedulare importazioni incrementali ogni 5 minuti;
• Possibilità di selezionare quali utenti importare attraverso filtri LDAP.

Le operazioni necessarie ad implementare ADI sono piuttosto semplici e vanno effettuate dopo i medesimi step propedeutici all’utilizzo di FIM:

• Creazione di una Web Application e di una Site Collection per ospitare i “My Sites”;
• Creazione di un’istanza della User Profile Service Application.

È richiesto un account con privilegi di Farm Administrator che sia membro del gruppo locale Administrators del server SharePoint.

Creare la Web Application per i “My Sites”

Nota: I passaggi qui descritti riguardano nello specifico SharePoint 2013, sebbene in SharePoint 2016 siano del tutto simili.

Accedere alla Central Administration di SharePoint.

Nella sezione Application Management, fare clic su Manage
web
applications.

Figura 3 – Manage web applications

Nel ribbon, fare clic su New.

Nella pagina Create New Web Application:

• Nella sezione Authentication, selezionare il metodo di autenticazione desiderato;
• Nella sezione IIS Web Site decidere se utilizzare un sito web esistente o se crearne uno nuovo (e nel caso definirne il nome nella text box Name);
• Nella sezione Security Configuration specificare un authentication provider, specificare se è consentito l’accesso anonimo e l’eventuale utilizzo di SSL;
• Nella sezione Application Pool, optare per un application pool esistente o crearne uno nuovo;
• Nella sezione Database Name and Authentication selezionare il nome del SQL Server, il nome del database per la Web Application e il metodo di autenticazione;
• Nel caso in cui si utilizzi il database mirroring, nella sezione Failover Database specificare il nome del SQL Server di failover;
• Nella sezione Service Application Connections selezionare le connessioni alla Service Application che saranno disponibili per la Web Application;
• Nella sezione Customer Experience Improvement
  Program selezionare Yes o No.

Fare clic su OK.

Creare la Site Collection per i “My Sites”

Nella Central Administration, sezione Application Management, fare clic su Create site collections.

Figura 4 – Create site collection

Nella pagina Create site collection:

• Nella sezione Web Application, selezionare la Web Application creata precedentemente;
• Nella sezione Title and Description digitare un nome ed una descrizione;
• Nella sezione Web Site Address selezionare l’URL per consentire agli utenti di accedere al sito (ad esempio la root “/”);

Figura 5 – Create site collection

• Nella sezione Template Selection, fare clic su Enterprise e selezionare My Site Host;

Figura 6 – Template Selection

• Specificare il nome dell’amministratore della Site collection nella sezione Primary Site Collection Administrator nella forma DOMINIO\NomeUtente;
• Eventualmente specificare un amministratore secondario nella sezione Secondary Site Collection Administrator;
• Nella sezione Quota Template, qualora si utilizzino le quote per limitare lo spazio occupato dalle Site Collections, selezionare un modello nell’elenco Select a quota template.

Fare clic su OK.

Creare la User Profile Service Application

Nella Central Administration, sezione Application Management, fare clic su Manage service applications.

Figura 7 – Manage service applications

Nel ribbon, fare clic su New e selezionare User Profile Service Application:

• Nella sezione Name, digitare il nome della User Profile service application;
• Nella sezione Application Pool, optare per un application pool esistente o crearne uno nuovo;

Figura 8 – Create New User Profile Service Application

• Accettare le opzioni di default per i database da creare e, qualora presente, specificare i server di failover;
• Nella sezione Profile Synchronization Instance, qualora necessario, specificare il nome del server SharePoint che eseguirà la sincronizzazione;
• Nella sezione My Site Host URL, specificare l’URL della Site Collection creata precedentemente;
• Nella sezione My Site Managed Path, digitare la parte del percorso che porterà ai siti personali;

Figura 9 – My Site Host URL e My Site Managed Path

• Nella sezione Site Naming Format, selezionare una modalità di generazione automatica del nome dei siti personali;

Figura 10 – Site Naming Format

• Fare clic su Create.

Al termine delle attività di creazione, nella pagina Create New User Profile Service Application fare clic su OK.

Avviare il servizio User Profile

Nella Central Administration, fare clic su System Settings e poi fare clic su Manage services on server.

Nella pagina Services on Server, qualora necessario, nella casella Server, selezionare il server che eseguirà la sincronizzazione.

Figura 11 – Services on Server

Nella riga User Profile Service, se il valore della colonna Status è “Stopped“, fare clic su Start nella colonna Action.

Figura 12 – User Profile Service partito!

Abilitare ADI

Per abilitare Active Directory Import è necessario disporre di un account di servizio che abbia privilegi di “Replicate Directory Changes” sul dominio Active Directory.

A tal fine, seguire le indicazioni riportate nell’articolo di Microsoft https://technet.microsoft.com/en-us/library/hh296982.aspx per assegnare i diritti necessari attraverso il Delegation of Control Wizard di Active Directory Users and Computers.

Figura 13 – Assegnazione del privilegio Replicate Directory Changes

Di nuovo accedere alla Central Administration di SharePoint e nella sezione Application Management fare clic su Manage service applications.

Nella pagina Manage Service Applications, fare clic sul nome della User Profile service application.

Nella pagina Manage Profile Service, sezione Synchronization, clic su Configure Synchronization Settings.

Figura 14 – Configure Synchronization Settings

Nella pagina Configure Synchronization Settings, sezione Synchronization Options, selezionare l’opzione Use SharePoint Active Directory Import e fare clic su OK.

Figura 15 – Versione SharePoint 2013

Figura 16 – Versione SharePoint 2016

Nel prossimo articolo

Fin qui abbiamo configurato i prerequisiti di Active Directory Import. Nel prossimo articolo vedremo come impostarne la sincronizzazione con Active Directory e abbinare le informazioni anagrafiche degli utenti raccolte da ADI con le proprietà dei profili utente gestiti da SharePoint.

I template in Microsoft Azure possono utilizzare un’ampia gamma di risorse oltre a quelle tipiche dell’ Infrastructure As A Service (IaaS), come ad esempio le Web App o i database SQL e permettono di distribuire automaticamente queste risorse in relazione tra loro.

Uno dei vantaggi dei template di Azure è quello di poter creare tutte le risorse necessarie alla creazione di una soluzione, anche complessa, semplicemente utilizzando un clic!

Sul sito web GitHub, all’indirizzo https://github.com/Azure/azure-quickstart-templates trovate centinaia di template in formato JavaScript Object Notation (JSON), che vi permettono di creare macchine virtuali, reti virtuali, applicazioni web, database SQL e di realizzare soluzioni e applicazioni già pronte all’uso.

Per poterlo fare basta dichiarare nel template di Azure quali risorse volete utilizzare e successivamente fornire i parametri necessari alla configurazione della soluzione scelta.

Moltissimi sono i template disponibili, visualizzabili alla pagina https://azure.microsoft.com/it-it/resources/templates/, che vi permettono di creare ad esempio un intero cluster, utilizzando diverse macchine virtuali.

Figura 1: Offerta dei template in Azure

Ovviamente potete creare template di Azure anche personalizzati. Trovate una serie di ottime guide al link https://docs.microsoft.com/it-it/azure/azure-resource-manager/resource-manager-template-best-practices , dove vi vengono illustrate le best practices per creare modelli di Resource Manager facili da usare.

Inoltre i template possono essere esportati anche da risorse che già avete nella vostra sottoscrizione Azure. Supponendo di aver creato una macchina virtuale e di volerla replicare, abbiamo la possibilità di visualizzare il file .json del template e di esportarlo per riutilizzarlo per ridistribuire la macchina virtuale in base alle nostre esigenze. Nella figura sotto, dopo essermi loggato al portale Azure, ho cliccato su una mia macchina virtuale e successivamente ho cliccato su Automation Script, in modo tale da visualizzare il template .json della Virtual Machine e poterlo scaricare.

Figura 2: Template .json esportabile dal portale di Azure

Cliccando su Download avrete la possibilità di scaricare i file Parameters.json e Template.json, oltre a file per poter distribuire il template utilizzando Powershell oppure Bash o Visual Studio.

Figura 3: File scaricati dal portale Azure

Figura 4: parte del file template.json

Figura 5: file parameters.json

Figura 6: File deploy.ps1

Ridistribuire i template diventa facilissimo perché possiamo usare il file deploy.ps1 dopo aver modificato i parametri dei file .json

Template pronti disponibili su GitHub

Dal repository GitHub potete partire dall’implementazione di modelli semplici, come ad esempio il template che permette di creare una nuova VM e promuoverla a domain controller di una nuova foresta Create an Azure VM with a new AD Forest

Figura 7: Template per la creazione di un nuovo domain controller

Trovo particolarmente interessanti alcuni template presenti su GitHub che ci danno la possibilità di creare soluzioni complesse di Clustering di VM.

In particolar modo è possibile utilizzare il template Windows Server 2016 Storage Spaces Direct (S2D) SOFS cluster per creare delle macchine virtuali da collegare ad una rete VNET esistente e poter creare un Windows Server 2016 Storage Spaces Direct (S2D) Scale-Out File Server (SOFS) cluster, il tutto con un semplice clic!

Figura 8: template per la creazione di uno Storage Spaces Direct (S2D) Scale-Out File Server (SOFS) cluster

Interessante anche il template Create a Storage Spaces Direct (S2D) SOFS Clusters with Storage Replica for Disaster Recovery across Azure Regions, che permette di creare due cluster Storage Spaces Direct (S2D) Scale-Out File Server (SOFS) utilizzando Windows Server 2016 in un ambiente realizzato tra due regioni diverse di Azure, in modo tale da poter utilizzare la nuova funzionalità di Storage Replica.

Figura 9: Schema di funzionamento di Storage Spaces Direct (S2D) in un ambiente realizzato tra due regioni diverse di Azure

Figura 10: template Create a Storage Spaces Direct (S2D) SOFS Clusters with Storage Replica for Disaster Recovery across Azure Regions

Per maggiori approfondimenti vi rimando anche all’articolo Implementare Storage Spaces Direct in Windows Server 2016 con Microsoft Azure.

Ci sono anche soluzioni più semplici che permettono di testare la nuova funzionalità di Storage Replica, di cui abbiamo parlato nell’articolo Implementare Storage Replica in Windows Server 2016 con Microsoft Azure. Trovate il template all’indirizzo Create a Storage Replica (SR) destination server with Windows Server 2016 on an existing VNET

Figura 11: Template Create a Storage Replica (SR) destination server with Windows Server 2016 on an existing VNET

Conclusioni

La facilità con cui i template di Azure ci permettono di realizzare soluzioni tecnologiche complesse, come Storage Replica, Storage Spaces Direcr oppure il Clustering, ci danno un’idea precisa della potenza del cloud pubblico di Microsoft e dell’evoluzione tecnologica dei nostri Datacenter.

E se volete cimentarvi con la creazione di vostri template potete cominciare visitando la pagina https://docs.microsoft.com/it-it/azure/azure-resource-manager/resource-group-authoring-templates

Buon lavoro!

Nic

Windows PowerShell è una interfaccia a riga di comando introdotta in Windows Server diversi anni fa. Tramite PowerShell è possibile configurare sia il sistema operativo sia gli applicativi. Microsoft Exchange Server e System Center Virtual Machine Manager sono stati i primi software ad essere basati interamente su PowerShell.

Col tempo Microsoft ha introdotto la possibilità di gestire anche tutte le funzioni del sistema operativo e anche altri importanti Vendor hanno iniziato ad implementare la gestione delle proprie applicazioni utilizzando PowerShell.

Questo tipo di approccio fa sì che dopo aver imparato ad utilizzare PowerShell siamo in grado di creare script complessi che ci permettono di interagire con software non Microsoft, di automatizzare alcune operazioni ripetitive utilizzando un unico tool e di eseguire operazioni che non sono disponibili dall’interfaccia grafica (GUI).

PowerShell Desired State Configuration

In questo articolo vi voglio descrivere la funzionalità Windows PowerShell DSC (Desired State Configuration), introdotta in PowerShell v4 e presente di default in Windows Server 2012 R2. DSC è una piattaforma di gestione di Windows PowerShell che consente di distribuire e gestire dati di configurazione per i software, nonché di gestire l’ambiente in cui vengono eseguiti questi software. DSC fornisce anche un set di estensioni di Windows PowerShell, nuovi cmdlet e risorse che è possibile usare per configurare le applicazioni o lo stato del sistema operativo.

Obiettivo di DSC è quello di configurare in modo automatico un insieme di computer ed in particolar modo:

• Abilitare o disabilitare funzionalità e ruoli del server
• Gestire il Registro di sistema
• Gestire file e directory
• Avviare, arrestare e gestire processi e servizi
• Gestire gruppi e account utente
• Distribuire nuovo software
• Gestire le variabili di ambiente
• Eseguire script di Windows PowerShell
• Correggere una configurazione che non sia quella desiderata

Quando viene eseguita la configurazione DSC (e le risorse chiamate dalla configurazione), gli script si assicurano che il risultato sia quello desiderato, facendo in modo che lo stato del sistema corrisponda a quanto definito dalla configurazione.

Esiste anche una versione di DSC per Linux. Vi rimando all’articolo Installare e configurare PowerShell Desired State Configuration for Linux per maggiori approfondimenti.

Prerequisiti

Per poter utilizzare DSC avete bisogno dei seguenti prerequisiti:

• Windows Management Framework 4.0
• .Net Framework 4.5
• Windows Server 2008 R2 SP1 e successivi
• Windows 7 SP1 e successivi

È consigliabile utilizzare Windows Server 2012 e soprattutto se usate Windows 8.1 o Windows Server 2012 R2 assicuratevi di aver installato la KB2883200

È importante anche che PowerShell Remoting sia abilitato.

Componenti di Desired State Configuration

DSC è una piattaforma costituita da 3 componenti principali:

• Configurazioni. Le configurazioni sono script di PowerShell che definiscono e configurano le istanze delle risorse. Quando viene eseguita la configurazione, DSC si assicura semplicemente che il risultato sia quello desiderato.
• Risorse. Le risorse si trovano all’interno dei moduli di PowerShell e possono essere scritte per modellare un elemento generico, come un file o un processo di Windows, o un elemento specifico, come un server IIS o una VM in esecuzione in Azure.
• Local Configuration Manager. È il motore usato da DSC per semplificare l’interazione tra risorse e configurazioni. Esegue regolarmente il polling del sistema per garantire che lo stato definito da una configurazione venga mantenuto.

Configurazioni DSC

Le configurazioni DSC sono script di PowerShell che definiscono una funzione. Per definire una configurazione bisogna usare la parola chiave Configuration. Nell’esempio sotto viene definito con Node il sistema target su cui fare la verifica della configurazione (presenza del ruolo IIS e della fuzionalità ASP.NET 4.5)

Dopo aver dichiarato la configurazione DSC è sufficiente creare un file MOF (Management Object Format) che potrà essere utilizzato per richiamare qualsiasi funzione PowerShell, utilizzando il comando:

ICTPowerWebsite –MachineName “Server01”

Dove Server01 è il nome della macchina da configurare.

Il comando non farà altro che creare una cartella con lo stesso nome della configurazione (nel nostro caso ICTPowerWebsite e un file MOF di output per OGNI blocco Node presente nella Configurazione.

Figura 1: Cartella di output del Configurazione

Figura 2: File MOF di output della Configurazione

Un Node DSC è qualsiasi computer in cui la configurazione è gestita da DSC. Può essere una macchina virtuale di Azure (con sistema operativo Windows o Linux), una macchina virtuale locale o un computer fisico. I nodi eseguono le configurazioni Node per diventare conformi e mantenere la conformità con lo stato desiderato.

Una volta che abbiamo ottenuto il file MOF abbiamo la possibilità di utilizzarlo applicando la cmdlet di PowerShell

Start-DscConfiguration –Path .\ICTPowerWebsite –Wait –Verbose

Il parametro Path può essere sia un percorso locale che un percorso di rete (UNC).

Figura 3: Applicazione della configurazione

Lanciando la cmdlet Start-DscConfiguration possiamo verificare in qualsiasi momento che Server01 abbia le configurazioni richieste e possiamo riutilizzarla per riapplicare le configurazioni tutte le volte che ci serve.

Figura 4: Riapplicazione della Configurazione usando la stessa cmdlet

Per verificare le configurazioni applicate potete usare la cmdlet Get-DscConfiguration, mentre per validare i parametri della configurazione potete usare la cmdlet Test-DscConfiguration, che vi restituirà il parametro True (se la configurazione del server è conforme con quello richiesto da DSC) oppure False (se non è conforme).

Interessante è anche la possibilità di fare roll-back ad una configurazione precedente, nel caso abbiate sbagliato, utilizzando la cmdlet Restore-DscConfiguration. Non è possibile invece tornare indietro ad uno stato precedente all’applicazione della configurazione DSC.

Figura 5: Verifica della configurazione

Utilizzo di DSC in Azure

Con Automation DSC (Desired State Configuration) per Azure è possibile distribuire in modo coerente, monitorare in modo affidabile e aggiornare automaticamente lo stato desiderato di tutte le risorse presenti nel Cloud.

Per poter utilizzare DSC è necessario installare nella VM un agent particolare chiamato Desired State Configuration extension.

Mentre di solito è necessario convertire gli script DSC di configurazione per il nodo in file MOF, compilandoli con una cmdlet PowerShell, Azure PowerShell gestisce automaticamente la compilazione quando distribuite l’estensione DSC alle VM di Azure.

Figura 6: Aggiunta dell’Estensione DSC ad una VM in Azure

Come esempio ci proponiamo di installare IIS all’interno della VM. Creiamo un file con estensione .ps1 con all’interno la configurazione di DSC:

Salviamo il file, lo comprimiamo in formato ZIP e successivamente installiamo dal portale di Azure, dopo aver selezionato la macchina, l’estensione PowerShell Desired State Configuration.

Carichiamo il file ZIP nell’apposita casella Configuration Modules or Script e scriviamo la notazione corretta della configurazione da eseguire nella casella Module-qualified Name of Configuration. La notazione deve essere nella forma <ConfigurationFile>.ps1\<ConfigurationName>. Nel mio caso è DSC-Install-IIS.ps1\MyDscConfiguration. Inserite nel campo Version il valore 2.0 e mettere su Yes il valore Auto Upgrade Minor Version.

Confermiamo con Create e vedremo che l’estensione è stata aggiunta alla nostra VM ed è in esecuzione.

Figura 7: Script in esecuzione

Dopo il reboot della VM verrà applicato lo script che avete caricato e lo status dell’estensione diventerà Provisioning
Succeded!

Figura 8: Esecuzione dello script completata

Lo script viene eseguito però solo una volta. Se volete rieseguire dovete ricaricarlo dal portale di Azure. Il motivo è dovuto al fatto che il Local Configuration Manager è configurato di default nella modalità ApplyAndMonitor. Per poter controllare e rieseguire lo script ciclicamente dovete modificare il Local Configuration Manager.

Modifica del Local Configuration Manager

Come ho già scritto prima, il Local Configuration Manager è il motore usato da DSC che esegue regolarmente il polling del sistema per garantire che lo stato definito da una configurazione venga mantenuto. Per verificare la configurazione del Local Configuration Manager è sufficiente lanciare sulla macchina la cmdlet

Get-DscLocalConfigurationManager

Figura 9: Valori di default del Local Configuration Manager

Di default il Local Configuration Manager è settato nella modalità ApplyAndMonitor.

Per riapplicare continuamente le impostazioni del vostro script DSC dovete modificare il parametro di ConfigurationMode in ApplyAndAutoCorrect. Potete realizzare uno script DSC e inserire il contenuto:

Salvate il file con estensione .ps1 ed eseguitelo sulla macchina per creare il file MOF, come ho precedentemente spiegato. Una volta che abbiamo ottenuto il file MOF abbiamo la possibilità di utilizzarlo applicando la cmdlet di PowerShell

Set-DscLocalConfigurationManager –Path .\LCMConfig\ –Verbose

Figura 10: Modifica del Local Configuration Manager

Rilanciando la cmdlet

Get-DscLocalConfigurationManager

vedrete che la vostra configurazione sarà stata applicata.

Figura 11: Modifica dei parametri del Local Configuration Manager

Con la configurazione appena modificata, DSC controllerà ogni 30 minuti lo stato della macchina e riapplicherà automaticamente lo script!

Maggiori informazioni su come configurare Windows PowerShell 4.0 Desired State Configuration Local Configuration Manager (LCM) sono disponibili al link https://msdn.microsoft.com/en-us/powershell/dsc/metaconfig4

Conclusioni

PowerShell DSC permette di poter avere le nostre macchine nello stato in cui le riteniamo conformi e si può assicurare che lo rimangano poiché gli script possono essere continuamente riapplicati. Per cominciare a lavorare con DSC potete visitare la pagina Getting Started with PowerShell Desired State Configuration (DSC)

Buon lavoro!

Nic

Tra le novità di Windows Server 2016 spiccano quelle relative all’iperconvergenza dello storage e dell’hypervisor. Per iperconvergenza o per infrastruttura iperconvergente si intende una infrastruttura IT basata su risorse hardware offerte da un unico vendor, che integra calcolo, memorizzazione, virtualizzazione e networking. Tutte le risorse vengono gestite tramite software e l’espansione del sistema è fortemente semplificata.

Avevamo già parlato in un precedente articolo su come implementare Storage Spaces Direct. La nuova funzionalità S2D di Windows Server 2016 permette infatti di creare sistemi di storage ad alta disponibilità utilizzando dischi locali. Se poi sugli stessi nodi fisici utilizzati per creare l’infrastruttura S2D installiamo anche Hyper-V, abbiamo la possibilità di creare un cluster hyper-convergente.

Vi ricordo che Storage Spaces Direct è una funzionalità disponibile solo nella versione Datacenter di Windows Server 2016. Per conoscere le differnze tra le diverse versioni di Windows Server vi rimando alla lettura dell’articolo Windows Server 2016 – Quali sono le differenze tra la Standard Edition e la Datacenter Edition.

Figura 1: Schema di funzionamento di una soluzione Hyper-convergente

In questo articolo vi voglio mostrare queste due funzionalità e realizzare un laboratorio di test per provare la soluzione di Hyper-convergenza offerta da Microsoft. L’obiettivo è quello di creare un cluster formato da SOLO 2 NODI di Hyper-V che usa Storage Spaces Direct.

Figura 2: Schema del laboratorio da realizzare

Nel mio laboratorio, realizzato su un computer con Windows 10 Anniversary Update e con il ruolo Hyper-V installato, ho creato due macchine virtuali, chiamate HV1 ed HV2, all’interno delle quali ho installato Hyper-V. Questo mi permette anche di farvi vedere come funziona la Nested Virtualization, un’altra novità disponibile in Windows 10 Anniversary Update e in Windows Server 2016.

Dopo aver creato le due macchine virtuali HV1 ed HV2 ed aver assegnato loro almeno 4GB di RAM staticamente (controllate i prerequisiti per la Nested Virtualization), ho lanciato (a VM spente) una PowerShell con privilegi elevati e ho abilitato la nested virtualization con i comandi:

#Abilitazione della Nested Virtualization

Set-VMProcessor -VMName HV1 -ExposeVirtualizationExtensions 1

Set-VMProcessor -VMName HV2 -ExposeVirtualizationExtensions 1

Figura 3: Creazione sulla macchina Windows 10 delle due macchine virtuali che faranno da host Hyper-V

Ho installato Windows Server 2016 all’interno di HV1 ed HV2 e ho abilitato il ruolo di Hyper-V. È possibile abilitare il ruolo anche utilizzando la nuova funzionalità di PowerShell Direct. Questa funzionalità permette di eseguire delle cmdlet di PowerShell dalla macchina host verso le VM, anche se le VM non hanno una scheda di rete o la scheda di rete è disconnessa. I comandi che ho usato sono:

#Installazione del ruolo Hyper-V utilizzando PowerShell Direct

$cred = Get-Credential

Invoke-Command -VMName HV1 -Credential $cred -ScriptBlock {Install-WindowsFeature -Name hyper-v -IncludeManagementTools -Restart}

Invoke-Command -VMName HV2 -Credential $cred -ScriptBlock {Install-WindowsFeature -Name hyper-v -IncludeManagementTools -Restart}

Terminata l’installazione del ruolo ho provveduto a creare sullo storage locale dei due nodi Hyper-V due machine virtuali che utilizzerò come Domain controller e che ho chiamato DC1 e DC2. I due domain controller rimarranno ognuno assegnato al proprio nodo Hyper-v e verranno messi in esecuzione automatica, in modo tale che il dominio sia sempre disponibile. Poiché il servizio cluster dipende da Active Directory i due domain controller non verranno “clusterizzati”, ma rimarranno delle semplici macchine virtuali.

Figura 4: Due Domain controller annidati sugli Host virtuali HV1 ed HV2

Per far parlare tra di loro i due domain controller ho provveduto a creare sui due nodi HV1 ed HV2 un virtual switch di tipo External e successivamente ho abilitato sulle schede di rete di HV1 ed HV2 il MAC Address Spoofing dalle proprietà avanzate delle schede, in quanto le due macchine DC1 e DC2 stanno utilizzando la Nested Virtualization e senza abilitazione del MAC Address Spoofing i pacchetti di rete non riuscirebbero a superare i due Virtual Switch.

Figura 5: Abilitazione del MAC Address Spoofing

L’abilitazione del MAC Address Spoofing si può effettuare anche da PowerShell usando il comando:

#Abilitazione del MAC Address Spoofing

Get-VMNetworkAdapter -VMName HV1,HV2 | Set-VMNetworkAdapter -MacAddressSpoofing On

Dopo aver creato il dominio su DC1 e aver aggiunto DC2 come domain controller aggiuntivo, ho provveduto ad aggiungere al dominio anche i nodi HV1 ed HV2. Ho configurato anche le virtual machine DC1 e DC2 in modo tale che possano partire automaticamente quando parte l’host di virtualizzazione.

Figura 6: Autostart dei due Domanin controller DC1 e DC2

Abilitazione delle funzionalità di Storage Spaces Direct

Prima di abilitare la funzionalità S2D vi invito a dare un’occhiata agli Storage Spaces Direct hardware requirements. Tra le configurazioni supportate io ho scelto quella in cui ci sono 4 dischi SSD per ogni singolo nodo.

Per questo motivo ho aggiunto ad entrambi i nodi HV1 ed HV2 4 dischi da 512 GB. Per semplicità ho effettuato l’operazione lanciando dalla macchina fisica con Windows 10 eseguendo le seguenti cmdlet:

#Aggiunta dei dischi alla macchina HV1

1..4 | % { New-VHD -Path “C:\LAB\HV1\Virtual Hard Disks\DISCO$_.VHDX” -Dynamic –Size 512GB}

1..4 | % { Add-VMHardDiskDrive -VMName HV1 -ControllerType SCSI -Path “C:\LAB\HV1\Virtual Hard Disks\DISCO$_.VHDX” }

#Aggiunta dei dischi alla macchina HV2

1..4 | % { New-VHD -Path “C:\LAB\HV2\Virtual Hard Disks\DISCO$_.VHDX” -Dynamic –Size 512GB}

1..4 | % { Add-VMHardDiskDrive -VMName HV2 -ControllerType SCSI -Path “C:\LAB\HV2\Virtual Hard Disks\DISCO$_.VHDX” }

Una volta che i dischi sono stati aggiunti sarà possibile utilizzarli per attivare la funzionalità di Storage Spaces Direct. Ho installato su entrambi i nodi HV1 ed HV2 la feature di Failover Clustering e terminata l’operazione di installazione ho aperto un prompt di PowerShell con privilegi elevati su uno dei due nodi ed ho effettuato un test per verificare se fosse possibile configurare il cluster ed utilizzare S2D eseguendo la cmdlet:

#Test della configurazione dei nodi che formeranno il Cluster

Test-Cluster –Node HV1,HV2 –Include “Storage Spaces Direct”, Inventory, Network, “System Configuration”

Figura 7: Test della configurazione dei nodi che formeranno il Cluster

Se tutti i test sono andati a buon fine e non avete ricevuto errori potete procedere alla creazione del cluster. Non avendo ricevuto errori ho eseguito su uno dei nodi del cluster HV1 oppure HV2 la seguente cmdlet:

#Creazione di un nuovo cluster

New-Cluster -Name S2DCluster -Node HV1,HV2 –NoStorage –StaticAddress 10.10.10.100

Figura 8: Creazione del Cluster S2DCluster

Al termine della creazione del cluster ho ricevuto un warning. Controllate il contenuto del report creato e verificate che, poiché abbiamo scelto di utilizzare solo 2 nodi e di non aggiungere nessuno storage condiviso al cluster, sarà necessario configurare un witness, come mostrato in figura:

Figura 9: warning presente nel report, riferito al quorum witness

Per questo laboratorio ho preferito usare una novità del cluster di Windows Server 2016: Il Cloud Witness. Aprendo la console Failover Cluster Manager su HV1 sarà infatti possibile cambiare la modalità di quorum selezionando il nome del cluster e scegliendo More Actions à Configure Cluster Quorum Settings…

Figura 10: Modifica della funzionalità di Quorum del Cluster

Ho seguito il wizard di configurazione ed ho inserito il nome dello Storage Account e la Primary Access Key del mio account di archiviazione di Microsoft Azure. Per maggiori informazioni sugli Azure Storage Account potete visitare il link https://docs.microsoft.com/en-us/azure/storage/storage-create-storage-account

Figura 11: configurazione del Cloud Witness

Dopo aver configurato tutto a dovere ho ottenuto una situazione come quella mostrata nella figura sotto:

Figura 12: Creazione del Cluster completata

Storage Spaces Direct

Siamo pronti per abilitare la funzionalità di Storage Spaces Direct (S2D). Ho notato che sia in Hyper-V che in Microsoft Azure i dischi collegati alle macchine riportano come MediaType il valore Unspecified. Storage Spaces Direct utilizza i due valori BusType e MediaType per configurare automaticamente lo storage pool, lo storage tiering e la cache. Infatti lanciando la cmdlet su uno dei nodi del cluster

#Verifica dei dischi collegati

Get-PhysicalDisk | ? CanPool -EQ 1 | FT FriendlyName, BusType, MediaType, Size

ottengo il seguente risultato:

Figura 13: verifica dei dischi collegati

Per ovviare a questo problema ho abilitato Storage Spaces Direct lanciando la seguente cmdlet su uno dei nodi del cluster:

#Abilitazione di Storage Spaces Direct

Enable-ClusterS2D -CacheState Disabled -AutoConfig:0 -SkipEligibilityChecks

Rispondete Yes to All al prompt che vi apparirà, come mostrato in figura:

Figura 14: Abilitazione della funzionalità di Storage Spaces Direct

Terminata la configurazione del cluster potreste ricevere un messaggio di avviso, come mostrato in figura:

Figura 15: Abilitazione completata con warning

Se aprite il report potrete verificare che ci sarà soltanto l’avviso relativo ai dischi che non sono stati aggiunti al cluster, in quanto durante la creazione abbiamo specificato il parametro -SkipEligibilityChecks

Figura 16: Warning relativi ai dischi non aggiunti al cluster

Figura 17: Funzionalità S2D abilitata

Dopo aver abilitato la funzionalità di Storage Spaces Direct noterete che nella console del Failover Clustering sono apparsi 2 Enclosures, ognuno dei quali fa riferimento a ogni singolo nodo del cluster:

Figura 18: Enclosure con 1 dischi aggiunti al Cluster S2D

Il passaggio successivo consiste nel creare uno Storage Pool utilizzando i dischi che sono stati aggiunti al cluster attraverso gli Enclosure dei due nodi. Ho creato uno Storage Pool semplicemente eseguendo su uno dei due nodi HV1 oppure HV2 il comando:

#Creazione dello storage pool

New-StoragePool -StorageSubSystemFriendlyName *Cluster* -FriendlyName S2D -ProvisioningTypeDefault Fixed -PhysicalDisk (Get-PhysicalDisk | ? CanPool -eq $true)

Nel mio caso ho scelto di creare uno storage pool utilizzando tutti i dischi disponibili: il risultato è mostrato in figura:

Figura 19: Storage Pool creato con tutti i dischi disponibili

Siamo pronti ora per creare un nuovo volume (da 1 TB), formattarlo REFS e trasformarlo in un Cluster Shared Volume. All’interno del volume CSV andremo poi a salvare tutte le macchine virtuali che creeremo in seguito. Per farlo basta eseguire su uno dei nodi del cluster la cmdlet:

#Creazione del nuovo volume

New-Volume -StoragePoolFriendlyName S2D* -FriendlyName VDisk01 -FileSystem CSVFS_REFS -Size 1TB

Il risultato ottenuto è quello mostrato in figura:

Figura 20: Volume da 1TB creato nel Cluster S2D

Se volete potete modificare il percorso predefiniti per il salvataggio delle macchine virtuali, eseguendo su uno dei due host HV1 oppure HV2 la seguente cmdlet:

#Modifica dei percorsi di deafult per il salvataggio delle VM

Set-VMHOST –Computername HV1,HV2 –Virtualharddiskpath ‘C:\ClusterStorage\Volume1’

Set-VMHOST –Computername HV1,HV2 -VirtualMachinePath ‘C:\ClusterStorage\Volume1’

Test del cluster Hyper-Convergente

Per testare il cluster basta utilizzare la console del Failover Cluster Manager per creare una nuova VM altamente disponibile. Ho lanciato il wizard di configurazione della nuova VM, ho inserito come percorso del salvataggio della VM il CSV creato prima e non ho avuto problemi a terminare le altre configurazioni.

Figura 21: Creazione della VM altamente disponibile

Terminato il wizard di configurazione avrete una VM altamente disponibile, che sarà visualizzata come ruolo del Cluster.

Figura 22: Nuova VM creata all’interno del cluster S2D

Provando a spegnere uno dei due nodi, nel mio caso ho spento il nodo chiamato HV2, il cluster continua a funzionare e la macchina virtuale rimane accesa.

Figura 23: Anche con un nodo spento la macchina continua a funzionare

Conclusioni

Creare un cluster Hyper-V con 2 nodi ed utilizzare la nuova funzionalità Storage Spaces Direct ci permette di creare una infrastruttura iperconvergente altamente performante e scalabile, massimizzando l’utilizzo dell’hardware. Semplicemente collegando i due nodi con schede di rete a 10 GBit abbiamo semplificato di molto la creazione del cluster e le configurazioni necessarie per renderlo operativo.

Per approfondire le configurazioni presentate in questo articolo potete visitare le pagine

• Storage Spaces Direct in Windows Server 2016
• Hyper-converged solution using Storage Spaces Direct in Windows Server 2016

Buon lavoro!

Nic

Premessa

A partire da SharePoint 2013 sono stati apportati sensibili miglioramenti ai meccanismi di sincronizzazione con Active Directory.

Nell’articolo SharePoint Server: Sincronizzazione con Active Directory – Parte prima abbiamo introdotto Active Directory Import (ADI), feature che permette di non utilizzare i servizi di Forefront Identity Management (FIM) per accedere ad Active Directory.

Abbiamo anche elencato le operazioni preliminari all’implementazione di ADI:

• Creare una Web Application e una Site Collection per i “My Sites”;
• Creare un’istanza della User Profile Service Application.

In questo articolo proseguiamo le attività impostando la sincronizzazione con Active Directory per poi effettuare il match delle informazioni raccolte da ADI con le proprietà dei profili utente gestiti da SharePoint.

Come già specificato, tutte le operazioni vanno svolte utilizzando un account con privilegi di Farm Administrator facente parte del gruppo locale Administrators dei server SharePoint.

Configurare le Connection Properties

Accedere al sito della Central Administration di SharePoint e, in Application Management, fare clic su Manage Service Application.

Nella pagina Manage
Service
Applications fare clic su nome della User Profile service application.

Figura 1 – Manage service applications

Nella pagina Manage Profile Service, sezione Synchronization, clic su Configure Synchronization Connections.

Figura 2 – Configure Synchronization Connections

Nella pagina Synchronizations
Connections fare clic su Create New Connection.

Figura 3 – Synchronizations Connections

Nella pagina Add new synchronization
connection, nella casella di testo Connection Name digitare il nome che si intende dare alla synchronization connection (ad esempio “ADI Sync”) e nell’elenco Type selezionare Active Directory Import.

Nella casella Fully Qualified Domain Name digitare il FQDN del dominio Active Directory (nel nostro caso demolab.local). Qualora necessario, specificare un Autentication Provider diverso da “Windows Authentication” a seconda delle caratteristiche della Web Application a cui afferisce la Site Collection dei “My Sites” (vedi prima parte di questa serie di articoli).

Nella casella Account digitare il nome che sarà utilizzato da ADI per effettuare la sincronizzazione con Active Directory, nell’esempio DEMOLAB\ADRepUser. Questo account è stato precedentemente configurato in modo che abbia i privilegi di Replicate Directory Changes a livello di dominio (vedi articolo precedente).

Nelle caselle Password e Confirm password digitare la password del suddetto account.

Figura 4 – Add new synchronization connection (1)

È possibile filtrare gli utenti disabilitati e specificare una query LDAP per sincronizzare solo alcuni oggetti. Ad esempio, con la query

    (&(objectCategory=person)(objectClass=user))

si estraggono solo gli oggetti di tipo “user”.

Figura 5 – Add new synchronization connection (2)

Maggiori informazioni sulle query LDAP possono essere trovate qui: https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx

Nella sezione Containers fare clic su Populate Containers e selezionare le OU e i containers che si intendono sincronizzare, poi fare clic su OK.

Nota: selezionando una OU vengono automaticamente selezionare anche tutte le sotto-OU.

Figura 6 – Add new synchronization connection (3)

Nella pagina Synchronizations
Connections viene inventariata la nuova connection appena creata.

Figura 7 – Connection creata e disponibile

Abbinare le proprietà degli User Profile agli attributi di Active Directory

Nella Central Administration, in Application Management, fare clic su Manage Service Application.

Nella pagina Manage
Service
Applications fare clic su nome della User Profile service application.

Nella pagina Manage Profile Service, sezione People, clic su Manage User Properties.

Figura 8 – Manage User Properties

Nella pagina Manage User Properties fare clic con il tasto destro sul nome della proprietà che si desidera abbinare ad un attributo preso da Active Directory e fare clic su Edit.

Figura 9 – Abbinamento User Properties

Per aggiungere un nuovo abbinamento, nella sezione Add New Mapping, nell’elenco Source Data Connection, selezionare la Data Connection che rappresenta il servizio di directory a cui vogliamo relazionarci (nel nostro esempio “ADI Sync”).

Nella casella di testo Attribute occorre poi digitare il nome dell’attributo presente in Active Directory a cui si desidera abbinare la proprietà, ad esempio “Description”, poi fare clic su Add.

Figura 10 – Add New Mapping

La stessa operazione va ripetuta per ogni ulteriore proprietà che vogliamo abbinare ad un attributo di Active Directory.

Avviare la sincronizzazione dei Profili

A questo punto siamo pronti per avviare la sincronizzazione dei profili: nella Central Administration, sezione Application Management, fare clic su Manage Service Application.

Nella pagina Manage Service Applications, fare clic su User Profile Service Application.

Nella pagina Manage Profile Service, nella sezione Syncronization, fare clic su Start Profile Syncronization.

Nella pagina Start Profile Synchronization fare clic su Start Full Syncronization.

Figura 11 – Avvio della sincronizzazione dei profili

Qualora sia stata già effettuata una sincronizzazione in precedenza, è anche possibile utilizzare l’opzione Start Incremental Syncronization.

Nel prossimo articolo

Nella terza parte di questa serie affronteremo l’integrazione di SharePoint Server 2016 con Microsoft Identity Management Server 2016, prodotto che sebbene richieda un server dedicato aumentando di fatto la complessità dell’infrastruttura, porta con sé alcune funzionalità di grande interesse, fra cui il supporto a scenari multi-foresta e la bidirezionalità del flusso con Active Directory.

Sono passati 9 mesi dal rilascio di Windows 10 Anniversary Update, l’aggiornamento del sistema operativo che ha introdotto la funzionalità Windows Subsystem for Linux (WSL), grazie alla quale è possibile eseguire su Windows i binari di tipo ELF64, compilati cioè per funzionare su un sistema operativo Linux.

All’interno della community ICTPower ci siamo spesso occupati di questa nuova funzionalità, poiché ribadisce con forza la volontà di Microsoft di avvicinare il mondo dell’Open Source, e costituisce quindi una delle novità più importanti della politica aziendale degli ultimi tempi.

Rimandiamo quindi agli articoli precedenti in cui abbiamo illustrato gli step per l’installazione di questa funzionalità:

https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm

e mostrato come sostituire l’immagine di Ubuntu di default con una contenente Suse:

https://www.ictpower.it/guide/opensuse-in-windows-subsystem-for-linux-in-windows-10.htm

In questo articolo, invece, presentiamo un progetto molto interessante che è possibile trovare su github, chiamato WSL Distribution Switcher. Come è possibile intuire dal nome si tratta di un tool in grado di tenere installate sul nostro client Windows 10 molteplici distribuzioni di Linux, ed impostare quella in uso con WSL con un semplice comando.

Finalmente, quindi, ognuno è libero di utilizzare la propria distribuzione preferita, e l’occasione è imperdibile per chi si sta avvicinando al mondo Linux per la prima volta per provare le differenze tra le varie distribuzioni senza creare un numero enorme di macchine virtuali, e scegliere quella più adatta alle proprie esigenze. L’occasione è imperdibile anche per me, poiché utilizzando in maniera molto più agevole CentOS rispetto alle altre, finalmente ho la possibilità di farlo anche con WSL.

Come premessa riporto la pagina del progetto è la seguente, in modo da poterla seguire per tutti gli aggiornamenti futuri:

https://github.com/RoliSoft/WSL-Distribution-Switcher

Il tool è costituito da una serie di immagini, una per ogni distribuzione di Linux, ed uno script per effettuare lo switch da una distribuzione all’altra. Lo script è scritto in Python, un linguaggio di programmazione molto semplice e dinamico, e quindi abbiamo bisogno di installare le relative librerie per utilizzarlo.

Scarichiamo l’ultima versione di Python3 dal sito python.org, ad oggi troviamo la versione 3.6.1 disponibile a questo link:

https://www.python.org/ftp/python/3.6.1/python-3.6.1-amd64.exe

ed installiamo il pacchetto lasciando le impostazioni di default:

Scarichiamo quindi il pacchetto contenente il tool dall’indirizzo:

https://github.com/RoliSoft/WSL-Distribution-Switcher/archive/master.zip

Ed estraiamo l’archivio, ad esempio nella cartella Download

Nel mio caso particolare tutti i file sono nella cartella:

C:\Users\ICTPower\Downloads\WSL-Distribution-Switcher-master

Apriamo una PowerShell e posizionamoci in questa cartella. Per eseguire semplicemente questa operazione è possibile scrivere “powershell” nella barra degli indirizzi della cartella stessa, ed avviamo il download della distribuzione desiderata utilizzando lo script get-source. Iniziamo, ad esempio, scaricando un’immagine di CentOS con il comando:

py.exe .\get-source.py centos

Allo stesso modo è possibile effettuare il download di debian, fedora, suse ed alpine; in futuro saranno sicuramente disponibili immagini di altre distribuzioni. Per eseguire lo step successivo è necessario che WSL sia installato ma non attivo, quindi non dovranno essere aperte istanze di Windows bash al momento dell’esecuzione del comando altrimenti lo script restituirà un errore.

Scaricata l’immagine la installiamo con:

py.exe .\install.py centos

Al termine delle operazioni l’immagine appena installata diventa quella di default all’apertura di Windows bash, verifichiamolo subito aprendo una shell eseguendo dal prompt dei comandi:

bash

e leggiamo il contenuto del file /etc/os-release, che nelle distribuzioni CentOS ci da un po’ di informazioni sulla versione in uso

cat /etc/os-release

Come possiamo vedere ci troviamo su una CentOS7, loggati nel sistema con l’utente creato in fase di installazione di WSL. Nel mio caso il nome dell’utente è gnanoia. Ho trovato un problema nell’eseguire il comando “su” e guadagnare i privilegi di root. Al momento della richiesta della password, infatti, questa non veniva riconosciuta. Non avendo modo di indagare se il problema fosse dovuto alla versione dell’immagine, alla mia build di Windows10 o ad altri fattori, ho trovato un rapido workaround settando l’utente root come predefinito all’apertura di Windows bash; in questo modo la shell viene avviata senza la richiesta di alcuna password ed è possibile eseguire il comando “passwd” per settarne una nuova. E’ poi possibile reimpostare l’utente non privilegiato come predefinito per tornare alla condizione iniziale.

E’ possibile modificare l’utente predefinito di WSL utilizzando il comando lxrun /setdefaultuser <user>, quindi nel nostro caso eseguiamo da un prompt di DOS:

lxrun /setdefaultuser root

quindi apriamo bash e modifichiamo la password con il comando

passwd

chiudiamo la shell di root con

exit

chiudimo la shell iniziale per tornare al DOS con

exit

e risettiamo l’utente iniziale come predefinito. Nel mio caso:

lxrun /setdefaultuser gnanoia

Tutta la sequenza è visibile nello screenshot seguente:

Proviamo ora ad avviare bash ed utilizzare su per utilizzare la shell con privilegi amministrativi:

Ora la nostra immagine Centos7 è completa e funzionante, e possiamo utilizzare il gestore dei pacchetti yum per installare i nostri software preferiti.

Da un’analisi più approfondita però sono emerse delle limitazioni dovute alla tenera età di WSL, per cui non risulta possibile installare alcuni pacchetti, probabilmente per la mancanza del supporto ad alcune syscall; non ci rimane che essere pazienti e sperare che questa funzionalità cresca il più velocemente possibile chissà che nella prossima build di Windows10 non sia già tutto perfettamente funzionante.

In particolare i test di installazione sono falliti per iptools ed httpd, nello screenshot seguente vediamo il dettaglio dell’errore:

yum install httpd

Alla fine dell’elaborazione del comando il risultato sarà quello mostrato in figura:

Senza allarmarci troppo, quindi, fiduciosi di una rapida risoluzione, non perdiamo troppo di vista lo scopo dell’articolo, e torniamo all’installazione di distribuzioni alternative di Linux per WSL, provando ad effettuare in maniera rapida lo switch da una all’altra.

Torniamo quindi sulla nostra PowerShell per scaricare ed installare un’immagine di debian.

Come per l’installazione precedente, lo script imposta l’ultima immagine installata come predefinita, quindi avviando Windows bash ci aspettiamo di trovare una shell Debian. Infatti…

Per switchare da una distribuzione all’altra non è ovviamente necessario reinstallarla, quindi volendo tornare ad utilizzare CentOS, od una qualsiasi altra distribuzione già installata possiamo ricorrere allo script per lo switch:

py.exe .\switch.py centos

Verifichiamo che l’operazione ha avuto successo riaprendo bash e leggendo il file /etc/os-release

Ringraziamo sentitamente gli autori dello script, e rimaniamo in attesa della disponibilità delle nostre immagini preferite; anche in questo caso non possiamo fare a meno di notare che l’avvicinamento di Microsoft al mondo dell’Open Source sta scatenando una miriade di contributi di chi, ognuno a modo proprio, cerca di favorire la completa integrazione dei sistemi.

Una delle richieste che più spesso fanno gli utenti è quella di usare le stesse credenziali (nome utente e password) per accedere alle risorse aziendali e ai servizi basati sul Cloud. Questo tipo di autenticazione viene chiamata SAME SIGN-ON.

Utilizzando il tool Azure AD Connect molte aziende usano la sincronizzazione delle password di Azure AD allo scopo di fornire agli utenti un solo set di credenziali di accesso ai servizi locali (Active Directory) e al Cloud.

Da non confondere con l’autenticazione SAME SIGN-ON è invece l’autenticazione SINGLE SIGN-ON, che necessita di Active Directory Federation Services (ADFS). Per approfondimenti vi rimando all’articolo Che cos’è Single Sign-On (SSO).

Autenticazione Pass-through di Azure AD

Una novità, che in realtà è ancora in Preview, è rappresentata dall’autenticazione Pass-through. L’autenticazione Pass-through di Azure AD garantisce che la convalida della password per i servizi di Azure AD venga eseguita in Active Directory (quindi sul Domain controller in locale) e non è quindi necessario memorizzare le password nel Cloud nel Tenant di Azure AD.

Molte aziende infatti, per motivi di sicurezza, non vogliono che le password, anche sotto forma di hash, vengano divulgate al di fuori dell’ambiente aziendale.

L’autenticazione Pass-through è configurata tramite Azure AD Connect, che usa un agent locale per ricevere le richieste di convalida delle password che gli arrivano da Azure AD.

Questo tipo di autenticazione è supportata per tutti i Browser e i client Office che supportano l’autenticazione moderna. Non sono supportati invece i client di posta elettronica nativi su dispositivi mobili.

Come funziona l’autenticazione Pass-through di Azure AD

Quando un utente inserisce nome utente e password nella pagina di accesso di Azure AD, le credenziali vengono inserite nella coda del connettore presente in Azure AD per poter essere poi convalidate in Active Directory. La convalida viene eseguita secondo una modalità simile a quella delle password in Active Directory Federation Services (ADFS). A questo punto il domain controller locale valuta la richiesta e restituisce una risposta al connettore, che a sua volta la restituisce ad Azure AD. In figura viene mostrato lo schema di funzionamento:

Figura 1: Principio di funzionamento delll’autenticazione pass-through di Azure AD

Abilitazione dell’autenticazione pass-through di Azure AD

L’autenticazione Pass-through di Azure AD viene abilitata tramite Azure AD Connect. Procediamo quindi all’installazione di Azure AD Connect. Scarichiamo l’eseguibile da link http://go.microsoft.com/fwlink/?LinkId=615771 e lanciamo il setup

Figura 2: Setup di Azure AD Connect

Scegliamo di installare Azure AD Connect in modalità personalizzata, cliccando su Customize e nella schermata successiva facciamo clic su Install.

Figura 3: Installazione dei prerequisiti di Azure AD Connect

Dopo l’installazione dei componenti necessari, viene richiesta la selezione del metodo di accesso degli utenti. Scegliamo quindi la modalità Pass-Through Authentication. Gli utenti potranno accedere ai servizi cloud Microsoft, come ad esempio Office 365, usando la stessa password specificata nella rete locale. La password degli utenti verrà convalidata contattando il domain controller locale.

Figura 4: Scelta della modalità di autenticazione Pass-through

Inseriamo le credenziali per autenticarci al Tenant di Azure AD. Consiglio di usare un account nel dominio onmicrosoft.com predefinito, in modo tale che l’accesso al Tenant non vi venga precluso in caso di indisponibilità del/dei domain controller.

Figura 5: Connessione al Tenant di Azure AD

Per connettersi a Servizi di dominio di Active Directory, Azure AD Connect richiede le credenziali di un account con privilegi di Enterprise Admin. Inseriamo le credenziali corrette e facciamo clic su Add Directory.

Figura 6: Connessione alla foresta locale

Nella schermata successiva ci verranno presentati i domini UPN che sono stati verificati (nel mio caso nicolaferrini.cloud). Assicuriamoci che i domini da usare siano stati verificati in Azure AD e che siano stati aggiunti precedentemente nella console di Active Directory Domains and Trusts.

Figura 7: Aggiunta del nuovo suffisso UPN alla console di Active Directory Domains and Trusts

Figura 8: Verifica dei domini visibili nel Tenant di Azure AD

Di default vengono sincronizzati tutti i domini e le unità organizzative (OU). Per escludere alcuni domini o unità organizzative dalla sincronizzazione con Azure AD, è possibile deselezionarli. Nel mio caso ho messo tutti gli utenti nella OU chiamata Office365 e ho deciso di sincronizzare solo questa OU.

Figura 9: Impostazione del filtro relativo ai domini e alle OU da sincronizzare

Nella schermata relativa all’Identificazione univoca degli utenti lasciamo le configurazioni predefinite e facciamo clic su Next.

Figura 10: parametri per l’identificazione univoca degli utenti

Decidiamo a questo punto se vogliamo filtrare alcuni gruppi della nostra Directory locale. Nel caso lo vogliamo fare, magari perché abbiamo individuato un gruppo di utenti da utilizzare per un test, utilizziamo la notazione LDAP, indicando il distinguished name del gruppo da filtrare.

Figura 11: Scelta di un eventuale gruppo di AD da filtrare

Nella schermata delle funzionalità aggiuntive lasciamo tutto invariato. Poiché abbiamo scelto l’autenticazione Pass-through, l’opzione di sincronizzazione delle password è abilitata di default per garantire il supporto per i client legacy (come ad esempio i dispositivi mobili) e come opzione di backup. Questa opzione ovviamente non è obbligatoria, in quanto, come si è già detto, per alcune aziende è importante che le password non vengano portate nel Cloud.

Figura 12: Scelta facoltativa della password synchronization

Figura 13: Schermata finale di conferma

Dopo aver cliccato su Install partirà il processo di configurazione di Azure AD Connect, come mostrato in figura:

Figura 14: Configurazione del connettore di Azure AD Connect

Terminata la configurazione ci apparirà la schermata finale che ci avviserà dell’avvenuta installazione. Nel mio caso ho ricevuto un avviso che indicava che alcune funzionalità dell’autenticazione Pass-through potrebbero non funzionare in quanto alcune porte sono bloccate.

Per il corretto funzionamento è necessario infatti che siano abilitate le seguenti porte verso il server che esegue il tool di Azure AD Connect:

Figura 15: Configurazione completata

A questo punto ho testato la funzionalità collegandomi al portare https://login.microsoftonline.com ed inserendo le credenziali di un utente locale presente nella OU chiamata Office365 che ho deciso di sincronizzare. Mi è apparsa la schermata “Tentativo di accesso per conto dell’utente” e sono riuscito a loggarmi senza difficoltà.

Figura 16: Accesso dal portale login.microsoftonline.com

Figura 17: Tentativo di accesso per conto dell’utente

Figura 18: Accesso effettuato

Alta disponibilità dell’autenticazione Pass-through di Azure AD

Sicuramente avere un solo server per l’autenticazione di Azure AD rappresenta un single point of failure. Di Di default il primo connettore dell’autenticazione Pass-through viene installato nel server dove avete installato Azure AD Connect. Per distribuire un secondo connettore in un altro server per garantire disponibilità elevata e bilanciamento del carico delle richieste di autenticazione basta scaricare l’Azure AD Application Proxy Connector sul server desiderato, come mostrato in figura:

Figura 19: Download dell’Azure AD Application Proxy Connector

Una volta scaricato Azure AD Application Proxy Connector eseguite un prompt di PowerShell con privilegi amministrativi ed eseguite il comando:

AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR="false" /q

Successivamente è necessario registrare il connettore con Azure AD per l’autenticazione Pass-through con la seguente procedura:

1. Aprire una finestra di PowerShell come amministratore
   
2. Passare a C:\Programmi\Microsoft AAD App Proxy Connector ed eseguire lo script
   .\RegisterConnector.ps1 -modulePath “C:\Program Files\Microsoft AAD App Proxy Connector\Modules\” -moduleName “AppProxyPSModule” -Feature PassthroughAuthentication
   
3. Inserire le credenziali del proprio account amministratore del Tenant Azure AD.
   

Figura 20: Configurazione di Azure AD Application Proxy Connector sul secondo server

Conclusioni

L’Autenticazione Pass-through di Azure AD semplifica enormemente gli scenari di autenticazione degli utenti, dando la possibilità di evitare che le password vengano sincronizzate con il Cloud e l’autenticazione degli utenti continui ad essere gestita tramite i Domain Controller locali.