_jd_

Hi, I've been maintaining unattended installations and sysprep images for XP Pro for the last few years and have used the SVCPACK method to install Microsoft Updates and other components like Windows Media Player, Internet Explorer 7, etc - no problems with SP2 builds. Unfortunately, with SP3, it appears that SVCPACK is not being processed during the unattended installation - nothing relevant noted in the C:\WINDOWS\setup*.* logs and no logs are being created for the updates specified in my SVCPACK.INF, even those run with an explicit /log option. Note that i've tried using 1) a slipstreamed SP3 build and 2) the XP Pro with SP3 downloaded from Microsoft (we have a volume license agreement). Both behaved the same. I've done some research and found some posts re: registering wups2.dll or force installing the Windows Update Agent, but the discussions are more relevant to end-user installation of SP3 after Windows has already being installed. I did however try adding the Windows Update Agent as the first item in SVCPACK.INF but had the same behaviour. Anyone encounter this or have suggestions on how to resolve it? Given our processes, the SVCPACK method is preferred way of installing Microsoft Updates vs doing RunOnce/RunOnceEx type stuff. Thanks.

Cool. IntelPPM service disabled = booting w/ mini-setup. Should be a walk in the park from here. Edit: Spoke too soon. I was hoping to disable the IntelPPM via a routine called from Cmdlines.txt, but that isn't processed until after the OS tries to load. Doh. So, I suspect those taking an image from Intel -> AMD systems are disabling the IntelPPM service prior to booting from the freshly imaged hard disk (e.g.: WinPE). Hmm...

----- Post Nº 1 ----- Background... We've been buying Intel-based systems over the past few years and I have maintained a sysprep'd image that works across ~16 different models of notebooks/desktops. When Intel introduced the Matrix Storage Technology I had to update my unattended/imaging builds to include the iastor/iaahci mass storage components, so i'd like to think I have some experience adding mass storage drivers to unattended/sysprep configurations. I'm now evaluating an AMD-based desktop that uses the ATI Xpress 1150 chipset. The board utilizes a SATA controller (SB600 I believe) but the BIOS only has options for Legacy and Native IDE modes. In both modes, the controller presents under XP as two "Standard Dual Channel PCI IDE Controller" devices. I've snagged the appropriate mass storage drivers and incorporated them in my sysprep configuration by adding the device id's and INF paths to sysprep.inf and as OEM drivers. When the image is dropped on one of the AMD machines, the OS fails to boot. It just cyclically boots to the "Windows failed to start successfully" screen. I've dug into the INFs and it looks like one of them doesn't actually install anything itself, it simply includes the standard msdhc.inf and installs pciide.sys, pciideex.sys and atapi.sys for a compatible device id. So, i'm nearing a brick wall on this one re: getting my sysprep'd image to boot on this chipset. Any thoughts? ----- Post Nº 2 ----- Looking at the IntelPPM service now... i'm hopeful that this is causing my problem and that it's not as mass storage issue.

That's what I ended up doing. Irritating tho.

The contents of RunOnceEx is what i'm currently using. Insertion of "start /min" was only done temporarily to test functionality - I don't have a copy of it but the modifications were to simply prefix each RunOnceEx action with "%COMSPEC% /c start /min ". I will edit my earlier post accordingly. As for install.cmd, it contains: @echo off cls echo "%date%:%time%:POST CLONE:Installing Roxio DigitalMedia Plus 7.2" >> C:\distribution.log start /wait %SYSTEMDRIVE%\temp\postimage\hp\roxio\dmp\7.2\setup.exe /qn REBOOT=ReallySuppress reg add "HKLM\SOFTWARE\Sonic\Registration\CinePlayer" /v "RunRegApp" /t "REG_DWORD" /d "00000002" /f reg add "HKLM\SOFTWARE\Sonic\Registration\DLA" /v "RunRegApp" /t "REG_DWORD" /d "00000002" /f reg add "HKLM\SOFTWARE\Sonic\Registration\SCAudio" /v "RunRegApp" /t "REG_DWORD" /d "00000002" /f reg add "HKLM\SOFTWARE\Sonic\Registration\SCCopy" /v "RunRegApp" /t "REG_DWORD" /d "00000002" /f reg add "HKLM\SOFTWARE\Sonic\Registration\SCData" /v "RunRegApp" /t "REG_DWORD" /d "00000002" /f reg add "HKLM\SOFTWARE\Sonic\Registration\SCMain" /v "RunRegApp" /t "REG_DWORD" /d "00000002" /f reg add "HKLM\SOFTWARE\Sonic\CinePlayer\1.5" /v "PerfWarn" /t "REG_DWORD" /d "00000000" /f reg add "HKLM\SOFTWARE\Sonic\CinePlayer\1.5" /v "FileAssociationsDontAsk" /t "REG_DWORD" /d "00000001" /f reg add "HKLM\SOFTWARE\Sonic\CinePlayer\1.5" /v "DVDAutoPlayDontAskApp" /t "REG_SZ" /d "" /f exit

