cluberti

Can you post screenshots of the installer, the task you have to kill in task manager, and the file copy window? That will help us help you.

If you can get access to the filesystem offline, just check for the existence of \Program Files (x86)\ and/or \Windows\SysWow64\ - both of those will exist on x64, but will not on a properly installed x86 system. There are other ways, but that's the easiest.

At this point, Ryu, can you run process monitor while trying to delete those values, and then save out the .PML file? We need to see why you're unable to delete these (as long as these entries exist in policies, you will not be able to override them).

It's not a flat-file-based system, and even slipstreaming updates doesn't actually "slipstream" them - CBS installs them during WinPE after the base WIM has been placed down on the system. Unfortunately, one of the drawbacks of having the current servicing stack and image-based installer means slipstreaming a whole service pack (versus perhaps a few packages) got a LOT harder. However, given that we have good tools now to build Windows 7 images, I'm not sure this is really a sticking point like it was when Vista SP1 came out.

The question is, what x64 OS did you have in MDT that was used as the basis for the x64 PE? When you rebuild the PE images, it uses one of your x64 OSes added to the deployment share as the template, and copies it's boot.wim out and modifies it for MDT.

Could be - if you add the vmware drivers that the additions install, you should be able to use it on VMWare as well.

No, they would not - you're still running MAK keys, so you're still in the boat of having to re-activate on every rebuild. An environment that does this regularly should be using KMS keys, period. That is what they were designed for (amongst other things). And thanks to Kels for pointing out the Office tools for re-arm . Very cool stuff indeed.

I doubt it's missing, or you would be unable to boot. As to DEP causing an issue, are you using IE6, 7, or 8? If you're using IE7 or IE8, try running "iexplore.exe -extoff" from Start > Run and see if the problem goes away. If it does, you have a misbehaving activex control, which you can use Manage Add-Ons to try and find with trial and error. If it still fails running IE with extoff, you probably have a browser helper (not an activex) that is causing it, and at that point the only thing you can do is to start using a tool like autoruns to try and clean out things that are loaded in your IE via the "Internet Explorer" tab in Autoruns to try and find the culprit.

Yes, Office 2010 and Windows 7 both support KMS activation.

From what I understand, Andre is right that Guest Mode in the Win7 betas was supposed to supplant SteadyState, but the feature was axed before Win7 RTM. We've not heard anything from Microsoft on how this is going to go down with Win7, so hopefully we'll hear more before June 2011 on how to do this without non-free, non-Microsoft tools on Windows 7.

Which webbrowser is causing the DEP failures, or is it consistent across multiple browsers?

There's nothing you can do to "release" a used MAK key - you will ultimately have to call Microsoft to get the limit increased, and have them remove old activations. If you are re-imaging the lab regularly, how frequently do you re-image? You can't re-arm Office, but you can re-arm Win7 every 30 days up to 90, so there may be zero need to activate the installations if you are rebuilding every 30 days or less. If you're activating less frequently, but still regularly, you might want to look into using KMS keys instead as these activations don't decrement for every reinstall (they're only keeping track of current activations, one of the benefits of KMS vs MAK).

WinPE for MDT will only show you architecture-like task sequences, unlike native Windows setup WinPE which enumerates the actual images themselves. If you boot from a LiteTouch x86 WIM, you will only see x86 task sequences (remember, you only see *task sequences*, not the actual images themselves). If you want to see x64 task sequences, you have to boot with an LiteTouch x64 WIM.

Unless you need to install an LDR branch from a mixed LDR/GDR package, there's no need to extract the .MSU first on Win7. The .MSU packages can be installed via WUSA directly from the .MSU - wusa <update>.msu /quiet /norestart /log.

So what's not applying then? You can always take the unattend.txt, rename to winnt.sif, place it in the i386 directory, and try to install from that i386 outside of MDT to see if it works. I've never personally had any issues with unattend.txt outside of MDT, but anything's possible. Perhaps post the contents here as an attachment?

Does it still work if you don't use the /tempdrive parameter? You're already using copysource and makelocalsource...

Are you talking about the one configured in the Task Sequence itself?

Well, assuming a desktop connected to a UPS, if the battery indicated it was running out of juice and the defined state when that happened was to sleep, that would make a lot of sense.

7B == INACCESSIBLE_BOOT_DEVICE. So, what's the boot device (raid, ahci, chipset, etc) and have you integrated drivers for it into your WIM (given the error, I'm pretty sure the latter is "no").

If you're getting access denied errors, even when running it as administrator (the LOCAL administrator account, not just an account in the administrators group), I've actually seen this happen. It would be a permissions issue on registry keys where TrustedInstaller is the owner and rights for other groups are missing. Hard to say which it is, but if you were to run the script whilst running procmon, you could probably just filter on the access denied and find your culprit.

If you host a POC elsewhere (and link to the page, and not the exploit) here, that'd be fine. Any exploit code hosted here, or direct links to it, would not be allowed.

Not sure - Class Not Registered usually means an IE binary is missing something in it's expected registry. You can try re-registering IE8 .dlls to see if that resolves it, but if not you'll probably have to use procmon to figure it out.

When you wake it back up, do you get any Event 42 (Kernel-Power) events in your System event log?

Are you talking about running regedit after sysprep but before the reboot? Or are you talking post-image deployment? If you need to run regedit in the former scenario, you need to have it open before you run sysprep. In the latter, I'd have no clue without a procmon showing it failing.

Very interesting - can you make installation media in MDT and install via that media with the custom image, or does that fail as well? Installation logs are on the local machine, in the \Panther directory and in \Windows\Logs.