Come trarre vantaggio dalla virtualizzazione annidata?
Probabilmente molti di voi si chiederanno che senso può avere creare più strati di virtualizzazione, la risposta è semplice: NON HA NESSUN SENSO…o quasi!.
Se osserviamo la cosa dal punto di vista “utilizzo delle risorse” non ha appunto nessun senso, se non quello di complicarsi la vita, ma se la osserviamo dal punto di vista “analisi e troubleshooting” probabilmente potrebbe averne.
Avere la responsabilità della gestione del server ESX comporta anche avere la responsabilità delle macchine virtuali ivi ospitate, occorre quindi prestare molta cura alla salute dell’host ESX.
Il rinnovo tecnologico, l’evoluzione della tecnologia della virtualizzazione stessa, generano inevitabilmente delle complicazioni che spesso si traducono nella necessità di installare upgrade oppure fix dell’hipervisor, che al loro volta introducono ulteriori complicazioni, infatti non sempre le procedure di fix o di upgrade di un sistema sono indolori.
Da tutto ciò, nasce la necessità di compiere analisi e verifiche in tal senso.
Ecco come installare un Virtual ESX (vESX):

Create una VM “custom”
Operative System: Linux Red Hat Enterprise 5 (64 bit)
Virtual Processors: 1 (o anche più, avendo cura di impostare l’affinity di ciascun Virtual Processor su altrettanti Phisical Processor)
Memory Size: 2048 MB
Network Adapter: 2 (E1000)
SCSI controller type: LSI Logic parallel
Disk Size: Quanto basta
Montate la iso di VMWare ESX 4 e procedete con l’installazione come fareste per qualsiasi altra VM.

Terminata l’installazione, per accedere al vESX, dovete apportare qualche modifica alla configurazione del “vero” hypervisor, in particolare è necessario impostare la scheda di rete al quale è “bindato” il virtal switch che ospita linterfaccia di rete oppure la VLAN del vESX in modalita “promisqua” (promiscuous mode) affinche possa ricevere tutto il traffico di rete e propagarlo a sua volta al virtual switch del vESX stesso.

Attraverso il client vSphere, potrete adesso accedere al vESX e configurarlo per eseguire tutte le prove desiderate.

Nel prossimo articolo spiegherò come creare Virtual Machines all’interno del vESX appena installato.

L’azienda per la quale lavoro è dotata di una infrastruttura Active Directory distribuita sul territorio.
Recentemente un domain controller (DC) di un uffico periferico ha mostrato alcuni errori e esperienze passate mi hanno indotto a pensare ad una possibile corruzione del database di Active Directory.
Normalmente i vari passaggi avrebbero previsto il boot in “Directory Service Restore Mode” (accesso ottenuto premendo F8 durante la fase di avvio) e l’uso di Ntdsutil per la verifica di integrità del database, ma in questo caso, fuori dai “normali” orari di lavoro in cui nell’uffico remoto non c’era nessuno che potesse aiutarmi, il solo accesso possibile restava Terminal Services.
Cercando una possibile scappatoia, mi sono ricordato di un vecchio documento dove avevo appuntato i parametri possibili del file “boot.ini”, ed ecco trovato il workaround.

1. Su “Esegui” digitate Mstsc /console
2. Inserite il FQDN o indirizzo IP del server remoto
3. Fate logon al DC utilizzando un utente di dominio
4. Su “Esegui” (DC) digitate notepad %HOMEDRIVE%boot.ini
5. Aggiungete la seguente stringa in fondo all’ultima riga del boot.ini

Ottenendo un risultato simile a questo:

6. Riavviate il server
7. Ripetete i punti 1 e 2
8. Dopo la riconnessione, in “Safe Mode“, fate logon con un account per la modalità ripristino servizi directory (non un account di Active Directory) utilizzando la password inserita nel corso del processo di promozione del controller di dominio.
9. Aprite una console (cmd.exe) e digitate Ntdsutil + Invio
10. Digitate Files + Invio
11. Digitate Integrity , per verificare il database.
12. Al termine premete q + Invio per tornare al menu precedente
13. Premete ancora q + Invio per uscire da Ntdsutil.
14. Modificare il boot.ini rimuovendo la stringa aggiunta in precedenza
15. Riavviare il DC.

