Hyper-V: Dispositivi sconosciuti

Nel precedente articolo ho accennato alla possibilità di riscontrare dei dispositivi sconosciuti. In genere tutti i dispositivi vengono riconosciuti ed installati automaticamente in fase di post installazione. Ma abbiamo una piccola eccezione introdotta a partire dalla versione Hyper-V eseguita con Windows Server 2012 R2 e Windows 8.1.

La KB2925727 Unknown Device (VMBUS) in Device manager in Virtual Machine for AVMA  indica che questi device sono riconosciuti ed installate a partire dalla versione 2012 R2/8.1. Una nota aggiuntiva specifica che la presenza dei due Unknown Device non implica nessun problema e che possiamo tranquillamente lasciarli in quello stato.

Quindi la presenza di tali dispositivi è normale per i sistemi operativi precedenti alla versione Windows Server 2012 R2 e Windows 8.1.

Gestione Dispositivi Windows XP e Windows 7

Gestione Dispositivi: Windows XP e Windows 7

Gestione Dispositivi: Windows 8 e Windows 8.1

Gestione Dispositivi: Windows 8 e Windows 8.1

 

Alla fine dell’installazione verificheremo che i due device sconosciuti altro non sono che:
Canale di controllo Desktop remoto Hyper-V Microsoft

  • VMBUS\{f8e65716-3cb3-4a06-9a60-1889c5cccab5}
  • VMBUS\{99221fa0-24ad-11e2-be98-001aa01bbf6e}

dispositivo_01

Componente di attivazione Hyper-V Microsoft

  • VMBUS\{3375baf4-9e15-4b30-b765-67acb10d607b}
  • VMBUS\{4487b255-b88c-403f-bb51-d1f69cf17f87}

dispositivo_02

Per i più puntigliosi, per quelli che vogliono vedere l’elenco dei device senza punti interrogativi od esclamativi, l’unica soluzione è l’installazione manuale dei driver estraendoli dal CD dei Servizi di Integrazione.

Prima di iniziare con l’installazione dei driver è bene verificare il livello e la presenza di tali servizi.

Per farlo possiamo eseguire due semplici CmdLet PowerShell:
Get-VM | Format-Table Name, IntegrationServicesVersion
Get-VMIntegrationService –VMName “nome macchina virtuale”

Verifica Servizi Integrazione

Verifica Servizi Integrazione

 

Installazione driver
Inseriamo il CD dei servizi di integrazione dal relativo menu . All’interno della cartella support troveremo due cartelle: amd64 ed x86. A questo punto, in relazione al sistema operativo utilizzato nella nostra Guest, dobbiamo selezionare la versione a 32 o 64 bit.

I driver sono contenuti all’interno del file Windows6.2-HyperVIntegrationServices-x64(x86).cab e dovranno essere estratti prima di poter essere utilizzati.

Per comodità copiamo il file di nostro interesse in una cartella locale (es. C:\Driver\)
Driver_1

Per estrarre i files contenuti all’interno del file .cab possiamo utilizzare un programma per compressione file come Winzip o Winrar, oppure il comando Expand.  Non avendo nessun software disponibile utilizzo il comando Expand il cui file sorgente Expand.exe è contenuto all’interno della cartella %systemroot%\System32\.

Copio il file all’interno della cartella precedente, cosi da semplificare l’esecuzione del comando di estrazione.
Driver_2

Il comando per estrarre i file, eseguito all’interno di un prompt DOS eseguito come Aministratore, è:
Expand.exe -F:* Windows6.2-HyperVIntegrationServices-x64 C:\Driver\
Expand

Driver_3

Siamo in grado adesso di eseguire una classica installazione manuale dei driver facendo puntare la ricerca alle cartelle appena estratte.
Driver_4

Alla segnalazione d’errore sulla verifica del driver proseguiamo.
Driver_5

Driver_6

Ed una volta completata l’installazione del primo device continuiamo con il secondo.
Driver_7

Bene, siamo arrivati alla fine del nostro duro lavoro :)

Dispositivi_installati_1
Dispositivi_installati_2
Dispositivi_installati_3

Ed anche i pignoli sono stati accontentati…

Hyper-V: Guest Server e Client

Lo spunto di questo breve articolo deriva da alcune riflessioni riguardanti l’esigenza di dover spostare macchine virtuali tra differenti Hypervisor ed Host.
L’astrazione logica di una macchina virtuale si integra comunque con quella che la specificità dell’Hypervisor. Il punto di congiunzione risultano essere i Servizi di Integrazione. E’ essenziale verificare che la macchina virtuale possa essere eseguita nello specifico Hypervisor e che i servizi di integrazione siano correttamente installati.

Particolare attenzione è da porre nella migrazione tra un ambiente Virtual PC ed Hyper-V. In genere queste migrazioni riguardano piccoli ambienti di test utilizzati con Windows 8/8.1. In questo caso, più che mai, i servizi di integrazione devono essere disinstallati prima di esportare la macchina virtuale in quanto le due versioni non sono compatibili.

