Seattle IT Pro User Group Meeting - 7 agosto a Bellevue

La prossima riunione SITPUG mensile è prevista per Mercoledì 7 Agosto 2013 presso il Lincoln Center di Piazza Bellevue alle 6:00 PM.

Sessione Dettagli Zubair Alexander, presidente di SeattlePro Enterprises, sarà il relatore di turno nella riunione di agosto. Zubair è un Microsoft MVP per Servizi di directory e un trainer certificato Microsoft. Il tema della sua presentazione è "ottimali per la protezione di Active Directory . "

Servizi di dominio Active Directory (AD DS) svolgono un ruolo importante nel fornire una gestione centralizzata delle risorse di rete. Essi sono essenziali anche per controllare l'accesso ai dati aziendali. Ha senso solo per garantire la sicurezza di Servizi di dominio Active Directory. Alcuni amministratori credono erroneamente che, poiché i server di Active Directory è in esecuzione sulla loro rete interna, sono relativamente al sicuro dagli attacchi dannosi. Secondo i ricercatori, la maggior parte degli attacchi a una rete media hanno luogo all'interno della rete interna dell'organizzazione.

Protezione dei Servizi di dominio Active Directory utilizzando le migliori pratiche è essenziale per proteggere la vostra infrastruttura di rete di Windows. In questa presentazione verrà illustrato come proteggere meglio i controller di dominio Active Directory, riducendo la superficie di attacco, individuando le fonti di minaccia e quindi minimizzando loro, come a cercare segni di compromesso, e come fissare correttamente gli account amministrativi.

Windows 8 Giveaway 

Ci regalerà una copia di Windows 8 Professional e alcune altre chicche alla riunione. Trarremo i nomi dei fortunati vincitori al termine della riunione. Si prega di verificare le norme sul nostro sito web.

Corso SQL Server  - Corso Windows Server
 Corso asp.net - Certificazione Microsoft - Corso Windows 2012 - Corso Server 2012 - Certificazione MCSA 2012 - Certificazione MCSA 2008

Windows Azure per ItPro

In un momento in cui tutti parlano di Servizi e Cloud, non puoi non conoscere Windows Azure!

Windows Azure è la piattaforma Microsoft per il public cloud: è una piattaforma scalabile, aperta, affidabile e può essere utilizzata in tantissimi modi.

Windows Azure può essere usato per creare macchine virtuali, come semplice Repository o per creare siti Web. Non solo: in Windows Azure puoi eseguire le tue applicazioni, svilupparne di tue o creare un database SQL.

Insomma, Windows Azure è la risposta a tutte le tue esigenze e oggi lo puoi mettere alla prova gratuitamente! A questo link puoi trovare le istruzione per ottenere una sottoscrizione gratuita per un mese, un credito per cominciare a lavorare e tutta la documentazione tecnica necessaria.

I servizi che Windows Azure mette a disposizione sono davvero tanti, molti dei quali rivolti al mondo degli It Pro. In un precedente post per esempio trovi una semplice guida per creare la tua prima macchina virtuale con a bordo Windows Server 2012.

E non dimenticare di tenere sempre sotto controllo il blog, dove puoi trovare, tra l’altro, le guide di configurazione dei diversi servizi di Windows Azure!

A presto e buon lavoro.

Corso SQL Server  - Corso Windows Server
 Corso asp.net - Certificazione Microsoft - Corso Windows 2012 - Corso Server 2012 - Certificazione MCSA 2012 - Certificazione MCSA 2008

Riprendiamo l’articolo pubblicato precedentemente continuando nella guida che ci aiuta a migrare Domain Controller da Windows Server 2003 a Windows Server 2012.

Rimozione del Domain Controller Windows Server 2003

Prima di iniziare la procedura di dismissione del Domain Controller Windows Server 2003(VMDC2003 nell’esempio) occorre impostare i client in modo che non lo utilizzino più come server DNS e utilizzino invece il nuovo server Windows Server 2012 (VMDC2012 nell’esempio). Questa impostazione generalmente viene distribuita tramite DHCP di conseguenza per evitare problemi ai client durante e dopo la rimozione del Domain Controller Windows Server 2003 sarebbe opportuno attendere che la configurazione sia distribuita col rinnovo del lease DCHP.

Di seguito analizzeremo i passi necessari per eseguire il demote di un Domain Controller Windows Server 2003, per maggiori informazioni si veda Decommissioning a Domain Controller.

