(imported topic written by JRigas)
Hey everyone,
I want to know if it’s possible, and how, to migrate users, user settings, etc from a workgroup to a domain, using TEM?
I was thinking about using USMT, but I don’t know for sure if this is a valid option.
Anyone who has done, or tried this?
Any help is much appreciated.
(imported comment written by JRigas)
A little update.
I’ve been working on this the last couple days, and have a small problem.
I’m trying to run
run cmd.exe /C "C:\test\amd64\scanstate.exe" /i:c:\test\amd64\migapp.xml /i:c:\test\amd64\miguser.xml /genconfig:c:\test\TestConfig10.xml /v:13
However, when I run this custom task, it runs succesfull, but nothing happens on the targeted endpoint.
I’ve tested the command with PStools, as stated in this KB: http://support.bigfix.com/cgi-bin/kbdirect.pl?id=1681, and it works like a charm.
Anyone any ideas on why the task doesn’t seem to run?
If I get this working, I’m pretty sure the rest of the commands are going to work too.
Had something like this in mind.
create config file (task I’m stuck on atm)
run scanstate with config file
join pc to domain
run loadstate
(imported comment written by JRigas)
Another update,
It does seem to work now.
Will post the rest of my ‘scripts’ once I’ve completed/tested them.
(imported comment written by JRigas)
Maybe one quick question though.
How can I ‘move’ the USMT folder from my server to my clients?
Will I have to work with a share, or can I distribute it with the TEM server?
(imported comment written by mcalvi91)
was out last week so i didnt see this. we did something very similar a few years ago so i would give you some advice on it. You will be carrying over a lot of crap/junk/issues from the old profiles.
Having said my warning, lets move on.
We did this in a workgroup-> domain and before/after a reimage occurred in 2 phases. We created several batch files that we made BF kick off to perform the user migration for each process.
Are you using USMT301? we used that version a few years ago. For the config i did the following to make the config xml.
<path>\scanstate.exe /i:<path>\MigUser.xml /i:<path>\MigSys.xml /i:<path>\Migapp.xml /i:<path>\CustomSettings.xml /v:5 /l:<path>\scanstate.log /targetxp /genconfig:<path>\config.xml
This will take all the other XML files (ugh) and make a config.xml file. At this point you just flip yes/no on the config file for what you want to move over.
at a high level, we did the following for the scan state command file
create a working directory
run scanstate. (We had a property to tail the progress log just for kicks and grins for each system to see where it was.)
dump certain local groups to restore the users back
get printers installed
vet the users that are on the system are actually in the domain to migrate. this was based on some fancy cmd scripting of the scanstate progress log.
type \scanprogress.log | findstr detectedUser | findstr Yes > x:%computername%\allusers.txt
for /f
"tokens=5 delims=," %%a in ( x:%computername%\allusers.txt)
do echo %%a >> X:%computername%\users.txt
for /f
"tokens=2 delims=" %%b in ( x:%computername%\users.txt) do c:\windows\system32\cscript.exe /nologo \vetUsers.vbs %%b >> x:%computername%\adusers.txt
push the scan state file and other files to a remote location (file share created for the migration on the local network).
our loadstate was basically just backwards of the scan state.
create a working area
copy down the scanstate files
re-inject the local group members with transforms for the domains
add printers back
run loadstate
clean up.
since you are just doing a workgroup user to a domain user on the same system, you dont need to push the scanstate file(s) anywhere though you will have to do some dos fancy-ness to get it working as scansate only looks to mapped drives or unc paths (at least 301 does). look up the dos command subst to alleviate that.
we pushed the whole thing (scripts, USMT, etc) to a folder on the remote computer via bigfix.