[THIN] Re: OT - freeware desktop profile utility for domain migrations
- From: "Jeff Durbin" <techlists@xxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Wed, 28 Jul 2004 16:27:42 +1200
Why not just use ADMT? It's also free, and it will migrate machine accounts
and local user profiles. Also supports a command-line option to migrate
local profiles:
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deploy
guide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/de
ployguide/en-us/dssbg_rent_vgkz.asp
JD
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Jim Hathaway
Sent: Wednesday, 28 July 2004 5:22 a.m.
To: thin@xxxxxxxxxxxxx
Subject: [THIN] OT - freeware desktop profile utility for domain migrations
Just thought I'd share this with you folks, even if it's not really terminal
services related. :)
I'm currently in the process of planning a medium sized domain migration (a
few thousand seats), and was trying to find an answer to the excessive
amount of time that can go into the process of migrating end user's desktop
local profiles with their workstations when they get moved into the new
domain.
After a great deal of searching I stumbled across this awesome little
utility that makes the process of migrating workstations and user profiles
to new domains a snap.
<http://www.forensit.com/Profwiz%5CDefault.htm>
http://www.forensit.com/Profwiz%5CDefault.htm
In a very simple approach to the problem, this utilty "shares" whatever
local machine or domain profile you specify with whatever domain account you
specify. No file copies, and almost no time needs to be spent at desktops
for this to run in the freeware version. You can get a corporate version
that allows for command line syntax, so the whole process of migrating your
profiles and desktops can be done from a login script.
The website has a general run down of what the utility does, below is a more
specific breakout of the only issue I've seen with the application . . It
leaves behind a "ghost" profile on a migrated system.
- machine is currently in DomainA, with "userA" logging into it w/ a
local profile.
- You run the utility to allow "UserB" from "DomainB" to access the
profile of "UserA", and you move the machine into "DomainB".
- on next boot, the domain list will default to "DomainA", you need
to change it to "DomainB".
- UserB is able to login to DomainB, and the profile they
get is the profile for "UserA"
- When logged in as an admin to the machine and looking at the
"profile list" that displays by right clicking "my computer" going to
"advanced" and "user profiles" you'll see 2 profiles listed.
- domainA\userA, and domainB\userB.
- If you look under C:\documents and settings\, you only see the
profile directory for "UserA".
Here's the trick with this. The way this utility works is to "share"
the root profile you define, and then to "trick" the OS into using the old
profile with whatever other account you've specified. So if you "delete"
from the profile list either "userA", or "userB" you are deleting the
profile that you just moved, because they both point to the same location \
profile.
For the amount of time this utility saves, this issue is very minimal, and
could likely be resolved with a follow up script that removes the refrence
to the old domain and user name in the profile list from the registry.
Hope this helps others out there.
J
Other related posts:
