"Moveuser.exe" from Resource Tools

[Charliesz]

Hi,


Just wondering if there is a "going back" once one uses this utility(moveuser.exe) that comes with Resource Tools for windows 2003.

I transfered local PC profiles to the domain user accounts using that util and its all great. All the settings have been preserved but email password.

Now, say i wanted to go back from domain back to workgroup
Once i do that, the local accounts are no longer available to me.

To explain what im trying to say:

Charlie <- my local profile
Computer name is COMPNAME

After i switch from domain back to workgroup and try using "Charlie" as a username , windows loads up a brand new profile.
If i go to "Documents and Setting" folder , i see the old account "Charlie" still there but i also see a new one called "Charlie.COMPNAME" which i use when using "Charlie" as a user name

i logged in as administrator, and deleted the new profile and renamed the "Charlie" profile to "Charlie.COMPNAME"
That worked partially. Backgrounds and menu configs are no longer there eventhough all the favortites and programs are.


Is there a way back?

 

[markdmac]

You don't say if this workstation is XP or WIn2K. Steps are mostly the same.

Create the local user account and log on as it.(do NOT make the user a local admin yet even if that ill be their end state) Log off.

Right Click My Computer
Click Properties
Click Advanced
Click Settings under User Profiles
Highlight the domain profile.
Click CopyTo
Browse to the local users folder under Docs & Settings
Click OK
Click the Permitted to Use button and assign to the local user.
Click OK.

It should now work.

After verifying that it works you can move the computer out of the domain.

Main question of course is why the heck would you want to go back to a domain and have to manage individual security accounts on each PC, that is nuts.



I hope you find this post helpful. Please let me know if it was.

Regards,

Mark

 

[Charliesz]

Thanks for the response. I will try it after i post this.

Why do i want to do that?
Just a a fail-safe step. Since im new to the world of "real" networking i'd like to know how to go one step back after a change is imlemented.

In this specific situation, i want to add a particular user to the domain. Let him play around with it and see if it works with all the crap hes got installed. Then if he draws an M16 at me, i would like to be able to set him back the way it was initially.

Thus far ive been experimenting on myself (have a test server and clients)

Thanks again

 

[Charliesz]

Well, doing the way you suggested is basicaly the same as just manually copying the content from one profile to another (ive run a few tests and confirmed). It does not preserve backgrounds, menu locations , email and etc. I was hoping all this specific user information would be somewaht stored in the ntuser.dat file but apparently moving it from one profile to another doesnt do much.

Moveuser.exe copies everything right. Its just if only it didnt corrupt the local profile after its done with it.

I still dont get why i get "Charlie.COMPNAME" profile and not just "Charlie" after i part from domain. So i end up with 2 profiles, non of which is the original before i joined the domain. I would think it would be logical to preserve settings instead of messing them up. Why do they have it so complicated Just learning the hard way heh like everybody else.

 

[markdmac]

If you don't have a user profile already on that box when you sign onto the domain you would see it create a directory just called Carlie. Likewise if the machine had been a member of an old domain you might see even more variations such as Charlie.OldDomain (old domain profile) Charlie (local profile) and Charlie.NewDomain (new domain profile)

Instead of using the utility, fo your testing just have the user sign onto the domain and get a new profile created. Then use the above steps to copy the local profile up to the new domain profile, that way the original is intact.

I hope you find this post helpful. Please let me know if it was.

Regards,

Mark