Configurazione delle impostazioni di rete per il Domain Controller Windows Server 2012

Dopo aver verificato la funzionalità di Active Directory col nuovo Domain Controller e aver controllato che la replica tra i due Domain Controller è avvenuta correttamente è possibile configurare il Domain Controller Windows Server 2012 affinché usi se stesso come primo server DNS tramite l’indirizzo IP 127.0.0.1 oppure tramite l’indirizzo IP assegnato (10.10.0.12 nell’esempio).

Spostamento dei ruoli Flexible Single Master Operations sul Domain Controller Windows Server 2012

Dal momento che il Domain Controller Windows Server 2012 dovrà sostituire il Domain Controller Windows Server 2003 è necessario spostare su di esso i ruoli FSMO (Flexible Single Master Operations) elencati nella seguente tabella:

Ruolo FSMO	Scope	Diritti necessari per lo spostamento
SchemaMaster	Foresta	Schema Admins
Domain Naming Master	Foresta	Enterprise Admins
RID Master	Domino	Domain Admins
PDC Emulator	Domino	Domain Admins
Infrastructure Master	Domino	Domain Admins

E possibile eseguire lo sposamento dei ruoli FSMO tramite PowerShell direttamente dal Domain Controller Windows Server 2012. Di seguito il comando PowerShell per trasferire tutti i ruoli FSMO sul Domain Controller Windows Server 2012 (VMDC2012 nell’esempio):

Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole SchemaMaster, DomainNamingMaster, RIDMaster,InfrastructureMaster,PDCEmulator

In alternativa è anche possibile spostare i ruoli uno alla volta:

Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole SchemaMaster
Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole DomainNamingMaster
Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole RIDMaster
Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole InfrastructureMaster
Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole PDCEmulator

Per verificare che lo sposamento dei ruoli FSMO sia avvenuto correttamente è possibile controllare che il seguente evento sia stato registrato 5 volte (uno per ogni ruoli FSMO trasferito):

· Registro Directory Services - Evento d’informazioni ActiveDirectory_DomainService 1458

Inoltre sempre tramite PowerShell, come visto precedentemente, è possibile controllare che i ruoli FSMO risultino assegnati ad Domain Controller Windows Server 2012 (VMDC2012 nell’esempio)

Get-ADForest | Select SchemaMaster, DomainNamingMaster
Get-ADDomain | Select RIDMaster, PDCEmulator, InfrastructureMaster

Rimozione del ruolo di Global Catalog dal Domain Controller Windows Server 2003

Prima di iniziare la procedura di demote del Domain Controller Windows Server 2003 oltre a rimuovere i ruoli FSMO detenuti occorre rimuovere anche il ruolo di Global Catalog come indicato in Demote a domain controller.

Per rimuovere il ruolo di Global Catalog è possibile utilizzare il tool Siti e servizi di Active Directory.

Per verificare che la rimozione del ruolo Global Catalog sia avvenuta correttamente è possibile controllare che sul Domain Controller Windows Server 2003 sia stati registrati i seguenti eventi:

· Domain Controller Windows Server 2003
Registro Servizio Directory - Evento d’informazioni NTDS General 1120

· Domain Controller Windows Server 2012
Registro Directory Services - Evento d’informazioni ActiveDirectory_DomainService 1869

Inoltre occorre verificare che il record DNS SRV _gc relativo al Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) sia stato rimosso e che sia presente solamente quello relativo al Domain Controller Windows Server 2012 (VMDC2012 nell’esempio), per maggiori informazioni si veda Verify Global Catalog DNS Registrations:

Dopo aver rimosso il ruolo di Global Catalog e aver verificato che l’operazione è andata a buon fineriavviare il Domain Controller Windows Server 2003.

Configurazione delle impostazioni di rete per il Domain Controller Windows Server 2003

Per evitare problemi di risoluzione DNS durante il demote del Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) occorre configurare il Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) affinché usi il Domain Controller Windows Server 2012(VMDC2012 con IP 10.10.0.12 nell’esempio) come primo server DNS.

Dopo aver modificato le impostazioni di rete riavviare il server.

Rimozione del server DNS dal Domain Controller Windows Server 2003

Dal momento che il servizio DNS sul Domain Controller Windows Server 2003 (VMDC2003 nell’esempio), non è più di fatto utilizzato all’interno dell’infrastruttura è possibile rimuoverlo tramite Amministrazione Server.

 

Demote del Domain Controller Windows Server 2003

Avviare il demote eseguendo sul Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) Dcpromo senza specificare che questo è l’ultimo server Domain Controller del dominio, al termine riavviare il server come richiesto.

 

Nel caso si verifichi l’errore di time out durante l’arresto del servizio NETLOGON come mostrato inFigura 5, molto probabilmente il Domain Controller Windows Server 2003 non è stato riavviato dopo aver rimosso il ruolo di Global Catalog o non è stato impostato il Domain Controller Windows Server 2012 (VMDC2012 con IP 10.10.0.12 nell’esempio) come server DNS primario. In alternativa potrebbero esserci sul server dei servizi dipendenti da Active Directory che vanno arrestati prima di eseguire il demote. Dopo avere provveduto a risolvere la causa del time out riavviare la procedura di Demote, per maggiori informazioni si veda la KB555078 Netlogon service time out error message while promote domain controller.

Eliminazione dell’oggetto server relativo al Domain Controller Windows Server 2003 dal Sito

Terminata la procedura di demote occorre rimuovere manualmente l’oggetto server relativo al Domain Controller Windows Server 2003 tramite il tool Siti e servizi di Active Directory.

Rimozione e correzione dei record DNS relativi al Domain Controller Windows Server 2003

Il demote del Domain Controller Windows Server 2003 dovrebbe già rimuovere gran parte dei record DNS, ma occorre eseguire alcune operazioni manualmente per quanto riguarda i record NS nel dominio e nel sottodomino _msdcs.

Il sottodominio _msdcs è riservato alla registrazione dei record DNS dei servizi di rete inerenti ai servizi di directory specifici di Microsoft, Active Directory infatti non è altro che l’implementazione Microsoft dei servizi di directory. I client il dominio che interrogano il dominio _msdcs , ad esempio, per un record DNS SRV relativo al servizio LDAP otterranno un record per un server LDAP Microsoft (Domain Controller). Le query verranno eseguite nel formato _Service._Protocol.DcType. _msdcs. DnsDomainName dove DcType sarà il GUID del dominio, _Service l’identificativo del servizio (_ldap per LDAP) e _Protocol l’identificativo del protocollo di rete (_tcp per TCP).

La prima operazione manuale consiste nel rimuovere il Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) dall’elenco dei Server dei nomi per la zona di ricerca diretta del dominio (sysadmin.lan nell’esempio).

 

La seconda operazione manuale consiste nel rimuovere il riferimento al Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) dal sottodominio dominio delegato _msdcs sostituendolo con il Domain Controller Windows Server 2012 (VMDC2012 nell’esempio).

 

La terza operazione manuale consiste nel rimuovere il riferimento al Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) dal sottodominio _msdcs sostituendolo con il Domain Controller Windows Server 2012 (VMDC2012 nell’esempio)

 

Controllare che non esistano altri record DNS che puntino ancora al Domain Controller Windows Server 2003 ad esclusione del record A nella zona del domino (sysadmin.lan nell’esempio) dal momento che tale server è membro del dominio.

Nel caso fossero ancora presenti altri record è possibile eliminarli manualmente o usare il tool a riga Nltest per eliminare i record DNS che un Domain Controller registra:

nltest /dsderegdns:vmdc2003.sysadmin.lan

Terminata la pulizia dei record DNS riavviare il Domain Controller Windows Server 2012.

Verifica della funzionalità di Active Directory

Terminata la dismissione del Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) è opportuno procedere alla verifica del funzionamento di Active Directory dopo aver arestato il Domain Controller dismesso eseguendo i seguenti controlli descritti nella sezioneVerifica della promozione del Domain Controller:

· Verifica dell’esistenza delle share NETLOGON e SYSVOL

· Verifica del servizio DNS

· Verifica della replica

· Verifica dei ruoli Flexible Single Master Operations

Come ultimo controllo rieseguire il best practices analyzer che dovrebbe elencare un nuovo avviso relativo all’opportunità di installare un secondo Domain Controller per garantire la ridondanza e l’errore che occorre impostare il Domain Controller Windows Server 2012 (VMDC2012 nell’esempio) per sincronizzare l’ora con una fonte valida dal momento che esegue il ruolo di PDC Emulator (a riguardo si veda AD DS: The PDC emulator master in this forest should be configured to correctly synchronize time from a valid time source).

