Hyper-V Server 2012 R2: Gestione remota in ambiente Workgroup (Server Manager)

Dopo aver visto la configurazione iniziale di Hyper-V Server 2012 R2 e come gestirlo velocemente attraverso una sessione Desktop Remoto, adesso vedremo come gestirlo remotamente utilizzando Server Manager.

Per ottenere il nostro scopo dobbiamo installare gli Strumenti di amministrazione remota del server per Windows 8 (RSAT), facendo attenzione ad aver  precedentemente installato tutti gli aggiornamenti di Sistema Operativo disponibili.

Essendo un’ambiente in modalità Workgroup è essenziale che il Client riesca a raggiungere il Server attraverso una ricerca DNS. Per ovviare alla mancanza di un Server DNS utilizzeremo il classico file Hosts (%systemroot%\System32\Drivers\Etc) aggiungendoci la seguente stringa: 172.18.18.236 HV2012R2SRV.

File Hosts

File Hosts

Una volta installati gli Strumenti di Amministrazione Remota, dal menu “Gestione” selezioniamo “Aggiungi server” e nella maschera inseriamo il nome del nostro Server Hyper-V (HV2012R2SRV).

aggserver_01

aggserver_02

Ops… errore :)

aggserver_03

In pratica al nostro Client dobbiamo indicare che il Server Hyper-V è Trusted (…di fiducia). Il comando per aggiungere il Server Hyper-V tra i sistemi Trusted ci viene implicitamente indicato nell’errore stesso.

Eseguiamo il CmdLet attraverso una PowerShell con privilegi elevati:
Set-Item wsman:\Localhost\Client\TrustedHosts HV2012R2SRV -Concatenate -Force

Windows PowerShell

Windows PowerShell

A questo punto nella Dashboard verrà aggiunto il Server. In particolare verrà aggiunto un Hyper-V

Server Manager

Server Manager

Server Manager

Server Manager

Le azioni disponibili per il Server appena aggiunto sono visibili nella seguente screen. Si potrà notare che non è presente la voce inerente alla gestione di Hyper-V in quanto il ruolo non è stato ancora installato nel Client.

aggserver_07

Scarica la copia di Strumenti di amministrazione remota del server per Windows 8.

Scarica la copia di Strumenti di amministrazione remota del server per Windows 8.1.

Wsman fornisce l’accesso ai Web Services Management (WS-Management). Ulteriori informazioni sono disponibili nel documento WSMan Provider.

Hyper-V Server 2012 R2: Gestione remota in ambiente Workgroup (Desktop Remoto)

Per chi, come me, vuole sfruttare le potenzialità messe a disposizione dalla virtualizzazione per creare un ambiente di test nasce l’esigenza di doversi (…o volersi) collegare da remoto.

Infatti una delle peculiarità della virtualizzazione è quella di poter avere numerose risorse utilizzando, ad esempio, un singolo Server.

Un’intera infrastruttura Hardware e Software racchiusa in un unico piccolo scatolotto.

Microsoft, ormai da qualche tempo, mette gratuitamente a disposizione un Hypervisor di fascia Enterprise con le stesse funzionalità di quelle presenti nelle versioni del Sistema Operativo GUI o CORE.

Le differenti versioni di licenza delle versioni GUI e CORE (Standard – Datacenter) includono un numero predefinito di istanze virtuali già licenziate mentre le versioni Hypervisor (ovviamente) non includono nessuna istanza virtuale.

Scopo del seguente articolo è quello di indicare come potersi connettersi remotamente ad un Hypervisor Hyper-V Server 2012 R2 in ambiente Workgroup attraverso una sessione Desktop Remoto.

Microsoft Hyper-V Server 2012 R2

Microsoft Hyper-V Server 2012 R2

Dati Infrastruttura

Hypervisor: Microsoft Hyper-V 2012 R2 Server
Gruppo di lavoro: WORKGROUP
Nome Computer: HV2012R2SRV
Indirizzo IP: 172.18.18.236
Subnet Mask: 255.255.255.0
Gateway: 172.18.18.1
DNS: 8.8.8.8 (google.com)
DNS: 8.8.4.4 (google.com)

Client: Microsoft Windows 8.1 Professional
Gruppo di lavoro: WORKGROUP
Nome Computer: PCNINO
Indirizzo IP: 172.18.18.206
Subnet Mask: 255.255.255.0
Gateway: 172.18.18.1
DNS: 8.8.8.8 (google.com)
DNS: 8.8.4.4 (google.com)

