Windows Server 2003 migrazione a Windows Server 2012

L’avvicinarsi della data di fine supporto per il vecchio glorioso Windows Server 2003 sta portando ad un’impennata di richieste di supporto.
Repliche non replicate, DNS non funzionanti, Server e Client orfani… di tutto di più.

Spesso il problema vero alla base di molti errori è la gestione del tempo.
– Tempo per leggere la documentazione prima di avventurarsi in una migrazione (poi non troppo difficile);
– Tempo per lasciare eseguire la replica completa dell’Active Directory (come se lasciare il vecchio server acceso per altri quindici minuti fosse un peso);
– Tempo di verificare che tutto abbia funzionato a dovere (prima di formattare il vecchio disco).

Cercherò di dare alcune indicazioni di massima, senza scendere troppo nei particolari tecnici su come effettuare le varie attività.
Sarebbe inutile ed impossibile andare ad analizzare ogni possibile inconveniente. Sono molteplici i parametri che entrano in gioco.

Quello che vorrei trasmettere è una metodica di analisi che può essere applicata in molte situazioni.

Descrizione infrastruttura
L’articolo si basa su un dominio in ambiente Microsoft Windows Server 2003 Standard Edition che sarà migrato ad un dominio basato su Microsoft Windows Server 2012 R2 Datacenter. Durante tutte le fasi sono stati utilizzati i valori di default proposti.

Dominio: testerlab.local

Domain Controller 2003
Nome Computer: DC-01
IPv4: 192.168.1.236
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.236/237

Domain Controller 2012 R2
Nome Computer: DC-02
IPv4: 192.168.1.237
IPv6: ottieni indirizzo automaticamente
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.236/237

Step-by-Step
Le attività da eseguire per effettuare una migrazione devono iniziare con l’analisi dettagliata dell’infrastruttura esistente e con l’analisi sullo stato di salute della stessa (oltre che dei prerequisiti).

– Analisi dei prerequisiti
– Analisi infrastruttura esistente
– Analisi dello stato dell’infrastruttura
– Backup, Backup ed ancora Backup
– Preparazione della foresta e del dominio esistente
– Aggiunta del nuovo Controller di dominio
– Verifica post installazione Server e Client
– Migrazione dei ruoli FSMO
– Migrazione dei servizi
– Verifica post installazione Server e Client
– Eliminazione vecchio Controller di dominio
– Verifica post installazione Server e Client

Analisi dei prerequisiti
Requisiti di sistema e informazioni sull’installazione per Windows Server 2012 R2.

Analisi infrastruttura esistente
Verificare attraverso gli strumenti di gestione quanti e quali server sono presenti nell’infrastruttura.

Analisi dello stato dell’infrastruttura
Può capitare di avere dei problemi latenti, spesso dovuti a problemi di configurazione, di cui non siamo attenzionati. Vuoi perché non abbiamo controllato a dovere lo stato dei server, vuoi per una dimenticanza, capita di scoprire (o riscoprire) problemi all’atto di effettuare qualche attività particolare.
Prima di iniziare una migrazione è essenziale essere sicuri che tutto funzioni alla perfezione. Se qualche problema è presente è assolutamente necessario risolverlo prima di iniziare qualsiasi ulteriore attività. Altrimenti il risultato potrebbe portarci un punto di non ritorno…

– Riavviare i server per essere sicuri di non avere delle segnalazioni in avvio;
– Analizzare gli eventi di sistema alla ricerca di errori e/o segnalazioni;
– Se nell’infrastruttura sono presenti più server ed in particolare più Domain Controller, eseguire netdom /query fsmo per verificare chi detiene i ruoli FSMO;
– Eseguire ed analizzare il risultato di un dcdiag;
– Verificare attraverso un ipconfig /all che gli unici DNS presenti siano quelli di riferimento a Domain Controller. IP pubblici e di Loopback vanno eliminati;
– Verificare la presenza delle share di sistema Sysvol e Netlogon attraverso il comando net share. Questa verifica va effettuata su ogni Domain Controller;
– Se nell’infrastruttura sono presenti più Domain Controller controllare lo stato delle repliche attraverso il comando dcdiag /test:replications;
– In caso di errori dovuti a problemi di connettività eseguire il comando dcdiag /test:DNS per un ulteriore verifica.

Per poter eseguire la migrazione, è necessario che i livelli di funzionalità della foresta e del dominio siano almeno alla versione 2003. In caso contrario si dovrà provvedere all’aumento del livello.
La verifica può essere effettuata attraverso “Domini e trust di Active Directory”.

Immagine_001a

Livello funzionalità dominio

Immagine_002a

Livello funzionalità foresta

Backup, Backup ed ancora Backup
Cosa aggiungere se non che è necessario avere sempre un backup verificato. Fidarsi è bene non fidarsi è meglio.

Preparazione della foresta e del dominio esistente
Durante la fase di aggiunta del primo Domain Controller 2012 R2 verranno automaticamente aggiornate le strutture della foresta e del dominio. Non è quindi necessario eseguire, come per le versioni precedenti, il forestprep ed il domainprep.

Aggiunta del nuovo Controller di dominio
Eseguire il join al dominio e dopo il riavvio eseguire Server Manager per l’aggiunta “Servizi di dominio Active Directory”.
Immagine_004
Immagine_006
Immagine_007
Immagine_009

Verifica post installazione Server e Client
Dopo il riavvio del nuovo Domain Controller modificare i parametri di rete per impostare esclusivamente il suo IP quale server DNS.

– Analizzare gli eventi di sistema alla ricerca di errori e/o segnalazioni;
– Eseguire ed analizzare il risultato di un dcdiag;
– Verificare la presenza delle share di sistema Sysvol e Netlogon attraverso il comando net share;
– Controllare lo stato delle repliche attraverso il comando dcdiag /test:replications;
– In caso di errori dovuti a problemi di connettività eseguire il comando dcdiag /test:DNS per un ulteriore verifica.

Migrazione dei ruoli FSMO
Nell’esempio tutti i ruoli FSMO sono detenuti dal server 2003.

Immagine_012

Windows Server 2003 ruoli FSMO

Per la migrazione sul nuovo server 2012 R2 utilizzerò un comodo CmdLet PowerShell.
Move-ADDirectoryServerOperationMasterRole -Identity “DC-02″ -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator
Immagine_010

Ovviamente il comando netdom /query fsmo ci darà conferma dell’avvenuto trasferimento.

Immagine_011

Windows Server 2012 ruoli FSMO

Migrazione dei servizi
Migrare tutti i servizi ed i programmi eseguiti sul server 2003 sul nuovo server 2012 R2 o su un qualsiasi altro server presente nell’infrastruttura.

Verifica post installazione Server e Client
Dopo la migrazione dei ruoli FSMO e dei servizi è consigliabile effettuare nuovamente una verifica. In questo caso possiamo limitarci al nuovo server 2012 R2.

– Analizzare gli eventi di sistema alla ricerca di errori e/o segnalazioni;
– Eseguire ed analizzare il risultato di un dcdiag;
– Verificare la presenza delle share di sistema Sysvol e Netlogon attraverso il comando net share;
– Controllare lo stato delle repliche attraverso il comando dcdiag /test:replications;
– In caso di errori dovuti a problemi di connettività eseguire il comando dcdiag /test:DNS per un ulteriore verifica.

Eliminazione vecchio Controller di dominio
Prima di eseguire il dcpromo per abbassare il livello di funzionalità a server membro del Domain Controller 2003 impostare come unico server DNS l’IP del Domain Controller 2012 R2.

Attraverso “Siti e servizi di Active Directory” togliere la spunta di Global Catalog ed iniziare il declassamento con il classico dcpromo.

Immagine_003
Immagine_005
Immagine_007
Immagine_009
Immagine_010

Concludo con la raccomandazione iniziale. Non abbiate fretta di spegnere il vecchio server, prendetevi il giusto tempo per effettuare tutti i controlli necessari.

Buona migrazione a tutti…

Approfondimenti
Move-ADDirectoryServerOperationMasterRole

Exchange 2013 Attivazione Certificato SSL SAN

Nel precedente articolo “Exchange 2013 Richiesta Certificato SSL SAN” abbiamo visto come eseguire la richiesta di un Certificato Digitale per Exchange. In particolare abbiamo visto come generare e personalizzare la richiesta per un Certificato Digitale SAN (Subject Alternative Names) da inviare ad una CA pubblica.

In questo secondo articolo vedremo come importare ed applicare il Certificato Digitale acquistato.

Ringraziamenti
Jason Parms di SSL2BUY Inc. che mi ha fornito un Certificato UCC SLL Comodo per Exchange Server 2013.

Comodo SSL

Importazione Certificato
Collegarsi all’Exchange Administrative Center attraverso adeguate credenziali (Durante le varie fasi di questo articolo sarà utilizzata l’utenza di sistema TESTERLAB\Administrator).
Nel menu verticale selezionare “server” e successivamente dal menu orizzontale selezionare l’opzione “certificati”.
Immagine_001

Come si può vedere dalla screen successiva lo stato del certificato è “Richiesta in sospeso”.
Immagine_021

Premere il link “Completa” per iniziare la procedura guidata di importazione.
Indicare il percorso contenente il certificato e premere il pulsante “Ok”
Immagine_001
Immagine_003

Lo stato del certificato passera a “Valido” e potrà essere assegnato ai servizi.
Immagine_004

Dopo aver selezionato il certificato premere il pulsante “modifica”. Le informazioni relative al certificato sono visibili nelle successive screen.
Immagine_005a
Immagine_005b

Assegnazione Certificato
Passare alla pagina “Servizi” per assegnare i servizi al certificato e premere il pulsante “Salva” per confermare.
Immagine_006
Immagine_007

Adesso siamo pronti per utilizzare il Certificato Digitale SAN e vedere il lucchetto chiuso…

Exchange 2013 Richiesta Certificato SSL SAN

Ci pensavo da molto tempo, ma non avevo mai avuto l’occasione per cercare un partner con il quale sviluppare questo articolo.

Una semplice guida passo passo per l’implementazione di un certificato SSL con Exchange 2013.
Quindi… come al solito… ho deciso di produrre un documento che spero possa essere utile a chi, come me, non ha molte occasioni di giocherellare con Exchange.

Ringraziamenti
Roberto Ferazzi MVP Exchange Server e fondatore di MSExchange.Community che mi ha aiutato nella ricerca di un valido distributore per il certificato SSL.

Jason Parms di SSL2BUY Inc. che mi ha fornito un Certificato UCC SLL Comodo per Exchange Server 2013.

Comodo SSL

Infrastruttura
L’articolo si basa su una installazione di dominio in ambiente Microsoft Windows Server 2012 R2 Datacenter e Microsoft Exchange 2013 SP1 Standard Edition. Durante tutte le fasi sono stati utilizzati i valori di default proposti.

Dominio privato: testerlab.local
Dominio pubblico: testerlab.it

Domain Controller
Nome Computer: DC-01
IPv4: 192.168.1.236
IPv6: ottieni indirizzo automaticamente
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.236

Server Exchange
Nome Computer: EXH-01
IPv4: 192.168.1.237
IPv6: ottieni indirizzo automaticamente
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.236

