sysprep - post image tasks

[_jd_]

I support 11 desktops and 5 notebooks via a single XP Pro SP2 image prepared with sysprep. Some of the machines require specific utilities or small applications that need to be installed post-image. Historically, i've been able to accomplish these installations by doing make/model identification and running setup.exe, or whatever the installer may be, silently via Cmdlines.txt.

Lately, a number of these installers are doing their own make/model detection (e.g.: the installer for a bundled app supplied by PC manufacturer X checks to make sure the target PC is in fact made by that manufacturer, otherwise it won't install) and it's breaking my framework. I'm fine with the concept, however, it appears the trend with these installers is to use WMI for the make/model detection, and WMI is not available/funcational post-image during mini-setup... which means my installs fail.

So, unless there's a way to enable WMI during mini-setup (haven't found one), i'm thinking of moving away from Cmdlines.txt and doing these post-image installs in a more appropriate Win32 environment. I need to find something that's fairly clean and not terribly complex tho.

Yesterday, I looked at some potential solutions:

Sysprep: Do a post-image boot with sysprep in factory mode (sysprep -factory) with a winbom.ini file configured to do the make/model detection and post-image installs as OEMRun/OEMRunOnce actions, then reseal the box for the user login. It would be work as WMI is available, but it seems more complex then need be and would increase the length of the imaging process.

WinPE: Boot WinPE from the hard disk post-image, do the make/model detection and post-image installs then boot back to the local XP install. Booting to WinPE isn't a problem and supposedly WMI can be made to work under WinPE, but from my testing the environment is too stripped down to allow many installers to run - lots of errors, missing dll's and registry keys.

Third-party: I've looked at stuff like XPlode, but i'd like to avoid paid solutions at this point.

Auto Login: I come back to this. It's not terribly elegant so it's not my first pick, but I suppose I could do an automatic login post-image, do the make/model detection and any additional installations then reboot for the first user login.

Any other thoughts? Am I missing anything?

[zorphnog]

RunOnceEx? http://unattended.msfn.org/unattended.xp/view/web/31/

[_jd_]

Thanks. The means of executing actions post-image doesn't elude me. At this stage i'm looking to identify the most appropriate environment in which to initiate the post-image actions. As outlined above, i've looked as sysprep -factory (too complex/drawn out) and WinPE (too stripped down)... I keep coming back to the good ol' reliable AutoLogon. Sure, it's not terribly elegant, but it's simple and offers a full Win32 environment.

[zorphnog]

I'm confused. What can you not run during RunOnceEx? You have WMI and Win32 capabilities.

[_jd_]

No offense, but i'm rather well versed in the various methods. The purpose of my post is rather to discuss the environments in which I can execute post-image actions. As I mentioned above, leveraging Cmdlines.txt during mini-setup no longer meets my requirements. In addition, I can not rely on the first user login post-image as I can not assume that the first user will have the required privileges.

So, I need to execute the post-image tasks in a managed fashion. As outlined above, i've looked at the factory mode of sysprep, WinPE and a simple auto-logon. I'm interested in some discussion around the suitability of those considerations and i'm completely open to entertaining ideas I may not have thought of.

I've dug into the auto-logon via sysprep but i'm disappointed to find that I can't use an encrypted admin password. Having the auto-logon username/password embedded in the image in plain text is not desired. I'm going to do some testing today with an alternate account that's created via Cmdlines.txt and configured for auto-logon (yes, a plain-text password). I'll then look at my options to remove that account once the auto-logon is complete.

[zorphnog]

I've dug into the auto-logon via sysprep but i'm disappointed to find that I can't use an encrypted admin password. Having the auto-logon username/password embedded in the image in plain text is not desired.

Have you tried using setupmgr.exe to create the sysprep.inf file with an encrypted password? Thats how I encrypt my admin password and then fill out the rest of sysprep.inf manually.

[_jd_]

Yeah, I generated the initial sysprep.inf in the same fashion. It's documented that the use of EncryptedAdminPassword disables AutoLogon tho - can't have it both ways I suppose (see ref.chm in DEPLOY.CAB). If you want to leverage AutoLogon as part of sysprep, you have to specify the password as plain text in sysprep.inf. Doh. I've proven this out in test as well. The plain text scenario doesn't work for me as I provide my image to our desktop/notebook supplier as they image incoming machines images prior to delivery.

The alternative method i'm working with is to continue using EncryptedAdminPassword but create a secondary account via Cmdlines.txt and configure that account for AutoLogon. This works fine and i've confirmed that I can run "net user <username> /delete" as that user and remove the account while that user is logged in (self deletion). It's not entirely clean tho as the profile remains, but the account is removed and I can't login as that user afterwards. I'm still working down that path and exploring options to cleanup the profile as well.

[_jd_]

We'll, i've been moving forward with the AutoAdminLogon configuration and things are looking promising, tho I had to rebuild my unattended to address the RunOnceEx issues caused by IE7. I had dealt with that before in one of my full-blown unattended builds by installing KB931768, but I hadn't gone that far with the development build that I use for image development.

On a positive note, it looks like the current IE7 download from Microsoft includes a newer revision of iernonce.dll (7.0.5730.13) then the package was using (7.0.5730.11) and does not appear to cause the RunOnceEx behaviour.