La gestione remota può avvenire attraverso Desktop Remoto, PowerShell, Server Manager e la Console di gestione Hyper-V. Per ognuno dei diversi strumenti utilizzati sarà necessario implementare le relative regole firewall lato Server e lato Client.

Desktop Remoto
La soluzione più immediata per amministrare remotamente la console di Hyper-V Server è quella di utilizzare una sessione Desktop Remoto.

Di default il Desktop Remoto è disattivato e lo si attiva attraverso l’opzione 7.

L’abilitazione del servizio configura automaticamente le regole firewall in ingresso per gli ambiti “dominio” e “privato” lasciando bloccate quelle relative all’ambito “pubblico“.

Per verificare le impostazioni firewall, subito dopo aver attivato il Desktop Remoto, eseguiamo il seguente commando PowerShell Get-NetFirewallRule – DisplayGrouop “Desktop Remoto”.

Name                  : RemoteDesktop-UserMode-In-TCP
Name                  : RemoteDesktop-UserMode-In-UDP
Name                  : RemoteDesktop-Shadow-In-TCP
DisplayGroup   : Desktop remoto

Profile               : Public
Enabled            : False

Profile               : Domain, Private
Enabled            : True

Il comando PowerShell Enable-NetFirewallRule -DisplayGroup “Desktop Remoto” ci permetterà di abilitare le regole firewall in ingresso anche per l’ambito “pubblico”.

Name                  : RemoteDesktop-UserMode-In-TCP
Name                  : RemoteDesktop-UserMode-In-UDP
Name                  : RemoteDesktop-Shadow-In-TCP
DisplayGroup   : Desktop remoto

Profile               : Public
Enabled            : True

Profile               : Domain, Private
Enabled            : True

A questo punto siamo possiamo connetterci liberamente per amministrare comodamente la nostra console attraverso una sessione Desktop Remoto.

Desktop Remoto

Desktop Remoto

Ancora due semplici ma importanti indicazioni pratiche: Per eseguire i comandi PowerShell dal prompt di DOS eseguire powershell

PowerShell

PowerShell

Per ritornare al menu di Hyper-V da un prompt di DOS eseguire sconfig.cmd

HV2012R2_4

Scarica la copia di Hyper-V Server 2012 R2

Approfondisci le conoscenze di Hyper-V Server 2012 R2

PowerShell, come districarsi con le lingue…

Capita spesso di leggere articoli tecnici in lingua inglese e di voler applicare le soluzioni trovate sul nostro PC o Server che, nella quasi totalità dei casi, è con un Sistema Operativo in lingua italiana.

Ovviamente, se tutto si basa su attività svolte da interfaccia grafica grossi problemi non se ne incontrano. Altro discorso e se le attività le dobbiamo svolgere da riga di comando. Quello che in inglese si chiama “Remote Desktop” in italiano si traduce in “Desktop Remoto”, semplice ma non è sempre così facile…

Un esempio pratico sono le numerose regole firewall, difficili da trovare nell’interfaccia grafica partendo da quelle in lingua inglese derivanti da una riga di comando.

Windows PowerShell

Windows PowerShell

Per avere un elenco completo delle regole firewall da una PowerShell possiamo utilizzare i comandi Show-NetFirewallRule oppure Get-NetFirewallRule. I due comandi produrranno un elenco piuttosto lungo che consiglio di memorizzare in formato testo per una successiva analisi. es. Get-NetFirewallRule >c:\regole_firewall.txt

Prendiamo ad esempio il comando Get-NetFirewallRule vm-monitoring-icmpv4 il cui output è illustrato nella seguente screen

powershell_02

Una volta ottenuto il risultato possiamo filtrare per gruppo attraverso il parametro -DisplayGroup.

Nel nostro caso andremo a ricercare tutte le regole del gruppo “Monitoraggio macchine virtuali” con il comando Get-NetFirewallRule -DisplayGroup “Monitoraggio macchine virtuali” | format-table Name

powershell_03

Un esempio pratico di utilizzo delle regole firewall da PowerShell è quello di attivare/disattivare le regole su un Hyper-V Server. Un elenco completo dei comandi riguardanti Hyper-V è disponibile sul sito Microsoft nel documento Hyper-V Cmdlets in Windows PowerShell.