Molte delle infrastrutture esistenti (in particolare di piccole dimensioni) utilizzano un dominio Active Directory privato il cui suffisso è quasi sempre .local ed un dominio pubblico .it o .com per i servizi mail e web.
Negli ultimi tempi si è vista una inversione di tendenza e si è passati ad utilizzare un unico dominio. Quello pubblico. Questo modus operandi per alcuni versi semplifica alcuni aspetti ma per altri impone una maggiore attenzione alla progettazione.

Il meccanismo di puntare dall’interno del dominio a risorse esterne attraverso il DNS locale è conosciuto come Split DNS.

L’articolo non tratta l’installazione e la configurazione del Server Exchange. Si presume che l’infrastruttura sia pronta e che siano stati configurati tutti i servizi necessari.
Configurazione DNS
Basandoci su una infrastruttura con due domini (.local e .it) dovremo aggiungere al nostro DNS interno una nuova zona. All’esterno del perimetro aziendale ci penseranno i Server DNS pubblici a fornire il corretto indirizzamento al Server Exchange.

Zona di ricerca diretta: testerlab.it
Record A mail 192.168.1.237
Record A autodiscover 192.168.1.237
Immagine_000

Durante la fase di installazione di Exchange vengono prodotti alcuni certificati. Questi certificati sono conosciuti come Self-Signed.  Per operare correttamente i certificati Self-Signed devono essere sostituiti con un certificato SSL prodotto da un ente certificatore qualificato (CA). In particolare si utilizza un certificato che ingloba all’interno una serie di domini alternativi a quello principale. Questo tipo di certificati vengono definiti SAN  (Subject Alternative Names) oppure UC (Unified Communications).

L’implementazione di un certificato SSL si distingue in tre fasi distinte:
Richiesta
Emissione
Installazione

Richiesta Certificato
Collegarsi all’Exchange Administrative Center attraverso adeguate credenziali (Durante le varie fasi di questo articolo sarà utilizzata l’utenza di sistema TESTERLAB\Administrator).
Nel menu verticale selezionare “server” e successivamente dal menu orizzontale selezionare l’opzione “certificati”.
Immagine_001

Nelle tre successive screen sono visibili i certificati Self-Signed prodotti durante la fase di installazione di Exchange.
Immagine_003a
Immagine_003b
Immagine_003c

Iniziare la procedura guidata per la creazione della richiesta di un nuovo certificato premendo il pulsante “aggiungi” (+).
Immagine_005

Indicare un nome descrittivo per il certificato SSL. Saltiamo la maschera successiva in quanto non siamo interessati all’emissione di un certificato jolly (*).
Immagine_006
Immagine_007

Selezionare il server sul quale vogliamo archiviare la richiesta e successivamente selezionare i domini che devono essere contenuti nel certificato.
Immagine_008b
Immagine_009

Nel nostro esempio utilizzeremo i seguenti domini:
testerlab.it
mail.testerlab.it
autodiscover.testerlab.it

Immagine_010
Immagine_011
Immagine_012
Immagine_013
Immagine_014
Immagine_015

Eliminare tutte le voci di dominio che non devono essere contenute nel certificato. In particolare vorrei ricordare che non è possibile emettere certificati SSL con domini privati (.local).
Immagine_017a
Immagine_017b

Compilare i campi con le informazioni relative alla società richiedente e memorizzare il file della richiesta (.req) in una share di rete.
Immagine_018
Immagine_019

La richiesta di emissione del certificato verrà inserita insieme agli altri certificati in attesa di essere completata. Come si può vedere dalla seguente screen lo stato è “Richiesta in sospeso”.
Immagine_021

Di seguito il contenuto del file prodotto dalla precedente procedura di richiesta di emissione del certificato SSL.
Immagine_020

La fase di emissione dipende dall’interfaccia utilizzata dalla CA o dal rivenditore. Per grandi linee si dovrà inviare il file di richiesta generato dal Server oppure compilare un form on-line indicando i parametri precedentemente indicati nel seguente articolo.

Nel prossimo articolo vedremo come importare ed installare il certificato ricevuto dalla CA.

Approfondimenti
Digital certificates and SSL

Windows Server 2012 R2 creazione dominio

I passi per creare un nuovo dominio Active Directory sono semplici, ma necessitano di metodica per non rischiare di ritrovarsi con problemi, che molto spesso si evidenziano a distanza di tempo.

Questo breve articolo non ha certo lo scopo di approfondire gli aspetti tecnici che stanno alla base di un dominio Active Directory. Lo scopo è semplicemente quello di dare delle indicazioni passo passo o step by step per chi ama i termini inglesi. Di fornire dei consigli pratici e di evidenziare alcuni aspetti che spesso sono sottovalutati.

Dati infrastruttura
L’articolo si basa su una installazione Workgroup di Windows Server 2012 R2 Standard Edition. Durante tutte le fasi sono stati utilizzati i valori di default proposti.

Gruppo di lavoro: workgroup
Nome Computer: DC-01
IPv4: 192.168.1.236
IPv6: ottieni indirizzo automaticamente
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.1

Foreste, alberi e domini
La creazione di un nuovo dominio implica la creazione di un nuova foresta e la creazione di un catalogo globale condiviso.
La ricerca degli oggetti (Account Utente, Account Computer, Domain Controller, etc.), all’interno di Active Directory, avviene attraverso l’utilizzo il servizio di ricerca DNS (Domain Name System).
Molti dei problemi riscontrati durante l’implementazione o l’utilizzo di una infrastruttura di dominio derivano proprio dal cattivo funzionamento del servizio DNS.

