Recentemente ho acquisito un nuovo cliente, ereditando una situazione informatica composta da 3 server e una 30ina di client.
La cosa strana è che chi mi ha preceduto non ha mai implementato un dominio Active Directory, e tutti i computer e i server fanno parte di un gruppo di lavoro.
La prima cosa che ho deciso di far implementare al cliente, in procinto di cambiare i server, ovviamente è stato Active Directory.
In casi come questi, però, va considerata una cosa: gli utenti lavorano con i profili locali da anni, quindi pensare semplicemente di mettere a dominio i PC e farli cominciare a lavorare con i nuovi profili di dominio, potrebbe essere di forte impatto sugli utenti. Infatti, con il nuovo profilo utente, si troverebbero con tutte le impostazioni personali perse, a partire dallo sfondo del desktop fino ad arrivare alle personalizzazioni dei programmi.
Quando ti trovi in questa condizione, puoi muoverti in diversi modi:
- Utilizzare un software per la migrazione dei profili, che in modo automatico copierà tutte le impostazioni del profilo locale sul profilo di dominio;
- Copiare a mano quello che serve da un profilo ad un altro;
- “Ingannare Windows” e far puntare il nuovo profilo alle vecchie impostazioni, mettendo mano al registro di sistema.
La soluzione numero 3 è la più veloce, e nell’articolo di oggi la voglio approfondire.
Applicando il metodo è possibile anche convertire utenti di dominio in utenti locali, o utenti di dominio in utenti di un altro dominio (in questo caso facendo un passaggio intermedio in locale: dominio1 -> locale -> dominio2).
Come macchina da laboratorio ho clonato un’installazione virtuale di Windows 7 che utilizzo nel mio MacBook e che contiene alcune applicazioni.
La prima operazione da compiere è quella di accertarsi che l’utente che si intende migrare sia un amministratore locale della macchina, poiché sarà necessario effettuare alcune modifiche al sistema che prevedono l’accesso con diritti amministrativi.
Posso quindi procedere con il join a dominio della macchina Windows, ed effettuare il riavvio richiesto. Una volta ripartita la macchina, effettuerò un primo accesso con l’utente di dominio, per poi disconnettermi ed accedere nuovamente con l’utente locale. Questo passaggio serve per far si che il sistema crei la struttura di cartelle e le chiavi di registro relative al nuovo profilo utente.
Mi disconnetto e accedo con l’utente locale.
Una volta effettuato l’accesso con l’utente locale, devo consentire il controllo completo all’utente di dominio sulla cartella c:\utenti\utentelocale, che nel mio caso è c:\utenti\utente1, comprese tutte le sottocartelle. Vediamo gli screenshot nel dettaglio.
Una volta concluso, chiudo tutte le finestre e apro l’editor di registro (REGEDIT) ed assegno i privilegi di accesso all’utente di dominio su HKEY_CURRENT_USER, come da immagini seguenti.
Ora espando la chiave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList e ne eseguo una copia di backup cliccando con il tasto destro, come da immagine:
Una volta messa al sicuro la chiave ProfileList, apro tutte le chiavi in essa contenute e guardo il valore della stringa ProfileImagePath, alla ricerca delle due chiavi che contengono c:\utenti\utente1 e c:\utenti\a.monguzzi (nel mio caso, l’utente di dominio).
Ora copio la stringa contenuta nella chiave riferita all’utente locale su quella relativa all’utente di dominio e, una volta effettuata la copia, cancello la chiave relativa all’utente locale.
L’operazione è conclusa. Ora posso riavviare il sistema ed accedere con le credenziali dell’utente di dominio, ritrovando il profilo dell’utente locale.
Attenzione: adottando questa soluzione, la cartella contenente il profilo utente manterrà il nome del precedente utente locale e quindi non sarà corrispondente al nome dell’utente di dominio.
Domandina: le cartelle, alla fine di tutto questo processo vengono reindirizzate sul server?
Ciao Valerio. Non ho fatto il test con le redirected folders. Se riesco nei prossimi giorni faccio due prove.
Di sicuro la cosa non avviene in modo “naturale”, poiché le cartelle reindirizzate vanno impostate sull’utente lato server. Se non sono configurate in tal senso, sicuramente non avviene nessun reindirizzamento.
Ok, era uno scrupolo, perché anche se ho letto attentamente l’articolo pensavo mi fosse sfuggito qualcosa. Tu di norma reindirizzi o lasci sul client?
L’anonimo sono sempre io 😀
Dipende dalle situazioni. Il problema del reindirizzamento è che l’utente deve poi capire che, se scaricasse 40GB di foto del matrimonio del cugino sul desktop, potrebbe avere qualche problema
per chi ha diverse macchine in coda suggerisco programmino semplice semplice che oltre a fare questo fa anche l’inverso, ovvero da domain user a loca user e per giunta fa anche il join diretto al dominio o al gruppo a seconda delle necessità.
4 minuti e il gioco è fatto!
http://www.forensit.com/domain-migration.html
Grazie Massimiliano
Complimenti per l’articolo ben dettagliato.
Volevo chiederti se c’è un sistema per ingannare Windows delle macchine a dominio per far vedere le macchine in LAN ma fuori dominio e viceversa, in modo da poter continuare ad accedere alle cartelle di rete della preesistente struttura a workgroup.
In pratica se è possibile una coesistenza dei due sistemi in modo da non dover stravolgere tutti i programmi e condivisioni locali in uso nel tempo. Ciò senza intervenire in modifiche sulle policy di Dominio ma solo sul PC client.
Grazie per l’attenzione.