Windows Server 2012 – AD Replication Status Tool

L’argomento Replica di Active Directory (Active Directory Replication) è uno di quegli argomenti che prima o poi qualsiasi sistemista deve affrontare. Cultura personale, problema aziendale, semplice attività di manutenzione prima o poi si arriva alla famigerata replica di Active Directory.

Active Directory, cosi come è concepita e strutturata, cioè con un database distribuito, non potrebbe esistere senza un meccanismo di replica che allinei i dati tra i vari server presenti nel dominio. Il cattivo funzionamento delle repliche sono, spesso, alla base dei problemi che giornalmente si possono riscontrare in un dominio. A volte questi problemi sono latenti, magari sottovalutati, in quanto possono presentarsi con eventi strani e poco significativi.

Per capire se la nostra infrastruttura gode di buona salute la prima cosa da fare è quella di analizzare gli eventi e successivamente di eseguire qualche test.

Sono disponibili alcuni tool da riga di comando quali repadmin, dcdiag ed ntdsutil ma per quelle persone che hanno poca dimestichezza con quell’ambinte è disponibile il tool grafico AD Replication Status Tool.

Il tool è disponibile all’indirizzo http://www.microsoft.com/en-us/download/details.aspx?id=30005

Ho voluto fare un raffronto pratico tra i vari tool raffrontando i risultati e verificando la facilità d’uso del tool grafico.

Dati Infrastruttura
Come al solito utilizzo l’infrastruttura formata da due DC/GC con sistema operativo Windows Server 2012.

Dominio: testerlab.local
Nome Computer: DC-01-01 Indirizzo
IP: 172.18.18.236
Subnet Mask: 255.255.255.0
Gateway: 172.18.18.1
DNS: 172.18.18.236
DNS: 172.18.18.237

Nome Computer: DC-02-01
Indirizzo IP: 172.18.18.237
Subnet Mask: 255.255.255.0
Gateway: 172.18.18.1
DNS: 172.18.18.237
DNS: 172.18.18.236

Il primo test prevede l’utilizzo del tool eseguito sul Server DC-01-01 con il Server DC-02-01 acceso.
adreplication_01

Nelle successive screen sono visualizzate le informazioni inerenti la replica tra i due Server
adreplication_02
adreplication_03
adreplication_04

Il secondo test prevede l’utilizzo del tool eseguito sul Server DC-01-01 con il Server DC-02-01 spento.
adreplication_05

Come si può immaginare, essendo il Server di replica spento gli errori vengono subito intercettati e visualizzati dal tool
adreplication_06
adreplication_07
adreplication_08
adreplication_09

Per concludere ho pensato di forzare una replica, ovviamente…. :)
adreplication_10

Direi che AD Replication Status Tool è semplice da utilizzare, veloce ed offre la possibilità di modellare le ricerche con poco sforzo.

Windows Server 2012 – Restricted Group

Le policy di sicurezza aziendali regolano l’accesso degli utenti all’interno dell’infrastruttura, garantendo agli utenti amministratori la manutenzione ordinaria e straordinaria dei client e la possibilità di poter installare applicativi.

Una delle attività richieste ad un amministratore di sistema  è quella di concedere i permessi amministrativi locali agli utenti dello staff tecnico. Per eseguire questa operazione possiamo sfruttare le Restricted Policy.

Per lo scopo creiamo una Unità Organizzativa ad hoc alla quale applicheremo la policy e dentro la quale sposteremo un client di test.

Dati Infrastruttura
Dominio: testerlab.local
Unità Organizzativa: ASSISTENZA-IT
Nome Policy: Policy ASSISTENZA-IT
Nome Computer: CL-W7-01
Nome Utente: utente.assistenza

Dalla Gestione Criteri di gruppo andremo a creare una nuova Unità Organizzativa
grouppolicy_1
grouppolicy_2
grouppolicy_3

Dopo aver creato l’Unità Organizzativa andremo a creare la Policy ad essa collegata.
grouppolicy_4

Nel Gruppo con restrizioni aggiungeremo un gruppo con nome Gruppo Assistenza
grouppolicy_5

All’interno del “Gruppo Assistenza” verrà inserito l’utente di test che fa parte dei Domain Users e che verrà legato al gruppo Administrator locale  quando verrà applicata la Policy
grouppolicy_6