Suffisso DNS
Nella versione Windows Server 2003 era possibile implementare un suffisso DNS particolare definito Single Label Domains (SLDs). Purtroppo l’adozione di quella scelta implicava diversi problemi operativi.
Fortunatamente Windows Server 2012 non consente l’implementazione di un nuovo dominio Single Label. E’ comunque possibile aggiungere un controller di dominio ad un dominio Single Label esistente.

Fino ad alcuni anni fa era consuetudine utilizzare un nome dominio privato (es. .local) ed un nome dominio pubblico (es. .it, .com, etc.).
Quindi all’interno di una infrastruttura era facile trovare un dominio privato “testerlab.local” ed un dominio pubblico “testarlab.it“.
Molti dei servizi esposti passavano attraverso la DMZ (Demilitarized Zone) del firewall perimetrale che, spesso, era il confine di applicazione del suffisso di dominio pubblico.

Negli ultimi anni si è vista una inversione di tendenza. Si utilizza sempre più un unico suffisso pubblico (es. testerlab.it) implementando quello che in gergo tecnico si chiama Split DNS. In pratica si aggiungono tutti i record DNS dei servizi erogati esternamente all’infrastruttura di dominio privato (anche se il termine risulta improprio). Un classico esempio è il record www. Nel caso in cui il sito web è ospitato da un provider esterno si punterà all’IP pubblico, viceversa si punterà all’IP privato.

Creazione del dominio
Dalla Dashboard di Server Manager, attraverso la voce di menu “Gestione” selezioniamo l’opzione “Aggiungi ruoli e funzionalità“.
Immagine_001a

Inizia la fase di aggiunta dei ruoli e funzionalità, che come precedentemente accennato avviene in maniera tale da avere un numero di riavvii del server inferiore rispetto al passato.
Immagine_002
Immagine_003

Il ruolo necessario per la creazione di un nuovo dominio o per l’aggiunta di un ulteriore Domain Controller è Servizi di dominio Active Directory.
Immagine_004

In maniera assolutamente trasparente verranno selezionate le funzionalità aggiuntive necessarie all’installazione del ruolo prescelto.
Immagine_004a
Immagine_005
Immagine_006
Immagine_007a

E’ possibile esportare le impostazioni di configurazione utilizzate per poterle replicare su ulteriori server.

Una volta avviata l’installazione dei ruoli e funzionalità è possibile chiudere la schermata di riepilogo. Il sistema, attraverso un alert nella Dashboard ci indicherà le fasi successive.
Immagine_008
Immagine_008b
Immagine_009a

Si passa dunque alla fase successiva, ovvero all’innalzamento del livello di funzionalità a Domain Controller. Questa fase, conosciuta dai più come dcpromo, nelle versioni di Sistema Operativo precedenti era eseguita direttamente nella fase iniziale.

Configurazione Servizi Active Directory
Nella prima maschera abbiamo la possibilità di scegliere il tipo di distribuzione necessaria.
Nel nostro caso “Aggiungi una nuova foresta“.

Il nome di dominio prescelto è testerlab.local.
Immagine_010

Nella maschera successiva verrà proposto il livello di funzionalità della foresta e del dominio che, ovviamente, sarà Windows Server 2012 R2.
Da notare che tra le funzionalità del controller di dominio è proposto il Server DNS. Questo servizio è essenziale per il funzionamento di Active Directory ed è quindi indispensabile lasciare la spunta dell’opzione (tranne i casi di utilizzo di un server DNS già esistente).
Digitare la password per la modalità di ripristino per i servizi directory e proseguire.
Immagine_011
Immagine_012

Verificare, ed eventualmente modificare, il nome NetBIOS e proseguire.
Immagine_013

Scegliere la posizione per il database dei servizi Active Directory e proseguire.
Nella maggior parte dei casi le impostazioni di default vanno accettate senza operare alcuna modifica.
Immagine_014

Se i controlli dei prerequisiti sono soddisfatti è possibile installare i servizi di dominio Active Directory.
Immagine_016

Al riavvio nella Dashboard di Server Manager verranno visualizzate le nuove voci dei ruoli e dei servizi appena installati.
Immagine_017a

Fasi successive e verifiche
Una volta installato il servizio di dominio Active Directory è consigliabile eseguire alcuni controlli per evitare di trascinarsi problemi latenti nel tempo.

Configurazione parametri rete
Durante la fase di installazione del dominio Active Directory l’indirizzo DNS primario dell’interfaccia di rete viene sostituito con l’indirizzo di loopback.
Di norma l’indirizzo di loopback andrebbe sostituito con l’indirizzo statico del server (192.168.1.236). Questa prassi trova un’applicazione pratica nei domini multi controller e multi site.

Di seguito le impostazioni di rete nelle varie fasi (si fa riferimento al solo protocollo IPv4):
Configurazione workgroup
IPv4: 192.168.1.236
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.1

Configurazione automatica dominio
IPv4: 192.168.1.236
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 127.0.0.1

Configurazione modificata dominio
IPv4: 192.168.1.236
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.236

Il DNS primario della configurazione iniziale (Workgroup) viene automaticamente utilizzato come IP di inoltro per il servizio DNS (nel nostro esempio 192.168.1.1)
Immagine_020

Se non utilizzata, possiamo escludere dall’ascolto DNS la porta riferita al protocollo IPv6.
Immagine_023

Verificare l’avvenuta creazione delle share di rete Sysvol e Netlogon attraverso il comando net share.
Immagine_022

Eseguire il comando dcdiag per una verifica completa del dominio Active Directory.

Eventuali errori e disfunzioni possono presentarsi quando le risorse hardware non sono sufficienti o le prestazioni non sono in grado di garantire le performance adeguate all’esecuzione dei servizi.

Approfondimenti
Active Directory
Domain Name System
Dcdiag

Veeam Backup & Replication: Installazione

