cluberti

No, the server and target don't need to be on the same subnet, but remember that PXE uses broadcast to find both DHCP and the deployment server. That means that if the client and server are NOT on the same subnet, you do need DHCP helpers to route the traffic - so while they don't necessarily need to be on the same subnet, it won't work by default without some configuration on the routers between subnets for the PXE traffic.I'm assuming your WDS server and your client are on separate subnets, which would explain why the client cannot find the server.

You could also use MDT 2010 to do this, and it would be fairly easy (and quick). It can also build ISOs of the results, right from the UI.

Would be best to create a task sequence and add all the language packs to the packages node of the deployment share. Assuming SkipPackages=NO, you should get prompted for which language to install during deployment. If you want it automated, you'll have to either use separate task sequences and specify LanguagePack001 in each TS section (which will involve some cs.ini and deploywiz_initialization.vbs modifications) or use a database to handle machine variables and specify LanguagePack001 languages based on some criteria you can query on.

Well, that is the error message. What specifically is the vbscript doing? The script host has limited virtual memory available to run in, so it might depend on what the script is doing and how large the data set it may be creating is, etc.

First, if a DC dies (assuming it wasn't the only GC in the domain), it would have been much easier for you to simply seize the FSMO roles (if necessary) to another DC that was online, clean up the old computer object and any old metadata for the failed DC in ntdsutil, reinstall Windows on and re-dcpromo AD on the failed box, and let AD replication do it's thing - that is all you would have needed to have done. The only time you really need to do a restore like that is if you lose the last GC in a domain, or if all DCs had fallen down and you were in a domain (or worse, forest) recovery scenario. If you *really* need to do a restore of a DC due to a DR scenario, there are a few steps you must take (and you cannot really skip any). With that in mind, you should *NEVER NEVER NEVER* restore a DC from a backup image without at least doing a non-authoritative restore of the objects from that machine in DS Restore mode (unless it's the only DC, which..... shouldn't be the case anyway!), or with the AD services stopped. You really (*really*) need to do a non-auth restore on the objects on that machine once you restore a backup image, and ****then**** bring the DC back online. What you have right now are conflicting USNs in AD, most likely (this is the same sort of thing that could happen if you were to pause a VM running a DC for a day or two). The steps you must do if you restore a DC image (or at least the system state), in order: Step 1 - restore that machine from an image Step 2 - boot into DS Repair mode Step 3 - do a non-auth restore of the objects you just restored Step 4 - reboot into normal mode, and let AD fix itself You skipped steps 2 and 3, and step 4 cannot happen right now because of it. If you're at 2008 native (not mixed), you should be using DFS-R anyway (consider migrating using dfsrmig after you fix this), as FRS is the old way and is inefficient comparatively. Ultimately at this point, if SYSVOL and the scripts folder are synced but your policies are not, this would likely indicate that you have a problem in the system container - not a filesystem issue, but a root issue with USNs in AD for policy. You honestly would be better off making sure the GC and FSMO roles are on another DC, removing that failed DC, and then set about removing it from the domain and rebuilding it again. Once it's back up, simply dcpromo it back to a DC. AD has multimaster replication, so assuming you have more than one GC in the domain, this is the easiest (and safest) way to do DR of a failed DC anyway. Good luck!

MDT 2010 no longer includes the PXE filter for unknown computer support in SCCM 2007, because SCCM 2007 gets support for this after installing R2 (which is a free download for SCCM 2007). You only need to run "Configure ConfigMgr Integration" from the MDT program folder to add the task sequence and WinPE support menus to SCCM 2007, but to get unknown support (PXEFILTER) in SCCM 2007, you need to install R2:

That's very interesting. Is it always the same error message as the screenshot shows?

Hmm. Are you deleting partitions and selecting the new empty space on the disk when prompted, or does it just go right into installing Windows?

Not really, but are you seeing any COM or DCOM errors in your eventlog?

The only way on an already-configured and running system is to use the netlogon share (and that's only for domain-joined machines).

No, FAT32 doesn't magically align, but the default cluster size for FAT32 volumes is 16K for any drive larger than 32GB, rather than NTFS's default of 4K for volumes up to 16TB in size. This could actually be why you don't see much difference, as you're already spanning multiple clusters in FAT32 with the default format options.

That's really odd. I haven't used the SIM or answer files directly in a long time (use MDT!!! ), so other than the disk just not being available at the time it's parsed, I couldn't explain it (especially if diskpart sees it). Does it happen with our file on any other environment (Hyper-V, VirtualPC on Win7, etc), or is it just a VMWare issue?

It shouldn't matter what it detects - if you only have x86 images, it's only going to boot an x86 PE image. I'm not sure you need to go through all of the trouble to force x86 booting - an x64-detected machine will still boot and run an x86 image if that's the image (or those are the images) available from the boot images folder in WDS.

If it's Windows 7 as the client and you're running Aero, the CPU is pretty much out of the question. From there, it would depend on the chipset design as to where the GPU traffic routes back to the CPU, but most likely it would point to the GPU or the slot it's in on the motherboard.

If you open a command prompt and run diskpart, did the partition get created and formatted?

No, given the fact there really isn't a viable pattern that leaves two things - malware, or hardware malfunctions. It seems like you're investigating hardware, but I'd run an offline scan of the HDD again to be sure it's clean of viruses and malware too just to be on the safe side and rule that potential problem area out.

Try the KB article first: http://support.microsoft.com/kb/973289

Sorry for the delay, but I posted a reply that apparently died due to my crappy internet connection last week. I reviewed the data, and it looked like it was either the audio driver on the hdaudio bus, or something attached to the USB bus. Unfortunately, this is one area (without stack traces) where I can only go that far. Does the problem reproduce with no USB devices attached to the system?

If you look at CPU time while just listening to music or watching video with an audio stream, do you see any cpu usage in any particular process? The spikes are coming from the keyboard filter, but the DPC and interrupts are tracking back to the HD audio driver - what driver is installed on your system for audio?

If the paging file is not RAM+300MB (ish) on the same volume as the \Windows directory, you won't get a complete memory dump (no matter where the dump file is set to be created). This is a bit different from previous versions of Windows, unfortunately.

Darn - this is getting spooky . If you do ever get a complete dump, let me know!

What is in common (other than Windows) amongst your installs? Is it the install media, is it the apps you install, etc? CSRSS, LSASS, or SMSS crashes would cause an F4 bugcheck, and given that these binaries are responsible for security and (very) base OS functionality, the likelihood of a nice clean pipe or RPC backtrack isn't likely. Also note that even with a kernel or complete dump there are no guarantees to figure who or what specifically caused it, but I'd still suggest capturing a full dump (so we can see both user and kernel memory) the next time an F4 bugcheck occurs.

Win7 will use whatever is available at the time of sleep. In general, though, sleep problems due to changing S1 vs S3 shouldn't be an issue. Windows 7 does prefer hybrid sleep over the legacy sleep methods, though. Also, if this is a Win7 SP1 install, it would be useful to make sure that the post-SP1 sleep/hibernate hotfix was installed as well for systems with SCSI miniports: http://support.microsoft.com/kb/2495523/en-us It would be best to re-enable hibernation and hybrid sleep, install the hotfix, reboot, and attempt again. However, given the symptoms, if the problem persists Windows itself is probably out of the picture here still, and hardware is probably a good place to be troubleshooting.

Agreed - DCACHE errors can indicate RAM errors as well, but usually only on Intel CPUs (due to the way they are capable of deferring an instruction on the register or partially in RAM, depending on load). I do not think this is something AMD CPUs do, so this error on an AMD CPU should indicate a CPU error 100% of the time, or thereabouts.

No - if the hardware has not changed, the hash built by the product key and hardware should match the previous activation, and not count. This would change if you were using a MAK volume license key or an OEM product key, but not a retail product key from something like a family pack purchased from a store (either online or off).