cluberti

Connecting to remote WMI means you must allow remote WMI management, and the account connecting to the remote machines must have access in DCOM (dcomcnfg) and WMI (wmimgmt). Also, if the firewall is enabled, you must enable WMI traffic through the firewall as well.

This last bit is being wokred on here already.

The problem isn't installing 64bit Windows from a 32bit PE (this is actually possible and works just fine). However, with MDT, you aren't directly installing Windows, you're running task sequences. You cannot execute a 64bit MDT Task Sequence from a 32bit Windows PE - that's why you have to have both for MDT.

- Swiss army knife (about 15 years old) - Keys (car, house, storage unit) - HTC Touch Pro - Wallet (about 10 years old, but no tape... yet) - Leatherman Charge TTi - Zune 8GB - 1x 64GB Patriot XPorter Magnum USB key, 2x 16GB Patriot XPorter Rage USB key I keep all my cables, cable testers, and heavy duty wiring and testing tools in the car, along with my regular toolbox and a set of jumper cables. Those obviously won't fit in my pockets anyway .

almost - you *can* use two separate task sequences to build, customize, and capture - use one MDT task sequence to do the build, then customize as you desire, then *from that OS install* run the sysprep and capture task sequence. If you manually sysprep first, it won't work. However, given that MDT is a tool for repeatable builds, you probably want to find a way to get that customization into your first MDT task sequence, so that you *can* use just one task sequence for build, customize, and capture. That's the whole point of MDT, really.

Base Image == the Windows image you've already sysprep'ed. It's called "sysprep and capture" for a reason, specifically you use it to run sysprep, generalize, and then capture. You've already done 1 and 2 of the 3 steps, so there's no need to even continue down that road. Second question, "do over" means remake your image in MDT, and make sure not to skip the sysprep and capture portion of the task sequence when making the new image. Back to your original problem, you're going to need a second partition or hard disk to capture the WIM to for now, unless you can find network drivers you can add to the capture image in WDS to make it work. What network hardware are we talking about here that isn't working? Win7 WIMs have tons of drivers, so it'd be interesting to know what network hardware isn't working under it.

Are you getting any power events in your system or application event log at or around the time the machine sleeps or wakes?