Here's an export of RunOnceEx: ----- Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx] "Title"="Additional Tasks (HP dc7600)" "Flags"=dword:00000000 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx001] @="Roxio DigitalMedia Plus 7.2" "1"="C:\\temp\\postimage\\hp\\roxio\\dmp\\7.2\\INSTALL.CMD" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\9999] @="Finalizing" "1"="C:\\WINDOWS\\system32\\cmd.exe /c rmdir /s /q C:\\temp\\postimage" "2"="C:\\WINDOWS\\system32\\net.exe user <username> /delete" "3"="C:\\WINDOWS\\system32\\reg.exe delete \"HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\WinLogon\" /v AutoAdminLogon /f" "4"="C:\\WINDOWS\\system32\\reg.exe delete \"HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\WinLogon\" /v DefaultUserName /f" "5"="C:\\WINDOWS\\system32\\reg.exe delete \"HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\WinLogon\" /v DefaultPassword /f" "6"="C:\\WINDOWS\\system32\\shutdown.exe -r -t 0 -f" ----- As I mentioned, the batch file (INSTALL.CMD) simply contains a "start /wait setup.exe /s" and some calls to reg.exe to configure the application being installed.

What method would you suggest for hiding them? I've used some vb in the past for something similiar.

I'm using RunOnceEx to do some tasks but i'm seeing some unexpected behaviour. The actions called via RunOnceEx consists of a batch file (contains a start /wait setup.exe and several directly related reg add calls to configure the installed app) then a few seperate unrelated command line calls (e.g.: rmdir, reg add/delete, some net stuff, etc). Because it's all processed by cmd as RunOnceEx is processed several command windows pop up... i'd like to get a handle on them. I modified the RunOnceEx entries to run the actions using "%COMSPEC% /c start /min" and that seems to control the command windows by minimizing them as they're opened. What's unexpected is that the start /wait in my batch file no longer waits with the parent window being minimized. I tried modifying the start /wait in the batch file by adding /b in the hopes that running the setup.exe in the minimized parent window would allow the /wait to actually wait. It didn't. So, some pointers would be appreciated. If I don't minimize the window in which the batch file runs then start /wait setup.exe works fine and waits. If i've lost anyone, let me know.

Well, I restored my image to another test workstation but removed all of the Intel display drivers except for 14.31.1 (thinking that perhaps there was a conflict between versions). Same behaviour - the .pnf remains post mini-setup along with the same error 32 (20) in the setup logs.

In my case, use of the following Intel display driver versions bring about the behaviour: 6.14.10.4864 (14.31.1) 6.14.10.4859 (14.31) 6.14.10.4833 (14.29) Unfortunately, I have two systems (one desktop/one notebook) that must use at least 14.29 or higher... all of which leave the .pnf remnant. I also include the following to support older chipsets: 6.14.10.4704 (14.25.0.4704) 6.14.10.4396 (14.17) 6.14.10.4342 (14.10.3) I have observed no issues with these older Intel drivers or any of the other ~790MB of drivers included in my unattended/image.

Sorry, I haven't looked at this in a while. Unfortunately, I haven't made any progress with the stubborn Intel .pnf file. For the Intel driver versions listed above, any system to which the image is restored ends up with the .pnf remnant below C:\sysprep (note: this directory is normally removed after mini-setup, so it irks me that it still kicking around). jaybot: Are you experiencing this behaviour with Intel display drivers or drivers for a different device? If it's related to the Intel drivers post which versions you've included in your image. I sent you an IM as well in case you're not watching this thread.

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.

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.

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.

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.