Rimozione del server Windows Server 2003

Il server Windows Server 2003 (VMDC2003 nell’esempio) può essere rimosso dal dominio arrestato e poi dismesso, quindi è possibile eliminare l’account computer relativo e il record DNS A.

Successivamente è possibile valutare se può essere conveniente attribuire al Domain Controller Windows Server 2012 (VMDC2012 nell’esempio) l’indirizzo IP che aveva il Domain Controller Windows Server 2003 (VMDC2003 con IP 10.10.0.11 nell’esempio). Questa modifica può essere conveniente se nell’infrastruttura vi sono un numero consistente di client, server o host che si riferiscono all’IP del Domain Controller dismesso tramite impostazioni statiche, ad esempio per risolvere le query DNS per gli host del dominio o, nel caso di host non in domino, come NTP server.

Migrazione della replica SYSVOL da FRS a DFS

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

Questo significa che nell’infrastruttura di esempio dal momento che il livello funzionale è Windows Server 2003 la replica della directory SYSVOL avviene tramite FRS e non tramite la nuova replica DFS che ha i seguenti vantaggi:

· Maggior efficienza.

· Maggior scalabilità.

· Utilizza l’algoritmo Remote Differential Compression (RDC) che riduce l’utilizzo della banda di rete.

· Ha un meccanismo di auto ripristino da eventuali corruzioni.

In scenari come quello dell’esempio risulta quindi necessario eseguire manualmente la migrazione dalla replica FRS alla replica DFS, sino a che la migrazione non è terminata non devono essere apportate modifiche a script di logon e Group Policy, per maggiori informazioni si veda SYSVOL Replication Migration Guide: FRS to DFS Replication e i seguenti post dello Storage Team:

· SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process

· SYSVOL Migration Series: Part 2 - Dfsrmig.exe: The SYSVOL migration tool

· SYSVOL Migration Series: Part 3 - Migrating to the Prepared State

· SYSVOL Migration Series: Part 4 – Migrating to the ‘REDIRECTED’ state

· SYSVOL Migration Series: Part 5 – Migrating to the ‘ELIMINATED’ state

Per le novità introdotte nella replica DFS in Windows Server 2012 si veda DFS Replication Improvements in Windows Server 2012.

Primo step: Verifica della funzionalità della replica FRS

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

1. Verificare l’esistenza e funzionalità delle share NETLOGON e SYSVOL su ogni Domain Controller (nell’esempio esiste solo VMDC2012) mediante i comandi:

a. net share

b. dcdiag /test:frssysvol

c. dcdiag /test:netlogons

2. Verificare su ogni Domain Controller (nell’esempio esiste solo VMDC2012) che il disco su cui risiede la share SYSVOL abbia lo spazio disponibile per crearne una copia.

3. Controllare la funzionalità della replica FRS tramite il tool FRSDIAG (si vedano le indicazioni nel seguente Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style)

4. Verificare su ogni Domain Controller (nell’esempio esiste solo VMDC2012) che la replica Active Directory funzioni correttamente tramite il comando repadmin /ReplSum.

5. Verificare su ogni Domain Controller (nell’esempio esiste solo VMDC2012) che la chiave di registro HKLM\System\CurrentControlSet\Services\Netlogon\Parameters contenga il valoreSysVol impostato a [drive:\]Windows_folder\SYSVOL\sysvol e che contenga il valore SysvolReadyimpostato a 1.

6. Controllare che su ogni Domain Controller (nell’esempio esiste solo VMDC2012) il servizio Replica DFS (DFSR) sia avviato e impostato per l’avvio automatico.

Secondo step: Aumento del livello funzionale del dominio

Per poter utilizzare la replica DFS occorre aumentare il livello funzionale portandolo almeno a Windows Server 2008, ma se si suppone di inserire nell’infrastruttura sol Domain Controller Windows Server 2012 o superiori conviene portare a Windows Server 2012 il livello funzionale della foresta per beneficiare di tutte le novità introdotte.

E’ possibile elevare il livello funzionale del dominio e della foresta tramite il tool i Servizi di dominio di Active Directory come visto precedentemente oppure usare i seguenti comandi PowerShell:

#Raise livello funzionale del dominio a Windows 2012 Set-ADDomainMode -Identity sysadmin.lan -DomainMode Windows20012 

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

#Raise livello funzionale della foresta a Windows 2012 Set-ADForestMode -Identity sysadmin.lan -ForestMode Windows2012

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

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

· Registro Directory Services - Evento d’informazioni ActiveDirectory_DomainService 2039

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

· Registro Directory Services - Evento d’informazioni ActiveDirectory_DomainService 2040

Terzo step: Migrazione del dominio nello stato Prepared

Prima di eseguire la migrazione del dominio nello stato Prepared eseguire un backup del system state dei Domain Controller nell’infrastruttura (nell’esempio esiste solo VMDC2012) eseguendo su ciascun Domain Controller il comando:

Wbadmin start systemstatebackup

Terminato il backup dei system state dei Domain Controller nell’infrastruttura, che consentirà di rispristinare la situazione precedente nel caso subentrassero problemi, è possibile impostare il global migration state a Prepared eseguendo da un Domain Controller (preferibilmente il PDC Emulator e comunque non un Read Only Domain Controller) il comando:

dfsrmig /setglobalstate 1

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

dfsrmig /getglobalstate

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

dfsrmig /getmigrationstate

Se il global migration state è stato impostato a Prepared viene registrato il seguente evento:

· Registro Replica DFS - Evento d’informazioni DFSR 8014

Prima di continuare la migrazione della replica SYSVOL da FRS a DFS eseguire i seguenti controlli:

1. Verificare l’esistenza e funzionalità delle share NETLOGON e SYSVOL su ogni Domain Controller (nell’esempio esiste solo VMDC2012) mediante i comandi:

a. net share

b. dcdiag /test:frssysvol

c. dcdiag /test:netlogons

2. Controllare la funzionalità della replica FRS tramite il tool FRSDIAG (si vedano le indicazioni nel seguente Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style).

3. Verificare che su ogni Domain Controller (nell’esempio esiste solo VMDC2012) sia stata la directory %SystemRoot%\SYSVOL_DFSR e che il contenuto delle directory domain e sysvol in%WinDir%\SYSVOL sia stato copiato in %WinDir%\SYSVOL_DFSR.

4. Usare il tool Gestione DFS per creare un report diagnostico per la directory SYSVOL_DFSR, è possibile installare lo snap-in aggiungendo la funzionalità Strumenti di amministrazione remota del server – Strumenti di amministrazione ruoli – Strumenti per servizi file – Strumenti di gestione DFS.

a. Selezionare il nodo Replica – Domain System Volume

b. Verificare nel Tab Appartenze che per tutti i Domain Controller sia abilitata la replica per il path %SystemRoot%\SYSVOL_DFSR\domain.

c. Selezionare Azioni – Crea rapporto di diagnostica.

d. Creare un Rapporto di stato, un Test di propagazione e un Rapporto di propagazione e verificare che non vi siano errori

Quarto step: Migrazione del dominio nello stato Redirect

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

dfsrmig /setglobalstate 2

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

dfsrmig /getglobalstate

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

dfsrmig /getmigrationstate

Se il global migration state è stato impostato a Redirect viene registrato il seguente evento:

· Registro Replica DFS - Evento d’informazioni DFSR 8017

Prima di continuare la migrazione della replica SYSVOL da FRS a DFS eseguire i seguenti controlli:

1. Verificare l’esistenza delle share NETLOGON e SYSVOL su ogni Domain Controller (nell’esempio esiste solo VMDC2012) mediante il comando net share e verificare che ora le share mappino rispettivamente le directory:

a. %SystemRoot%\SYSVOL_DFSR\sysvol\NomeDominioDNS\SCRIPTS (nell’esempio C:\Windows \ SYSVOL_DFSR\sysvol\sysadmin.lan\SCRIPTS)

b. %SystemRoot%\SYSVOL_DFSR\sysvol

2. Usare il tool Gestione DFS per creare un report diagnostico per la directory SYSVOL_DFSR, come descritto nel secondo step.

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

Quinto step: Migrazione del dominio nello stato Eliminated

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

1. Verificare che le repliche funzionino correttamente tramite il comando repadmin /ReplSum(controllare che non siano riportati errori)

2. Eseguire un backup del system state dei Domain Controller nell’infrastruttura (nell’esempio esiste solo VMDC2012) che consentirà di rispristinare la situazione precedente nel caso subentrassero problemi eseguendo su ciascun Domain Controller il comando Wbadmin start systemstatebackup.

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