A partire dalla versione Windows Server 2012/Windows 8, nelle macchine virtuali create od importate, potrebbero essere presenti dei device sconosciuti.  In questo caso è indispensabile installare manualmente i driver che i servizi di integrazione non installano automaticamente.
Questi device sono:
Microsoft Hyper-V Remote Desktop Control Channel
Microsoft Hyper-V Activation Component

Nelle seguenti tabelle sono raggruppati i sistemi operativi guest supportati in base alla versione dell’Hypervisor.

Guest Server

Guest Server

Guest Client

Guest Client

Ulteriori e più dettagliate informazioni sono presenti nella documentazione ufficiale:

Outlook 2013: mail headers

Capita spesso di avere dei dubbi sulla reale provenienza di una mail. Il mittente sembra conosciuto, ma qualcosa non ci convince. La dimensione, l’oggetto, la ricezione stessa della mail ci portano a pensare che forse… l’apparenza inganna.

Sappiamo benissimo che l’apertura di una mail sospetta, magari sfuggita alle verifiche dell’antispam o dell’antivirus, può portare a pesanti ripercussioni di sicurezza.

In questo caso, oppure in tutti quei casi in cui è necessario verificare le informazioni del messaggio è opportuno leggere le informazioni nascoste (headers)che viaggiano insieme al corpo della mail.

Negli anni mi è capitato molte volte di dover inviare l’header al supporto specialistico di partner tecnologici per la verifica dei motori antispam.

Purtroppo Outlook 2013 non integra nella barra degli strumenti (ribbon) l’opzione diretta per la visualizzazione dell’header. Molta letteratura propone l’apertura della mail per poi leggerne l’header, niente di più sbagliato. Una volta aperta la mail il nostro sistema potrebbe diventare da subito vulnerabile.

Dobbiamo quindi aggiungere alla barra degli strumenti l’opzione che ci permette di analizzare la mail senza aprirla.

La soluzione migliore è quella di aggiungere l’opzione messaggio alla barra degli accessi rapidi. Direttamente dalla personalizzazione della barra oppure dalle Opzioni possiamo arrivare al nostro scopo.

barra_01

Outlook 2013: Barra accesso rapido

opzioni_01

Outlook 2013: Opzioni

Dal menu a tendina selezioniamo tutti i comandi ed una volta individuato il nostro comando lo aggiungiamo con le frecce di selezione
opzioni_02opzioni_03

A questo punto basta selezionare la mail di cui vogliamo leggere l’header e selezionare opzione messaggio dalla barra di accesso rapido.

Di seguito l’esempio di un header letto dalla seguente mail

Outlook 2013: mail

Outlook 2013: mail

Outlook 2013: header

Outlook 2013: header

========================================

X-Message-Status: n:n
X-Message-Delivery: Vj0xLjE7dXM9MTtsPTE7YT0xO0Q9MTtHRD0xO1NDTD0w
X-Message-Info: GnpImppio6N7xti6Y+ibLX0mh3rfD4k3DzofCdK9BuHax72ls/YxfN1PIuw9azFZ0UFuyNXfaxfOY5N1opcXqshBBOhp0rUVqjEufDwPibVuMgzRS0Ike22d/b44ewyeqBXKLPMmyxLIxiXVBcURnSXVa3DjoIGdKHPyjAQfJsBnLgijkrurQzVjSAGTHI9deK4+MKUra1aVzENvMGZkbNlRsCg6SG5mH5Z/d8YzyGs=
Received: from mta28.email.microsoftemail.com ([66.231.92.214]) by SNT004-MC4F11.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712);
  Wed, 27 Aug 2014 13:45:57 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=102420140131; d=email.microsoftemail.com;
 h=From:To:Subject:Date:MIME-Version:Reply-To:Message-ID:Content-Type:Content-Transfer-Encoding;
 bh=grTgvgqn7z7Mlm68ruXLkvanfYw=;
 b=SLKKWHrD5uULtx6+y7z9EI10huQoe3hQiU7jbtZCPrvRPk5aAJrHBXXeRFwSTtJEvkAhp7l12qxI
   1m6FjFXim6M6mfYSZJVrKSectr421qlhAlLriuB9QXElS+Mw2HHTc/z4yiP9OEvDNSPD34Zl87vs
   MY4ZNv9Npqvc+kG1PGg=
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=200608; d=e-mail.microsoft.com;
 b=Jm/AGuxqZEvxBSbfMM2zOR7iXSTVmJyKwnqqnjCoUndY6iXymHwa4YC2XOrt4iP3tJ76Xn0GNqQa
   cz/b9eKdCYqIzC+kFnHVHuXUOLIpyiz4hoeNWL4mAIpTV6nPfSTqmnzYLvTiKkWgFawUS1TnykNG
   3pxdKFAZukSV5L4ov30=;
