Dopo l’uscita di Microsoft Windows 7 era venuta l’ora di metterci un pò le mani.
Anticipo subito che lavoro principalmente ancora con il buon vecchio client WindowsXP, ed ho sempre cercato di evitare Vista, quindi ho poco confronto con il suo diretto predecessore ma ho subito trovato Seven molto veloce e molto più stabile di Vista.

Dopo alcune ore passate su di esso ho avuto la necessità di sposare, come di consueto per le mie installazioni, la folder Users al di fuori della partizione dedicata al sistema operativo C:
Per fare ciò sono disponibili anche in windows (cosa ben nota agli utenti unix) i link
si chiamano “juntion points” e con questi possiamo personalizzare al meglio senza rischi la nostra struttura Windows

Eccone la procedura seguita per spostare la cartella Users in un’altra partizione in Windows 7:

1- Instalare l’S.O.
2- Riavviate il PC con il DVD di Win7 o con una chiavetta di recovery win7 ed entrare nel prompt di ms-dos
3- digitate i seguenti comandi:
> diskpart
> list disk
> sel disk 0 (il disco principale)
> list part
> sel part 1 (di solito quella Riservata – 100Mb)
> Assign letter=Z (lettera a caso)
> sel part 2 (quella dove avete installato il sistema operativo)
> assign letter=C
> sel part 3 (quella dove volete creare la nuova Users Folder)
> assign letter=D
> exit
4- siete tornati a X:\Sources, eseguite questi comandi
> mkdir D:\Users
> robocopy C:\Users D:\Users /mir /e /xj
> rmdir /s /q C:\Users
> mklink /j C:\Users D:\Users
> mklink /j “C:\Documents and Settings” D:\Users
5- Riavviate

Così facendo avete spostato i dati in una cartella D:\Users e lasciata intatta la configurazione dei registri
Windows cercerà ancora di scrivere sulla partizione C: ma attraverso il juntion point verrà re-diretto sull’altra partizione.

Attenzione ad usare con cautela questa procedura e ricordatevi che in caso di reinstallazione/restore dovrete rimodificare la configurazione.

Queste tipo di directory/link sono utili anche in caso vogliate sposare altre cartelle, esempio la PROGRAM FILES o altro su cui non vi basta lavorare con le variabili di sistema

Ebbene si’, anche io, mio malgrado, sono passato a Windows 7.
Purtroppo era diventato impossibile lavorare con Windows Vista e Windows XP a 64 bit non e’ il massimo.
Appena terminata l’installazione ho cominciato a “destreggiarmi” tra i vari menu, installando per primi i programmi “utili” e proprio terminata l’installazione di “VMware vSphere Client”, provando ad accedere al Virtual Center, mi e’ comparso il seguente errore:

e successivamente:

Ovviamente, conscio che qualcosa non avrebbe funzionato con la nuova versione di Windows, mi sono messo alla ricerca di una possibile soluzione.
Il sito VMware propone l’aggiornamento a vSphere 4 Update 1 per supportare Windows 7 e Windows 2008 R2, ma in attesa di procedere con l’aggiornamento, prendendo vari spunti qua’ e la’ ecco il “Workaround”.

Fase 1

• Procuratevi il file “System.dll” da un sistema operativo diverso da Windows 7 sul quale e’ installato il framework 3.5 (il file lo trovate in %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\), considerando, qualora utilizziate un sistema a 64 bit, di prelevare la versione del file a 32 bit (il client vSphere e’ comunque a 32 bit)

Fase 2

• Copiate il file in una directory creata ad hoc (es. lib) in %ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher

Fase 3

• Editate il file VpxClient.exe.config inserendo il blocco

  <runtime>
  <developmentMode developerInstallation="true"/>
  </runtime>

  appena prima del tag “</configuration>”

Fase 4

• Lanciate SystemPropertiesAdvanced.exe, premete il pulsante ‘Variabili d’ambiente‘ e create la variabile di sistema “DEVPATH” con riferimento alla directory contenente il file “System.dll” (Fase 2).