L’implementazione di una soluzione di backup all’interno di un ambiente virtualizzato o di un datacenter non è semplice.

Molteplici sono i fattori da tenere in considerazione:
– Hypervisor
– Distribuzione dei site
– Numero dei nodi
– Costi

Una delle soluzioni più importanti presenti sul mercato è sicuramente Veeam Backup & Replication.

Disponibile per ambiente VMWare ed Hyper-V, Veeam Backup & Replication permette di gestire con relativa semplicità il backup ed il restore delle macchine virtuali.

In questa prima parte vedremo come effettuare l’installazione del programma partendo dalla versione gratuita (avete capito bene). Infatti è disponibile la versione Veeam Backup Free Edition che permette alle piccole aziende di gestire a costo zero e con un’interfaccia semplice ed intuitiva i backup delle macchine virtuali. Per passare alla versione completa basta acquistare il codice di licenza appropriato senza la necessità di dover reinstallare niente.
Volendo, cosi come vedremo di seguito, è possibile richiedere una chiave di licenza con validità trenta giorni. Questo ci permetterà di valutare e di verificare fin da subito tutte le funzionalità offerte dalla versione completa.

Il download è disponibile sul sito http://www.veeam.com/it
Per eseguire il download, essendo il prodotto destinato ad un utilizzo professionale, è necessario effettuare una registrazione utilizzando una mail aziendale valida.
veeam_menu

Dati Infrastruttura
L’infrastruttura di test è composta da un Host Hyper-v basato su Windows Server 2012 Datacenter.

Nome Computer Host: HOSTHV
Installazione

Dopo aver eseguito il download ed estratto il contenuto della ISO in una cartella temporanea (o montato), avviamo l’installazione eseguendo il classico Setup.exe
Dal menu principale selezioniamo la relativa opzione di installazione e proseguiamo accettando i termini di licenza.
Immagine_001
Immagine_002
Immagine_003

Per la versione Veeam Backup Free Edition non è necessario inserire nessuna chiave di licenza, quindi proseguiamo con l’installazione.
Immagine_004

Consiglio di includere PowerShell SDK che di default non è selezionato.
Immagine_005a

L’installazione proseguirà con la verifica dei prerequisiti di sistema.
Immagine_007

Se i parametri di default vanno bene possiamo confermare l’installazione (le screen si riferiscono ad una installazione con parametri di default).
Immagine_008
Immagine_009
Immagine_010
Immagine_011
Immagine_012
Immagine_013

Pronti per partire
Immagine_014

L’installazione della licenza (acquistata o di valutazione) avviene in maniera molto semplice.
Nella maschera License Information selezionare il pulsante “Install License” e selezionare il file di licenza .lic precedentemente scaricato.
Immagine_002_
Immagine_003_

A questo punto nella maschera License Information avremo il dettaglio della nostra licenza (…temporanea)
Immagine_004_

Approfondimenti
Veeam Backup Free Edition
List of Ports Used by Veeam Backup & Replication

Windows Server 2012 R2 Installazione Server Licenze RDS (Remote Desktop Services)

Dopo aver visto la modalità di distribuzione Avvio rapido di una infrastruttura RDS (Remote Desktop Services), vediamo come attivare il ruolo Servizio Licenze Desktop remoto.

Durante la fase di distribuzione dei ruoli servizi, il sistema ci ricorda che la modalità gestione licenze Desktop remoto non è configurata. In assenza di un server di distribuzione licenze (RDSCAL), o semplicemente di una attivazione delle licenze RDSCAL, il sistema permetterà un accesso illimitato (in termini di User/Device) per un periodo di 120 giorni.
Alla scadenza di tale periodo saranno attive esclusivamente le due sessioni amministrative standard presenti su ogni sistema.

licenza120rds

Attivazione ruolo servizio
Attraverso Server Manager andiamo ad attivare il Servizio Licenze Desktop remoto. Dal Pool di server disponibili selezioniamo quello di destinazione. Nel nostro caso, essendo una modalità di distribuzione “Avvio rapido”, utilizzeremo lo stesso server già utilizzato per i ruoli servizi precedenti, RDS-01.
Immagine_012
Immagine_013
Immagine_015

Come si può vedere dalla screen successiva, il Servizio Licenze Desktop remoto risulta attivato.
Immagine_016
Selezionando l’opzione “Panoramica” (Vedi screen precedente), attraverso il menu a tendina “ATTIVITÀ” > “Modifica proprietà distribuzione” possiamo selezionare la tipologia di licenza utilizzata (User/Device) e l’ordine di ricerca server licenze Desktop remoto.
Immagine_018

Dopo aver installato ed attivato il Servizio Licenze Desktop remoto dobbiamo eseguire i seguenti passi:

  • Configurare il Server Licenze
  • Attivare il Server Licenze
  • Attivale  la licenza RDSCAL

 

Configurazione Server Licenze
Da Strumenti Amministrazione eseguire Gestione licenze Desktop remoto.
Lo stato di attivazione, ovviamente, sarà in “non attivato” e lo stato della configurazione sarà in “Controllo”.
Immagine_019

La prima attività che dovremo eseguire è quella di rendere il server membro del gruppo Server licenze.

Attraverso il link “Controllo” iniziamo la procedura di configurazione. Premere il pulsante “Aggiungi al gruppo” e confermare.
Immagine_020
Immagine_020a
Immagine_020b
Immagine_021

Al termine dell’attività lo stato della configurazione passerà ad “Ok”
Immagine_022

Attivazione Server Licenze
Prima di poter rilasciare le licenze RDSCAL il server deve essere attivato presso Microsoft. Tutti i server licenze e tutte le licenze devono essere attivate presso Microsoft, questa procedura serve a tutelare sia il Cliente finale sia la stessa Microsoft da tentativi di frode.
In alcuni casi particolari e/o per le riattivazioni e/o per i trasferimenti dei server licenze è necessario telefonare al supporto Microsoft dedicato a questo tipo di attività.