Received: by mta28.email.microsoftemail.com id hvp1oa163hsd for <mia_mail@hotmail.it>; Wed, 27 Aug 2014 14:45:56 -0600 (envelope-from <bounce-887404_TEXT-811016559-3033347-188147-858@bounce.email.microsoftemail.com>)
From: “Microsoft” <securitynotifications@e-mail.microsoft.com>
To: <mia_mail@hotmail.it>
Subject: Microsoft Security Bulletin Re-Releases
Date: Wed, 27 Aug 2014 14:45:56 -0600
MIME-Version: 1.0
Reply-To: “Microsoft” <reply-fe9817707667077972-887404_TEXT-811016559-188147-858@email.microsoftemail.com>
x-job: 188147_3033347
Message-ID: <704dfdb6-179b-47eb-aecc-b9f44e14197e@xtinmta1135.xt.local>
Content-Type: text/plain; charset=”us-ascii”
Content-Transfer-Encoding: quoted-printable
Return-Path: bounce-887404_TEXT-811016559-3033347-188147-858@bounce.email.microsoftemail.com
X-OriginalArrivalTime: 27 Aug 2014 20:45:57.0168 (UTC) FILETIME=[E701D300:01CFC237]

========================================

Voglio segnalarvi due interessanti strumenti online di analisi delle headers ed un documento di supporto Microsoft.

 

Windows Update errore 0x800f0922 durante l’installazione dell’aggiornamento KB2920189

Nei giorni scorsi Microsoft ha rilasciato alcuni avvisi di sicurezza. Tra questi c’è il 2962824 del 13 maggio 2014, identificato con la KB2920189, che potrebbe creare qualche problema durante la fase di installazione.

L’aggiornamento revoca il certificato per quattro moduli UEFI. La configurazione di avvio sicuro provoca l’arresto dell’installazione dell’aggiornamento con un codice specifico: 0x800f0922.

I Sistemi Operativi interessati al problema sono: Windows 8, Windows 8.1, Windows Server 2013 e Windows Server 2012 R2.

Per capire quale impatto potrebbe causare questo errore basti pensare ad una farm dove girano decine o centinaia di Macchine Virtuali che eseguono quei Sistemi Operativi.

La risoluzione del problema è piuttosto semplice, se non fosse per il fatto che prevede il doppio riavvio. In presenza di un numero elevato di Server (fisici o virtuali) si può ben capire la mole di lavoro ed il tempo che ci vorrà per l’applicazione della correzione.

Di seguito saranno presentate alcune screen che simulano l’errore e la soluzione applicata su una Macchina Virtuale Windows Server 2012 R2 in ambiente Hyper-V.

Windows Update

Windows Update

Errore 0x800f0922

Errore 0x800f0922

Per applicare la soluzione dobbiamo modificare le impostazioni della Macchina Virtuale a livello Firmware eliminando il flag “Abilita Avvio protetto“.

Impostazioni Macchina Virtuale

Impostazioni Macchina Virtuale

Dopo aver salvato la nuova configurazione riavviare il server ed eseguire nuovamente Windows Update.

Windows Update

Windows Update

Il passo successivo è quello di rimettere il flag “Abilita Avvio protetto” per aumentare la protezione del sistema.

Impostazioni Macchia Virtuale

Impostazioni Macchia Virtuale

Per approfondire:
Advisory Microsoft sulla sicurezza 2962824 del 13 maggio 2014
Aggiornamento cumulativo dei moduli UEFI non conformi e revocati

Hyper-V Server 2012 R2: Gestione remota in ambiente Workgroup (Console di gestione Hyper-V)

Dopo aver visto come gestire un Hypervisor Hyper-V Server 2013 R2 attraverso Desktop Remoto e Server Manager, in questo post vedremo come utilizzare la Console di gestione Hyper-V.

La Console di gestione Hyper-V si attiva come funzionalità di Windows e si integra in Server Manager se installato.

aggserver_08

Ovviamente, una volta attivata la funzionalità, la Console di gestione Hyper-V potrà essere richiamata direttamente da Server Manager.

aggserver_09

Prima di poter realmente utilizzare la Console di gestione Hyper-V dovremo autorizzare l’accesso anonimo al PC per i Component Services DCOM.

Da Pannello di controllo > Strumenti di amministrazione > Servizi componenti ( oppure semplicemente eseguendo dcomcnfg). Espandere l’albero e selezionare proprietà del computer locale

aggserver_11

Dal tab “Sicurezza COM” premere il pulsante “Modifica limiti” e, per l’ACCESSO ANONIMO consentire il Local Access e l’Accesso Remoto.

aggserver_12

aggserver_13

ACCESSO ANONIMO NON CONSENTITO
aggserver_14

ACCESSO ANONIMO CONSENTITO
aggserver_15

MACCHINA VIRTUALE GESTITA NELLA CONSOLE
aggserver_16

 

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 Server 2012 R2
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: PC-NINO
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

 

Iscriviti

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