dfsrmig /setglobalstate 3

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

dfsrmig /getglobalstate

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

dfsrmig /getmigrationstate

Se il global migration state è stato impostato a Redirect viene registrato il seguente evento:

· Registro Replica DFS - Evento d’informazioni DFSR 8019

Terminata la migrazione della replica SYSVOL da FRS a DFS eseguire i seguenti controlli:

1. Verificare l’esistenza delle share NETLOGON e SYSVOL su ogni Domain Controller (nell’esempio esiste solo VMDC2012) mediante il comando net share e verificare che ora le share mappino rispettivamente le directory:

a. %SystemRoot%\SYSVOL_DFSR\sysvol\NomeDominioDNS\SCRIPTS (nell’esempio C:\Windows \ SYSVOL_DFSR\sysvol\sysadmin.lan\SCRIPTS)

b. %SystemRoot%\SYSVOL_DFSR\sysvol

2. Usare il il tool Gestione DFS per creare un report diagnostico per la directory SYSVOL_DFSR, come descritto nello step due.

3. Verificare che su ogni Domain Controller (nell’esempio esiste solo VMDC2012) sia stata rimossa la directory % SystemRoot%\SYSVOL

4. Arrestare e disabilitare il servizio FRS su tutti Domain Controller (nell’esempio esiste solo VMDC2012) tranne nel caso in cui l’FRS venisse utilizzato per repliche diverse dalla directory SYSVOL. E’ possibile eseguire tale configurazione tramite i comandi:

a. sc stop ntfrs

b. sc config ntfrs start=disabled

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

· Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style

· The Case for Migrating SYSVOL to DFSR

Conclusioni

In Windows Server 2012 il processo d’installazione di un Domain Controller si è semplificato molto e può anche essere eseguito remotamente grazie alla nuova console Server Manager. Inoltre il modulo PowerShell per Active Directory consente agli amministratori di eseguire attività di configurazione e verifica in modo estremamente automatizzabile.

Corso SQL Server - Corso Hyper-V -Corso Windows Server – Corso asp.net

 Certificazione Microsoft

Migrazione Domain Controller Windows Server 2003 a Windows Server 2012 – Parte 1

Con l’uscita di Windows Server 2012 molte infrastrutture prenderanno la decisione di aggiornare i propri Domain Controller per poter trarre vantaggio dalle numerose funzionalità che sono state introdotte rispetto a Windows Server 2003 che rappresenta la versione di sistema operativo più datata da cui è ancora possibile eseguire la migrazione.

In questo articolo verranno analizzate le problematiche relative all’aggiornamento di un’infrastruttura Active Directory basata su Domain Controller Windows Server 2003 affinché si possano introdurre Domain Controller Windows Server 2012.

In particolare si analizzerà nel dettaglio lo scenario in cui si desidera dismettere un Domain Controller Windows Server 2003 rimuovendolo completamente dall’infrastruttura Active Directory per sostituirlo con un Domain Controller Windows Server 2012.

Data la complessità dell'argomento si è scelto di dividerlo in più articoli. Ecco la prima parte!

Novità in Active Directory

Rispetto a Windows Server 2003, nelle successive versioni di sistemi operativi, sono state introdotte diverse novità, anche in ambito Active Directory . Le sintetizzo nella seguente tabella.

Sistema operativo	Funzionalità	Requisiti
Windows Server 2008	· Supporto per la replica del SYSVOL (System Volume) tramite DFS (Distributed File System) che garantisce una replica più robusta e dettagliata · Supporto per Advanced Encryption Standard (AES 128 e AES 256) per il protocollo Kerberos · Informazioni sull’ultimo logon interattivo · Fine-grained password policies · Personal Virtual Desktops	Livello funzionale di dominio Windows Server 2008
Windows Server 2008 R2	· Memorizzazione nel token kerberos utente delle informazioni circa il tipo di autenticazione. · Supporto ai Managed Service Accounts	Livello funzionale di dominio Windows Server 2008
Windows Server 2008 R2	· Active Directory Recycle Bin	Livello funzionale di foresta Windows Server 2008
Windows Server 2012	· Kerberos armoring · Supporto da parte del KDC claim e compound authentication	Livello funzionale di dominio Windows Server 2012

Per ulteriori informazioni circa le novità in Active Directory legate ai nuovi livelli funzionali si vedaUnderstanding Active Directory Domain Services (AD DS) Functional Levels.
Vi sono inoltre anche una serie di novità riguardanti la gestione di Active Directory, quindi non correlate alle modifiche apportate al Directory Service, che sono state introdotte nelle versioni del sistema operativo successive a Windows Server 2003.

Funzionalità introdotte in Windows Server 2008

· Active Directory Domain Services auditing mediante l’introduzione della sottocategoria di policies di audit Directory Service Changes · Read-Only Domain Controllers · Restartable Active Directory Domain Services che consente di eseguire tasks come offline defragmentation, aggiornamenti del Domain Controller senza riavviare il sistema · Database Mounting Tool (Dsamain.exe) che consente di migliorare il processo di recovery visualizzando e confrontando i dati presenti in backup eseguiti in tempi diversi in modo da decidere quale ripristinare · Gestione degli Owner Rights · Nuovo formato ADMX e nuove funzionalità per gli Administrative template files · Starter Group Policy objects · Commenti per GPOs e policy settings · Network Location Awareness · Group Policy Preferences Corso SQL Server - Corso Hyper-V -Corso Windows Server – Corso asp.net  Certificazione Microsoft

Perché Windows Server 2012 gli spazi di stoccaggio di parità potrebbe eseguire lentamente

Recentemente sono stato la costruzione di un laboratorio basata su spazi di stoccaggio , una nuova funzionalità in Windows Server 2012. Il mio piano era quello di ospitare un Hyper-V sulla configurazione SMB per alcune macchine virtuali. Ho deciso di creare la configurazione con una striscia di parità in modo da poter ottimizzare l'uso della memoria che avevo, pur mantenendo una qualche forma di resilienza. Ho installato 3 x dischi SATA da 1 TB e configurato lo spazio di archiviazione, come richiesto. Ho creato la condivisione per la VM e iniziato a utilizzare la quota per memorizzare le macchine virtuali da un cluster Hyper-V che avevo costruito in precedenza.

Attraverso il processo di utilizzo delle macchine virtuali, ho notato che questi erano molto lento. Ho cominciato a studiare e ho visto che la VM tutti avevano problemi di prestazioni di scrittura su disco. Con indagini ancora di più, ho scoperto che aveva a che fare con le prestazioni del disco lento lo spazio di archiviazione. Ho testato questo copiando un file di 1,5 GB unbuffered (xcopy / J) allo spazio di parità. Velocità superato fuori a 25 MB / s. Ho deciso che ho iniziato ad esaminare singolarmente ogni disco, così ho rotto la striscia e testato ogni disco con la stessa lima 1,5 GB. Velocità raggiunto i 140MB / s. Piuttosto la differenza. Ho provato uno spazio specchio e che anche effettuata ad una velocità di circa 140MB / s.

Sembrava che tutto quello che mi veniva in mente funzionato senza problemi, tranne che per lo spazio di parità. Ma perché
Beh, ho chiesto in giro all'interno di Microsoft ed è stato sottolineato a questo documento:  spazi di stoccaggio - Progettare per le prestazioni . All'interno di questo documento ho trovato il pezzo seguente chiave di informazioni:

" L'avvertimento di uno spazio parità prestazioni di scrittura è bassa rispetto a quella di uno spazio di immagazzinaggio semplice o mirror, poiché dati e delle informazioni di parità devono essere letti ed elaborati prima di una nuova scrittura può verificarsi. Spazi di parità sono una scelta eccellente per i carichi di lavoro che sono quasi esclusivamente di lettura basato, altamente sequenziale, e richiedono resilienza, o carichi di lavoro che scrivono dati in grandi blocchi di accodamento sequenziali (come i backup di massa). "

Quindi, in realtà, il prodotto funziona come previsto, stavo solo cercando di usarlo per la cosa sbagliata! L'articolo va a dire che uno spazio di parità di 3 unità potrebbe essere migliorata utilizzando due unità SSD dedicati per la rivista, ma a questo punto lo spazio sarebbe più che probabile superare il costo dello spazio specchio e ancora non può rivolgersi al stessa velocità che lo spazio mirroring fornirebbe.

Morale della favola: Per carichi di lavoro pesanti che richiedono alta velocità, I / O casuali e la migliore capacità di recupero possibile, utilizzare lo spazio a specchio rispetto allo spazio di parità.

Corso SQL Server - Corso Hyper-V -Corso Windows Server – Corso asp.net

 Certificazione Microsoft

Microsoft SQL Server 2012 Best Practices Analyzer (BPA)

Microsoft SQL Server 2012 Best Practices Analyzer (BPA) è un potente strumento che esamina la configurazione e le impostazioni del vostro SQL Server 2012 istanze. Inoltre, lo strumento mette in evidenza le impostazioni che differiscono dalle raccomandazioni sulle migliori pratiche. Quando lo strumento rileva le impostazioni che non rispettano le procedure consigliate, il BPA fornisce anche consigli su come applicare le impostazioni per ridurre al minimo i potenziali problemi.

Il BPA ora include funzioni di valutazione diverse per l'intero stack di SQL Server. Lo strumento esegue la sua analisi non solo sul motore di database relazionale, ma anche su SQL Server Analysis Services (SSAS), SQL Server Integration Services (SSIS), e SQL Server Reporting Services (SSRS). La valutazione comprende anche la replica e le impostazioni di configurazione. Lo strumento fornisce diversi controlli, tra cui:

• SSAS: 33 controlli
• Motore di database relazionale: 59 controlli
• SSIS: 3 controlli
• SSRS: 4 controlli
• Replica: 8 Controlli
• Setup: 2 controlli

Lo strumento può utilizzare PowerShell per eseguire la scansione remota computer locali e remoti. Questo compito richiede di modificare le impostazioni di PowerShell per aumentare il numero massimo di conchiglie simultanee per utente e richiede l'accettazione esplicita durante l'installazione. Per ulteriori informazioni sulla comunicazione remota di PowerShell, vedere l'articolo "Microsoft di installazione e configurazione per la gestione remota Windows . "

Lineamenti

Una volta installato il BPA, richiamare lo strumento e scegliere un server di destinazione per la scansione nelle impostazioni di casa. Successivamente, le parti selezionate dello stack di SQL Server che si desidera che il BPA di esaminare. Ad esempio, la figura 1 mostra come escludere le impostazioni di replica selezionando le scelte appropriate sulle impostazioni di immettere i parametri.

Figura 1: Impostazioni di replica Escluse 

Dopo aver effettuato le selezioni, il BPA esegue la scansione dei parametri specificati.Quando il BPA è terminato, sarete in grado di rivedere i risultati delle analisi attraverso una visione d'insieme o di una relazione dettagliata, come la figura 2 mostra.

Figura 2: Risultati dell'analisi BPA 

È possibile selezionare la radio Risultati pulsante per visualizzare i risultati delle analisi BPA.In alternativa, fare clic sul pulsante di opzione raccolti dati mostra i dati di configurazione della scansione BPA raccolti. Per entrambi i tipi di report, fare clic su l'opzione Filtro per individuare il nome del computer per il server di scansione per visualizzare informazioni dettagliate. Poi si può cercare il valore sottomodello che correla ai vari parametri della scansione, come ad esempio Motore Submodel = per una scansione delle pratiche migliori motori di database.

È inoltre possibile salvare i risultati utilizzando l'opzione Esporta rapporto. Se il BPA ha restituito un sacco di risultati, si potrebbe desiderare di filtrare i vari aspetti della relazione utilizzando l'opzione Filtro. È inoltre possibile leggere il report tramite Microsoft Baseline Configuration Analyzer (MBCA) GUI se si ha familiarità con lo strumento.

Requisiti di sistema

Il BPA viene eseguito sui seguenti sistemi operativi: Windows 8 , di Windows Server 2012 , Windows 7, Windows Server 2008 R2 e Windows Server 2008. Lo strumento funziona anche su qualsiasi edizione di SQL Server 2012, ma non è compatibile. Il BPA richiede PowerShell 2.0 e MBCA 2.0. Inoltre, l'utente deve essere un amministratore del computer di destinazione perché MBCA richiede privilegi di amministratore. Inoltre, l'utente deve disporre di privilegi di amministratore sul sistema l'istanza di destinazione di SQL Server.

È possibile scaricare il BPA dall'Area download Microsoft , dove è anche possibile scaricare lo strumento MBCA. Come sempre, SQL Server Pro vuole sentire i vostri commenti al forum di discussione strumento Tempo .

Corso SQL Server - Corso Hyper-V -Corso Windows Server –

 Certificazione Microsoft