Selezioniamo il server che vogliamo attivare e premiamo il tasto destro del mouse, dal menu scegliamo l’opzione “Attiva server”.
Immagine_023

Seguiamo le indicazioni compilando i campi richiesti. Per utilizzare l’opzione di connessione automatica è utilizzata una connessione SSL, di conseguenza la relativa porta dovrà essere aperta verso l’esterno.
Immagine_025
Immagine_026
Immagine_027
Immagine_028

Attivazione Licenza
Al termine dell’attivazione del server licenze è possibile avviare automaticamente l’attivazione delle licenze (Vedi flag Avvia Installazione guidata licenze nella screen precedente).
Selezionare il programma di licenze idoneo a quanto acquistato e premere il pulsante “Avanti”. Inserire il codice licenza e premere i pulsanti “Aggiungi” ed “Avanti”.
Al termine dell’elaborazione una schermata conclusiva ci darà il riepilogo delle licenze appena installate.
Immagine_029
Immagine_030
Immagine_031
Immagine_032

Come si può vedere dalla screen successiva lo stato di attivazione del server è passata ad “Attivati” e sul nome del server è apparsa la spunta verde.
Immagine_033

Una ulteriore verifica dell’attività svolta la possiamo effettuare attraverso lo Strumento Diagnosi Servizio licenze Desktop remoto.
Immagine_034

A questo punto non ci rimane che distribuire le ns. licenze RDSCAL…

Windows Server 2012 R2 Installazione RDS (Remote Desktop Services)

Ho deciso di realizzare questo articolo perché l’utilizzo delle sessioni remote, anche in ambiente PMI, è sempre più utilizzato.

Da un lato troviamo le grandi aziende che stanno spostando parte del loro Datacenter sul Cloud.
Dall’altro troviamo le piccole aziende, che vorrebbero utilizzare le funzionalità di virtualizzazione ma spesso non hanno le risorse economiche o tecniche per fare il grande salto.

Come spesso succede (forse) nel mezzo troviamo la soluzione (..o verità). In questo caso la soluzione si chiama RDS (Remote Desktop Services).

Ho volutamente introdotto il termine virtualizzazione perché, come vedremo più avanti, la virtualizzazione potrebbe essere necessaria per poter distribuire una soluzione RDS.

La distribuzione dei ruoli servizi RDS può avvenire in due modalità.

  • Distribuzione standard: Una distribuzione standard consente di distribuire Servizi Desktop remoto in più server
  • Avvio rapido: Un avvio rapido consente di distribuire Servizi Desktop remoto in un server, nonché di creare un insieme e pubblicare programmi RemoteApp

Tutte e due le modalità di distribuzione prevedono la presenza nell’infrastruttura di uno o più server di dominio (DC). Quindi, la dicitura “in un server” contenuta nella descrizione della modalità “Avvio rapido” non deve trarre in inganno. L’interpretazione corretta è che in un server si installano tutti i ruoli servizi RDS, ma i server necessari sono almeno due.

Ecco che ci viene in aiuto la virtualizzazione…

Parlando di piccole aziende, è quasi automatico parlare di licenze “Standard”. Quasi sempre “OEM”.

  • La versione Standard di Windows Server 2012 R2 include due licenze virtuali (1)(2)
  • La versione Datacenter di Windows Server 2012 R2 include illimitate licenze virtuali (1)(2)
  1. Sull’Host deve essere installato esclusivamente il ruolo Hyper-V
  2. Le licenze virtuali devono essere utilizzate esclusivamente sullo stesso server su cui è in uso la licenza fisica

Ovviamente per una soluzione altamente performante e scalabile utilizzeremo la modalità di distribuzione standard, mentre per una soluzione base utilizzeremo la distribuzione rapida.

Dati Infrastruttura
Per eseguire l’attività di distribuzione rapida descritta in questo articolo, verrà utilizzata una infrastruttura Hyper-V basata su Host Windows Server 2012 R2 Datacenter. Di seguito i parametri utilizzati durante la fase di installazione del Sistema Operativo, la creazione del dominio e l’installazione dei ruoli servizi RDS. Durante tutte le fasi sono stati utilizzati i valori di default proposti.

Dominio: testerlab.local
Nome Computer: DC-01
Indirizzo IP: 192.168.1.236
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.236

Nome Computer: RDS-01
Indirizzo IP: 192.168.1.237
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.236

Infrastruttura RDS

Installazione ruoli servizi RDS
Da Server Manager, attraverso la voce di menu “Gestione” > “Aggiungi ruoli e funzionalità” iniziamo la fase di installazione dei ruoli servizi RDS.
Immagine_001

Selezioniamo l’opzione “Installazione di Servizi Desktop remoto” e nella successiva maschera “Avvio rapido”.
Immagine_002
Immagine_003b

Dobbiamo quindi selezionare la voce “Distribuzione di desktop basati su sessioni”. (La voce “Distribuzione desktop basati su macchine virtuali” si riferisce alla soluzione conosciuta come VDI – Virtualization Desktop Infrastructure).
Immagine_004
Immagine_005
Immagine_006
Immagine_009

Al termine dell’installazione, all’interno di Server Manager troveremo i servizi appena installati in grigio mentre quelli ancora da installare in verde.
Immagine_010

L’infrastruttura RDS, anche se con alcune limitazioni, è già funzionante per essere testata.

Per consentire l’accesso alle risorse e pubblicare RemoteApp sono necessari ulteriori step che non sono inclusi in questo articolo.

