Deployment Solution

Hello all,

I'm having a problem maintaining a local administrator account on my Windows 7 PC after imaging. Let me briefly summarize my imaging process:

To create my image, I use a DS 7.1 Scripted OS Install job to install Windows 7 Enterprise using a custom unattend.xml on my master image PC. It enables the Administrator account, then also creates a secondary local admin account called Admin. I install updates on the PC, then capture the image for deployment.

I only added the second Admin account to the PC because Windows 7, after imaging, leaves the local Administrator account disabled. I use group policy preferences to enable the local Administrator account once the newly imaged PC joins the domain. However, if the PC does not join the domain, I am completely locked out of the PC. My intent was to add a secondary local admin account to the machine so that, even if the configuration task sent to the PC after imaging failed, my techs could still log into the PC and do basic troubleshooting, look at Altiris logs, etc.

What I find is happening, however, is that on deployment of my image, my second local Admin account has its administrative rights stripped away from it, making it just a standard user account. While I can at least log into the machine, I can't administer it until the PC gets joined to the domain.

One last thing - While my Scripted OS install job used to create the master image does use a custom answer file, my Deploy Image task does not, nor do I want it to. I want to keep the option checked in my Deploy Image task to "generate Sysprep info using inventory data". So, given that constraint, is there any way for me to be able to do either of the following:

A. Keep my local administrator account enabled, even if the PC doesn't join the domain? Or,

B. Find a way to allow this second local Admin user to retain its administrative rights?

My reluctance to use another custom answer file for my imaging task stems from the fact that it was a real PITA setting up my original answer file for the SOI. If I made another custom one, I'd need it to contain all of the same tokens that the "Generate from inventory data" checkbox uses. It's just so much cleaner to be able just check that checkbox and be done with it. I'm sure I could get it to work this way if I worked at it, but I'd really prefer not to. And then there's the matter of principle - what good is the option to Generate from inventory data if I can't log into the PC after it's imaged? (I have to run a Config task after imaging new bare metal PC's because importing Predefined Computers via CSV file doesn't work in DS 7.1 like it ought to. But that's another thread.)

Any thoughts on this matter? Thank you!

You probably want to use the custom answer file.  After the deploy image a new unattented file gets copied to the c:\windows\panther. Either the custom or the answer file using inventory data.  To test the answer file open the image if Rdeploy image with Imager Explorer and replace the answer file. I know there is something similar for Ghost.

Not sure what tokens the inventory checkbox gives you, I use custom answer file that enables local admin account, sets password and auto logs in once (and then join domain task reboots machine). I dont use any ther users. Let me know if you need details.

Sally check \\localhost\NSCap\bin\Win32\X86\Deployment\SOI\AnswerFile it will show you what gets used for inventory.

Okay, if I have to use a custom answer file, that's fine. But the ones in the SOI directory do not work for the Deploy Image task. Neither do the ones at \\localhost\NSCap\bin\Win32\X86\Deployment. I have tried every single sample answer file available, and none work for the Deploy Image task. What am I doing wrong?

I just created a new Windows 7 x64 image, my first since upgrading to MR1. My secondary local Admin account on this image retained its local Admin settings. Well, that's great news, but why? Does MR1 have different sysprep settings that would account for this?

I'm 99% certain at this point that Altiris's behavior is NOT the culprit in this scenario. I have two forests each with different group policy settings. I'm near certain I have a group policy out there in at least one of them that is stripping admin rights from unspecified local administrator accounts, such as the one I just created.