cluberti

Any particular reason this has to be x64?

In general, no, but be careful if "interesting" behavior occurs installing a random update or software package. There have been, for example, Windows updates in the past that fail if %TEMP% doesn't resolve to a specific (the default) location. It's been awhile, but it does happen. Assuming you're willing to troubleshoot that if it does (and temporarily "fix" it if that is the problem), you should be fine.

By default, no it does not, and removal of something like a monitor isn't going to be logged with removable device logging either (it's only for devices that support polling events, like USB and FireWire devices).

That would have been useful to know from the beginning , although debugging in your scripts is still a recommendation you should consider. If we know the file copied, then yes, it's probably the launcher, and iamtheky's post is probably relevant. Those switches are indeed usually specific and introducing a character out of place can cause the whole thing to go up in smoke.

Again, given it happens when files are streamed or downloaded (streaming video, etc and downloading files), this is likely at the network layer. Disk seems unlikely at this point. You can confirm it repros simply if you download a file from the internet, nothing special otherwise?

You should probably add debugging prompts into the script so you know exactly where you are on each execution step. I'm betting it's failing on the initial connection to the UNC path for the server, but you'll need some script instrumentation to be sure of where you are exactly, honestly. Given that you're running this as a startup script, assuming it's not a user logon script but a machine startup script, you're connecting to \\server with the computer account, not a user account - if the computer object doesn't have permissions in the share and the NTFS permissions on the data to at least r+x the content, you'll either fail or hang.

Interestiing - what is the specific error you get from WSIM (either text or actual hex error code, or both)?

No, not really. The "installing updates" pass is where the installation engine goes through and installs any updates integrated into the image offline - integration of a package into a WIM only does half the install, and the CBS engine needs to come by and finish it during setup (you'll see this in the cbs.log file after the OS is installed). This is similar to the installing features phase - any enabled features are configured (if necessary), and any disabled features are disabled (files / reg keys removed, etc), since none of this can actually happen until the WIM is placed on the disk and CBS has a chance to modify it.

I re-read your original post - did you use vLite on this image at all?

Hmmm... You don't have a download manager, but you're seeing high CPU when downloading files, and it spans two different browsers. The only thing in common between Firefox and IE on a Windows machine is at the socket layer and the filesystem itself, so either it's an LSP on the network stack (like antivirus/antimalware, 3rd party firewall, etc), the network driver itself, or a filesystem filter driver (again, antivirus would have a hook here).

Perhaps zip and upload the content generated, and we can take a look?

Sample? What language?

You might indeed consider using something like RunOnce then, and use that to bootstrap all of your additional installations rather than MDT task sequences.

You might want to use WSIM to create a new catalog for your newly captured image, as the original catalog file on the Vista source will no longer be valid.

Probably not, given that the PS/2 bus is an interrupt bus and the USB bus is not, sharing devices like Multipoint does probably requires the drivers to be in usermode (like USB drivers are). Depending on the audio driver, if it's interrupt-driven (rather than a driver that can run in the user mode driver framework), it probably won't work given the design of Multipoint. I don't know what the desired design is long term, but currently this doesn't seem to work. Given that Multipoint isn't really meant to be a server (or even a functional desktop) but rather an educational tool (with it's own SDK, no less), I'm wondering if this will even be something they'll spend time on.

Click the "start orb", and start typing in the search box in the start menu (it should have the default text "Search programs and files" in it in italics, if you're having trouble finding it). I usually see the Folder Options option in the start menu search area right around the time I have the letters "fold" typed in.

I can't speak to showing images from imageshack.us (I'll try to find a thread that has one to test), but as to #2, the DB is indeed slow and is likely to be so for a short while longer. This should be temporary. For #3 and #4, we've actually disabled the rating system here for a long time, and you'll find those options will be gone shortly.

It's because they're injecting the one created via the task sequence from the \Control folder in the distribution share. Seems more like a sanity check (so that you actually use the unattend you expect to use, even if you've managed to use a source with one integrated already) than anything else.

I always had the $OEM$ folder alongside (not in) the i386 folder on the REMINST share, and it's always worked fine. That may well be it.

That error equals "COR_E_DIRECTORYNOTFOUND", so keep that in mind when troubleshooting - it's not finding something it expects.

You'll note that article doesn't include Win7, because there's a specific one for Win7 - http://support.microsoft.com/kb/973289. Yes, the previous methods will work that you link to, but you should also consider the Win7 article as well.

Agreed, the flamewar is almost inevitable. Somewhat OT but touching on one of your points, PC - it's been pretty interesting in a Win7 deployment I'm working on with a colleague of mine. The pushback on Win7 and appcompat testing for all of their myriad apps was intense, but eventually they hit a showstopper bug (for them, anyway) that Microsoft wouldn't fix due to XP being out of mainstream support, so they started down the upgrade road grudgingly (we determined this was fixed in Vista, and also worked fine in Win7). We had already been slowly upgrading their backend servers first (Server 2008 R2 instead of Server 2003, Exchange 2010 last month instead of Exchange 2003 (etc all along the board), along with an upgrade from a hodgepodge of Scriptlogic and vbscripts to SCCM 2007 for the migration). One wave has finished the Win7 + Office 2007 + new apps upgrade, and all we hear is how wonderful it is and why didn't IT do this sooner, etc. Given the fact the org has *finally* given IT money to virtualize and upgrade everything (it's been 4 years since they've been able to buy anything above and beyond breakage replacement), we don't really have the heart to tell the rank and file that their departmental (and every department did) pushback was the reason we hadn't done this yet .

I'd have to say the WMICodeCreator and the MSDN class articles are probably the best way to go. Regardless of vbscript or autoit (although PowerShell is out there too), learning WMI via vbscript+WMICC+MSDN is probably the most straightforward way. WMI is pretty easy if you already know the framework around it (vbscript, AutoIT, PS, .NET, etc) - it's just a structured query language, basically.

I know most people say "it's ok", and it probably is - but if all you're going to do is run /integrate, why take the chance? It can be done outside of nLite, removes the possibility (however small) that a problem can occur, and you can test that SP3 source (and make a copy) before you even involve nLite. I always prefer to do things the cleanest way possible, because it makes testing and troubleshooting situations just like this easier in the future.

The only time I've ever seen that happen is when Teredo and the ISATAP adapter are configured in group or local policy.