In particolare una delle attività da eseguire è quella di installare il ruolo Servizio Licenze Desktop remoto. Senza l’installazione delle RDSCAL (ovvero le licenze che permettono l’accesso al servizio), l’infrastruttura funzionerà, senza nessun limite di accessi, per 120 giorni.

Vedremo in un successivo articolo come attivare il ruolo servizio e come installare la licenza RDSCAL
licenza120rds

Approfondimenti
Tutte le attività svolte attraverso l’interfaccia grafica di Server Manager è possibile svolgerle attraverso CmdLet PowerShell.
Remote Desktop Cmdlets in Windows PowerShell

Hyper-V USB RDX Quikstor Pass Through

L’utilizzo di dischi fisici direttamente connessi ad una Macchina Virtuale è molto utilizzata in ambienti Enterprise dove si utilizzano LUN Storage dedicati.

La modalità operativa per l’utilizzo dei dischi fisici da parte della Macchina Virtuale si chiama Pass Through. Nello specifico di dischi USB viene definito USB Pass Through.

In questo articolo vedremo la configurazione e l’utilizzo dell’USB Pass Through utilizzando una unità Tandberg Data RDX Quikstor nella versione USB 3+.

Dati Infrastruttura
L’infrastruttura di test è composta da un Host Hyper-v basato su Windows Server 2012 Datacenter. E’ possibile utilizzare la stessa configurazione in ambiente Hyper-V 8 ed 8.1.

Nome Computer Host: HOSTHV
Nome Macchina Virtuale: WS2012R2

L’utilizzo di un disco Pass Through impone l’accesso esclusivo da parte della Macchina Virtuale. Per poter ottenere tale condizione dobbiamo porre a livello Host il disco nello stato di offline.

Per eseguire questa attività possiamo utilizzare la modalità GUI attraverso Server Manager.
disco_online
Selezionare il disco da portare in offline e premere il tasto destro del mouse, nel menu contestuale che si attiverà selezionare “Porta offline”.
disco_offline

Per gli amanti della Command Line è disponibile il comando Diskpart.

DISKPART> List Disk
DISKPART> Sele Disk n (dove n rappresenta il disco ce vogliamo mettere offline)
DISKPART> Offline Disk (porta il disco in offline) [Online Disk (porta il disco in online)]
DISKPART> Exit

Nella seguente screen è visibile la configurazione iniziale della Macchina Virtuale.
2 - Initial Settings

All’interno di una Macchina Virtuale, i dischi (virtuali e fisici) vengono gestiti come una normale catena SCSI “Bus” > “LUN” > “Destinazione”
Nel caso specifico dell’unità USB RDX Quikstor i parametri, visibili nella scheda impostazioni della Macchina Virtuale, sono:
Bus 3
Lun 0
Destinazione 0
configurazione_rdx

L’utilizzo della destinazione corretta è essenziale per il funzionamento della Macchina Virtuale.
Aggiungendo l’USB RDX Quikstor come disco aggiuntivo al controller SCSI di default, verrà inserito nella prima posizione libera (nel nostro esempio 1).
4 - Impostazioni RDX default
Attenzione questa configurazione non permetterà l’avvio della Macchina Virtuale

Il sistema tenterà inutilmente di avviare la Macchina Virtuale. Traccia di questo tentativo di avvio lo troviamo negli eventi di sistema. Infatti verranno registrati una serie di eventi che (purtroppo) non sono troppo indicativi per la risoluzione del problema.

Eventi Sistema:
Informazioni Hyper-V-VmSwitch 102 (1019)
Networking driver in WS2012R2 is loaded and the protocol version is negotiated to the most recent version (Virtual machine ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX).

Informazioni storvsp 7 Nessuna
The storage device in ‘WS2012R2′ is loaded and the protocol version is negotiated to the most recent version (Virtual machine ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)

Eventi Hyper-V-Worker:
Informazioni Hyper-V-Worker 18500 Nessuna
Macchina virtuale ‘WS2012R2′ avviata. (ID macchina virtuale XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)

Informazioni Hyper-V-Worker 23020 Nessuna
Il dispositivo ‘Microsoft Synthetic Display Controller’ nella macchina virtuale ‘WS2012R2′ è caricato e per il protocollo è stata negoziata e ottenuta la versione più recente. ID macchina virtuale: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

Critico Hyper-V-Worker 18560 Nessuna
La macchina virtuale ‘WS2012R2′ è stata reimpostata a causa di un errore irreversibile in un processore virtuale, che ha causato un errore triplo. Se il problema persiste, contattare il supporto tecnico. (ID macchina virtuale)

Una possibile soluzione per aggirare l’ostacolo è quello di modificare l’ordine di destinazione tra disco virtuale e disco fisico. La soluzione migliore è comunque quella di aggiungere un secondo controller SCSI dedicato al nostro disco fisico.
Nella configurazione personalizzata dovremo utilizzare la posizione 0.
4 - Impostazioni RDX custom

Questo tipo di soluzione potrà essere utilizzata per l’esecuzione di backup nativi all’interno della macchina virtuale utilizzando Windows Backup o per il trasferimento di dati off-site.

Approfondimenti:
Overview of LUN Types
Una descrizione dell’utilità della riga di comando Diskpart

Tandberg Data RDX Quikstor, la nuova concezione del backup

Il backup è sicuramente uno dei temi che giornalmente fanno discutere milioni di persone nel mondo.

Da un lato ci sono gli utilizzatori finali, il singolo utente che non vuole perdere le foto di famiglia, il professionista o la piccola azienda che voglio conservare i dati aziendali, la grande azienda attratta dalle potenzialità offerte dai nuovi servizi offerti dal Cloud.
Dall’altro lato ci sono le aziende che propongono nuove soluzioni, magari migliorate rispetto al passato, in termini di sicurezza, performance e costo di acquisto e mantenimento.

