Jump to content


  • Posts

  • Joined

  • Last visited

  • Donations

  • Country


Everything posted by _jd_

  1. 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.
  2. 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...
  3. ----- 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.
  4. 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
  5. 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.
  6. What method would you suggest for hiding them? I've used some vb in the past for something similiar.
  7. 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.
  8. 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.
  9. In my case, use of the following Intel display driver versions bring about the behaviour: (14.31.1) (14.31) (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: ( (14.17) (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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. If all of the systems you intend to support with the resulting image have the same base configuration as you outlined above, then yes, you would have an image that is "universal" to your environment in so far as it should boot. In the environment I support, I leverage sysprep to develop an image that applies to a broader hardware base and is independent of HAL or controller type. Sysprep enabled me to accomplish this. Usage of sysprep also takes care of SIDs, clearing event logs and preparing the system for a new user. Also, in mini-setup mode (-mini), sysprep gives me the ability to execute additional actions post-image (Cmdlines.txt) prior to the first user login. This is useful as there are some items I can't or don't want to integrate on the master workstation. Depending on your environment, you could also opt to run sysprep in a fashion that exposes all or portions of the Windows Welcome/mini-setup process to the user, enabling them to customize some of the settings. Ultimately, it depends on what is required of your environment. In some situations, like my own, sysprep has been a valuable tool.
  16. 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?
  17. Well, I contacted Intel and was informed that issues re: sysprep are outside their scope of support... even tho the issue has only surfaced with v14.29 and up of their graphics drivers. If I downgrade, no problem... but the older drivers don't support some of the newer GMA devices. Doh. So, still hunting for a fix. I'm still digging for some info on the error message/number i'm seeing in setuplog.txt but have been unsuccessful so far...
  18. Anyone? I haven't had too much time to dig into this over the last few days but i've done testing with new Samsung 19" LCDs w/ a native resolution and sure enough, post-image the resolution is set to 1024x768 as per my sysprep.inf. I suppose I could get into some writing scripts to identify the attached display hardware and set the resolution accordingly... but i'd prefer a more dynamic approach.
  19. How are people handling the support for multiple display resolutions in their XP images? The sysprep answer file (sysprep.inf) allows only a default resolution to be specified in the [Display] section. In my case, I need to support 1024x768, 1280x800, 1280x1024, and 1680x1050 and i'd like the appropriate resolution to be configured during mini-setup so that the it's configured for the first user login. Should the appropriate resolution not be set as per the .inf for the attached display?
  20. Unfortunately, the file in question isn't locked post mini-setup/when I login for the first time. I checked the setupact.log/setuperr.log/setuplog.txt in C:\WINDOWS and note the following: "Setup was unable to remove temporary file or directory C:\sysprep\Drivers\display\intel\14.29.1\Graphics\igxp32.PNF from your hard disk because of the following error: DeleteFile(C:\sysprep\Drivers\display\intel\14.29.1\Graphics\igxp32.PNF) returned error 32 (20)." I'm done some digging on the error, particularly the numeric values noted, but have come up empty handed so far. Perhaps i'll send an email over to Intel.
  21. I tried to forcibly delete the .pnf file via Cmdlines.txt, but it remains. It only seems to happy with the newer Intel display drivers tho. No problem with 14.25, but of course that version doesn't support the devices I need to support. I'm going to do a diff on the .inf's between 14.25 and 14.31. I'll take a look at the link you provided as well. Thanks.
  22. Same problem with the newer drivers (14.31). The file "igfx32.pnf" remains after imaging a device that uses a corresponding Intel display adapter. Everything else below C:\sysprep, including the directory itself, has been deleted as it should. There are no file permissions issues and all of the driver files are signed in this case so it's not waiting on an admin user to login. I don't get it.
  23. I've been maintaining a sysprep'd image for years now in support of ~15 desktops/notebooks, most of which use Intel display drivers. Anyway, my current image includes Intel display drivers 14.10.3, 14.17 and 14.25 to give the required hardware support... from 845G to Q965 chipsets. I'm now adding support for two new notebooks, both of which use the mobile GM965 chipset and are not supported by the 14.25 drivers. I downloaded the latest drivers from Intel (14.29.1) that supports this chipset and added them as OEM drivers to my sysprep image. Testing reveals that the new drivers install fine on target systems, but post-image the file "igfx32.pnf" remains in the folder structure for my OEM drivers. I keep the OEM drivers below C:\sysprep, which is automatically deleted when mini-setup completes it's job. This keeps C:\ nice and clean for the user... Anyway, i'm curious to know if anyone else has experienced issues when adding newer Intel display drivers as OEM drivers to unattended installation or sysprep'd image based on XP SP2. I tried downgrading to 14.27 but experienced the same problem. I tried deleting the .pnf file from my image but it's recreated on first boot. If I look in setuplog.txt and setuperr.log files there are entries indicating that the file could not be removed with an error code of 32... haven't been able to figure out what that means. I just did a quick check and it looks like Intel has released newer drivers - 14.31. I'm going to give them a try.
  24. Well, I made some progress... After adding an entry to my sysprep.inf for the device listed above the A100 booted and ran mini-setup without issue. I went through all of the Intel drivers I embedded in my images/unattended and identified a total of 14 IDE/SATA controllers that were not listed in sysprep.inf. I will adding them today and I expect that will improve our odds with imaging notebooks. I find it interesting that an number of ICH6/ICH7/ICH8 Ultra ATA/SATA controllers don't fall under the Intel Matrix Storage Technology umbrella.

  • Create New...