cluberti

Doing things manually will take time and introduce potential for error. It's worth noting that MDT uses all of the same tools, but puts it all inside an easier-to-use (not easy, but much easier) package for both creating and deploying images. There's nothing you've mentioned above that MDT can't handle, and the use of WPI technically wouldn't be necessary as MDT already handles those things (very well, in fact), but if you wanted to spawn WPI you could always do so. If you're looking for a purely deployment solution, use MDT. If you're looking for PC lifecycle management (from purchase to replacement), use SCCM.

Or use System Center ConfigMgr, but that's a pretty expensive way to get a hardware inventory.

Yes, that is true. But unless you're going to write your own code, that's what you're going to get. It doesn't get much better with powershell, as a lot of the device information just isn't available without asking the HAL directly in a real program.

Correct. @llaub01, If you'd look around, you'd find there are already scripts posted here that do basically what you're asking. We put a pretty heavy premium on searching before posting, so please always remember to do so - there's an archive of stuff here that goes back 10 years, so you're likely to find what you're looking for if you search the forums .

Dell actually provides a custom WinRE when you get a Server 2008 / 2008 R2 install, which has quite a few tools that sound like what you're discussing. It might be worth contacting Dell to see what your options are, because if they're running the same sorts of tools in WinPE (which is all WinRE is) on systems with Server installed, they might be able to help you get what you need for client.

Because Windows does. There are folks who run their own personal domains at home who want the features. As to what options you have, it depends almost entirely on what exactly you're trying to achieve. If you're simply trying to automate much of the install/deployment, MDT 2010 is probably a good choice. It's free, easy to use, and has no such restrictions as nLite on use in for-profit or non-personal environments.

Thanks Trip - I forget which licensing terms apply to OEMs that aren't royalty anymore. Trip is right .

They are no longer available on WU, as the product went out of support. Sometime last year Microsoft pulled the packages. http://support.microsoft.com/lifecycle/?p1=2484 I'm not sure how to figure out which patches are available anymore, as they're no longer in the mbsa cab for scanning, and WU no longer lists them. Given it's 5 Office product cycles ago, it might not be worth investigating too heavily anyway.

MDT is recommended by Microsoft for use instead of doing things manually with the WAIK and other tools, unless you're an OEM with licensing that prohibits you from doing so. MDT *is* what you should be looking at if you're *NOT* an enterprise . SCCM is designed for the enterprise.

#1 - unless you provide the product key in the unattend you pointed sysprep to when you reseal it, the only way around it is to use token activation (as the royalty OEMs do). You need to provide the key in the unattend you pass to sysprep, otherwise the user has to enter the key or skip activation altogether. #2 - Use a virtual machine and snapshots, and get things 100% setup before you then do the same setup/configuration on your real hardware.

Correct - the privacy issue of sending data only exists if the user manually opts-in to do so.

You tried what?? When you opened the XML in Windows System Image Manager (WSIM) and validated it, did it show any errors or warnings in the contents of your XML?

Microsoft's big problem with using a single bar was that (by default) anything you typed in the address bar was sent back to your default search provider. The feature probably did get a lot of requests, so they merged the bars but simply turned off sending search items to your default search provider by default - rather than being on and having to opt out as with some other browsers, you have to opt-in for that to happen. That was the security/privacy risk they were talking about.

If a user is an administrator on a system, they can indeed install Internet Explorer (or anything else for that matter) regardless of the blocker toolkit. That toolkit is only to block delivery from Windows Update or WSUS. You could use something like software restriction policies in a domain, but as you mentioned these machines are not domain joined. In that case, your recourse is to a) not make users administrators by default or B) provide some sort of detriment to doing so (political, rather than technical, solution). Those are your options in a non-domain-joined environment.

Yes, driver bloat happens if you're supporting a ton of different hardware. As to package install, if you *must* use the packages node, you're going to have to do some trial and error (and cbs/panther/setupapi log review) to figure out which patches you can install offline, and which ones are going to need to go into an application bundle and be installed via wusa.exe from the task sequence (or manually, although that sort of defeats the point).

Yes, you're using the Packages node. While that should work, you have to be very careful about which updates go in there. The patches are applied offline via dism during setup (staged), and then are actually applied as the OS comes up after setup. This is, to put it kindly, fraught with danger. You would be much better off standing up a WSUS server and pointing the client at that via the wsusserver parameter in customsettings.ini (and enabling the Windows Update steps in the TS). Staging updates is much harder than letting wusa.exe handle these in an online, running OS (and allowing WU to do the logic on which updates need to be installed, and in what order).

There's a KB on this: http://support.microsoft.com/kb/973289

This was fixed in June's IE cumulative update release. If you've not installed that yet, do so now (reboot, and all should be well).

Imaging XP in a hardware-independent fashion *can* be done, but it's not necessarily easy. You need to make sure you do a few things, and these are *NOT* optional: Create your base XP image in a supportable VM environment (as per Microsoft) - it must be Hyper-V, VMWare Workstation, or VirtualBox. Do NOT install any VM additions. Capture your base XP image to a WIM (I'd recommend a sysprep and capture TS) to the MDT server Configure your MDT distribution point with the correct drivers for each model, in a VERY SPECIFIC WAY (see my blog post here, specifically the section entitled "Driver Management / Add Drivers", for how to do make\model driver management). Configure your Task Sequence's inject drivers steps exactly as seen in the above blog to make sure the requisite drivers get installed for the correct model If you have drivers that are not sys/inf based, but require .exe installers, then you'll need to find a way to install them as applications using Make\Model WMI filters so that the proper apps get installed on the proper models, just as you would with any other OS. Note that these are the same steps if you're deploying any other OS image via MDT as well, so the steps are not XP-specific. It's just that using the "plug and pray" or "total chaos" methods with XP is far more fraught with failure than it would be with newer OSes like Vista or Win7.

Are you using the packages node? Or are you using a WSUS server and enabling the Windows Update steps?

Start using replmon to figure out why the DNS container information is not replicating, would be where I would suggest starting.

You can either move it manually, or write your SQL query so that it (and/or machines like it) will end up in the collection. You have to remember/understand that a collection is just that - a collection. It's not a directory, it's just a logical representation of systems that match the criteria for the collection. http://www.windows-noob.com/forums/index.php?/topic/1237-sccm-collection-moving-clients/

RDS works the same for Hyper-V/VDI as it would if there were a TS behind it instead. You need certificates and a way to get to the server via the internet, but that's about it.

What version of Windows are you using?

SP2 is not the same as R2, R2 is a separate download/install (that you should do - in fact, you really should be using R3 at this point).