Con Tandberg Data RDX Quikstor è cambiata la concezione del backup

L’utilizzo di una cartuccia disco al posto di una a nastro ha rivoluzionato il modo di lavorare per moltissime aziende.

Finestre di backup ed RTO (Recovery Time Objective) ridotti, basso TCO (Total Cost of Ownership) ed applicazione delle normative di sicurezza sono solo alcuni dei punti di forza del Tandberg Data RDX Quikstor.

Come si può vedere dall’immagine precedente, l’RDX Quikstor si presenta con le sembianze di una classica unità tape.
Questa è una delle peculiarità che fanno dell’RDX Quikstor uno strumento utilissimo. Sempre più aziende stanno spostando il backup su storage, ma in molti (fortunatamente e saggiamente) continuano a gestire una copia off-site. La classica struttura di rotazione Nonno-Padre-Figlio continua ad essere utilizzata.

Con l’integrazione dell’ambiente Microsoft Windows Server è possibile effettuare i backup in maniera nativa senza l’ausilio di software di terze parti. Un enorme vantaggio economico per le PMI.

L’ultima versione di firmware permette un utilizzo differenziato dell’RDX. Infatti, Windows Backup non consente l’utilizzo di unità removibili.

Ringrazio Paolo Rossi, Channel Sales Manager Italia, che mi ha fornito un’unità di test con la quale cercherò, in una serie di articoli, di illustrare alcuni aspetti tecnici e di utilizzo pratico dell’RDX Quikstor.

Attraverso l’RDX Utility, disponibile sul sito Tandberg Data, è possibile eseguire una serie di attività quali l’aggiornamento del firmware, la diagnostica ed il cambio della modalità operativa.
rdxutility_001

rdxutility_002

Modalità Fixed Disk
Questa è la modalità operativa che permette l’accesso diretto da parte di Windows Backup
Fixed Disk

Modalità Removable
Questa è anche la modalità operativa utilizzata per l’accesso attraverso software di backup di terze parti.
Tra i marchi supportati troviamo:
Acronis – Backup & Recovery
CA – Arcserve
CommVault – Shimpana
EMC – Retrospect
HP – Data Protector
IBM – Tivoli Storage Manager
Symantec – Backup Exec
Veeam – Backup & Replication
Tandberg Data – AccuGuard
Removable

* La lista di compatibilità completa è disponibile al link  http://www.tandbergdata.com/default/assets/File/PDFs/RDX_Compatibility_Guide.pdf

Buon backup a tutti… ma cosa più importante… buon restore

Active Directory: Repliche e siti (site) parte 2

Nella prima parte avevamo visto la creazione di un sito e tre subnet di connessione.

Testerlab

Testerlab

Vediamo adesso come aggiungere gli ulteriori site e come configurare le repliche andando, eventualmente, a modificare i valori di default che il sistema ci propone.

Creazione sito
Analogamente a quanto già visto creeremo i due nuovi siti, Milano e Roma.

Sito Milano

Sito Roma

Creazione subnet
A seguire creeremo le due subnet, cosi come raffigarate nelle seguenti screen.

Subnet Milano

Subnet Roma

E’ possibile aggiungere nuovi Server in uno specifico sito in qualsiasi momento. Allo stesso modo è possibile spostare un Server in un qualsiasi sito in base alle esigenze infrastrutturali.
Durante la fase di aggiunta di un nuovo Server, in base alla network utilizzata, verrà proposto il sito di appartenenza. Ovviamente quando parlo di Server mi riferisco ad un Controller di dominio (DC).

Trasporto
Nelle proprietà del singolo Server potremo scegliere il tipo di trasporto utilizzato per la replica (SMTP od IP). Nel caso specifico è stato impostato tutto su IP.

trasporto_ip_01

Anche a livello Server possiamo indicare il traporto preferito.
trasporto_ip_02

Di seguito la Directory completa.
directory

Connessioni
Il sistema crea automaticamente delle connessioni di replica dal nome .
Le connessioni vengono generate in base alla topologia fisica. In una infrastruttura semplice come può essere un site-to-site consiglio di lasciare tutto secondo le impostazioni di sistema.

Possiamo comunque rinominare le connessioni esistenti e/o crearne di nuove.

Durante la creazione di una connessione dobbiamo tenere in considerazione la topologia fisica dell’infrastruttura. Se ad esempio il sito AA ed il sito BB non sono direttamente connessi non sarà possibile attivare una connessione tra loro.

Topologia di rete

Topologia di rete

Per creare una nuova connessione, dal menu contestale di NTDS Settings > Nuovo > Connessione. Selezionare il Server di destinazione e premere OK

nuova_connessione_01

nuova_connessione_02

Pianificazione
Possiamo pianificare le repliche attraverso una semplice interfaccia che ci permette, nell’arco delle ventiquattro ore, di scegliere tra quatto valori. Si parte da zero fino ad arrivare a quattro repliche nell’arco di un’ora.

pianificazione

Raccomandazioni
L’unica raccomandazione che posso dare è quella di non avere fretta durante le attività di aggiunta e (soprattutto) di eliminazione di un Domain Controller. Le repliche spesso non sono immediate. L’algoritmo implementato verifica lo stato della linea per evitare blocchi od intasamenti vari.
Quindi prima di spegnere tutto… verificare che la modifica si sia regolarmente propagata.

Approfondimenti e strumenti utili
Active Directory Replication Topology Technical Reference
Repadmin
Active Directory Replication Status Tool, per il cui utilizzo vi segnalo un vecchio articolo

Iscriviti

Ricevi al tuo indirizzo email tutti i nuovi post del sito.