_jd_

Hey... No BSOD or error messages after cloning. The system passes POST then goes to a black screen... never even gets to mini-setup. I can't get to safe mode via F8 either. Being that the system hasn't completed mini-setup tho I expect safe mode isn't even option anyway. I have the A100 on the bench now and just got around to reviewing the unattended. The only device not installed post-unattended was the modem. All other devices were installed from the drivers embedded in the unattended and the driver files for those devices are list as being signed. So, I suspect this just a case of a missing driver as my images are built from the same unattended and use the same driver set. I'm thinking that something is missing from the [sysprepMassStorage] section of my sysprep.inf. This is where I had to hack in support for Intel's Matrix Storage Technology to support some of the newer SATA-based systems we were ordering. The Intel SATA controller used in the A100 has IDs of VEN_8086&DEV_27C4, which doesn't relate to the Storage Matrix controller and isn't in my sysprep.inf. It's identified by XP as "Intel® 82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controler - 27C4" and is using a signed driver from Intel. I will identify the specific drivers used by this device and add a corresponding entry to sysprep.inf... we'll see how that goes.

Looks like the Toshiba A100 won't boot post-clone either... it's a C2D model with Intel 945GM, much like the notebooks in our standard fleet that boot without issue. I did a quick overview of the drivers available from Toshiba and identified no core drivers that my image is lacking. I will do a base unattended today and do a closer review of what gets installed and what doesn't.

