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).

  • One thing I'd suggest is to make sure the workgroup name is the same as the Netbios name of the domain. Oct 21, 2009 at 13:03
  • 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.
    – user3914
    Oct 21, 2009 at 13:58

8 Answers 8


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.


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.

  • 1
    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.aspx), and even recommended if you need to convert a local profile to a roaming profile (support.microsoft.com/kb/314478).
    – Zoredache
    Oct 21, 2009 at 19:43
  • 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. Oct 21, 2009 at 20:08

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.

  • 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.
    – Massimo
    Oct 22, 2009 at 20:57
  • 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.
    – Kyle Smith
    Oct 22, 2009 at 22:36

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.


You can have it off of the domain but when it needs to access anything it will prompt for a domain logon since the workgroup logon wouldn't be valid (and windows passes the current users credentials by default).

This happens when I'm setting up a fresh machine and hop over into our install directories to install applications before the reboot to have the domain change take effect. fortunantly its very seldom this situation occurs, only when my slipstream installers don't have the network drivers to add the machine itself.

Why would you want a machine off of the domain? I would think this would be a big administrative issue.


You can leave the domain if you have a Local Administrator account as well, which you will need to add programs to the computer, etc if you are going to own it.


Follow the below steps:

1) Make sure you have the local administrator password.

2) Leave the domain, reboot and login as local administrator.

3) Create a new local account with administrative privileges. (Normal account if you don't need the admin privileges)

4) Go to the following location in registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

5) All the accounts and their associated profiles are listed here,

6) Point the new account to the old-user's (domain user's) profile.

7) Reboot and login with the new account. You won't see the difference between old and new account.


Zoredache's answer works in practice. I posted the original question and found that his solution worked well, and seems to be Microsoft's intended remedy for this scenario. After I copied the profile of the domain account to a local account, I had to reset the local account password. Did not lose any documents since I wasn't using EFS encryption. Thanks to everyone who helped with this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy