Ghost Solution Suite

We are a small company and were initially using a domain admin account for GSS 2.5 for deployment.  We created several images for Dell Latitude E series laptops and T series precision workstations.  The Windows 7 images had been working great up until today when we tried it again.

Our Jr. net admin had left so we decided as all good practice suggests to change a lot of our passwords for various accounts.

One of them was this account we used for GSS.

I'll attempt to use one of the syspreped Windows 7 images that we had used 100s of times before, the image deploys great, starts up but then does not connect to the Domain and has the local admin account disabled.

The only way around this issue is to run a task that changes the configuration and add it to the domain that way.  I don't like how I have an extra step in here right now.  Do I really need to recreate the images?

I don't like how I have an extra step in here right now.

You dislike something as trivial as ticking a checkbox *as opposed to having an administrative password stored obfuscated in the unattend.xml*? And needing to update your images when it changes? Each to their own, I guess, but I'm not with you on that one.

Do I really need to recreate the images?

Of course not. Just edit them using Ghost Explorer to replace the unattend.xml which has the baked-in password with the new one, if you really want to keep your processes unchanged.

This is known issue with Windows 7 Sysprep.

Best practice is to edit sysprep file using Image Manager (WAIK) to enable local admin account after restore.

Please follow d below link which will help you to edit your answer file with WAIK.Make sure you enter the logon count.

https://www-secure.symantec.com/connect/articles/how-prevent-microsoft-sysprep-disabling-local-administrator-account-windows-7

Thanks Harshu, that's good to know, but I still guess the underlying problem is that the machine is not being added to the domain upon image restore.

Nigel, I think you miss the point.  I can't access the machine without using a task assigned to add the machine to the domain.  The imaging process may have disabled the local administrator previously and I just never realized it because restoring an image also added the machine to the domain, since I'm a domain admin I could access it.

I don't appreciate comments that are critical of a practice when you the other parties don't know all the circumstances, or read into the problem differently.  I'm just looking for answers.

In order to join the domain, the build has to have details of an account with the necessary privileges to perform the domain join. This is not necessarily the same account that is used for deployment.

Does your build documentation describe the details of what account is used for the domain join? The solution may be as simple as updating the password for this account as Nigel described.

When you say not necessarily the same account used for deployment, I'm not sure if I understand what you mean.

I've actually created a new account now that is limited to more of a domain power user, who has access to do basic functionality such as add/remove computers from the domain, create users etc...  So given that, I'm attempting to change the unattend.xml file on the image itself with the new account information to see if that does the trick.

If it works, great, if not then enabling the local admin account so I can at least log on to the machine would get the job done as well.

Thanks for your help!

Editing unattend.xml file would do your job.

* Using unattend.xml file will make your machine add to the Domain.

* Configuration task from Ghost Console will also help you to add the machine back to Domain.

Editing the unattend.xml file did not work.

Am I doing something wrong?

Using Ghost explorer, I opened the unattend.xml file under the sysprep folder on the image I'm testing.
I changed the username and password used to add the machine to the domain.
I saved the unattend.xml file back to the same sysprep folder using Ghost explorer.

I even attempted to recompile the image and name it something differently.

Regardless the machine will not do an unattended domain join.

I was editing an incorrect unattend.xml file.  The one that finally worked was the one located under C:\windows\Panther

This image for some reason had an unattend.xml file located in a folder in C: named sysprep.

Also I took a look at the unattend.xml file post restoration and it removes the password for domain join with *SENSITIVE*DATA*DELETED* for those concerned about security.