Molto spesso è sufficiente mettere il database offline ed eseguire la verifica di integrità appena descritta per risolvere buona parte dei problemi che possono verificarsi al database di AD.

Se volete conoscere quali porte sono aperte sul vostro server Linux,
eseguite:

oppure solo le porte TCP:

oppure solo le porte UDP:

Se dovete collegare una interfaccia ethernet del vostro server alla rete e non riuscite a distinguere l’eth0 dalla eth1 o eth2.
eseguite:

Questo farà lampeggiare il LED della scheda per 10 secondi, senza interrompere il traffico di rete.

La scorsa settimana mi è capitato di andare da un cliente per preparare l’Active Directory appena installata affinchè possa migrare gli oggetti dei vecchi domini NT4 e 2003 con la loro SID History mediante ADMT 3.0.

Inizio con la procedura preparata in ufficio, la termino e puntualmente la migrazione dei SID non funziona:

“Could not verify auditing and TcpipClientSupport on domains. Will not be able to migrate Sid’s. access is denied”

Le provo tutte: rifaccio il trust bidirezionale, configuro il gruppo domainsource$$$ nel dominio sorgente, modifico la chiave di registro del caso, aggiungo l’utente definito per la migrazione negli administrator dei due domini (source e target), setto la SID History… ma nulla.

“Accidenti, oggi la giornata non passa proprio… sono solo le 16.38… Un momento! L’ora della macchina su cui gira l’ADMT è indietro di un’ora!”

Controlla… Controlla… c:\w32tm /monitor /domain:dominio.loc e praticamente l’ora dei Domain Controller sparsi per l’europa non coincide!! Per sistemare la questione procedo come di seguito:

1. net time /setsntp:ntp.ien.it sul primo DC
2. creo un alias nel dns ntp.dominio.loc che punti al DC menzionato prima
3. su tutti gli altri DC net time /setsntp:ntp.dominio.loc
4. net stop “windos time” && net start “windows time”

Dopo qualche minuto di panico in cui la forzatura delle repliche dava il poco incoraggiante “ACCESS IS DENIED” il comando repadmin /showrepl inizia a dare notizie confortanti sulle repliche e dopo circa 20 minuti tutte le repliche funzionano correttemante.

“Prova un pò con l’ADMT!!”

“SID Migrati…!”

Alla fine tutto è bene quel che finisce bene!!

Se utilizzate abitualmente Windows e in particolare se avete a che fare con file di grandi dimensioni, vi sarà sicuramente capitato di imbattervi in un comune quanto fastidioso errore:

Questo dovrebbe normalmente capitare quando si cerca di eliminare/spostare/rinominare files in uso da altre applicazioni – es: se cercate di rinominare un documento di Word aperto – ma “curiosamente” la cosa capita anche senza alcuna ragione apparente.In tali casi, la prima cosa da fare è… ritentare l’operazione. Sembrerà assurdo ma a volte funziona. In caso di insuccesso, si passa a tentare la stessa operazione da riga di comando:

del “mio file bloccato.zip” [INVIO]
move “mio file bloccato.zip” “altro mio file bloccato.zip” [INVIO]
ren “mio file bloccato.zip” “mio file bloccato rinominato.zip” [INVIO]

Se anche questo tentativo dovesse fallire, si può passare a programmi come Unlocker o FileAssassin (ce ne sono anche altri) che tentano il “rilascio” dei suddetti files presi indebitamente in ostaggio dal SO. Può capitare anche che neppure in tal modo il vostro file possa essere sbloccato; in tal caso questi programmi vi daranno un’ultima possibilità, ossia programmare l’operazione in modo da eseguirla durante il successivo riavvio del sistema.

