Archivio

Archivio per novembre 2009

Cisco Tuning

15 Novembre 2009

Tuning dello stack IP

I comandi successivi servono ad effettuare un miglioramento dello stack IP del routerl. Il primo abilita l’algoritmo di Nangle per la gestione del controllo della congestione (RFC 896). Il secondo limita il tempo di timeout dei pacchetti Syn, il default è di 30 secondi. Il terzo e il quarto nel rispetto degli RFC 1323 e RFC2018.

service nagle
ip tcp synwait-time 10
ip tcp window-size 2144
ip tcp selective-ack

Tuning della CPU

Attraverso il seguente comando si garantisce il tempo minimo della CPU per i processi vitali (500 millisecondi)

scheduler-interval 500

Sui Cisco 7200 e 7500 si può anche inserire il seguente comando, che abilita 500 microsecondi per ciclo di clock sul fast-packet switching e 100 microsecondi per cliclo di clock per process-switching:

scheduler allocate 500 100

Share

Cisco ,

Testare la qualità della linea ADSL

15 Novembre 2009

Spesso tra le  varie problematiche che si possono incontrare durante l’installazione di linee ADSL, la qualità offerta e’ uno di questi.  I router  Cisco ci mettono a disposizione un comando specifico per verificarne l’efficienza.

Show dsl interface atm

Tra i vari parametri che  vengono visualizzati ci soffermeremo su due di questi che già da soli danno un’ idea della qualita’ della linea. Il primo è il rumore di fondo (noise) che viene espresso in decibel, ed il secondo è l’attenuazione (attenuation) sempre espresso in decibel. Con questi due parametri si puo’ gia’ avere un’idea di ciò che il gestore sta erogando.

Il primo parametro viene visualizzato con la seguente espressione;Noise Margin:     18.00 dB il concetto di rumore è abbastanza semplice, più alto è il rumore e minore è la qualita’ della linea. Diciamo che intorno ai 20.0 dB la linea puo’ essere utilizzata senza alcun problema , per grandezze inferiori si potrebbero avere dei problemi che consistono nella perdita di pacchetti.

L’altro parametro è l’attenuazione, anche lui espresso in Decibel e viene visualizzato nel seguente modo; Attenuation : 10.0 dB. Questo numero varia a seconda della qualita’ della linea e del rumore stesso (noise), infatti maggiore sono i Decibel di “Noise Margin” e inferiore è l’attenuazione. Per intenderci l’attenuazione puo’ essere interpretata come la perdita di segnale tra il punto A ed il punto B della rete.

La soluzione a questi problemi può essere: Sotituzione del doppino ADSL, sotituzione del filtro ADSL o diminuzione della distanza tra la centrale che eroga il servizio ed il router che lo utilizza.

Share

Cisco ,

Migrare un dominio NT 4 a windows 2000/2003

15 Novembre 2009

Un ottimo tutorial per la migrazione di un server nt4 domain controller a Windows 2000/2003 tratto dal sito di http://www.andreabeggi.net

Negli ultimi due anni mi è capitato sovente di dover aggiornare un dominio NT4 ad uno Active Directory Windows 2000 o 2003, e nell’ultimo periodo anche i ritardatari si sono decisi ad effettuare la migrazione. Oltre alle ben note caratteristiche introdotte dalla piattaforma, va segnalato che tra un mese circa MS cesserà di fornire supporto per NT, e l’assenza di aggiornamenti è un fattore critico. Inoltre ci sono problemi con le nuove normative sulla sicurezza e la privacy che dovrebbero entrare in vigore tra breve.
Dopo diverse migrazioni ho trovato un metodo abbastanza sicuro e veloce per effettuare l’aggiornamento.

Intanto tutte le migrazioni che ho fatto sono state effettuate in occasione dell’acquisto di un nuovo server, dato che, un server che funziona non si tocca, ma si sostituisce quando è vecchio.
In un dominio NT, l’aggiornamento fa fatto partendo dal Primary Domain Cantroller (PDC), seguito poi dai Backup Domain Controller (BDC), se ci sono.
Naturalmente il server in attività è troppo vecchio per essere aggiornato, ed inoltre non lo vogliamo assolutamente toccare finchè non siamo sicuri del successo dell’operazione. D’altronde non voglio che il nuovo server abbia un s.o. “sporco” che è stato caricato da un aggiornamento. Ultima cosa: voglio assolutamente un backup del database di dominio, se qualcosa andasse storto.
Per fare tutto questo ho bisogno di due PC abbastanza recenti da usare rispettivamente come backup e “ponte” per l’aggiornamento, li chiameremo A e B (*). Si procede così:
Come prima cosa fate un backup completo del server, non si sa mai. Intallate NT4 server su A, rendendolo BDC del dominio, e sincronizzate il database da “gestione server”. Controllate sui log l’avvenuta sincronia, dopodichè scollegate A dalla rete e mettetelo da parte: è il backup del database del dominio, che vi permette di ritirare su la struttura se qualcosa va male.
Installate NT4 Server anche su B, rendendolo PDC, questa volta. Sincronizzate il dominio come avete fatto prima.
Adesso inizia la migrazione vera e propria. Aggiornate B da Windows NT 4 Server a Windows Server 2000/2003.
Al termine dell’aggiornamento, se tutto è andato a buon fine il dominio è già migrato, ed è in modalità mista. Durante l’aggiornamento la rete continua a funzionare, tranne che per un breve periodo durante il riavvio dei servizi di rete sul server.
Adesso potete preparare il vostro nuovo server con Windows 200x. Rendetelo Domain Controller (DC) tramite un dcpromo. Il vostro dominio AD al momento ha 2 DC. Configurate molto attentamente il servizio DNS. Controllate lo stato del dominio e della sua replicazione tramite dcdiag. Tornate sulla macchina B e abbassatela a server membro, usando sempre dcpromo. Ricontrollate dcdiag, spegnete la macchina B e rimuovetela dal dominio e dall’elenco dei DC. Spegnete e rimuovete dal dominio anche il vecchio server, che a questo punto non serve più.
Ecco fatto: il dominio è migrato. Se avete anche dei BDC potete tenerli così, oppure sostituirli.
Adesso terminate l’installazione dei servizi di cui avete bisogno. (Una guida qui.)
Se qualcosa andasse storto, in qualunque momento potrete ripristinare il database del dominio staccando i server sui quali state lavorando, riattaccando la macchina A e promuovendola PDC.
Sui client non va fatta nessuna operazione.

Share

Microsoft

Active Directory disaster recovery: sostituzione del root domain controller

15 Novembre 2009

Introduzione

Active Directory rappresenta il baricentro di un’infrastruttura informatica basata su tecnologia Microsoft. L’accesso alle risorse, la funzionalità dei servizi, la configurazione degli ambienti di lavoro dipendono da Active Directory. Diventa quindi essenziale progettare l’infrastruttura in modo che questo fondamentale servizio sia ridondato e predisporre delle procedure per ripristino in casi in cui occorre eseguire un disaster recovery.

Sommario

Scenario

In questo scenario prenderemo in esame un’infrastruttura ipotetica con un’unica foresta a singolo dominio test.local in cui vi siano due domain controller:

  • il server SRVDC01 che detiene i cinque ruoli FSMO (master schema, master per la denominazione dei domini, master RID, master emulatore PDC e master infrastrutture) ed configurato come server DNS e Global Catalog;
  • il server SRVDC02 configurato come server DNS e Global Catalog.

Si noti che in una struttura a singolo dominio non sono presenti phantom, quindi il master infrastrutture non ha funzioni da svolgere. Questo significa che ruolo master infrastrutture può essere collocato su un qualsiasi controller di dominio indipendentemente dal fatto che sua o meno configurato come catalogo globale. I phantom sono oggetti di basso livello del database Active Directory utilizzati per operazione di gestione interna e non visibili tramite LDAP o Active Directory Service Interfaces (ADSI). Per ulteriori informazioni in merito si vedano Collocazione e ottimizzazione di FSMO in controller di dominio Active Directory e Phantoms, tombstones and the infrastructure master.

Si supponga ora che il server SRVDC01 cessi di funzionare rendendo così non disponibili i ruolo FSMO, per ripristinare la funzionalità di Active Directory occorre eseguire le seguenti operazioni:

  • Assegnare (seize) i ruoli FSMO sul server SRVDC02 in quanto, dal momento che il server SRVDC01 non è disponibile, non è possibile trasferirli.
  • Rimuovere da Active Directory i riferimenti al server SRVDC01.
  • Assicurarsi che i client abbiano il sever SRVDC02 configurato come DNS e non abbiano più riferimenti al server SRVDC01.

Si noti che sebbene il server SRVDC01 non sia disponibile i client possono continuare ad autenticarsi se su di essi è stato configurato come DNS secondario il server SRVDC02 grazie al fatto che entrambi i DC sono Global Catalog. Il Global Catalog (GC) contiene una copia parziale in sola lettura di tutti gli oggetti definiti nei domini della foresta il cui insieme e l’aggiornamento dei loro attributi è frutto della replica multimaster. Le attività che prevedono l’utilizzo del GC sono:

  1. ricerca di oggetti a livello di foresta eseguite tramite LDAP su porta TCP 3268 o su porta TCP 3269 se viene utilizzato LDAP con SSL. Un esempio di utilizzo del GC è lo snap-in Active Directory Users and Computers quando si esegue una ricerca che ha come scope Entire Directory un altro esempio è l’Infrastructure Master durate la fase di aggiornamento dei phantom record;
  2. user logon in un dominio con livello funzionale Windows 2000 nativo o successivo in quanto a partire da versione dello schema di Active Directory sono disponibili i gruppi universali e ciò comporta che durante la fase di autenticazione il DC contatti il GC per ottenere i SID dell’utente e dei gruppi universali a cui appartiene (anche quelli definiti esternamente al dominio).
  3. UPN logon se l’utente utilizzi la sintassi UPN (User Principal Name) per l’autenticazione, in questo caso il DC contatta il GC fornendo il valore dell’attributo user-PrincipalName dell’oggetto User per ottenere il DN dell’utente e ricavare in questo modo il dominio di appartenenza dell’account. Inoltre il GC viene anche utilizzato nel caso vi sia un trust tra due foreste con livello funzionale Windows Server 2003 o successivo durante l’autenticazione UPN di un  account definito esternamente alla foresta su cui si sta eseguendo l’autenticazione (in questo il GC contatta il GC dell’altra foresta per ottenere le informazioni sull’account).
  4. Exchange client infatti i client Outlook durate l’apertura dell’Address Book o durate la compilazione del campo “Da” di una mail contattano il GC specificato dal server Exchange  per ottenere la GAL (Global Address List).
  5. Client Active Directory che utilizzano la rubrica di Windows per ricercare persone e contatti memorizzati in Active Directory.

Nel caso di una foresta a dominio singolo ogni DC può servire tutte le richieste di logon (incluse le UPN) senza utilizzare il GC, ma solo un DC configurato come GC può rispondere a richieste LDAP.

L’indisponibilità dei ruoli master impedisce l’esecuzione delle seguenti operazioni e genera alcuni disservizi:

  1. la modifica dello schema della foresta in quanto tale operazione, che può essere eseguita da un qualunque DC, prevede la connessione al DC che detiene il ruolo di Schema Master e che è anche l’unico DC della foresta a possedere una copia in scrittura dello Schema Partition;
  2. la creazione di un nuovo dominio in quanto tale operazione prevede la connessione al DC che detiene il ruolo Domain Naming Master che provvede a verificare che il dominio non sia già stato definito e ad attribuirgli un identificativo GUID univoco, inoltre il Domani Naming Master si occupa anche dell’autorizzazione alla cancellazione di un dominio e della creazione e cancellazione di una Application Partition, nonchè della validazione delle operazioni di modifica dei nomi dei domini tramite il tool RENDOM;
  3. la richiesta di un nuovo pool di RID (Relative ID) in quanto tale operazione viene servita da DC che detiene il ruolo di Relative ID Master, i RID sono utilizzati dai DC durate la creazione di oggetti Security Principal (User, Group o Computer) per attribuirgli identificativi Security ID (SID) univoci nel formato S-1-5-Y1-Y2-Y3-Y4 (dove Y1-Y2-Y3 è il domain SID e Y4 il RID). Ciò significa che esaurito il pool di RID corrente non sarà più possibile creare oggetti Security Principal (un pool di RID è composto da 500 RID e quando si raggiunge le 100 unità disponibili viene richiesto un nuovo pool). Il Relative ID Master è contattato anche per autorizzare lo spostamento di un oggetto in un altro dominio tramite ad esempio Active Directory Migration Tool per evitare che possa essere spostato in due domini diversi;
  4. l’autorizzazione del raise del livello funzionale del dominio in quanto tale operazione viene servita da DC che detiene il ruolo di PDC Emulator. Inoltre la modifica della password potrebbe avere tempi di convergenza maggiori poiché in seguito ad un cambio password di un account utente o computer il DC interessato comunica la nuova password al PDC Emulator e nel caso un altro DC durante la fase di autenticazione rilevi una password errata prima di comunicare l’errore verifica se il PDC Emulator non abbia ricevuto una modifica delle credenziali (se il ruolo PDC Emulator non è disponibile occorre attendere la replica di Active Directory affinché il secondo DC validi la nuova password). Potrebbero verificarsi anche problemi di sincronizzazione oraria dal momento che il PDC Emulator è la fonte di sincronizzazione del Windows Time Service infatti i DC di un dominio utilizzano il PDC Emulator del proprio dominio come time source e i PDC Emulator dei vari domini utilizzano come time source il PDC Emulator del Forest Root Domain. Infine il PDC Emulator è utilizzato di default dallo snap-in di creazione o modifica di un Group policy Object, ma tramite DC Options è possibile selezionare un altro DC;
  5. possibili incoerenze durante la visualizzazione degli utenti/gruppi nei domini esterni utilizzati nei gruppi del dominio (phantom record) in quanto la relazione GUID-SID-DN di tali utenti/gruppi definiti nei domini esterni viene mantenuta aggiornata dal DC che detiene il ruolo di Infrastructure Master. Il corretto funzionamento dell’Infrastructure Master prevede infatti che la visualizzazione dei membri di tali utenti e dei membri di tali gruppi non produca incoerenze causate dalla modifica del Distinguished Name (DN), per spostamento nel dominio, o del SID, per spostamento in altri domini. L’Infrastrucure Master per svolgere questa attività verifica e aggiorna periodicamente eventuali differenze tra il proprio database locale di phantom record e le informazioni contenute nei Global Catalog e replica tale database a tutti i DC del dominio.

Assegnazione (seize) dei ruoli FSMO

Per eseguire il seize dei ruoli FSMO sul server SRVDC02 è possibile utilizzare l’utility a riga di comando Ntdsutil, utilizzando la seguente procedura valida per Windows 2000 Server, Windows 2003 Server e Windows 2008 Server.

  1. Autenticarsi al server SRVDC02 con credenziali di amministratore di dominio.
  2. Aprire un prompt dei comandi.
  3. Digitare il comando ntdsutil.
  4. Al prompt ntdsutil: digitare il comando roles.
  5. Al prompt fsmo maintenance: digitare il comando connections.
  6. Al prompt connections: digitare connect to server srvdc02.
  7. Verificare che la connessione sia avvenuta controllado di ottenere il seguente output.
    Connesso a srvdc02 tramite le credenziali dell’utente connesso localmente.
  8. Al prompt server connections: digitare quit.
  9. Al prompt fsmo maintenance: digitare il comando seize domain naming master.
  10. Confermare il messaggio di conferma della requisizione del ruolo.
  11. Al prompt fsmo maintenance: digitare il comando seize schema master.
  12. Confermare il messaggio di conferma della requisizione del ruolo.
  13. Al prompt fsmo maintenance: digitare il comando seize infrastructure master.
  14. Confermare il messaggio di conferma della requisizione del ruolo.
  15. Al prompt fsmo maintenance: digitare il comando seize pdc.
  16. Confermare il messaggio di conferma della requisizione del ruolo.
  17. Al prompt fsmo maintenance: digitare il comando seize rid master.
  18. Confermare il messaggio di conferma della requisizione del ruolo.
  19. Al prompt fsmo maintenance: digitare il comando quit.
  20. Al prompt ntdsutil: digitare il comando quit.

Per verificare che i ruoli siano stati correttamente assegnati è possibile utilizzare il comando netdom query fsmo che dovrà restituire il seguente output:

Schema owner SRVDC02.test.local

Domain role owner SRVDC02.test.local

PDC role SRVDC02.test.local

RID pool manager SRVDC02.test.local

Infrastructure owner SRVDC02.test.local

The command completed successfully.

In Windows 2003 Server il tool a riga di comando Netdom è contenuto nei Support Tools, mentre in Windows 2008 Server e successivi è nativamente presente nel sistema. In Windows 2008 Server R2 grazie alla presenza di PowerShell, la nuova shell a riga di comando basata sul .NET framework 2.0, è possibile utilizzare il cmdlet Move-ADDirectoryServerOperationMasterRole per trasferire i ruoli Fsmo.

Per ulteriori informazioni si vedano:

Rimozione dei riferimenti del Domain Controller

Dal momento che si è reso necessario il seize dei ruoli si presuppone che il server SRVDC01 non tornerà più ad essere disponibile e quindi occorre rimuovere da Active Directory ogni suo riferimento. Inoltre va precisato che anche qualora SRVDC01 tornasse ad essere operativo non dovrà più essere connesso alla rete e andrà formattato.

Per eseguire l’eliminazione dei riferimenti del server SRVDC01 da Active Directory verrà utilizzato ancora il tool Ntdsutil che a partire dalla versione inclusa in Windows 2003 Server SP1 e successivi è in grado di svolgere le seguenti operazioni quando viene eseguito il metadata cleanup:

  • Rimozione dei riferimenti NTDSA o NTDS Setting del DC da eliminare.
  • Rimozione delle impostazioni di replica AD relative al DC da eliminare.
  • Rimozione del computer account del DC da elinare.
  • Rimozione delle impostazioni relative al FRS (File Replication System) relative al DC da eliminare.
  • Viene tentato il seize dei ruoli FSMO posseduti dal DC che si intende eliminare.

Di seguito viene riportata la procedura da eseguire su sistemi Windows 2003 SP1 o successivi per rimuovere i riferimenti del server SRVDC01 in Active Directory.

  1. Autenticarsi al server SRVDC02 con credenziali di amministratore di dominio.
  2. Aprire un prompt dei comandi.
  3. Digitare il comando ntdsutil.
  4. Al prompt ntdsutil: digitare il comando metada cleanup.
  5. Al prompt metadata cleanup: digitare il comando connections.
  6. Al prompt connections: digitare connect to server srvdc02.
  7. Verificare che la connessione sia avvenuta controllando di ottenere il seguente output.
    Connesso a srvdc02 tramite le credenziali dell’utente connesso localmente.
  8. Al prompt server connections: digitare quit.
  9. Al prompt metadata cleanup: digitare il comando select operation target.
  10. Al prompt select operation target: digitare il comando list domains.
  11. Viene restituita la lista dei domini tramite il seguente output
    Trovati 1 domini
    0 – DC=test,DC=local
  12. Al prompt select operation target: digitare il comando select domain 0
    (per selezionare il dominio in cui si trova il server da rimuovere SRVDC01).
  13. Viene restituito il seguente output
    Nessun sito corrente
    Dominio – DC=test,DC=local
    Nessun server corrente
    Nessun contesto dei nomi attivo
  14. Al prompt select operation target: digitare il comando list sites.
  15. Viene restituita la lista dei siti tramite il seguente output
    Trovati 1 siti
    0 – CN=Nome-predefinito-primo-sito,CN=Sites,CN=Configuration,DC=test,DC=local
  16. Al prompt select operation target: digitare il comando select site 0
    (per selezionare il sito in cui si trova il server da rimuovere SRVDC01).
  17. Viene restituito il seguente output
    Sito – CN=Nome-predefinito-primo-sito,CN=Sites,CN=Configuration,DC=test,DC=local
    Dominio – DC=test,DC=local
    Nessun server corrente
  18. Al prompt select operation target: digitare il comando list server in site.
  19. Viene restituita la lista dei server tramite il seguente output
    Trovati 2 server
    0 – CN=SRVDC01,CN=Servers,CN=Nome-predefinito-primo-sito,CN=Sites,CN=Configuration,DC=test,DC=local
    1 – CN=SRVDC02,CN=Servers,CN=Nome-predefinito-primo-sito,CN=Sites,CN=Configuration,DC=test,DC=local
  20. Al prompt select operation target: digitare il comando select server 0
    (per selezionare il server da rimuovere SRVDC01).
  21. Viene restituito il seguente output
    Sito – CN=Nome-predefinito-primo-sito,CN=Sites,CN=Configuration,DC=test,DC=local
    Dominio – DC=test,DC=local
    Server – CN=SRVDC01,CN=Servers,CN=Nome-predefinito-primo-sito,CN=Sites,CN=Configuration,DC=test,DC=local
    Oggetto DSA – CN=NTDS Settings,CN=SRVDC01,CN=Servers,CN=Nome-predefinito-primo- sito,CN=Sites,CN=Configuration,DC=test,DC=local
    Nome host DNS – SRVDC01.test.local
    Oggetto computer – CN=SRVDC01,OU=Domain Controllers,DC=test,DC=local
    Nessun contesto dei nomi attivo
  22. Al prompt select operation target: digitare quit.
  23. Al prompt metadata cleanup: digitare il comando remove selected server.
  24. Confermare il messaggio di conferma.
  25. Viene restituito il seguente output
    Rimozione di metadati FRS per il server selezionato.
    Ricerca di membri FRS in “CN=SRVDC01,OU=Domain Controllers,DC=test,DC=local.
    Rimozione dei membri FRS “CN=SRVDC01,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=test,DC=local.
    Eliminazione della sottostruttura in “CN=SRVDC01,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=test,DC=local.
    Eliminazione della sottostruttura in “CN=SRVDC01,OU=Domain Controllers,DC=test,DC=local.
    Il tentativo di rimuovere le impostazioni FRS su CN=SRVDC01,CN=Servers,CN=Nome-predefinito-primo-sito,CN=Sites,CN=Configuration,DC=test,DC=local non è riuscito per il seguente motivo: Impossibile trovare elemento.
    È ancora in corso la pulitura dei metadati.
    CN=SRVDC01,CN=Servers,CN=Nome-predefinito-primo-sito,CN=Sites,CN=Configuration,DC=test,DC=local rimossi dal server srvdc02
  26. Al prompt metadata cleanup: digitare quit.
  27. Al prompt ntdsutil: digitare il comando quit.
  28. Aprire lo snap-in Siti e servizi di Active Directory (dssite.msc).
  29. Selezionare il nodo Sites.
  30. Selezionare il sito a cui il server da rimuovere SRVDC01 appartiene (in questo caso Nome-predefinito-primo-sito).
  31. Selezionare il nodo Servers.
  32. Selezionare il server SRVDC01 e quindi selezionare Azione -> Elimina.

Per eseguire l’eliminazione dei riferimenti del server SRVDC01 dal DNS utilizzare la seguente procedura:

  1. Aprire lo snap-in DNS (dnsmgmt.msc /s).
  2. Nella zona diretta _msdcs.dominio rimuovere il record CNAME relativo al server SRVDC01. Nel caso il server non venga reinstallato e promosso Domain Controller con lo stesso nome eliminare anche i record NS (tramite la scheda Server dei nomi delle proprietà della zona) e i vari record SRV.
  3. Nella zona diretta relativa al dominio rimuovere il record A (Host) relativo al server SRVDC01. Nel caso il server non venga reinstallato e promosso Domain Controller con lo stesso nome eliminare anche i record NS (tramite la scheda Server dei nomi delle proprietà della zona) e i vari record SRV e impostare su SRVDC02 il record CNAME nella zona delegata _msdcs (tramite la scheda Server dei nomi delle proprietà della zona).

Terminata l’eliminazione dei riferimenti del server SRVDC01 in Active Directory e nel DNS occorre assicurarsi che i client non continuino ad utilizzarlo con server DNS, assicurarsi quindi che il DHCP non fornisca ai client tale impostazione.

Per ulteriori informazioni si vedano:

Conclusioni

In questo scenario grazie al fatto che nell’infrastruttura sono prendi almeno due DC e che si ha la ridondanza del GC e del servizio DNS nonostante cessi di funzionare il server che detiene i ruoli FSMO i disservizi risultano contenuti. Infatti gli utenti possono continuare ad autenticarsi e ad operare normalmente e anche la procedura di disaster recovery risulta non eccessivamente complessa e soprattutto non comporta interruzioni di servizio.

Share

Microsoft

Funzionamento e Diagnostica di Active Directory

14 Novembre 2009

Una copia di questo articolo la puoi trovare anche su Microsoft Technet. qui

Introduzione
Il seguente articolo analizza l’architettura di Active Directory per comprenderne il funzionamento e descrive una serie di tools che consentono di controllarne il buon funzionamento.

Le utility DCDIAG (Domain Controller Diagnostics Tool), NETDOM (Windows Domain Manager), PORTQRY (Port Query), NTDSUTIL e ADSIEdit (ADSI Edit) fanno parte dei support tools che sono contenuti nella cartella support/tools del CD di Windows Server 2003 oppure sul primo CD di Windows Server 2003 R2, in alternativa è possibile scaricarli al seguente link Windows Server 2003 Service Pack 1 32-bit Support Tools.

Sommario
Diagnostica funzionalità rete
Condivisioni Netlogon e Sysvol
Verifica delle condivisioni Netlogon e Sysvol
Global Catalog
Verificare se il DC è stato eletto come Global Catalog
Replica di Active Directory e Ruoli FSMO
Verifica funzionalità Active Directory
Verifica funzionalità replica con altri Domain Controller
Verifica detenzione ruoli master
Verifica della disponibilità dei ruoli master operazioni
Servizio DNS
Verifica funzionalità DNS del Domain Controller
Struttura fisica di Active Directory
Verifica dell’integrità del database di Active Directory

DIAGNOSTICA FUNZIONALITA’ DI RETE
Un dominio Windows 2000/2003 è sempre identificato da due nomi:

– Nome DNS. E’ il nome completo DNS o FQDN (Fully Qualified Domain Name) ed è limitato a 255 caratteri, 63 per ogni etichetta (label) e rappresenta il nome nativo del dominio.
– Nome NetBIOS. E’ utilizzato per compatibilità con i sistemi pre-Windows 2000 ed è limitato a 15 caratteri. Coincide per default con i primi 15 caratteri della prima label del FQDN DNS del dominio.
Per verificare che la funzionalità dei servizi di rete su cui si basa Active Directory è possibile utilizzare l’utility NETDIAG (Network Connectivity Tester):

* Test del servizio DNS: NETDIAG /test:dns
* Test dell’elenco dei controller di dominio: NETDIAG /test:dclist
* Test del rilevamento dei controller di dominio: NETDIAG /test:dsgetdc
* Test di LDAP (Microsoft Lightweight Directory Access Protocol): NETDIAG /test:ldap
* Test dell’appartenenza al dominio: NETDIAG /test:member
* Per verificare la registrazione di NetBIOS, del servizio DNS e dei servizi utilizzare il seguente comando:

NETDIAG /debug

L’ utility NETDIAG registra automaticamente l’output sul file NetDiag.log che viene creato nella directory di esecuzione consentendo di esaminare il risultato del test diagnostico in modo più agevole.

Per maggiori informazioni sull’utilizzo di NETDIAG si veda al seguente articolo della Knowledge Base Microsoft HOW TO: Utilizzare lo strumento Diagnostica di rete (Netdiag.exe) in Windows 2000.

CONDIVISIONI NETLOGON e SYSVOL
Nei Domain Controller (DC) Windows NT gli script di logon venivano memorizzati nella condivisione amministrativa NETLOGON (che corrisponde alla directory %SystemRoot%\System32\Repl\Import\Scripts), mentre nei DC Windows 2000/2003 risiedono in SYSVOL (che corrisponde alla directory %SystemRoot%\Sysvol). Dcpromo modifica il valore di registro che definisce il path della condivisione NETLOGON facendola puntare a %SystemRoot%\Sysvol\Sysvol\NomeDominio\Scripts per consentire l’operatività ai client Windows 9x e Windows NT.

Ogni modifica alla directory %systemroot%\SYSVOL su un qualunque DC viene replicata agli altri DC utilizzando il servizio Replica file (FRS) basato su RPC (Remote Procedure Call).

La struttura della condivisione SYSVOL è la seguente:

* Sysvol\Sysvol\NomeDominio\Policies (corrispondente alla directory %SystemRoot%\Sysvol\NomeDominio\Policies) che contiene i Group Policy Template (ADM templates)
* Sysvol\Sysvol\NomeDominio\Scripts (corrispondente alla directory %SystemRoot%\Sysvol\NomeDominio\Scripts) che contiene gli scripts

VERIFICA DELLE CONDIVISIONI NETLOGON E SYSVOL
Per verificare se il Domain Controller condivide Netlogon e Sysvol e che i privilegi di logon necessari alla replica siano impostati è possibile utilizzare l’utility DCDIAG:

DCDIAG /test:frssysvol

DCDIAG /test:netlogons

Per maggiori informazioni sulla condivione SYSVOL si veda il seguente articolo della Knowledge Base Microsoft: How to rebuild the SYSVOL tree and its content in a domain.

GLOBAL CATALOG
In ogni domino è necessario avere un Global Catalog (GC) server e per impostazione predefinita al primo DC del dominio è assegnato automaticamente tale ruolo. Il GC contiene una replica completa di tutti gli oggetti di directory nel dominio host e una parziale di tutti gli oggetti di directory in tutti i domini della struttura. Il compito principale del GC consiste nel fornire autenticazione per gli accessi. Inoltre, poiché contiene informazioni su tutti gli oggetti in tutti i domini dell’insieme di strutture, consente la ricerca di oggetti a livello generale indipendentemente dal dominio di appartenenza di ciascun utente e/o computer fornendo informazioni sulle ubicazioni in cui è possibile trovare l’oggetto evitando query inutili nei domini. E’ possibile configurare un DC come GC e aggiungere GC ad un dominio per accelerare i tempi di risposta per le richieste di accesso e di ricerca.

VERIFICARE SE IL DC E’ STATO ELETTO COME GLOBAL CATALOG
Per verificare se un DC è stato eletto come Global Catalog e se, una volta inserito il flag Global Catalog, sia i grado di accettare richieste sulla porta TCP 3268 è possibile utilizzare l’utility PORTQRY e controllare il valore di isGlobalCatalogReady sia TRUE.

portqry -n -e 3268 -p tcp

Per maggiori informazioni sull’utilizzo di PORTQRY si veda al seguente articolo della Knowledge Base Microsoft HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues.

REPLICA DI ACTIVE DIRECTORY E RUOLI FSMO
Il database di Active Directory non ha una struttura monolitica ma è organizzato in partizioni o naming context che identificano strutture gerarchiche di oggetti, ciascuna delle quali costituisce un’unità di replicazione indipendente. Le partizioni Active Directory possono essere di tipo generale oppure di tipo applicativo (Active Directory Partition ADP).

Le partizioni generali possono essere di tre specie:

* Schema Partition. Contiene la definizioni degli oggetti (attributi e classi) utilizzabili in Active Directory (user, group, computer, organizational unit, etc…) e delle regole di utilizzo. Esiste una sola Schema Partition per ogni ciascuna foresta.
* Configuration Partition. Contiene informazioni generali sulla struttura e la composizione di una foresta (site, subnet, partizioni che compongono la foresta, dc, etc…). Esiste una sola Configuration Partition per ogni ciascuna foresta.
* Domain Partition. Contiene informazioni sugli oggetti creati in ogni dominio (user, group, computer, organizational unit, etc…). Esiste una sola Domain Partition per ogni dominio appartenente alla stessa foresta.

Le informazioni della Schema Partition e della Configuration Partition sono comuni a tutti i domini della foresta e quindi verranno replicate a tutti i DC della foresta, mentre le informazioni della Domain Partition sono private del dominio e quindi verranno replicate solo ai DC dello stesso dominio.

Le partizioni applicative possono essere di due specie:

* ADP builtin. Sono quelle dedicate al DNS (DomainDnsZones e ForestDnsZones) create automaticamente all’atto della creazione del dominio, nel caso si scelga di installare e configurare il servizioDNS dal wizard Dcpromo.
* ADP custom o personalizzate. Possono essere create manualmente per ospitare informazioni riguardanti applicazioni integrate in Active Directory (AD-aware)

Il processo di replica di Active Directory mantiene allineate le Directory Partition dei DC tramite una tipologia multimaster incrementale che consente di effettuare modifiche su qualsiasi DC e far sì che questo fornisca agli altri DC soltanto le differenze rispetto all’ultima sincronizzazione avvenuta. Per minimizzare i conflitti dovuti a modifiche dello stesso oggetto su DC diversi Active Directory implementa la replica a livello di singolo attributo, I DC, infatti, a seguito di una modifica aggiornano lo stamp associato all’attributo che è compostato da un Version Number (incrementato ad ogni modifica), un Timestamp (data e ora della modifica) e da un Server GUID (contenente il GUID del DC su cui è avvenuta la modifica). Nella comparazione degli stamp si considera il Version Number maggiore, nel caso ugualianza si considera il Timestamp maggiore e se anche il Timestamp è uguale si valuta il Server GUID.

Allo scopo di evitare conflitti di replica non risolvibilit tramite la comparazione degli stamp, Active Directory introduce l’amministrazione centralizzata di alcune operazioni, in altre parole alcune attività possono essere eseguite esclusivamente a seguito dell’autorizzazione data dal DC in possesso del ruolo associato alla specifica tipologia di operazione. Tali ruoli sono definiti flexible o Floating Single Master Operations (FSMO) in quanto è possibile spostare un ruolo assegnandolo ad un altro DC.

I ruoli FSMO sono cinque:

* Schema Master. Lo Schema Master è l’unico DC della foresta che possiede una copia i scrittura della Schema Partition (ciò significa che la modifica dello schema può essere seguita da un qualunque DC, ma prevede la connessione diretta con lo Schema Master).
* Domain Naming Master. Il Domain Naming Master è unico nella foresta e viene contattato quando è necessario creare un dominio per verificare che non sia già stato definito e ottenere un identificatore GUID univoco. Il Domain Naming Master è responsabile anche dell’autorizzazione alla cancellazione di un dominio, della validazione durante le operazioni di modifica dei nomi di dominio tramite il tool RENDOM.EXE e della creazione e cancellazione di una Application Directory Partition.
* Relative Identifier Master. Il Relative Identifier Master è unico nel dominio ed è responsabile della distribuzione dei pool contenenti le sequenze univoche dei Relative ID (RID) ai DC del dominio. I RID sono utilizzati dai DC durante la creazione degli oggetti Security Principal (User, Group o Computer) per attribuirgli identificativi Security ID (SID) univoci.
Il Relative Identifier Master si occupa anche di autorizzare lo spostamento di un oggetto in un altro dominio, tramite ad esempio l’Active Directory Migration Tool, per evitare che lo stesso oggetto possa essere spostato in due domini diversi.
I DC del dominio ricevono un pool di 500 RID dal Relative Identifier Master e quando la quantità disponibile raggiunge circa le 100 unità il DC contatterà il Relative Identifier Master per ottenere un nuovo pool.
Un SID è composto da 4 elementi S-1-5-Y1-Y2-Y3-Y4:
S-1 che indica la revisione del SID (al momento è in uso la 1)
5 che definisce l’autorità di emissione del SID (5 indica Windows NT, 2000 o 2003 Server, per i well know SID si utiliza 0 o 1)
Y1-Y2-Y3 è la porzione del domain SID (uguale per tutti i Security Principal del dominio)
Y4 rappresenta il relative ID del dominio.
PDC emulator. il PDC emulator è unico nel domino e viene utilizzato come fonte di replica (master-slave) degli update della Domain Partition verso i BDC NT nel caso in cui il livello funzionale del dominio sia Windows server 2003 Interim o Windows 2000 Mixed Mode. il PDC emulator viene inoltre contattato da client precedenti Windows 2000 su cui non è installato l’Active Directory client durante la fase di cambio password degli account e per offrire piena compatibilità verso essi.
Il PDC emulator assolve anche la funzionalità di Domain Master Browser e indipendetemente dal livelo funzionale del dominio ha i seguenti compiti:
– Diminuire il tempo di convergenza nei cambi password.
– Essere la fonte di sincronizzazione del Windows Time Service (in una foresta i DC di un dominio usano il PDC emulator del proprio dominio come time source e a loro volta i PDC emulator dei vari domini della foresta usano come time source il PDC emulator del Forest Root Domain il quale può essere sincronizzato su un time server esterno tramite il comando net time \\servername /setsntp:TimeServer).
– Essere utilizzato di default dallo snap-in di creazione o modifica di un Group Policy Object.
– Autorizzare il raise del livello funzionale del dominio.
Infrastructure Master. l’Infrastructure Master è l’unico DC nel domino che ha il compito di mantenere aggiornata la relazione GUID-SID-DN degli utenti/gruppi definiti nei domini esterni a quello di appertenenze dell’Infrastructure Master, ma utilizzati anche nei gruppi del suo dominio (phantom record). In caso di modifica del Distinguished Name (DN) (per es. spostamento nel domino) o del SID (per es. spostamento in altri domini) di tali utenti/gruppi la visualizzazione dei membri dei gruppi che li contengono non deve produrre incoerenze. Per ottenere tale risultati l’Infrastructure Master verifica e aggiorna periodicamente eventuali differenze tra il proprio database locale di phantom record e le informazioni nei Global Catalog server.

VERIFICA FUNZIONALITA’ ACTIVE DIRECTORY
Tramite Dcdiag è possibile verificare la registrazione DNS di un controller di dominio, controllare che i descrittori di protezione (SID) nelle intestazioni del contesto dei nomi dispongano delle autorizzazioni appropriate per la replica, analizzare lo stato dei controller di dominio in un insieme di strutture o in un’organizzazione e così via. Per maggiori informazioni si veda il seguente link: Domain Controller Diagnostics Tool (dcdiag.exe).

DCDIAG /v /f:


VERIFICA FUNZIONALITA’ REPLICA CON ALTRI DOMAIN CONTROLLER
Per verificare verificare la funzionalità replica con altri Domain Controller è possibile utilizzare l’utility DCDIAG:

DCDIAG /test:replications

VERIFICA DETENZIONE RUOLI FSMO
Per verificare quale server detiene i ruoli FSMO è possibile utilizzare l’utility NETDOM:

netdom /query fsmo

VERIFICA DISPONIBILITA’ DEI RUOLI MASTER OPERAZIONI
Per verificare la disponibilità dei ruoli master operazioni è possibile utilizzare l’utility DCDIAG, controllandone la localizzazione tramite il test knowsofroleholders e la disponibilità e il corretto funzionamento tramite il test fsmocheck:

DCDIAG /s: /test:KNOWSOFROLEHOLDERS /verbose

DCDIAG /s: /test:FSMOCHECK

SERVIZIO DNS
Uno degli aspetti più importanti dell’implementazione di Active Directory è la sua filosofia “IP-centrica”, nel senso che questa tecnologia si basa su alcuni standard del TCP/IP e in modo particolare sul servizio DNS che svolge le seguenti funzioni:

– Servizio di risoluzione dei nomi dei computer e/o domini in in indirizzi IP e viceversa.
– Servizio di registrazione dinamica (Dynamic DNS o DDNS) dei nomi dei computer (resource record di tipo address o RR di tipo A), degli indirizzi IP (RR di tipo pointer o RR di tipo PTR) e degli RR di tipo service location o RR di tipo SRV. Gli RR di tipo A e PTR vengono registrati da tutti i computer mentre gli RR SRV sono registrati solo dai DC.
– Definizione degli standard da adottare per la definizione dei nomi dei domini AD. DNS e AD condividono gli stessi namespace, ovvero la stessa gerarchia di domini, pertanto ad ogni dominio AD deve obbligatoriamente corrispondere un dominio DNS
– Servizio per la localizzazione (service location) dei DC Windows 2000/2003 che offrono servizi strategici ai client AD (LDAP Server, Kerberos Server, Global Catalog Server, etc…)

Per un client Windows 2000/XP/2003 membro di un dominio AD Windows 2000/2003 l’assenza o l’incorretta impostazione del server DNS comporta un declassamento del dominio AD da Windows 2000/2003 a semplice dominio Windows NT (eseguendo l’utility gpresult.exe per la determinazione del “Resultant Set Of Policy” il dominio di appartenenza appare infatti come “Domain Type: WindowsNT 4”). Su questi client configurati in modo errato il dominio AD Windows 2000/2003 verrà visto come un dominio Windows NT con un determinato nome NETBIOS che offre servizi di autenticazione NTLM e tutti i servizi nativi AD (autenticazione Kerberos, GPO, ricerche LDAP e/o ADSI, etc…) non saranno disponibili. Ovviamente queste considerazioni sono valide anchenel caso in cui il client sia configurato correttamente ma il servizio DNS non sia disponibile.

VERIFICA FUNZIONALITA’ DNS DEL DOMAIN CONTROLLER
Per verificare verificare la funzionalità del DNS del Domain Controller è possibile utilizzare l’utility DCDIAG (il test diagnostico del DNS è stato introdotto con la versione di DCDIAG rilasciata con Windows Server 2003 SP1):

DCDIAG /test:DNS

Per l’esecuzione di ulteriori attività e controlli relativi al servizio DNS si faccia riferimento ai seguenti articoli della Knowledge Base Microsoft:

How to reinstall a dynamic DNS Active Directory-integrated zone
Troubleshooting Active Directory replication failures that occur because of DNS lookup failures, event ID 2087, or event ID 2088
SRV Records Missing After Implementing Active Directory and Domain Name System

STRUTTURA FISICA DI ACTIVE DIRECTORY
Active Directory è basata su un database di tipo ISAM (Index as Sequential Access Method) gestito da un DBMS ESE (Extensible Storage Engine) noto anche col nome di Jet Blue (vi sono infatti due implementazioni separate delle Jet Api, chiamate Jet Blue e Jet Red e spesso il termina “Jet” viene utilizzato per riferirsi a Jet Red che è il DBMS utilizzato da Microsoft Access).

ESE è un componente introdotto con Windows 2000 che implementa un user-mode storage engine che gestisce i dati mediante un file binario. I dati saranno resi disponibili all’applicazione tramite Api mediante l’utilizzo di una DLL. Questo DBMS viene utilizzato da svariate applicazioni, come ad esempio Exchange e ADAM, in quanto offre buone performance ed un elevata scalabilità.

Il database di Active Directory è contenuto di default nella directory %SystemRoot%\NTDS e il cuore del DIB (Directory Infomation Base) è rappresentato dal file NTDS.DIT che viene creato dal comando dcpromo all’atto della promozione del server a DC utilizzando il modello %SystemRoot%\System32\ntds.dit.
Per la gestione dei log il DBMS ESE utilizza i file edb.log, edb*.log, res1.log e res2.log, mentre per la gestione del checkpoint utilizza il file edb.chk (per default la dimensione dei file di log è di 10 MB mentre quella del file di checkpoint è variabile).

Per conoscere la posizione del database NTDS.DIT e dei file log è possibile utilizzare l’utility NTDSUTIL:

1. Aprire il prompt dei comandi.
2. Digitare SET SAFEBOOT_OPTION=DSREPAIR e premere invio.
3. Digitare ntdsutil e premere invio.
4. Digitare files e premere invio.
5. Digitare info e premere invio per visualizzare le informazioni sul file di database e sui file di log.
6. Digitare quit e premere invio.
7. Digitare quit e premere invio per chiudere la sessione NTDSUTIL.

Quando viene eseguita un’operazione sul DC che avvia una scrittura sul database (creazione/cancellazione di un oggetto, modifica di un attributo di un oggetto o replica di oggetti e attributi da altri DC partner di replica) viene generata una transazione che contiene i dati e i meta-dati (numero di versione USN, il timestamp, il GUID del server su cui è stata generata la modifica). Una transazione è un’unità atomica di operazioni da eseguire su un database, ovvero devono essere portate a termine con successo tutte in caso contrario verrà ripristinata la situazione precedente all’esecuzione della transazione.

Le transazioni vengono immediatamente registrate in modo sequenziale nel file di log corrente (EDB.LOG) e quindi viene eseguita la modifica nella copia del database in memoria, ciò garantisce che le modifiche vengano eseguite anche nel caso di uno shutdown o di un crash immediatamente successivo.

Il DBMS ESE si occupa di di aggiornare il file NTDS.DIT con le transazioni contenute nei file log e aggiornando il contenuto del file di checkpoint (EDB.CHK) in modo che contenga la posizione sino a cui le operazioni di scrittura nel database sono state eseguite con successo (stato di committed della transazione).

Quando il file di log corrente (EDB.LOG) raggiunge la dimensione massima di default di 10.204 KB viene rinominato come EDBHHHHH.LOG (dove H è una cifra esadecimale) e viene creato un nuovo file EDB.LOG. Per una miglior ottimizzazione dello spazio su disco i file di log vengono gestiti tramite la modalità circular logging, che consiste nel sovrascrivere i log più vecchi in modo circolare cancellano i file non più necessari una volta eseguite le scritture sul database e aggiornato il file di checkpoint.

Per garantire la disponibiltà di spazio anche in situazioni di emergenza oper le normali operazioni di deframmentazione online, vi sono due file di riserva (RES1.LOG e RES2.LOG) della dimensione standard dei file log che vengono utilizzati nel caso in cui il sistema esaurisca lo spazio disponibile sul volume contenente il database.

I file EDBTMP.LOG e TEMP.EDB sono due file temporanei utilizzati da attività quali deframmentazione online, recovery, situazioni di emegenza derivati da sovraccarico, ecc.

Nel caso di chiusura anomala del sistema il DBMS ESE rileva l’esistenza di una situazione anomala controllando il log degli eventi e se l’ultimo record non corrisponde ad uno shutdown “normale”, ESE riapplica il log segnalati nel file di checkpoint (EDB.CHK) notificandolo nell’Event Viewer tramite gli eventi NTDS ISAM 300, 301, 302. Nel caso di assenza del file di checkpoint (EDB.CHK) vengono riaplicate tutte le transazione contenute file di log.

VERIFICA DELL’INTEGRITA’ DEL DATABASE DI ACTIVE DIRECTORY
Per verificare l’integrità del database di Active Directory è possibile utilizzare l’utility NTDSUTIL:

1. Riavviare il sistema.
2. Durante la fase di avvio premere F8.
3. Selezionare l’opzione Modalità ripristino servizi directory (solo controller domini Windows).
4. Selezionare il sistema operativo da avviare.
5. Autenticarsi tramite l’account Administrator con la password di “amministratore modalità ripristino servizi” specificata durante l’esecuzione di dcpromo.
6. Confermare il messaggio che indica che Windows è in esecuzione in modalità provvisoria.
7. Aprire il prompt dei comandi.
8. Digitare ntdsutil e premere invio.
9. Digitare files e premere invio.
10. Digitare integrity e premere invio per avviare il controllo di integrità
11. Digitare quit e premere invio.
12. Digitare sematic database analysis e premere invio.
13. Digitare go e premere invio per avviare il controllo semantico del database.
14. Digitare quit e premere invio.
15. Digitare quit e premere invio per chiudere la sessione NTDSUTIL.

Per l’esecuzione di ulteriori attività e controlli tramite l’utility NTDSUTIL si faccia riferimento ai seguenti articoli della Knowledge Base Microsoft:

Utilizzo di Ntdsutil per gestire file di Active Directory dalla riga di comando in Windows Server 2003
How to complete a semantic database analysis for the Active Directory database by using Ntdsutil.exe
Deletion of Critical Objects in Active Directory in Windows 2000 and Windows Server 2003
Rimozione di dati in Active Directory dopo un abbassamento di livello non riuscito di un controller di dominio
Utilizzo dello strumento Ntdsutil.exe per assegnare o trasferire ruoli FSMO a un controller di dominio
HOW TO: Cercare ed eliminare gli identificatori di protezione (SID) duplicati con Ntdsutil in Windows Server 2003
Reimpostazione della password dell’account amministratore per la modalità ripristino servizi directory (DSRM) in Windows Server 2003
How to restore deleted user accounts and their group memberships in Active Directory
Mancato abbassamento di livello dei controller di dominio quando si utilizza l’Installazione guidata di Active Directory per forzare l’abbassamento di livello in Windows Server 2003 e in Windows 2000 Server

CONCLUSIONI
La diagnostica di Active Directory dovrebbe essere eseguita periodicamente soprattutto quando vengono eseguite modifiche corpose, prima di un backup del system state evitando così di salvare una versione non valida, ma soprattutto dopo il cambio di una Domain Controller (DC) per accertarsi che il processo di trasferimento sia andato a buon fine (a tal proposto si faccia riferimento alla guida Migrare un DC Windows2003 verso un nuovo server).

Per ulteriori approfondimenti si faccia riferimento al seguente articolo della Knowledge Base Microsoft How to verify an Active Directory installation.

_______________________________

È possibile che l’abbassamento di livello dei controller di dominio Microsoft Windows 2000 o Microsoft Windows Server 2003 non venga eseguito correttamente mediante l’Installazione guidata di Active Directory (Dcpromo.exe).

Cause

Questo problema può verificarsi in caso di errore di una dipendenza o di un’operazione necessaria, ad esempio la connettività di rete, la risoluzione dei nomi, l’autenticazione, la replica del servizio directory di Active Directory o l’individuazione di un oggetto fondamentale in Active Directory.

Risoluzione

Per risolvere il problema, determinare la causa del mancato abbassamento di livello normale del controller di dominio di Windows 2000 o Windows Server 2003, quindi provare di nuovo a eseguire l’operazione mediante l’Installazione guidata di Active Directory.

Workaround

Se non si riesce a risolvere il problema, è possibile utilizzare le soluzioni alternative descritte di seguito per forzare l’abbassamento di livello del controller di dominio in modo da mantenere l’installazione del sistema operativo e le applicazioni installate.

Avviso Prima di utilizzare una delle soluzioni descritte di seguito, assicurarsi di poter eseguire l’avvio in modalità ripristino servizi directory. In caso contrario, dopo l’abbassamento di livello forzato del computer non sarà possibile effettuare l’accesso. Se si è dimenticata la password per la modalità ripristino servizi directory, sarà possibile ripristinarla mediante l’utilità Setpwd.exe che si trova nella cartella Winnt\System32. In Windows Server 2003 la funzionalità dell’utilità Setpwd.exe è stata integrata nel comando Set DSRM Password dello strumento NTDSUTIL. Per ulteriori informazioni su come effettuare questa procedura, fare clic sul numero dell’articolo della Microsoft Knowledge Base riportato di seguito (il contenuto potrebbe essere in inglese):

271641 (http://support.microsoft.com/kb/271641/ ) Impostazione di una password vuota per la modalità di ripristino da parte della Configurazione guidata server

Controller di dominio di Windows 2000

  1. Installare l’aggiornamento rapido (hotfix) Q332199 su un controller di dominio di Windows 2000 che esegue il Service Pack 2 (SP2) o versione successiva oppure installare Windows 2000 Service Pack 4 (SP4). Nel Service Pack 2 e nelle versioni successive è supportato l’abbassamento di livello forzato. Riavviare il computer.
  2. Fare clic sul pulsante Start, scegliere Esegui e digitare il comando seguente:
    dcpromo /forceremoval
  3. Scegliere OK.
  4. Nella pagina Installazione guidata di Active Directory scegliere Avanti.
  5. Se il computer che si sta rimuovendo è un server di catalogo globale, scegliere OK nella finestra di messaggio. Nota Innalzare di livello altri cataloghi globali nell’insieme di strutture o nel sito se il controller di dominio che si sta abbassando di livello è un server di catalogo globale, secondo le esigenze.
  6. Nella pagina Rimozione di Active Directory assicurarsi che la casella di controllo Questo server è l’ultimo controller di dominio nel dominio sia deselezionata, quindi scegliere Avanti.
  7. Nella pagina Credenziali di rete digitare il nome, la password e il nome di dominio di un account utente con credenziali di amministratore dell’organizzazione nell’insieme di strutture, quindi scegliere Avanti.
  8. In Password amministratore digitare e confermare la password da assegnare all’account amministratore del database SAM locale, quindi scegliere Avanti.
  9. Nella pagina Riepilogo scegliere Avanti.
  10. Eseguire la pulitura dei metadati del controller di dominio abbassato di livello su un controller di dominio rimanente nell’insieme di strutture.

Se è stato rimosso un dominio dall’insieme di strutture utilizzando il comando remove selected domain di Ntdsutil, assicurarsi che in tutti i controller di dominio e nei server di catalogo globale dell’insieme di strutture siano stati rimossi tutti gli oggetti e i riferimenti al dominio rimosso, prima di innalzare di livello un nuovo dominio nello stesso insieme di strutture con lo stesso nome di dominio. Per stabilire se è stata eseguita la replica end-to-end, possono essere utili strumenti quali Replmon.exe o Repadmin.exe disponibili negli Strumenti di supporto di Windows 2000. La rimozione di oggetti e contesti dei nomi in Windows 2000 SP3 e nei server di catalogo globale precedenti è notevolmente più lenta rispetto a Windows Server 2003.

Controller di dominio di Windows Server 2003

  1. Per impostazione predefinita, i controller di dominio di Windows Server 2003 supportano l’abbassamento di livello forzato. Fare clic sul pulsante Start, scegliere Esegui e digitare il comando seguente:
    dcpromo /forceremoval
  2. Scegliere OK.
  3. Nella pagina Installazione guidata di Active Directory scegliere Avanti.
  4. Nella pagina Imponi rimozione di Active Directory scegliere Avanti.
  5. In Password amministratore digitare e confermare la password da assegnare all’account amministratore del database SAM locale, quindi scegliere Avanti.
  6. Nella pagina Riepilogo scegliere Avanti.
  7. Eseguire la pulitura dei metadati del controller di dominio abbassato di livello su un controller di dominio rimanente nell’insieme di strutture.

Se è stato rimosso un dominio dall’insieme di strutture utilizzando il comando remove selected domain di Ntdsutil, assicurarsi che in tutti i controller di dominio e nei server di catalogo globale dell’insieme di strutture siano stati rimossi tutti gli oggetti e i riferimenti al dominio rimosso, prima di innalzare di livello un nuovo dominio nello stesso insieme di strutture con lo stesso nome di dominio. La rimozione di oggetti e contesti dei nomi in Windows 2000 Service Pack 3 (SP3) e nei server di catalogo globale precedenti è notevolmente più lenta rispetto a Windows Server 2003.

Se le voci di controllo di accesso (ACE) presenti nel computer da cui è stato rimosso Active Directory erano basate su gruppi locali di dominio, potrebbe essere necessario riconfigurare queste autorizzazioni, in quanto questi gruppi non saranno disponibili per i server membri o i server autonomi. Se si ha intenzione di installare Active Directory in un computer che verrà innalzato a livello di controller di dominio del dominio originale, non sarà più necessario configurare le voci di controllo di accesso. Se si preferisce mantenere il computer a livello di server membro o di server autonomo, è necessario convertire o sostituire le eventuali autorizzazioni basate su gruppi locali di dominio. Per ulteriori informazioni sulla modifica delle autorizzazioni a seguito della rimozione di Active Directory da un controller di dominio, fare clic sul numero dell’articolo della Microsoft Knowledge Base riportato di seguito (il contenuto potrebbe essere in inglese):

320230 (http://support.microsoft.com/kb/320230/ ) Conseguenze sulle autorizzazioni dopo l’abbassamento di livello di un controller di dominio

Miglioramenti introdotti in Windows Server 2003 Service Pack 1

Windows Server 2003 SP1 consente di migliorare il processo dcpromo /forceremoval. Quando si esegue il comando dcpromo /forceremoval, viene effettuata una verifica per determinare se il controller di dominio svolge il ruolo di master operazioni, è un server DNS (Domain Name System) o un server di catalogo globale. Per ciascuno di questi ruoli l’amministratore riceve un avviso popup per l’esecuzione dell’azione appropriata.

Status

Microsoft ha eseguito test e fornisce il supporto per forzare l’abbassamento di livello dei controller di dominio che eseguono Windows 2000 o Windows Server 2003.

Informazioni

Mediante l’Installazione guidata di Active Directory vengono creati controller di dominio di Active Directory in computer basati su Windows 2000 e su Windows Server 2003. Durante l’Installazione guidata di Active Directory vengono effettuate diverse operazioni, fra cui l’installazione di nuovi servizi, l’esecuzione di modifiche ai valori di avvio di servizi esistenti e il passaggio ad Active Directory come area di protezione e autenticazione.

Con l’imposizione dell’abbassamento di livello, gli amministratori di dominio possono forzare la rimozione di Active Directory ed eseguire il rollback delle modifiche di sistema apportate a livello locale senza contattare altri controller di dominio nell’insieme di strutture o replicare alcuna modifica locale.

Dato che l’abbassamento di livello forzato comporta la perdita delle modifiche apportate a livello locale, deve essere utilizzato solo come soluzione estrema nei domini di produzione o test. È possibile forzare l’abbassamento di livello dei controller di dominio quando le dipendenze relative a connettività, risoluzione dei nomi, autenticazione o motore di replica non possono essere risolte, in modo da consentire un abbassamento di livello normale. Gli scenari validi per l’abbassamento di livello forzato comprendono:

  • Nel dominio padre non è disponibile alcun controller di dominio quando si tenta di abbassare di livello l’ultimo controller di dominio in un dominio figlio diretto.
  • L’Installazione guidata di Active Directory non può essere completata a causa di una dipendenza relativa alla risoluzione dei nomi, all’autenticazione, al motore di replica o a oggetti di Active Directory che non può essere risolta dopo un’accurata procedura di risoluzione dei problemi.
  • Le modifiche di Active Directory in ingresso non sono state replicate da un controller di dominio entro la durata dell’oggetto contrassegnato per rimozione (per impostazione predefinita, entro 60 giorni) per uno o più contesti dei nomi.Importante Ripristinare tali controller di dominio solo se costituiscono l’unica possibilità di ripristino per un determinato dominio.
  • Il tempo disponibile non consente una risoluzione dei problemi accurata, poiché è necessario rendere immediatamente operativo il controller di dominio.

L’abbassamento di livello forzato può rivelarsi utile in ambienti di laboratorio o didattici, in cui è possibile rimuovere i controller di dominio dai domini esistenti, ma non è necessario abbassare di livello ciascun controller di dominio in successione.

Se si forza l’abbassamento di livello di un controller di dominio, andranno perse le modifiche univoche residenti in Active Directory del controller di dominio di cui si sta effettuando l’abbassamento forzato del livello, tra cui l’aggiunta, l’eliminazione o la modifica di utenti, di computer, di gruppi, di relazioni di trust, di criteri di gruppo o della configurazione di Active Directory di cui non è stata eseguita la replica prima dell’esecuzione del comando dcpromo /forceremoval. Andranno inoltre perse le modifiche apportate a qualsiasi attributo di tali oggetti, quali le password per gli utenti, i computer, le relazioni di trust e l’appartenenza ai gruppi.

Se tuttavia si forza un abbassamento di livello di un controller di dominio, viene ripristinato uno stato del sistema operativo corrispondente a quello ottenuto con l’abbassamento di livello dell’ultimo controller di dominio in un dominio, per quanto riguarda i valori iniziali dei servizi, i servizi installati, l’utilizzo di un sistema SAM basato sul Registro di sistema per il database degli account e l’appartenenza del computer a un gruppo di lavoro. I programmi installati nel controller di dominio abbassato di livello rimangono installati.

Nel registro eventi di sistema i controller di dominio di Windows 2000 di cui è stato forzatamente abbassato il livello, nonché le istanze dell’operazione dcpromo /forceremoval, sono identificati dall’ID evento 29234. Ad esempio:

Tipo evento: AVVISO
Origine evento: lsasrv
Categoria evento: Nessuno
ID evento: 29234
Data: MM/GG/AAAA
Ora: HH.MM.SS
Utente: N/D
Computer: nomecomputer Descrizione: A questo server è stato imposto un abbassamento di livello. Pertanto, non è più un controller di dominio.

Nel registro eventi di sistema i controller di dominio di Windows Server 2003 a cui viene imposto un abbassamento di livello sono identificati dall’ID evento 29239. Ad esempio:

Tipo evento: AVVISO
Origine evento: lsasrv
Categoria evento: Nessuno
ID evento: 29239
Data: MM/GG/AAAA
Ora: HH.MM.SS
Utente: N/D
Computer: nomecomputer Descrizione: A questo server è stato imposto un abbassamento di livello. Pertanto, non è più un controller di dominio.

Dopo avere utilizzato il comando dcpromo /forceremoval, i metadati per il computer abbassato di livello non vengono eliminati nei controller di dominio rimanenti. Per ulteriori informazioni, fare clic sul numero dell’articolo della Microsoft Knowledge Base riportato di seguito:

216498 (http://support.microsoft.com/kb/216498/ ) Rimozione di dati in Active Directory dopo un abbassamento di livello non riuscito di un controller di dominio

Di seguito sono indicate alcune operazioni da effettuare, se necessario, dopo avere imposto l’abbassamento di livello di un controller di dominio:

  1. Rimuovere l’account computer dal dominio.
  2. Verificare che i record DNS, quali i record A, CNAME e SRV, siano stati rimossi ed eventualmente rimuoverli se ancora presenti.
  3. Verificare che gli oggetti membro del servizio Replica file (FRS e DFS) siano stati rimossi ed eventualmente rimuoverli se ancora presenti. Per ulteriori informazioni, fare clic sul numero dell’articolo della Microsoft Knowledge Base riportato di seguito (il contenuto potrebbe essere in inglese):
    296183 (http://support.microsoft.com/kb/296183/ ) Panoramica degli oggetti Active Directory utilizzati da FRS
  4. Se il computer abbassato di livello è membro di gruppi di protezione, rimuoverlo da tali gruppi.
  5. Rimuovere tutti i riferimenti del file system DFS, rappresentati da collegamenti o repliche della directory principale, al server abbassato di livello.
  6. A un controller di dominio rimanente devono essere assegnati i ruoli di master operazioni o FSMO (Flexible Single Master Operations) precedentemente gestiti dal controller di dominio a cui è stato imposto un abbassamento di livello. Per ulteriori informazioni, fare clic sul numero dell’articolo della Microsoft Knowledge Base riportato di seguito:
    255504 (http://support.microsoft.com/kb/255504/ ) Utilizzo dello strumento Ntdsutil.exe per assegnare o trasferire ruoli FSMO a un controller di dominio
  7. Se il controller di dominio che si sta abbassando di livello è un server DNS o un server di catalogo globale, è necessario creare un nuovo server DNS o di catalogo globale per soddisfare le impostazioni di bilanciamento del carico, di tolleranza d’errore e di configurazione nell’insieme di strutture.
  8. Quando si utilizza il comando remove selected server di NTDSUTIL, viene rimosso l’oggetto NTDSDSA, ovvero l’oggetto padre per le connessioni in ingresso verso il controller di dominio di cui si sta abbassando forzatamente il livello. Il comando non rimuove gli oggetti server padre visualizzati nello snap-in Siti e servizi di Active Directory. Utilizzare lo snap-in MMC Siti e servizi di Active Directory per rimuovere l’oggetto server se il controller di dominio non verrà innalzato di livello nell’insieme di strutture mantenendo lo stesso nome computer.

Come rimuovere un Domain Controller (DC) non più funzionante

Se nel vostro dominio muore uno dei Domain Controller (Windows Server 2003), magari obsoleto e utilizzato solo per la replica di Active Directory, gli altri servers continueranno a funzionare tentando però di replicarsi sul server defunto.
Ripulire Active Directory dalle repliche non necessarie, almeno per me, non è stata una cosa banale. Come spesso accade in questi casi la parte più difficile è stata reperire un guida sicura per effettuare questa delicata operazione.
Personalmente ho seguito la guida Rimozione di dati in Active Directory dopo un abbassamento di livello non riuscito di un controller di dominio riportata sul sito di Microsoft con alcune modifiche.

La procedura che ho seguito può essere sintetizzata in 5 fasi che vedremo in dettaglio:

  • Verificare chi detiene il Global catalogue
  • Verificare chi detiene i 5 ruli FSMO
  • Rimozione del server con ntdsutil (da guida Microsoft)
  • Rimozione delle repliche con ADSIedit (da guida Microsoft)
  • Rimozione delle repliche in Active directory sites and services

Verificare chi detiene il Global catalogue

  1. Aprite il pannello Active directory sites and services e visualizzate la lista dei servers. All’interno di ogni server trovate le NTDS setting.
  2. Cliccate con il tasto destro del mouse su NTDS setting e selezionate Properties.
  3. All’interno della scheda General verificate che il Global catalogue sia presente in almeno uno dei server attivi.

Verificare chi detiene i 5 ruli FSMO

  1. In Active directory users and computers cliccate con il tasto destro sul vostro dominio e selezionate Operations Masters.
  2. Verificate che i 3 ruoli RID, PDC e Infrastructure siano assegnati ai vostri server attivi
  3. Aprite Active directory domains and trusts e cliccate con il tasto destro su Active directory domains and trusts selezionando Operations Masters.
  4. Verificate che il 4° ruolo di Domain Naming Master sia assegnato ad uno dei server attivi.
  5. Se non lo avete già fatto, registrate lo snap-in dello Schema utilizzano il seguente comando in Start->Run…
    regsvr32 schmmgmt.dll
  6. Aprite una consolle mmc (scrivendo mmc in Start->Run…) e aggiungete lo snap-in Active Directory Schema.
  7. Cliccate con il tasto destro e selezionate Operations Masters.
  8. Verificate che il 5° ruolo di Schema Master sia assegnato ad uno dei server attivi.

Rimozione del server con ntdsutil
Per la parte seguente ho seguito la guida Rimozione di dati in Active Directory dopo un abbassamento di livello non riuscito di un controller di dominio riportata sul sito di Microsoft. Vi rimando a questa guida per eventuali approfondimenti e per le raccomandazioni in merito ai rischi dell’utilizzo non corretto di ntdsutil, il tool che sarà utilizzato per i passaggi successivi.

  1. Lanciate il comando ntdsutil in Start->Run…. In ogni schermata di ntdsutil sarà possibile ottenere una guida ai comandi digitando ? e successivamente INVIO.
  2. Digitate metadata cleanup, quindi premete INVIO.
  3. A questo punto è necessario connettersi ad uno dei server attivi. Digitate connections e premete INVIO.
  4. Digitate connect to server nomeserver, quindi premete INVIO. Verrà visualizzato un messaggio per confermare che la connessione è stata stabilita. E’ importante capire ora che i comandi successivi saranno riferiti al server a quale vi siete connessi.
  5. Digitate quit e premete INVIO per tornare al menu di metadata cleanup.
  6. A questo punto digitate select operation target e premere INVIO.
  7. Digitate list domains e premete INVIO. Verrà visualizzato un elenco dei domini nell’insieme di strutture, ognuno con un numero associato. Nel mio caso era presente un solo dominio.
  8. Digitate select domain numero e premete INVIO, dove numero è il numero associato al dominio di cui è membro il server che si desidera rimuovere. Il dominio selezionato viene utilizzato per determinare se il server in fase di rimozione è l’ultimo controller di dominio presente nel dominio.
  9. Digitate list sites e premere INVIO. Verrà visualizzato un elenco di siti, ognuno con un numero associato. Nel mio caso era presente un solo site.
  10. Digitate select site numero e premere INVIO, dove numero è il numero associato al sito di cui è membro il server che si desidera rimuovere. Verrà visualizzato un messaggio di conferma con l’indicazione del sito e del dominio scelti.
  11. Digitate list servers in site e premere INVIO. Verrà visualizzato un elenco dei server nel sito, ognuno con un numero associato. Nel mio caso erano presenti 3 server: 2 attivi e uno non più attivo.
  12. Digitare select server numero, dove numero è il numero associato al server che si desidera rimuovere. Verrà visualizzato un messaggio di conferma con l’indicazione del server selezionato, il relativo nome host DNS (Domain Name Server) e il percorso dell’account computer del server che si desidera rimuovere.
  13. A questo punto potete digitate list current selection e premete INVIO per verificare quanto è stato selezionato. Verificate che si tratti proprio del server attivo.
  14. Digitate quit e premete INVIO per tornare al menu metadata cleanup.
  15. Digitate remove selected server e premere INVIO.Successivamente vi verrà visualizzato il risultato di questa operazione. Se tutto è andato a buon fine, il più è fatto. Verificate all’interno di Active directory users and computers: il domain controller non più attivo non dovrebbe essere presente nella lista dei DC.

Rimozione delle repliche con ADSIedit

  1. Utilizzare lo snap-in ADSIEdit presente nei support tools del cd di installazione, per eliminare l’oggetto Membro FRS in CN=System (condivisione SYSVOL),CN=servizio Replica file,CN=sistema….
  2. Nella console DNS utilizzare DNS MMC per eliminare il record cname (definito anche Alias) nel contenitore _msdcs.
  3. Nella console DNS utilizzare DNS MMC per eliminare il record A (definito anche Host) in DNS.

Rimozione delle repliche in Active directory sites and services

  1. Aprite lo snap-in Active directory sites and services e visualizzate la lista dei servers dove dovrebbe ancora comparire il server non funzionante.
  2. Cliccate con il tasto destro e selezionate delete.
Share

Microsoft

Clonare una macchina virtuale su VMWare ESX

12 Novembre 2009

vmware

Clonare una macchina virtuale su VMWare ESX

Lo strumento canonico di VMWare per la creazione di macchine virtuali senza dover reinstallare tutto da zero ogni volta, sarebbero i template.
Lavorare con i template presuppone di averli preparati prima e di usarli spesso, altrimenti potrebbe non valere la pena di utilizzare tempo e spazio sullo storage per gestirli.
La necessità di clonare una macchina virtuale mi si presenta raramente, e di solito procedo in questo modo:
Come prima cosa creo una snapshot della macchina tramite VC Backup. Al termine del processo ho ottenuto un backup della macchina virtuale su una cartella di uno storage esterno, ad esempio i dischi del server Virtual Center. Rinomino la cartella con il nome che desidero per il clone che andrò a creare, e utilizzando VMConverter (quello fornito con ESX server), provvedo a reimportare la macchina, avendo cura di non farla avviare automaticamente al temine del processo di importazione.

Nel frattempo mi procuro Sysrep, un’utility gratuita di Microsoft, scaricabile da qui. Malgrado la pagina parli solo di Windows 2000, WMWare dice che va bene anche per XP Pro e Windows Server 2003 (è vero, uso questa e funziona benissimo).
Con i files di Sysprep è necessario creare un file ISO che va copiato insieme alle altre immagini ISO sul datastore, nella cartella /vmimages/tools-isoimages dei server ESX, tramite WinSCP oppure Veeam FastSCP.
Al termine dell’importazione edito la configurazione del clone, impostando l’avvio con la scheda di rete scollegata e mappando il CD-ROM virtuale sulla ISO di Sysprep residente sui server ESX.

A questo punto posso finalmente avviare la macchina clonata. Alla partenza copio i files di Sysprep dal CD-ROM virtuale a c:\sysprep e lancio il programma; un wizard mi guida nelle operazioni di cambiamento dell’hostname della macchina, dell’impostazione dell’indirizzo IP e nell’eventuale join al dominio. Importante: subito prima di confermare le proprità del TCP/IP bisogna ricollegare la scheda di rete. Al termine del processo il pulsante “Seal” applica le impostazioni e fa ripartire la macchina. Al riavvio il sistema operativo si comporta come se fosse stato appena installato, ma con le impostazioni da voi definite poco prima. Se joinate lo stesso dominio, il profilo utente è bello pronto che vi aspetta e non dovete modificare una virgola rispetto alla macchina di partenza.

Risultato finale dell’operazione: due macchine identiche dal punto di vista del software e della configurazione, ma comunque distinte e funzionanti contemporaneamente. Perché è importante il processo di customizzazione tramite Sysprep appena descritto?

Ciascuna macchina in un dominio Active Directory possiede un SID che deve necessariamente essere univoco. Clonando brutalmente la macchina, il SID non viene modificato, neppure se cambia l’hostname. Due SID uguali su una rete pongono problemi di sicurezza e di funzionamento, e non sono in alcun modo supportati.

La procedura descritta va bene se non deve essere utilizzata con troppa frequenza, poiché le fasi di snapshot e importazione sono abbastanza lunghe. Nel caso si dovesse produrre parecchie macchine virtuali è sempre meglio utilizzare i template.

Share

Vmware - Virtualizzazione

Managing VMware ESX through the service console – 10 Basic Linux

9 Novembre 2009

10 Basics of Linux that apply to managing VMware ESX through the service console

Introduction

If you are using the full version of VMware ESX you have the option to manage it, from the command line, using the service console operating system (called the COS). The service console, in VMware ESX, is really a modified version of Red Hat Enterprise Linux. Thus, basic Linux administration knowledge is very valuable when you go to manage VMware ESX from the command line.


On the other hand, if you are using VMware ESXi you likely do not access any CLI console from the server. Two command line options for managing ESXi from the command line are-

  1. The hidden ESXi service console – for information on this tiny Linux console, with very limited features, and how to access it see my article How to access the VMware ESXi Hidden Console.
  2. The VMware remote command line interface (RCLI) – for information on RCLI, see my article; Using VMware’s remote command line interface (RCLI) with VMware ESXi.

Now, here are my 10 basics of Linux administration that apply to managing VMware ESX:

1.      Understanding file structure and navigation are critical

Just like navigating Linux or Windows from the command line, it is critical in ESX that you know how to navigate the file structure. Here are some common Linux & ESX commands you will use to get around:

  • ls – to list out files in a directory, just like the DOS dir command. Although, the DOS dir command actually does work in ESX as well. I prefer the long format of the ls command, ls -l


Figure 1: the ls, dir, and ls –l commands in VMware ESX

  • cd – change directory
  • rm – to remove files
  • cp – to copy files
  • rename – to rename files
  • pwd – to show the current directory

One of the best Linux commands I ever learned was the command that allows me to find a file anywhere on a filesystem-

find ./ -print | grep {what you are looking for}

Yes, this works great in ESX and it allows me to find the location of log files or executables when they are not in my path or I forget where they are stored. Here is an example of how I used this to find the location of the esxcfg-firewall command:


Figure 2: using the find command

2.      Remote access is usually via SSH when using the CLI

Just as I connect to a Linux server using a SSH client like putty, I also connect to my ESX server. In fact, all the command line examples in this article were done with putty through SSH.

You should know that access to the ESX service console is not allowed, via SSH, for root, by default. To enable it, you need to go to the server’s console, edit /etc/ssh/sshd_config, set PermitRootLogin to yes, save it, and restart the ssh dameon with service sshd restart.

3.      Local user administration is in /etc/passwd

Just as in Linux, it is best practice in ESX to create yourself a local user that can be used to su to the root account when local root privileges are needed (yes, even if you are using vCenter and likely will not use this a lot).

You could edit the /etc/passwd file, sure, but you should, instead, use useradd to add local users from the command line (but this is also easily done in the VI client if you connect directly to an ESX host). You can change passwords using passwd, just like in Linux.

One thing that is different is that you can set just about all of the ESX authorization settings by using esxcfg-auth.

4.      Critical administration commands can be found in

As we learned back in #1 with the find command, the esxcfg-XXXX commands are located in /usr/sbin. These are ESX specific commands that you will need to use if administering the server from CLI.

Here is what they look like:


Figure 3: esxcfg commands located in /usr/sbin

5.      Text file editing with vi and nano is a must

How are you going to edit text files like sshd_config to enable SSH remote access without a text editor? Well, you can’t. You must know how to use one of the Linux / ESX text file editors – vi or nano.

Like whiskey, vi is “an acquired taste” and takes some getting used to. If you are a Linux admin, you already know vi. For those who don’t, I encourage you to use nano as it works much like the Windows notepad.

Here is a look at nano:


Figure 4: Using nano to edit text files in VMware ESX

6.      You will need to patch it with using RPMs but with different tools – rpm and esxupdate

Just like any OS, you will need to patch ESX. In Linux, this is typically done at the command line using rpm. While rpm is available in ESX, you should instead use esxupdate to apply ESX patches.

Still, the concept is the same and the applications are almost identical.

For more information on using esxupdate and patching in ESX see:

7.      Common network tools like ping, ifconfig, traceroute, proper network configuration are all crucial.

Just as in configuring Linux or even Windows from the command line, critical pieces of ESX Server aren’t going to work without the proper network configuration. The easiest way to do that in ESX is to use the VI client but you can do it at the command line using commands like esxcfg-nics, esxcfg-route, esxcfg-vmknic, esxcfg-vswif.

About half of what these commands do is to edit traditional Linux text configuration files like /etc/hosts, /etc/resolv.conf, /etc/sysconfig/network, /etc/vmware/esx.conf.

Just like any Linux host, in ESX you must have an IP address, proper subnet mask, default gateway (if you want to get outside your subnet), DNS servers (unless you are going local), your ESX host name must be able to be resolved as a FQDN, and you must have full network communication. That full network communication can be tested with traditional Linux commands like ping, traceroute, nslookup, and ifconfig

8.      Process administration, at times, is necessary – ps, kill

Just as in Linux, at times, process administration is required. In ESX, you can view running processes with the ps (or process list) command. You can kill processes with the kill command.

Unlike Linux, ESX has some critical processes such as vmware-watchdog, vmware-hostd, vmklogger, and others.

9.      Performance management from the CLI is quickly handled with top and esxtop

Eventually in any OS you will have a performance management issue. You can quickly resolve performance issues in Linux with top. In ESX, top also works but you should, instead, use esxtop.


Figure 5: VMware ESXTOP

For more information on understanding performance statistics with esxtop, see the VMware ESX Resource Management Guide and Interpreting ESXTOP Statistics in the VMware Community.

10.  Getting help with –help and man

And finally, getting help in Linux and in ESX are the same. To learn more about a command you can use that command and add “dash dash help” or “–help” after it. Even better, you can get more instructions using man, which stands for manual pages. For example, if I wanted to learn about esxcfg-firewall, I can just type man esxcfg-firewall and I see a screen like this:


Figure 6: VMware ESX man pages

Conclusion

Some would say “of course VMware ESX service console and Linux are the same, the ESX service console IS LINUX”. That is not exactly true as it is a modified version of Red Hat Enterprise Linux. Plus, what libraries and packages are loaded in it? What extra commands? What commands are removed? There are many differences. Also, the ESX service console Is may still be based on Linux but may be very different from other flavors of Linux like Ubuntu, Suse, or Fedora.

From this article, you learned 10 Linux system administration tasks / commands that you can perform in VMware ESX Server and, trust me, if you are not familiar with Linux already, this basic knowledge will be extremely helpful when you get to the ESX service console and need to, say, find and edit a configuration file.

Share

Vmware - Virtualizzazione

Extend the boot volume of Win2000/2003 Virtual Machine with “diskpart”

5 Novembre 2009

Extend boot volume on Windows Server 2000/2003

Before you begin, make sure that you do not have an active snapshot on the VM, extending a virtual disk with a snapshot will cause corrpution

Extend the boot volume of Windows Server 2003 Virtual Machine
To start, I have a Windows Server 2003 Virtual Machine that has a 5.3G disk allocated to it, I need to expand this disk to 10G.

Step 1: Power off the virtual machine that holds the boot volume that you want to extend.

Step 2: Make a backup copy of your virutal disk, this is optional but if you mess up don’t call me unless you’re willing to pay.

Step 3: From the service console, increase the size of the .dsk or .vmdk virtual disk file. This can also be accomplished through the Virtual Infrastructure Client if you are using VirtualCenter 2.x+.

[root@esx-test local]# ls -lah test.vmdk
-rw-------    1 root     root         5.4G Jul 18 13:57 test.vmdk

Extend the virtual disk with vmkfstools. The input to the -X switch is the size that you want the disk file to be not the size you want to extend the disk file by.

[root@esx-test local]# vmkfstools -X 10G test.vmdk

View the new size of test.vmdk

[root@esx-test local]# ls -lah test.vmdk
-rw-------    1 root     root          10G Jul 18 13:57 test.vmdk

Step 4: For this step you will need an additional Virtual Machine running Windows Server 2003. Power off the second Virtual Machine, and add the disk from the first Virtual Machine to it through the mui. Power up the second Virtual Machine and verify that the imported disk has unallocated space on it.

From the run menu type “diskpart.exe” to enter the command line utility to resize disk partitions in Windows Server 2003.

The command list volume will show you all the available volumes. Select your volume as shown below. select volume 1 corresponds to the “D” volume that I want to exntend. Finally extend the volume with the extend command.

If all goes well, the partition will be immediately exnteded under the Disk Management snap in.

Step 5: Shut down the second Virtual Machine and remove the disk from the second Virtual Machine. Power on the first Virtual Machine and check out your new space.

Share

Vmware - Virtualizzazione

VMware ESX vSphere resize disk with “extpart” (Dell)

5 Novembre 2009
VMware ESX vSphere resize disk

Every now and then I need to resize (usually extend/enlarge) a disk attached to a Virtual Machine. I have tried several methods to do this over the years (including combinations of VMware Converter, third party partition manager apps, diskpart etc) but none have been as efficient as the method I discovered during recent VMware training for my VCP4 exam.

One of the new features of vSphere is the ability to resize disks without having to shut down the Virtual Machine. This was previously impossible in VI3. This greatly speeds up the resizing process which can be executed in a couple of stages:

1) Use the vSphere Client to edit the settings of the Virtual Machine in question. Select the hard disk and modify it’s provisioned size as appropriate. Click OK to apply these changes – resizing the .vmdk file.

resize1.png

2) Verify that the .vmdk has been resized by opening the Management Console -> Disk Management to find the unallocated space on the disk that resides in the .vmdk (distinguished by the black colour in the legend at the bottom.) In this case you can see I have increased the size by 5GB.

resize2.png

Right click on the disk (in this case ‘Disk 0’) and select properties. On the Volumes tab make a note of the unallocated space, in my case it is 5122MB.

resize3.png

Download Dell’s EXTPART and extract it on the server that contains the disk you want to resize. Navigate to c:\dell\ExtPart (the default extracted location) and run extpart.exe. When prompted enter the the Windows drive letter of the disk on the Virtual Machine e.g. c:. When prompted for the size to extend the partition by enter the number noted down earlier (I used 5122 in this example.) After doing so the disk should be resized. You can check this by opening the Management Console -> Disk Management and verifying the size of the partition.

resize4.png

NB – If you receive the following error:

“Unable to connect to c: or it does not exist”

There are a couple of workarounds that you could try.

1) Close the Management Console (if it is open) and try extpart.exe again.

2) Try restarting the VM in safe mode and then run extpart.exe. This is not ideal but it is still easier than other methods I have tried to resize .vmdk files.

Share

Vmware - Virtualizzazione