Xp Domain Removal

I received this from a fellow technician:
I am becoming more aware (and frustrated with) an issue
with XP Pro when trying to remove it from a domain.

The system in question was physically removed from the
domain and not able to be 'removed' by an approved user.  
The system was then moved to a workgroup (without having a
local user account set up prior - a key point I am
learning).  As the domain name was removed and the
workgroup name applied, XP asked for an appropriate
username and password for the domain it was leaving.

I left the username and password blank, clicked ok, and a
few hourglass spins later was welcomed to the workgroup.
XP then prompted for the obligaroty reboot.  No prompts,
no warnings, and sure as heck no "STOP YOU CANNOT DO

What I am finding now is that the user info is still there
in the SAM, but XP is not allowing any login whatsoever.
The majority of accounts are disabled (or are so corrupt
that they are read that way) and I'm stuck...

I simply cannot believe this issue has not been more
common, and/or a fix doesn't exist.  Any thoughts?



Anyone want to take a crack at it?

LVL 40
Fatal_ExceptionSystems EngineerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Fatal_ExceptionSystems EngineerAuthor Commented:
I thought I would add something to the above.

Now that I am actually sitting in front of the machine, I have used a LInux password crack to view the user accounts in the SAM database and have found them all disabled.  Very curious.  When I tried to re-enable the user accounts and change the password so I can gain access to the system, it hung and would not initialize the SAM hive.

I am now considering re-installing the OS.  


You should be able to boot into safe mode with admin account and
enable the accounts.
Fatal_ExceptionSystems EngineerAuthor Commented:
Unfortunately, all accounts had been disabled.  I believe this happened as a result of not properly disconnecting from the domain before adding the box to a workgroup.  Now the passwords DO NOT work, although I was able to re-enable the accounts.  

???????????????????  Am completely dumbfounded by this.    Could the SAM db be hosed?  ARGH!
The 7 Worst Nightmares of a Sysadmin

Fear not! To defend your business’ IT systems we’re going to shine a light on the seven most sinister terrors that haunt sysadmins. That way you can be sure there’s nothing in your stack waiting to go bump in the night.

Boot Windows XP CD
enter to start setup
F8 for the license agreement
R to repair the current installation
run and wait until it reboots and installs devices
shift F10 to open a command prompt
type nusrmgr.cpl press enter (user accounts will open)
select user(s), remove/change passwords
exit command prompt so setup is running again
finish in-place upgrade

This will work like a parallel install
I don't really post these kinds of links as a rule but it may
help you with the corrupted SAM...

Being the tech in question, I thought it best to register and throw in my two cents...  Never been on this site before, but I can tell I will be.

spiderfix - The recovery console is asking which installation (only one indicated) to access, and its asking for the Administrator password... which lands us back at square one.

Also, XP has been reinstalled over top of the previous install.  No change.  It's like Kerberos has lost track of where the SAM holds the username/pw info...


Fatal_ExceptionSystems EngineerAuthor Commented:
Spiderfix.  Thanks for the comments.  As you can see, the tech (SH) is wrestling with the problem and will continue to monitor this page for any help.

Anyway, I thought I would post this URL for all those that might be interested.  I thought it was hilarious, and it did help me with some questions I had about DC's and passwords.  (For those that do not know what a command line is, please do not get offended by the authors remarks.)


>>I thought it was hilarious<<
Heh, he has run out of patience there for sure. We all know that
syndrome, you can get to a point where your get frustrated with
clients and their unrelated concerns.

With M$ serving O/Ss when changing from domain to workgroup you have
to run DCPROMO http://support.microsoft.com/default.aspx?kbid=332199
the reason is to avoid problems with the security identifiers. Apparently they
will not be linked to the objects correctly after removing active directory. I
don't know where [and how deep] the linking exists but this is obviously where
your problem lays.

It's a pretty common problem when changing from domain to workgroup, there
are many references to this is google. I can't find any references to any work-arounds
other than serving O/Ss http://support.microsoft.com/default.aspx?scid=kb;EN-US;216498

In the past any probs with logging in are usually cured with the boot disk programs
like Ntpasswd and ERD Commander but it seems these are not helping with your
lost links to the objects. This is probably one of the toughest assistance problems
to help with without sitting in your chair. It may be time to consider slaving the drive
and pulling off the files you need.

Sorry I can't help more, I've read a lot this morning on your prob and I've hit the wall
on this one. Maybe this link I've ran across may spark and idea for you...

Spiderfix - thanks for the effort, but I'm finding out that this is an "undocumented security feature" of unca bill.  The "logic" behind it is that it stops you from taking a machine physically from a workplace and attaching it to you your own workgroup, you naughty naughty hacker.  Those of us who need to do it for legitimate reasons are given a shrug of the shoulders and told we're wrong for assuming something that's worked before will work again.  Or M$ is just lazy and was criminally irresponsible for releasing XP half-baked.  Your choice.

In my mind saying (as every m$ site I've seen says) "You cannot do this."  Is a far cry from "WARNING: IF YOU DO THIS YOU WILL NEVER EVER EVER EVER BE ABLE TO LOG IN AGAIN."

I've been pounding my head against that wall for days...  Did I mention its a DELL that detects when the case was open?  That's another headache - having to tiptoe around a warrantee.  The client's fed up, so the jumpers have been changed, I'm just making one last desperate grab at a solution before I press the button...

M$ needs to lose the "tree-falls-in-the-woods" approach to security and software development.

I guess this problem is all over except the for the griping.  Thanks again.


Another good reason to have ghost images of the drives.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Fatal_ExceptionSystems EngineerAuthor Commented:
ERD Commander looks to be a good investment, eh?  I used a trial version last year, but never got approval to purchase the full version.  Guess I will just have to dig deep and get a copy.

Thanks for all the help Spider.  And since you were the only one to notice our little problem, you get the points.  Look forward to conversing  with you on another thread.

By the way, we finally just installed another HD and the WXP OS, took ownership of the files on the original HD, copied the folders over and ghosted back to the original Drive.   Only took ALLLLLL day.  Hard lessons learned!

>>Only took ALLLLLL day<<

You have to take a time-hit every once in awhile.
Something similar has happened to me. I put a registry key in our network login script (we're running primarily novell and win98 clients) that would verify/change the computers workgroup, and then point them to the WINS server. Afterwards, I couldn't get into a few XP machines without it telling me the Domain Controller couldn't be verified or something to that effect. I could get past the Novell login, but when it went to hit the windows password it would pop that error message up. Strange thing is, if you left that loigin screen up for about 5 mins, it would just log itself in. I'm not sure why or how, but it does. For future readers of this particular thread, try leaving the screen up for 5-10 mins and see if it'll just log itself in eventually.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows XP

From novice to tech pro — start learning today.