XP Leave Windows Domain

Question

I've left a firm with a windows domain. They'll give me the development machine I used on their domain if I contract for them, but they don't want me to log into the domain, because they don't have dedicated administration. So I would be able to do anything on the LAN having access to the domain for just one more session, but not after bringing the xp machine home. I will not have access to, or need any of their LAN resources.

Ideally, I would like to keep using the same account. My question is how to quickly regain as similar a desktop and development environment as possible, running SQL Server and Management Studio and other development tools locally with minimal reinstallation.

What's the simplest way of removing an machine with XP pro from a windows domain (to workgroup) with minimal loss of application functionality and data? (Still have access to domain).

Solution 1

Removing a computer from the domain is simple, simply join it to a workgroup.

If you want to maintain their profile you'll want to copy their profile before you leave the domain.

• Create a local account for the user, and login once so the users profile folder gets created.
• Login as an account that has the local administrator privilege that is not the user you want to copy the profile from or the local account you created for the user
• Right click on my computer, choose properties
• on the advanced tab, click the button for user profile settings
• From the list select the profile that belongs to the domain account and click the 'Copy To' button.
• Change the 'permitted user' to the the local account.
• Set the profile path to point at the directory (c:\documents and settings\blahblahblah) for new local account.
• Click yes if it asks about overwriting the contents of the directory.

Of course not everything will migrate perfectly. It is likely that the users some links to domain resources in their profile that will no longer work. But you should get most of their settings.

Solution 2

It's really unclear what you're looking for. There aren't really multiple "methods" of disjoining a client computer from a domain. (I mean, sure, you could use NETDOM versus the GUI, but it's still calling the same APIs...)

Being joined to a domain isn't anything magical. Applications and data on the PC will remain intact (though software that was "pushed" with Group Policy may uninstall automatically if it was selected to uninstall when it falls out of scope of management.)

If you disjoin the Windows XP client from the domain you'll no longer be able to logon with any domain user accounts. Any local user profiles that were associated with domain user accounts will become unavailable. That would seem to qualify as "loss of application functionality" to me. Granted, nothing will be lost-- you can re-join the domain and everything will go back to functioning as it did before. It's just inconvenient.

You could create a local user account on the machine with the same username and password as a valid domain user account. This would allow fairly transparent access to server computers in the domain (a "poor man's domain trust relationship", often used on the "Home" versions of operating systems when needing to access domain resources), but that won't get you the existing domain user's locally-stored user profile.

You can "migrate" a user profile from one account to another, but there is not a documented and "supported" operation to end up with the new local profile having the same path in "C:\Documents and Settings" as the old profile, to my knowledge. Given the number of applications that I've seen that, stupidly, store references to the "C:\Documents and Settings..." folder for the user's profile, I'd say that any "solution" that doesn't preserve that path for the new local account is going to result in some loss of functionality.

Solution 3

You can leave the domain by using any Domain Administrator account to convert the machine back to a Workgroup computer. However, you will have to define a local user account which you will use in place of your existing Domain account.

The profile data (if they are not using strict roaming profiles) should be stored in C:\Documents and Settings\username.DOMAIN.

You will need a Domain Admin account, and a Local Admin account.

With not-too-much headache, you should be able to:

• Create the new local user account. (Using an Admin account)

• Log into the new account.

• Log out of the new account (This sets up your Docs & Settings folder).

• Log back into Admin and copy the files from C:\Documents and Settings\username.DOMAIN\ to C:\Documents and Settings\new_username. (Be sure you are seeing hidden files, as well.)

• Log into the new account and check the results.

Applications themselves are not stored in your user profile, but a lot of specific Application Data (Usually kept in C:\Docs\User\AppData or similar) is. You should be able to retain almost all of this data using the above method.

Solution 4

Another option is the Windows Easy Transfer Wizard (and/or User State Migration Tool). This should allow you to make a backup of the user profile, then when you go to reimport it you can specify that you want to import the settings to a locally created user account.

View more solutions

Comments

[BobbyShaftoe]

One thing I'd suggest is to make sure the workgroup name is the same as the Netbios name of the domain.

[Admin]

Not quite sure what the issue is. Windows will cache your credentials, so you'll still be able to log in anyway, even if you're not on the LAN. You might have some issues with password expiry though.

[Zoredache]

There is a way to copy a profile without regedit or manually copying files. It is documented (technet.microsoft.com/en-us/library/cc781200%28WS.10%29.asp‌​x), and even recommended if you need to convert a local profile to a roaming profile (support.microsoft.com/kb/314478).

[Spence]

Good point. I didn't think about the profile GUI. Getting the new local profile to use the same directory as the old domain profile (to keep apps working that insist on using / saving paths referring to "C:\Documents and Settings\oldprofile\..." instead of dynamically pulling %USERPROFILE% from the enviroment) will need more hackery than the procedures outlined in those articles, though.

[Massimo]

If the new local user account is not a local administrator, this won't work due to permission issues on the copied profile and its Registry; you should use Windows' "copy profile" utility.

[Kyle Smith]

I was previously unaware of this utility, sounds like it's worth looking into. Changing file ownership is definitely a point I forgot to mention.