Applichiamo la Policy appena creata connettendoci ad un client con l’utente Administrator ed apriamo una shell DOS con privilegi elevati (Esegui come amministratore).

Il comando per applicare la Policy è gpupdate, mentre il comando gpresult ci permette di verificare le Policy applicate.

grouppolicy_7

Il risultato dopo l’applicazione della Policy è quello di avere un nuovo gruppo all’interno degli Administrator locali, nel nostro caso ASSISTENZA-IT

grouppolicy_8

 

Windows Server 2012 – Metadati Active Directory 2

Dopo aver visto come leggere i metadati di Active Directory, proseguiamo aggiungendo un secondo Domain Controller al nostro dominio.

Per la lettura dei dati utilizzerò nuovamente l’utility ntdsutil dal Prompt dei comandi eseguito con privilegi elevati (esegui come amministratore).

Dati Infrastruttura
Per confrontare i Metadati  presenti in Active Directory riporto tutti i parametri utilizzati durante la fase di installazione del Sistema Operativo e la creazione del dominio all’interno della foresta. Durante tutte le fasi sono stati utilizzati i valori di default proposti.

Dominio: testerlab.local
Nome Computer: DC-01-01
Indirizzo IP: 172.18.18.236
Subnet Mask: 255.255.255.0
Gateway: 172.18.18.1
DNS: 172.18.18.236
DNS: 172.18.18.237

Nome Computer: DC-02-01
Indirizzo IP: 172.18.18.237
Subnet Mask: 255.255.255.0
Gateway: 172.18.18.1
DNS: 172.18.18.237
DNS: 172.18.18.236

Eseguiamo i comandi connettendoci al nuovo DC presente nell’infrastruttura (DC-02-01).

Ntdsutil
12-Prompt

I comandi, che verranno eseguiti per selezionare il server su cui eseguire la ricerca, sono quelli già presenti nel precedente articolo (Windows Server 2012 – Metadati Active Directory 1):
List sites (0 – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local)
Select site 0
List domains in site (0 – DC=testerlab,DC=local)
Select domain 0

List server for domain in site
Trovati 2 server
0 – CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
1 – CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local

Selezioniamo il nuovo server (1)
Select server 1
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-02-01.testerlab.local
Oggetto computer – CN=DC-02-01,OU=Domain Controllers,DC=testerlab,DC=local
Nessun contesto dei nomi attivo

A questo punto elenchiamo tutti i nomi di contesto che sono identificati univocamente.
List Naming Contexts
Contesti dei nomi di 5 trovati
0 – CN=Configuration,DC=testerlab,DC=local
1 – CN=Schema,CN=Configuration,DC=testerlab,DC=local
2 – DC=testerlab,DC=local
3 – DC=DomainDnsZones,DC=testerlab,DC=local
4 – DC=ForestDnsZones,DC=testerlab,DC=local

Select Naming Context 4
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-02-01.testerlab.local
Oggetto computer – CN=DC-02-01,OU=Domain Controllers,DC=testerlab,DC=local
Contesto dei nomi – DC=ForestDnsZones,DC=testerlab,DC=local

Select Naming Context 3
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-02-01.testerlab.local
Oggetto computer – CN=DC-02-01,OU=Domain Controllers,DC=testerlab,DC=local
Contesto dei nomi – DC=DomainDnsZones,DC=testerlab,DC=local

Select Naming Context 2
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-02-01.testerlab.local
Oggetto computer – CN=DC-02-01,OU=Domain Controllers,DC=testerlab,DC=local
Contesto dei nomi – DC=testerlab,DC=local

Select Naming Context 1
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-02-01.testerlab.local
Oggetto computer – CN=DC-02-01,OU=Domain Controllers,DC=testerlab,DC=local
Contesto dei nomi – CN=Schema,CN=Configuration,DC=testerlab,DC=local

Select Naming Context 0
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-02-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-02-01.testerlab.local
Oggetto computer – CN=DC-02-01,OU=Domain Controllers,DC=testerlab,DC=local
Contesto dei nomi – CN=Configuration,DC=testerlab,DC=local

 

Windows Server 2012 – Metadati Active Directory 1

Dopo aver visto i dati di riferimento dei ruoli FSMO sul nostro unico server presente nell’infrastruttura di test, oggi esaminiamo i dati identificativi dello stesso server in Active Directory.