+1 - Process Monitor can give you the Process ID (PID) and the callstack of the svchost making the request (just use the network filter in procmon), and Process Explorer can give you more information about that PID and what is running in it (if the stack from procmon doesn't already make it incredibly obvious).

You're supposed to run that in the base image, not a WinPE (it won't find sysprep in WinPE, because WinPE doesn't have sysprep!). If you've already sysprep'ed the image, your only options are save it locally with your capture image, or do over.

Might want to consider writing a simple HTA to do this - I doubt you need to purchase anything (and in fact I don't know of any singular tool that will do all of that for you anyway, honestly - I know lots of separate tools that can do those things if combined, but that would be more confusing than if you just wrote an HTA front end for your (likely) already useful vbscripts.

What you might want to do is consider WDS + MDT 2010 (update 1). This allows you to deploy XP flat-file setup, but from a WinPE bootstrap from WDS. It's the goodness of flat-file installs to meet your needs for a "universal" install point, but with the automation and WinPE goodness from Win7. There really isn't a better way (short of using SCCM 2007) to deploy XP. RIS is just painful, honestly, and it's a wonder we used it for so long .

#1 - Auto activation should work if your KMS is discoverable. The VAMT docs should have guided you through that setup, but if not, it's always easily found on Technet. #2 - No, KMS is auto activation (both Windows and Office) as long as you meet the minimum number of activations and the KMS server is discoverable by hosts on the network (which ties back to #1). You don't have to do anything (you can, but you don't have to).

No, but the fact it's on your machine is indication of an infection or attack that succeeded in getting it's payload on your machine. It's not *able* to do what it wants, but it *did* get on the box. Your machine was compromised by this at the least, and who knows what else. Are you *sure* it's clean? Also, restoring registry without restoring a backup from the same time is usually not a good idea.

Actually, I notice "DeskMovrW" in the iframe properties that are displayed on your "My Computer" icon. That's actually one of the things you find on an infected machine where the default .htt file has been modified with one of the viruses/malware out there that replaces desktop contents with rotating porn pictures on the desktop and in the Explorer interface (no kidding, really). I'm with DJPro, you probably need to take this offline and clean it, or just admit that the infection has broken things and start over. Once a machine has been compromised, you can't really ever be 100% certain it's completely healed in the future anyway without starting over.

Riprep images work with RIS, as well as simply using pre-sysprep'ed OSes. I'd sugest riprep if you are stuck with RIS, or migrating to WDS and creating WIM images there if you aren't stuck on the older RIS technology for any specific reason.

Considering nlite is for personal use only, you probably should just recreate that image legally to see if it works.

No, that's correct. One common reason for such an error is trying to run net localgroup commands on a machine that has joined the domain but hasn't rebooted after it was successful (what happens if you reboot and try the script manually???).

It's probably unable to find sysprep itself (the error is a generic E_FAIL error code). Are you running this from a UNC share, or an actual mapped drive? Also, make sure you're running cscript litetouch.wsf, and not the litetouch.vbs file.

Network discovery is a firewall rule set in Vista and Win7, so if you go looking for it you won't find it. Basically, it's an amalgamation of firewall rules for allowing in (on a Vista/Win7 machine) Link-Layer Topology Discovery (LLTD), Netbios, Functional Discovery Resource Publication (FDRP), Universal Plug-and-Play (UPnP), and Web Services for Devices (WSD) requests. Windows XP obviously doesn't have FDRP or WSD at all, nor LLTD by default - but you *can* install the LLTD listener for XP by installing the update in 922120 (you should do this on any mixed networks where XP and Vista or Win7 will co-exist). However, if VAMT isn't discovering your machines and you're *in a workgroup setting*, you need to have both netbios and LLTD working - otherwise, you won't find anything (DNS isn't a broadcast medium, so LLTD and netbios are used for discovery).

If you're deploying that many seats of *datacenter*, you are likely to be able to get KMS keys. KMS keys only require access to the local KMS server, not Microsoft, and KMS keys are *much* more flexible for activating hosts than MAK or retail keys. You are limited to a max of 6 KMS keys by default for use in your KMS activation servers, but you can request more if you have a valid reason. You do need at least 5 servers and/or 25 clients before the KMS activations actually succeed, so you wouldn't want to use KMS for a small environment with 2 or 3 servers, or less than 25 clients. It might require some planning, but KMS is probably your best bet (especially with datacenter keys, as those are the most mighty with regards to downlevel activation of lesser versions of server, clients, and downgrades). If it must be *totally* offline, there is something called "Token-based Activation" (TBA) that you can ask your MS rep about. It's not really documented, and it's not really public, but it is available to large volume licensing customers from what I understand (it's similar to how OEMs activate windows via SLIC, but it's not *exactly* the same).

You can't set a domain group to a local group if the machine account the image deploys with is not correctly added to the domain. That error would indicate that the computer object in the domain either doesn't exist, or hasn't been ACLed properly during the domain join. How is this machine being domain-joined?

Correct - a WinXP installation source that is hardware independant (as much as can be made so) matters not if it's being installed from a WIM, from source, or any other imaging format. The WIM file is just a container for deploying the filesystem and files, the actual act of making the image fairly hardware-independant is the same as if you used other methods (like the one jaclaz pointed out). If you can make a riprep or ghost image (or acronis, or.... <insert imaging format here>) hardware independant, the exact same steps will work on a WIM image.

No, unless you're on an NT4 (or 2000+ network requiring WINS resolution), this is ignorable and means nothing.

NetBIOS communication to the machine PC2149 was unable to get WINS browser list information. There's actually a Microsoft KB article on why this can happen.

This is one of the many reasons why Task Sequences in MDT do sysprep and capture .