cluberti

You are going to have to compress at least one of these and upload it somewhere, as what you've shown means nothing.

You can use vLite, although adding a driver to a WIM file can be done manually as well - you just need to make sure you add it to both the boot.wim and install.wim (and the correct install image in those WIMs you will be using). This is documented on technet.

If you have a USB key, just integrate the drivers into the WIM (make sure to integrate both into install.wim *and* boot.wim). Instructions here. Making a bootable usb key for Vista or Win7 is here.

You need to acquire a *real* install CD. That DVD from Dell can only be used for regular installs, and not for upgrades. That is why it does not work.

Got about 500 users upgraded now, and the only problem is the ost getting rebuilt after SP2, but apparently that's expected behavior. Not noticing any of the other problems you have, so I'm starting to wonder if you don't have a COM add-in installed on some of the machines having the issues that may not be compatible with the SP2 codebase?

Did you try to upgrade from within Windows itself? Also, is this a retail disc or is it a disc from the computer manufacturer?

Alokcomp, if this behavior continues the banhammer will fall. This will be your only warning, so heed it.

Also, I've had problems with Vista setup on large volumes with both the ICH9R and ICH10R chipsets. However, after adding in the Intel driver to the install source, it worked fine. Seems like perhaps the generic inbox driver has issues with larger volumes, whereas the actual Intel driver does not. Consider integrating the latest driver for the ICH10R into your Vista source before attempting installation.

There is a fix for this, but unfortunately it's Vista (this would have worked fine with Vista).

Correct - if you can spare the 40MB or so on your hard disk, that's the size you absolutely have to have to boot.

Yes, but Microsoft does not support replacing OEM images unless you're the OEM. If you're going to be doing this regularly, you should be able to get VLK media from Microsoft in a license agreement that allows you to have your own media and keys, and that is the supported way. Otherwise, you can try using your HP installation media to create a new installation, and I know this has been discussed in the Unattended section of the forums.

Well, you should be able to do an upgrade install using the Vista media - that will "upgrade" Windows and keep your settings and (most) programs.

Windows 2000 uses the old NT-style registry loading of hives, and it requires you to have 40MB of paging file on boot to store the portion of pages backing the kernel paged pool memory that would house a full registry. This was changed for XP and 2003 (there are lots of changes, but registry size and loading are one of them) thus making it possible to run without a paging file in XP. This is indeed not recommended for 2000 for this specific reason, and why it won't let you do it.

I'm guessing the pricing will likely be similar (if not identical) to Vista, but nothing official seems to be public on this yet.

Yup . I uploaded a subroutine back in 2006 that handles this as well, and it's posted here. Just add and call from the beginning of your vbscript, add creds when prompted, and viola - elevated vbscript and anything it calls.

Probably there's no catalog or no EULA text matching your install on the media, because that's what setup is about to check (the catalog, for versioning) and the EULA directories (for a EULA matching your installation type with your language).

Does it always happen when using Google Chrome, or does it happen when using, say, Internet Explorer as well?

Answers here Second link is probably what you need. I have to second (and third) the other posts here, though, as your answers were very easy to find on google (first three links answered both questions, each in a different way, so hopefully you'd find one that meets your learning style. Why, may I politely ask, are you asking these questions? Was there another question or problem that prompted these questions?

I've not had that problem at all, honestly, but you do have to make sure you're running the installer with a full token (mapping a drive with an elevated vbscript and then running it there works fine, for example, no errors).

This isn't a Microsoft beta - moving to appropriate location.

Look at the WU logs in the Windows directory, as well as the IE8*.log files to see what you can determine. Most of the info comes from there - if it was installed via SUS, it should be logged in the WU logs. If you don't see it there, it was either pushed via GP or manually installed from another source, which the IE8*.log files should tell you (hopefully).

Well, I'd say uninstall avast, reboot, and see if it recurs. If it does, don't get a dump - consider getting a process monitor log to run while you work, in the hopes it'll catch the offender when it happens again. I would, however, consider updating the Intel driver anyway, because it is a beta product and there are some things that the latest Intel driver addresses that may be pertinent to the behavior you are seeing. Sonic may be onto something with the driver issues.

Well, the problem with this dump is that it won't tell my WHY the HDD is pegged, but I can confirm it probably is. In looking at the dump, there were quite a few threads in the SYSTEM process (the kernel) that looked like this: 0: kd> k *** Stack trace for last set context - .thread/.cxr resets it Child-SP RetAddr Call Site fffff880`02ffc910 fffff800`028ec6f9 nt!KiSwapContext+0x7a fffff880`02ffca50 fffff800`028ef626 nt!KiCommitThreadWait+0x1b9 fffff880`02ffcae0 fffff880`05e6ae56 nt!KeDelayExecutionThread+0x186 fffff880`02ffcb50 fffff880`010790c3 aswMonFlt+0x3e56 fffff880`02ffcc70 fffff800`028ea744 fltmgr!FltpProcessGenericWorkItem+0x43 fffff880`02ffccb0 fffff800`02b6ae66 nt!ExpWorkerThread+0x11a fffff880`02ffcd40 fffff800`02897a86 nt!PspSystemThreadStartup+0x5a fffff880`02ffcd80 00000000`00000000 nt!KxStartSystemThread+0x16 // They are all waiting on a particular notification event: 0: kd> dt nt!_dispatcher_header fffff88002ffc808 ... +0x008 WaitListHead : _LIST_ENTRY [ 0x00000000`00000000 - 0x0 ] Except it appears, as you can see above, that the wait block is empty, meaning the thread that created the notification event has either already signaled it, or is gone (crashed, closed, can't say, but it is probably gone). So I don't know specifically that the Avast filter driver is causing it (I expect to see a filter driver being called in an I/O thread, that is normal), but I would like to know if you can reproduce the issue without Avast installed on the system, as it's at least suspect at this point. You could also use process monitor to try and capture the spikes, although since they're intermittent that would probably be tedious and consume lots of disk space monitoring the system.

Not sure I see anything obvious there - the next question is, if you do a manual install attended and select the proper time zone, is it also one hour behind?

Well, if that is the case, your problem makes little sense, honestly.