All of my (Ghost) images are based on XP SP2, are prepared with sysprep and have a fairly robust set of signed drivers. I've also configured sysprep to apply the multiprocessor HAL by default but to switch to the ACPIAPIC_UP HAL as an alternative (configured in sysprep.inf not via some custom scripting). For our standard fleet (13 desktops and 3 notebooks), this configuration works well - the P4 HT/C2D machines get the MP HAL and the rest get the UP HAL. I'm not sure why, but the image frequently fails to boot on non-standard notebooks including: Dell's (Inspiron 1100, etc), Toshiba's (M2, etc), etc and the occasional desktop (usually Dell's... GX240/GX260 works fine but 4400 has been a problem). Even tho they're not part of our fleet, I see no reason why most of these systems shouldn't boot. Most of the problematic systems are either P4/P4-M or Centrino systems and typically use an Intel chipset and video. Nothing terribly shocking. I had one machine come in the other day with an ATI chipset but i'm not surprised it didn't boot as the drivers are not embedded. Granted, some of newer Intel stuff uses SATA and Intel's appropriate controller, but I embedded support for Intel's Matrix Storage some time ago. If I resort to an unattended on these machines then they boot without issue. This is the same unattended used to build my images and it uses the same driver set. So, aside from the odd sound or modem driver I know that most of the required core drivers are already available in my image and that they *should* boot. Even the HAL configuration defined in my image agrees with what HAL is installed post-unattended. So, any thoughts on how to improve my odds with these non-booting systems? It would certainly save some time for those on the front-line. I've confirmed that the image does indeed land on the target system without error but the OS never tries to load... so not setup*.log files to review. Thanks.

It's a standard ACPI HAL. I intentionally built my sysprep images to support both UP and MP ACPI HAL's (default is MP and the "upgrade" HAL is UP). From Microsoft's knowledge base the APCI UP HAL support's standard ACPI systems as well. This is confirmed because the image lands fine on systems that use the "standard" HAL. I also think it's the IDE controller, but I can't say why it's a problem. The drivers are in place and the path is referenced properly... i've even rebuilt the mass storage drivers in sysprep.inf without any luck. And since it won't boot, I have no setup*.log files to work from. Doh... this one's getting an unattended I suppose.

Odd situation with the Toshiba Tecra M2. My unattended installs without issue - only three non-critical devices require manual installation on completion (video, audio and one unknown device). Nothing I can't handle. However, if I drop my sysprep image on the M2 it won't even boot - normal or safe mode. The odd thing is that my sysprep image is built from the same unattended, and both are populated with the same driver set. I've seen this behaviour with one our standard notebooks and the problem was linked to the SATA controller. I resolved this by adding the appropriate drivers for the controller. In this case the M2 appears to use an Intel 828 chipset, and those drivers are accounted for. Thoughts?

I'm still watching this thread and hoping someone else has a solution. Are third-party tools (nLite, HFSLIP, etc) really the only option to integrate IE7? If so, do they mess with the "Default User" just the same and does the "Personalized Settings" process still run when a new user logs in post-unattended? Not looking to hi-jack the thread, just keeping discussion open.

I'm still banging my head against this one. So far, i've been trying to embed IE7 into my unattended installs via SVCPACK.INF. Post-unattended, IE7 is installed but for each new user that logs into the system there is a "Personalized Settings" process that executes to configure things like Outlook Express, Address Book, Themes, etc. This process appears to be overwriting customizations that I had made to the "Default User" profile during the unattended install (registry keys/values written to HKCU during Cmdlines.txt). The end result is that when a new user logs in their account is mis-configured. Sure, they have IE7 installed, but some critical customizations are missing, including theme settings, some browser settings, some Windows Internet Settings, etc. I could add some user-based RunOnce stuff, but there's no guarantee that an admin user will be the first to login... and I really don't want to get into automatic logins as the Administrator. Any thoughts on how I can disable the "Personlized Settings" process for each new user? I had looked at integrating IE7 with the unattended source but there's no /integrate switch. From what i'm seeing, IE7 is really geared for installation on home desktops or as a post-installation task on corporate desktops.

I use the SVCPACK.INF method. If you already have this configured just download IE7 update and put it in \I386\SVCPACK then edit \I386\SVCPACK.INF to include "IE7.exe /quick /udpate-no /no-default /nobackup /norestart" to the [setupHotfixesToRun]. It's better to put this at the top of the list and don't forget to include qchain.exe at the end of the list. If you need more info, the SVCPACK method of installing Microsoft Updates is covered on the MSFN site. This works well for me, but i'm still having trouble configuring IE7 for the "Default User". My approach has been to include user registry settings during execution of Cmdlines.txt, which are applied to "Default User". For IE7, some of the settings are retained (ie: first run page, home page, search providers, etc) but a few settings are overwritten for new users (phishing filter settings, intranet settings, etc).

Take a look at a thread a started a while ago... it may help you out: http://www.msfn.org/board/index.php?showtopic=83941&hl=

Actually, i'm only using one image... I just build on the multiprocessor system and allow sysprep to downgrade the HAL to uniprocessor if need be. Luckily, I don't have to support anything below a Northwood P4 on an i845G chipset. As for disk sizing, i'm using Ghost at the moment... I simply build the image for the lowest common denominator. I can then set the partition sizing when restoring the image. Generally, most of the systems use a 40GB HDD or larger...

I had no problem installing IE7 via SVCPACK.INF using the install package downloaded from Microsoft. I found that a few of the IE7-specific registry settings applied to HKCU (aka Default User) during execution of Cmdlines.txt weren't retained tho...

I'm installing the update via SVCPACK.INF... works fine.

That was my initial approach. Unfortunately, only a portion of the registry values I set in the "Default User" hive are applied to new users. Some of the registry values are overwritten with default values, i'm assuming during the small setup routine that runs when a new user logs in. Unfortunately, these settings are critical to our environment...

I'm putting together a new image but need to build a new unattended install of XP Pro SP2 first. Anyway, i'm looking to integrate Internet Explorer 7 into the unattended install. I first started with the standard downloadable package available from Microsoft and installed it via SVCPACK.INF using the switches "/quiet /nobackup /norestart". During testing afterwards, I then found a few settings that I wasn't able to customize via registry settings and I turned to Microsoft's IEAK (Internet Explorer Administration Kit) to pre-configure some default settings, etc. The resulting installation package built by the IEAK, which is still an executable, no longer installs via SVCPACK.INF, with or without any switches... I still have IE6 post-install. Thoughts? The IEAK-built IE7 package does install without issue if triggered manually... One thing I noticed is that the IE7 install package from Microsoft has many more switches that are common to standard Microsoft Update files (/quiet /passive /update-no /no-default etc...) whereas the package built with the IEAK only has four available switches (/Q /C /T: /C:).

I've seen similiar behaviour... no solution tho as it's pretty low on my list of priorities at the moment.

I'm out of ideas. My sysprep images are built on a P4 non-HT system that's detected as an "ACPI Uniprocessor PC". These images can be applied without issue on P4 HT or Core Duo system, both are properly detected as an "ACPI Multiprocessor PC" after mini-setup. The only thing i've done is add "UpdateUPHAL=ACPIAPIC_MP,%WINDIR%\Inf\hal.inf" to my sysprep.inf file to make the installation of the proper HAL cleaner, otherwise I get a prompt on the first login re: finalizing installation of the proper HAL. No other magic has been done...

Ok. I rebuilt another image on a P4 non-HT w/ "UpdateUPHAL=ACPIAPIC_MP,%WINDIR%\Inf\hal.inf" in sysprep.inf. The master PC was detected as "ACPI Uniprocessor PC" in Device Manager prior to running sysprep. The resulting image was then restored on a P4 HT system and there was no message re: "finished installing hardware" on the first login and "ACPI Multiprocessor PC" was listed in Device Manager. So, it looks like mini-setup is entirely capable of implementing the required HAL between uniprocessor and multiprocessor systems.

I removed the -quiet switch from the call to sysprep and I got an error message, which was something to go on... I ended up tracking it down to some custom entries in sysprep.inf re: mass storage drivers that are required to support a specific controller. Doh.

Did you dump a new sysprep image that excluded your HAL selection scripts or re-use the existing image and simply bypassed your HAL selection script? If you built a new image, on which system did you build the new image? Which system did you restore it the image to?

Image built on Intel P4 HT and applied to Intel P4 non-HT results in "APCI Multiprocessor PC" being used. No good. I rebuilt the image on the Intel P4 HT and added "UpdateUPHAL=APCIAPIC_UP,%WINDIR%\Inf\hal.inf" in the "[unattended]" section of sysprep.inf. When restored on the non-HT system I no longer see the prompt on login and Device Manager reports "ACPI Uniprocessor PC". I'm trying in reverse again, just for fun. Build on Intel P4 non-HT, add "UpdateUPHAL=ACPIAPIC_MP,%WINDIR%\Inf\hal.inf" to sysprep.inf and restore on Intel P4 HT system.

Doing some testing... I just built a fresh XPP SP2-based sysprep image on an Intel P4 non-HT PC, which is identified in Device Manager as "ACPI Uniprocessor PC". I then dropped the image on an Intel P4 HT and on the first login I received the message listed above. I'm going to try the process in reverse and build the image on the Intel P4 HT then drop it on the non-HT. I've seen the "UpdateUPHAL" entry for sysprep.inf but haven't tried it yet - didn't need to XPP SP1.

Moments ago I built an XPP SP2-based sysprep image on an Intel P4 non-HT system, which is identified in Device Manager as "ACPI Uniprocessor PC". I then restored the image on an Intel P4 HT system, rebooted, let mini-setup complete and the PC rebooted without hitting safe mode. When I login I see a message re: "Windows has finished installing new devices... restart... yes|no". If I check device manager "APCI Multiprocessor PC" is listed. I've used none of the HAL-related entries in sysprep.inf, no magic with cmdlines.txt to detect/replace the HAL and did not call sysprep w/ the -pnp switch. As far as i can see, mini-setup was able to detect and install the appropriate HAL, which is the behaviour I would expect in your case if the image was built on an "ACPI Uniprocessor PC" system, such as the Dell D810. I have no idea why you're seeing the behaviour you're reporting...

Yeah, unknown territory. If the image was built on the Dell D810 (APCI Uniprocessor, halaacpi.dll) as you mentioned then I would expect it to apply on any of the machines you're looking to support without having to add any magic to sysprep.inf or cmdlines.txt. I really don't know what it's hitting safe mode. When you drop the image on the two systems where the safe mode issue occurs, does mini-setup run first then the system reboots into safe mode? Or is safe mode the first thing to come up? If mini-setup runs first then i'd be curious to catch the system before the next reboot and take a look at the setup.* files in C:\WINDOWS... setuperr.log will give you a quick list of any errors encountered and setupapi.log will indicate which devices were enumerated.

Ok. I watched the sysprep process, which isn't terribly exciting, and at 6:15 sysprep just quit and the "limited or no connectivity" message appeared. I'm just skimming through the logs... I imported the FileMon logs (from 6:15:00 to 6:15:59) into Excel and sorted it by the status looking at anything that wasn't a SUCCESS. Right off the hop there are a few "BUFFER OVERFLOW" results around the same time, one of which relates to a "QUERY" call made by IPCONFIG.EXE @ 6:15:00 for "FileNameInformation" for "C:\WINDOWS\system32\ipcnofig.exe". Hmm. The other "BUFFER OVERFLOW" results are from CSRSS.EXE (Microsoft Client/Server Runtime Server Subsystem), one from WMRUNDLL.EXE and one from SVCHOST.EXE... more "QUERY" requests for either "FileNameInformation" or "FileAllInformation" for varies policy files. Moving to the TDIMon logs I can see IPCONFIG fire up at 6:15:01... SVCHOST.EXE appears to initiate some DHCP related traffic at 6:15:03... also at that time the "System" process returns with a result of 0xC0000141 (NT_STATUS_INVALID_ADDRESS). By 6:15:08 i'm seeing "HOST_UNREACHABLE" results, which i'm going assume is when the system reports "limited or no connectivity". I still have no idea what's causing this... and I really don't want to call M$.

I ran this through again w/ sysinternals filemon, regmon and tdimon capturing in the background. I'm just collecting the enormous log file and will see what I see... I will also note that the PC is lost when this occurs.