Dopo aver riavviato l’istanza di Explorer.exe oppure il computer, per rendere la variabile visibile al sistema, dovreste poter accedere al Virtual Center.

Può capitare a volte, per un motivo o per l’altro, di avere bisogno di un tunnel privato che ci colleghi ad un host remoto garantendo sicurezza e stabilità. Connessioni di questo tipo trovano largo impiego sia in ambito aziendale che privato, sebbene non tutte le soluzioni esistenti siano economiche o facili da realizzare.

Vediamo ora com’è possibile realizzare un tunnel fra due macchine senza necessità di agire su firewall per impostare regole di port forwarding.

Supponendo di volerci collegare alla macchina A alla macchina B, su cui sia già installato un server SSH, fra i vari client utilizzabili a tale scopo c’è Putty: leggero ed Open Source, non richiede installazione, e fa al caso nostro per risolvere la questione che ci siamo posti.

Aprendo Putty, inseriamo l’indirizzo della nostra macchina B verso cui vorremmo collegarci:

Spostiamoci poi nel menù a sinistra, verso il basso, aprendo il sottomenù Tunnels come in figura:

Qui, scegliamo Dynamic fra le scelte multiple in basso, immettiamo nel campo Source port la porta verso cui la macchina remota si collegherà alla nostra per aprire il tunnel (non è necessario che questa sia aperta verso l’esterno, poiché la connessione avverrà in reverse) e lasciamo bianco il campo Destination.

A questo punto, premendo Add dovrebbe comparire nell’elenco Forwarded ports la porta che abbiamo scelto, preceduta da una D:

La configurazione è finita, prememdo su Open si instaurerà la connessione, e una volta autenticatici nel server come di consueto avremo creato il nostro tunnel. Un esempio di utilizzo: proxy SOCKS – anche per accesso a servizi nella lan locale della macchina cui ci siamo collegati.

Impostando su FireFox come proxy SOCKS l’indirizzo localhost e come porta quella che abbiamo poc’anzi specificato, navigheremo usando la macchina remota come tramite.

Uno script di autoconfigurazione con estensione *.pac, chiamato per comodità proxy.pac contiene genericamente una funzione JavaScript chiamata “FindProxyForURL(url, host)” che restituisce uno o più risultati, basandosi su condizioni definite dal gestore del sistema di proxy, che un moderno browser è in grado di interpretare.
Viene solitamente utilizzato quando è necessario discriminare la modalità di navigazione al fine di indirizzare l’utente, in modo trasparente, a rivolgere la sua richiesta attraverso il proxy oppure in modalità “diretta”.
Eccone un esempio:

function FindProxyForURL(url, host)
{
       if (isPlainHostName(host))
       {
       return "DIRECT";
       }
// NAME HOSTS --> DIRECT

        if ((host=="domainname.it")||
            (host=="domainname.com"))
        {
        return "DIRECT";
        }

// NAME HOSTS --> PROXY

        if ((host=="abcd.domainname.it")||
            (host=="efgh.subdomain.domainname.it"))
        {
        return ProxyServer(url);
        }

// IP HOSTS --> DIRECT

        if ((host=="10.60.50.141") ||      // Servizio XYZ;
            (host=="10.32.1.103"))          // Servizio ZXY;
        {
        return "DIRECT";
        }

// IP HOSTS --> PROXY A

        if ((host=="10.128.64.50")   ||    // Servizio A
            (host=="10.51.8.50")     ||     // Servizio B
            (host=="10.51.76.202"))        // Servizio C
        {
        return ProxyServer(url);
        }

// IP HOSTS --> PROXY B;

        if ((host=="XXX.201.99.120") ||
            (host=="YYY.223.212.242") ||
            (host=="ZZZ.221.99.154"))
        {
        return "PROXY aa.bbb.ccc.d:8080; DIRECT";
        }

 //LOCAL DOMAIN NAME --> DIRECT

        if (dnsDomainIs(host, "subdomain.mydomain.it") ||
            dnsDomainIs(host, "subdomain.mydomain.com") ||
            dnsDomainIs(host, "internaldomain.loc") ||
            dnsDomainIs(host, "otherdomain.it"))
        {
        return "DIRECT";
        }

//PRIVATE NETWORK --> DIRECT

        if (isInNet(host, "10.0.0.0", "255.0.0.0") ||
            isInNet(host, "127.0.0.0", "255.0.0.0")  ||
            isInNet(host, "172.16.0.0", "255.240.0.0")  ||
            isInNet(host, "192.168.0.0", "255.255.0.0"))
        {
        return "DIRECT";
        }

        // otherwise use Proxy Server

        else

        function ProxyServer(url);

function ProxyServer(url) {
   return "PROXY cache.internaldomain.it:3128; DIRECT";
}

Il proxy.pac per essere utilizzato deve essere messo in linea su un web server opportunamente configurato, argomento che tratteremo in un prossimo articolo.

Per ulteriori informazioni sull’uso degli script di autoconfigurazione consultate Wikipedia
Per verificare la sintassi e/o i risultati del vostro proxy.pac potete utilizzare pactester.

Qualsiasi amministratore si augura di non dover mai utilizzare questa password, ma proprio perchè il suo utilizzo non è così frequente, molti non la ricordano, oppure essendo subentrati nella gestione dei sistemi a qualcun altro, non la conoscono.
Accorgersi di non conoscerla in un momento critico, può essere davvero moltro frustrante, quindi se vi sta sorgendo il dubbio, reimpostatela.

In Windows 2000, a partire dal Service Pack 2, è possibile utilizzare il comando setpwd digitando,

• Aprite una console (cmd.exe) e digitate setpwd /s:nomeserver(dove nomeserver è il nome del Domain Controller sul quale si intendende impostare la nuova password).

In Windows 2003, questa funzionalità è stata inserita nell’utilità di sistema Ntdsutil, ecco i passaggi da seguire:

• Aprite una console (cmd.exe) e digitate Ntdsutil + Invio.
• set dsrm password.
• digitare uno dei seguenti comandi:
  • reset password on server null (per impostare la password sul server su cui si sta operando)
  • reset password on server nomeserver (dove nomeserver è il nome del Domain Controller sul quale si intendende impostare la nuova password)
• Al termine premete q + Invio per tornare al menu precedente
• Premete ancora q + Invio per uscire da Ntdsutil.

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.

Ultimamente sto implementando un ambiente di laboratorio su Hyper-V presso un cliente e dopo alcuni giorni di lavoro vi segnalo un paio dritte che a me hanno fatto risparmiare un pò di tempo (… e mal di pancia!)

Innanzitutto, se avete a disposzione un client Vista SP1, potrebbe essere utile amministrare i vostri server fisci e virtuali da snap-in. E’ vero che è già disponibile System Center Virtual Machine Manager che fornisce funzionalità aggiuntive, ma è anche vero che quest’ultimo necessita di licenza a parte. Nonostante questo, l’utilizzo dei Remote Server Administration Tool (o il singolo snap-in di Hyper-V) si è dimostrato molto efficace nella situazione in cui l’ho implementato. Il gorsso vantaggio riscontrato è che è possibile distribuire il tool di gestione remota avendo però il controllo delle operazioni che gli utenti possono effettuare sulle macchine virtuali e sul server, delegando in modo “abbastanza tranquillo” la gestione degli Hyper-V server.

Tutto ciò è fattibile grazie alla possibilità di creare “ruoli” custom all’interno della gestione dei server virtuali ai quali è possibile associare gruppi o utenti Active Directory. Ne mio caso ho utilizzato un ruolo “administrator” per la gestione completa dell’ambiente virtuale (creazione macchine virtuali, modifiche al HW virtuale, connessione alla console, ecc..) che è stata attribuita al team dei sistemisti, e di un ruolo “developer” per la gestione essenziale della mcchine (accensione\spegnimento, snapshot, ecc…) messo a disposizione del team di sviluppo.

Per i dettagli della implementazione di tale soluzione può tornarvi utile il seguente link per due motivi: primo perchè è quello che ha aiutato me e secondo perchè non vorrei prendermi meriti che non mi spettano!!

Un’altra situazione che potrebbe darvi qualche grattacapo è quella della modifica delle caratteristiche dei dischi virtuali (tipo, dimensione, ecc…): in questo caso ricordatevi sempre di controllare se ci sono degli snapshot!! Se avete creato delle “fotografie” in momenti diversi della vita del vostro server virtuale (troppo sdolcinato??) e dovete modificare la dimensione dei dischi per una qualsiasi ragione, eliminate gli snapshot, spegnete la macchina virtuale e attendete che le operazioni di merging siano terminate(anche se durante la modifica del disco prima del merge nessun pop-up vi avviserà che l’operazione crea danni a non finire…)

L’altra dritta che potrebbe risolvervi un pò di problemi, è quello di utilizzare nelle macchine virtuali le schede di rete Legacy invece delle schede che utilizzano i driver contenuti nelle “additions” di Hyper-V. Sinceramente non so ancora dirvi con precisione il motivo reale per cui i driver Legacy funzionano meglio di quelli inclusi nel role di 2008 ma credo sia dovuto alla “giovane età” del prodotto (anche se per molti versi mi ricordano i problemi che si hanno con la gestione delle netwok connection di Vista…): in ogni caso se ho qualche news vi terrò aggiornati. Nel frattempo posso dirvi che i consigli forniti sono maturati dopo diversi giorni di test su configurazioni di ambienti virtuali Windows 2003\2008 con implementati Sql 2005 e Share Point, ciò non toglie che sono gradite segnalazioni\delucidazioni da parte vostra in merito!

Windows 7 (codename “Vienna”) la cui data di rilascio è prevista per Giugno 2009 sarà il naturale successore di Windows Vista. Non è previsto lo sviluppo di un nuovo kernel, ma il modello adottato attualmente da Vista sarà totalmente ridefinito. Windows 7 dovrà operare utilizzando gli stessi requisiti hardware di Windows Vista e sarà dotato di un’interfaccia multi touch simile a quella presente sull’Iphone che permetterà di utilizzare il sistema operativo tramite touch screen con più dita, oltre che con i dispositivi di input tradizionali. Sarà inoltre sviluppato un sistema “modulare” con una base al quale ogni utente potrà aggiungere i vari servizi in funzione delle proprie esigenze e del proprio budget.

In Outlook Web Access (OWA) 2003, la funzione che permette agli utenti di cambiare la password è disabilitata (configurazione di default). Di seguito illustrerò come configurare il server Exchange 2003 per abilitare questa funzione, dando per assunto che il server in oggetto sia già configurato per l’uso di SSL.

1. Sul server Exchange, aprite Internet Information Services Manager (Administrative Tools).
2. Espandete l’albero fino a raggiungere il Web Site di OWA (di solito Default Web Site).
3. Fate click col tasto destro su “New” –> “Virtual Directory” per accedere al Wizard ; Next.
4. Nel campo “Virtual Directory Alias” Inserite iisadmpwd ; Next.
5. Premete “Browse” e cercate %Systemroot%\System32\Inetsrv\iisadmpwd ; Next.
6. Assegnate i permessi di Read, Run, Execute ; Finish.

Occore adesso fare una configurazione al registro di sistema.

1. Aprite il registro di sistema (regedit)
2. Espandete l’albero fino a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA
3. Nella finestra di destra, fate click col testo destro su “New –> DWORD Value” e create DisablePassword assegnando il valore 0 (zero).
4. Chiudere Regedit.
5. Riavviate il servizio IIS.

A questo punto, aprite OWA, inserite le credenziali di accesso, fate click su “Opzioni” ed in basso potrete vedere il pulsante “Cambia Password”.

N.B.
Se avete un’architettura Exchange strutturata in Backend e Frontend, questa configurazione deve essere fatta sul Frontend (sul Backend sarà necessario modificare solo il registro di sistema).