Dati Infrastruttura
Per confrontare i Metadati  presenti in Active Directory riporto tutti i parametri utilizzati durante la fase di installazione del Sistema Operativo e la creazione del dominio all’interno della foresta. Durante tutte le fasi sono stati utilizzati i valori di default proposti.

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

Per la lettura dei dati utilizzerò nuovamente l’utility ntdsutil dal Prompt dei comandi eseguito con privilegi elevati (esegui come amministratore).

Ntdsutil
1-Prompt

Selezioniamo l’opzione ruoli e ci connettiamo al dominio
2-Prompt
3-Prompt
4-Prompt

Dopo esserci connessi al dominio ritorniamo alla gestione FSMO e lo selezioniamo come target per le prossime operazioni.9-Prompt
10-Prompt

Nella prossima screen sono evidenziate le query che andremo ad eseguire e che ci danno una visione globale dei dati del nostro server.
11-Prompt

List sites: Questo comando ci permette di elencare tutti i site presenti in Active Directory. Ogni site è identificato univocamente e nel nostro caso ha valore “0″.
Trovati 1 siti
0 – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local

Select site 0
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nessun dominio corrente
Nessun server corrente
Nessun contesto dei nomi attivo

List domains in site: Questo comando ci permette di elencare tutti i domini all’interno del site. Ogni dominio è identificato univocamente e nel nostro caso ha valore “0″.
Trovati 1 domini
0 – DC=testerlab,DC=local

Select domain 0
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Nessun server corrente
Nessun contesto dei nomi attivo

List server for domain in site: Questo comando ci permette di elencare tutti i server all’interno del site. Ogni server è identificato univocamente e nel nostro caso ha valore “0″.
Trovati 1 server
0 – CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local

Select server 0
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-01-01.testerlab.local
Oggetto computer – CN=DC-01-01,OU=Domain Controllers,DC=testerlab,DC=local
Nessun contesto dei nomi attivo

List Naming Contexts: Questo comando ci permette di elencare tutti i nomi di contesto che sono identificati univocamente.
Contesti dei nomi di 5 trovati
0 – CN=Configuration,DC=testerlab,DC=local
1 – DC=testerlab,DC=local
2 – CN=Schema,CN=Configuration,DC=testerlab,DC=local
3 – DC=DomainDnsZones,DC=testerlab,DC=local
4 – DC=ForestDnsZones,DC=testerlab,DC=local

Di seguito tutti i metadati dei cinque nomi di contesto:
Select Naming Context 4
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-01-01.testerlab.local
Oggetto computer – CN=DC-01-01,OU=Domain Controllers,DC=testerlab,DC=local
Contesto dei nomi – DC=ForestDnsZones,DC=testerlab,DC=local

Select Naming Context 3
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-01-01.testerlab.local
Oggetto computer – CN=DC-01-01,OU=Domain Controllers,DC=testerlab,DC=local
Contesto dei nomi – DC=DomainDnsZones,DC=testerlab,DC=local

Select Naming Context 2
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-01-01.testerlab.local
Oggetto computer – CN=DC-01-01,OU=Domain Controllers,DC=testerlab,DC=local
Contesto dei nomi – CN=Schema,CN=Configuration,DC=testerlab,DC=local

Select Naming Context 1
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-01-01.testerlab.local
Oggetto computer – CN=DC-01-01,OU=Domain Controllers,DC=testerlab,DC=local
Contesto dei nomi – DC=testerlab,DC=local

Select Naming Context 0
Sito – CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Dominio – DC=testerlab,DC=local
Server – CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Oggetto DSA – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Nome host DNS – DC-01-01.testerlab.local
Oggetto computer – CN=DC-01-01,OU=Domain Controllers,DC=testerlab,DC=local
Contesto dei nomi – CN=Configuration,DC=testerlab,DC=local

I valori riportati possono essere utilizzati come riferimento durante la fase di Troubleshooting in caso di errori che possono essere riscontrati ad esempio dopo aver promosso un server a Domain Controller oppure dopo aver aggiunto un nuovo site.

Windows Server 2012 – Ruoli FSMO

Primo di una serie di articoli dedicati ad Active Directory in ambiente Windows Server 2012, oggi vediamo come verificare quali ruoli FSMO sono presenti nel nostro server. L’infrastruttura, basata su Windows Server 2012 Standard Edition, per questo articolo, è formata da una foresta con singolo site, singolo dominio e singolo server. Data la particolare configurazione, ovviamente, tutti i ruoli FSMO saranno presenti nell’unico server installato.

