I suppose you are using ghostwalker to assign a different computername to each machine? If so you should make sure that the same SID is active every time by explicitly telling the SID
Main Topics
Browse All TopicsHello Experts,
I am managing the QA LAB and re-imaging machines using Symantec Ghost on a daily basis.
Machines are members of different 2K and NT domains.
Once in a while (between two weeks and one month) after loading the image I just could not log on back to the domain: System's computer account missing or password incorrect.
I have to re-add the station to my domain in order to solve this. Any solution?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Once you join a machine to a domain, it will change the machine account password on a regular basis. So once you've taken the machine's image, and the machine will be used again, it will change the password at some point. The imaged version still has the old password, and is then of course unable to logon if it's restored.
Before you take the image, you'll have to disable the computer account password change on the machine.
On an NT4 client, you need to edit the registry, the DisablePasswordChange value described here:
How to disable automatic machine account password changes
http://support.microsoft.c
This will work for W2k and XP, too, but you can do it on those with the local security policy (or a group policy, depending on your setup) as well. It's in [Computer Configuration\]Security Settings\Local Policies\Security Options; In W2k, it's named something like "Don't allow computer account password change" (not using an English version), in XP, it's "Domain Member: Deactivate computer account password change".
Hello everybody and thank you for your comments.
I am using ghost.exe version 8 on all machines locally (not a corporate image server). Machines were installed from the ground (not cloned), so it is not a problem of "SID in use". Password remains the same all the time: "Never change" was selected.
What else could it be?
<< after loading the image >>
I think I missed in my first comment that you are talking about a system restored from a ghost image, and that goes off line. In this case, it is definitely an issue of SID vs. machine name.
You should run as a matter of course, some SID edit utility, either the hard (microsoft) way --
http://support.microsoft.c
or some easier way. I've never had a SID problem, but I've heard it is an issue using some Ghost versions --
http://www.google.com/sear
Check out that last list. Even if the SID is not in use, it is also linked to other features which can cause problems.
Sciwriter,
What do you mean by "definitely an issue of SID vs. machine name"?
Let me repeat: Machines were not cloned, so their SIDs are unique.
All you could find about SID problem on Symantec web-site is related to CLONING procedures (not my case).
After all I tried to generate new SID before saving the image using Sysinternals NewSID utility. It does not help.
I have a theory that there is a mechanism of SID synchronization between domain controller and the host. Once in a while (where and how to configure?) for security reasons domain controller changes the SID locally and on the host. When this happens, re-imaging will bring back machine with an "old" SID and logon to the domain will fail.
This is just my theory.
<< a mechanism of SID synchronization between domain controller and the host. >>
That is absolutely correct. That is what I was getting at, although I am still a bit uncertain as to exactly what you are restoring from a ghost image -- sounds like you are restoring the original setup, and that was not clear to me to begin with.
Let me explain it this way -- in a NON domain controller environment (or AD on 2003), the SID issue is NOT an issue. It is strictly the domain controller (or its AD equiv) that is producing this problem, and the haphazard nature of it is caused by exactly how long the DC is keeping the old SID setup cached, versus exactly when you bring a restored system online.
You can force a refresh on the DC if it becomes a persistent problem -- but usually the SID mis-ID forces the AD to clear that one out anyway, so the next time you boot, the system is "recognized" anew. Hope that is clearer.
Well, it was in the MS article I listed above --
"Programs or services that leave a handle open to the user's registry cause the unload of the hive not to succeed."
There are oodles of MS articles on this same problem, and they pretty much explain the SID problems --
here are a few more key artilces on this issue --
http://support.microsoft.c
http://www.windowsitpro.co
http://support.microsoft.c
http://www.interex.org/pub
http://www.adminlife.com/2
asssa,
please read my post again. This is NOT about a *user's* password, this is about the *computer's* account password (yes, computer accounts in a domain have passwords, too), and it's exactly what's happening here. There's no way to set this password to "Never change" except for the ways I described; the *user's* profile checkboxes "Password never expires", "User may not change password" etc. are of no interest here.
Business Accounts
Answer for Membership
by: sciwriterPosted on 2005-03-21 at 22:04:07ID: 13598442
Hmmmmm... That's a challenging one -- if you do NOT run Ghost, presumably, this would not happen?
Assuming it does not, are you doing ghost images -- or file-by-file replication? If the latter, it is entirely possible that your system is looking on the LOCAL replicated drive before it is seeking a (the original) remote drive, and it is finding a domain and/or user acc. mismatch, and reporting an error. Since this IS a tough one, rule that out first....
Second look to the GHost corporate server, see if it is set to "see" your replication environment as a remote share -- if so, that could be throwing off the domain controller. You will have to test a few possibilities before we solve this...