Vi è mai capitato di provare a creare, sotto Windows, cartelle con nomi come “con”, “prn”, “nul”? O di provare a rinominare in tal modo cartelle già esistenti? Se la risposta è sì, probabilmente avrete già notato che il SO sembra semplicemente limitarsi ad ignorare il comando, cosa abbastanza curiosa.

In realtà, una ragione esiste, e va ricercata nel retaggio pluridecennale – ereditato dal DOS – che tutte le versioni di Windows continuano a trascinarsi appresso.

Già nei primi anni ’80 infatti, l’MS-DOS proibiva la creazione di directory denominate NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 etc… per evitare problemi di collisione con le periferiche.

In effetti, sotto Windows è possibile creare o rinominare cartelle con tali appellativi, ma per farlo bisogna ricorrere ai cari vecchi comandi DOS da shell. Digitando infatti:

md \\.\c:\NUL [INVIO]

avremo creato la cartella NUL, che sebbene potrà essere riempita normalmente di file e/o altre sottocartelle, risulterà inamovibile da Esplora Risorse (nessuna possibiltà di ridenominarla o rimuoverla). Per cancellarla dovremo nuovamente ricorrere ad un comando DOS da shell:

rd \\.\c:\NUL [INVIO]

ovviamente previa eliminazione del suo contenuto, altrimenti incapperemmo in un errore che ci avviserebbe che la directory non è vuota.

Ho avuto modo di verificare un altro problema riguardante Windows Update che può rivelarsi molto fastidioso. Dopo aver scaricato ed installato gli aggiornamenti con Windows Update ed aver riavviato il computer, qualche volta succede che Windows Update continui a riproporvi esattamente gli stessi aggiornamenti.
In molti di questi casi gli aggiornamenti non risultano correttamente installati, mentre a volte l’installazione va a buon fine, ma Windows Update non lo realizza. Per verificare esaminate ciascun log contenuto nella directory Windows (numerofix.log) e se in fondo sono riportate le diciture “RebootNecessary = x,WizardInput = x, DontReboot = x, ForceRestart = x” (dove x è un valore numerico) la patch è correttamente installata, oppure andate sul sito Windows Update e verificate la colonna dello stato degli aggiornamenti.

Per risolvere il problema, Microsoft propone l’utilizzo dello strumento di rimozione malware per Microsoft Windows (KB890830) oppure la procedura di troubleshooting descritta nel seguente articolo.

Sono molto frequenti i casi in cui amministratori di sistema, lamentino che alcuni client restino invisibili sulla WSUS console, nonostante la corretta distribuzione delle configurazioni mediante l’uso di Group Policy.
L’anomalia si verifica a seguito dell’installazione dei sistemi operativi con l’utilizzo di sistemi di duplicazione di immagine (tipo Symantec’s Ghost, PowerQuest’s Image Drive, and Altiris’ RapiDeploy) che riproducono cloni con il “SusClientSid” duplicato nel registry.
La normalizzazione di questa anomalia è molto semplice.

* Fermare il servizio “Automatic Updates”
* Avviare regedit, spostarsi in:
“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate”, cancellare i valori “AccountDomainSid” , “PingID” e “SusClientId”
* Riavviare il servizio “Automatic Updates”
* Avviare la console di comando (cmd) ed eseguire: wuauclt.exe /resetauthorization /detectnow

A questo punto sulla WSUS console dovreste vedere il client pronto, per gli aggiornamenti.

Quando si tenta di collegare (attach) un database a un’istanza di SQL Server 2000 utilizzando SQL Server Enterprise Manager, SQL Server esegue internamente la stored procedure di sistema “sp_attach_db”, ma nel caso in cui il vostro database è formato da più di 16 datafiles, la procedura “sp attach db” fallisce terminando con errore 8144 (Error 8144: Procedure or function sp_attach_db has too many arguments specified).
Per aggirare il limite, potete usare il comando CREATE DATABASE FOR ATTACH.

CREATE DATABASE Nome database
ON PRIMARY (FILENAME = ‘C:\Program Files\Microsoft SQL Server\L’istanza di SQL Server\Data\Nome di file primario.mdf’)
FOR ATTACH