Dati Infrastruttura
Per confrontare i Metadati  presenti in Active Directory riporto tutti i parametri utilizzati durante la fase di installazione del Sistema Operativo e la creazione del dominio all’interno della foresta. Durante tutte le fasi sono stati utilizzati i valori di default proposti.

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

Per la verifica utilizzerò l’utility ntdsutil dal Prompt dei comandi eseguito con privilegi elevati (esegui come amministratore). Per una guida completa di ntdsutil consultare la Command-Line Reference di Microsoft (http://technet.microsoft.com/en-us/library/cc753343.aspx).

Ntdsutil
1-Prompt

Selezioniamo l’opzione ruoli
2-Prompt

Ci connettiamo al dominio e subito dopo al nostro server
3-Prompt
4-Prompt
5-Prompt

Dopo aver effettuato la connessione al server ritorniamo alla gestione ruoli ed eseguiamo la ricerca sul nostro target selezionato
6-Prompt
7-Prompt
8-Prompt

Vediamo il risultato della nostra ricerca:
Server “DC-01-01″ riconosce i ruoli 5
Schema – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Master per la denominazione – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
PDC – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
RID – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local
Infrastrutture – CN=NTDS Settings,CN=DC-01-01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testerlab,DC=local

Preferiti di Internet Explorer, con SkyDrive sempre con te

Il servizio Cloud SkyDrive, messo gratuitamente a disposizione da Microsoft, permette, agli utenti registrati, di sincronizzare le proprie cartelle o semplicemente di depositare i propri documenti in un area protetta accessibile da un qualsiasi browser oppure attraverso l’installazione di una app.

Una delle applicazioni pratiche fruibili giornalmente  è quella di poter sincronizzare i preferiti di Internet Explorer (anche di differenti release) tra i vari dispositivi utilizzati.

Di seguito vedremo come utilizzare questa utilità tra un PC Windows 7 con Internet Explorer 9 ed un PC Windows 8 con Internet Explorer 10.

Installazione SkyDrive
Potete scaricare l’app dal link http://windows.microsoft.com/it-IT/skydrive/download in relazione al proprio sistema (Windows, Mac, Android,etc).

Condivisione cartella preferiti
Visualizzare le proprietà e l’attuale percorso di memorizzazione dal tab “Percorso” che, di default, è posizionato all’interno della struttura del proprio profilo (..Users\..\Favorites).

Percorso_1

Modificare il percorso di memorizzazione selezionando SkyDrive
Selezione_1

Confermare il nuovo percorso per iniziare la sincronizzazione della cartella preferiti.
Conferma_1

Durante la fase di sincronizzazione, che durerà solo pochi minuti, una animazione sarà visibile sotto il logo SkyDrive presente nella barra delle applicazioni.

Ripetere le stesse operazioni in tutti i dispositivi in cui si vuole attivare la sincronizzazione.

Preferiti pre e post sincronizzazione
Ecco come si presentava l’elenco dei preferiti di Internet Explorer 10 prima della sincronizzazione.
Preferiti_1

ed ecco lo stesso browser subito dopo la fase di sincronizzazione
Preferiti_2

Per la serie se c’è la possibilità di utilizzare questa comodità senza dover tenere dietro una Pen-drive perché non farlo…

WINDOWS 8 Hyper-V – Installazione e configurazione

Questa breve guida sull’utilizzo di Hyper-V con Windows 8 nasce per dare una risposta alle richieste di supporto pervenute al forum Microsoft TechNet.

Prerequisiti
Hyper-V è una funzionalità di Windows 8 che può essere attivata esclusivamente nelle versioni a 64bit e con  processori che supportano il Second Level Address Translation (SLAT).
(http://technet.microsoft.com/en-us/library/hh857623.aspx)

E’ comunque possibile creare macchine virtuali sia a 32 che a 64bit.

Prima di attivare la funzionalità Hyper-V consiglio di effettuare una verifica del processore attraverso l’utility Coreinfo di Mark Russinovich.
(http://technet.microsoft.com/en-us/sysinternals/cc835722)

E’ necessario eseguire l’utility con privilegi attraverso il comando  coreinfo –v.
Per i processori Intel verificare la voce EPT mentre  per i processori AMD la voce da verificare è NP.

Di seguito il risultato ottenuto eseguendo il test con la CPU utilizzata per questi test

coreinfo

coreinfo

Installazione
Da Attivazione o disattivazione delle funzionalità di Windows selezionare Hyper-V. Questa voce include la piattaforma, il modulo PowerShell e gli strumenti di gestione.

Attivazione Hyper-V

Attivazione Hyper-V

Una volta completata l’installazione e dopo aver riavviato il sistema host potremo lanciare la console di gestione.

Console Hyper-V

Console Hyper-V

Selezionando l’host, nell’area Azioni avremo a disposizione una serie di voci tra cui “Arresta servizio, Gestione SAN virtuale, Importa macchina virtuale, etc.” dalle quali potremo avviare l’azione desiderata.

Console Hyper-V Host

Console Hyper-V Host

Commutatore Virtuale
Prima di procedere alla configurazione della Macchina Virtuale è necessario associare la scheda di rete fisica a quella virtuale. Questa associazione si esegue attraverso il Commutatore Virtuale.

Le configurazioni possibili sono:

  • Esterna: Crea un commutatore virtuale che esegue il binding alla scheda di rete fisica in modo che le macchine virtuali possano accedere a una rete fisica.
  • Interna: Crea un commutatore virtuale che può essere utilizzato solo dalle macchine virtuali in esecuzione nel computer fisico e tra le macchine virtuali e il computer fisico. Un commutatore virtuale interno non consente di stabilire una connessione di rete fisica.
  • Privata: Crea un commutatore virtuale che può essere utilizzato solo dalle macchine virtuali in esecuzione nel computer fisico.

Dunque per poter accedere alla scheda di rete fisica implementeremo un Commutatore Virtuale Esterno. Questo tipo di commutatore è quello che viene utilizzato nella grande maggioranza dei casi proprio perché permette di sfruttare la connessione fisica verso il mondo esterno (internet).

Commutatore Virtuale Esterno

Commutatore Virtuale Esterno

L’utilizzo di una connessione Wireless implica l’adozione di una connessione bridge con la scheda di rete Wireless cosi come spiegato da John Mathew nell’articolo Bringing Hyper-V to “Windows 8”.
(http://blogs.msdn.com/b/b8/archive/2011/09/07/bringing-hyper-v-to-windows-8.aspx)

Creazione Macchina Virtuale
La creazione di una nuova Macchina Virtuale è semplice ed intuitiva ed avviene attraverso una serie di maschere che permettono di configurare i parametri di partenza. Indichiamo il nome che avrà la Macchina Virtuale all’interno della nostra console ed il percorso nel quale memorizzare i file. Se non avete esigenze particolari potete lasciare quello di default proposto dal sistema.

5-Creazione_nome

Assegnare la quantità di RAM adeguata alle esigenze della Macchina Virtuale tenendo conto della quantità di RAM totale dell’host e del numero di Macchine Virtuali che dovranno essere eseguite contemporaneamente.

7-Creazione_RAM

A questo punto configuriamo la rete assegnando il Commutatore Virtuale creato in precedenza.

8-Configurazione_rete

Per il disco fisso abbiamo la possibilità di crearne uno nuovo in base alle nostre esigenze oppure di utilizzarne uno già esistente.

9-Configurazione_disco

L’ultima fase consiste nell’indicare il device da cui installare il Sistema Operativo. Possiamo utilizzare una immagine ISO, una unità fisica come il classico DVD oppure una  Pen Drive nella quale avremo precedentemente inserito l’ISO.

10-Configurazione_avvio

Di seguito le impostazioni della Macchina Virtuale viste all’interno della console di gestione di Hyper-V
11-Configurazione

Dispositivi fisici e virtuali
Senza scendere nel dettaglio di tutti i dispositivi presenti nel PC utilizzato per i test, analizziamo i più rappresentativi.
Processore: Il processore utilizzato è un Intel i5 QC 650 3.2GHz (HOST-W864). Per la Macchina Virtuale si è scelto di utilizzare un  solo core (GUEST-W764).
Scheda di rete: l’host è basato su una scheda madrea con Controller Realteck PCIe GBE integrato (HOST-W864), lo stesso  viene virtualizzat come Scheda di rete Hyper-V Microsoft (GUEST-W764).

12-Gestione dispositivi

Adesso è arrivato il momento di sbizzarrirci con le nuove Macchine Virtuali per tenere sempre un piede nel passato…

Buon lavoro.

Iscriviti

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