cluberti

Well, sometimes you do have to tell customers (in a very polite but concise way) that this *is* dumb. There's no reason to have a boot volume that large, although with Win8 it will "just work" anyway. With 2008 R2, you still have a bunch of issues with UEFI boot to GPT, even if it is officially supported. I can tell you it's not really tested much at all (although MDT 2012 and SCCM 2012 will have pretty good support for GPT and UEFI).

Also note that outside of Hyper-V, it really only runs on VirtualBox and physical hardware. And, I have to say, running it on VirtualBox is an exercise in bugcheck codes.

Not a bad idea to have a Windows 8 forum in the end, but for now use the Beta discussion forum. We'll reconsider it during the beta/RC phases.

As long as Intel atom machines exist in numbers (and they still do) that are 32bit only, there will be a potential for a 32bit Windows 8 release. I'd say it'll be the last, but Vista was supposed to be the last, then Win7...... At least OEMs are now preloading 64bit Win7 on all new hardware that supports it, which should get the 64bit installed base to grow (I believe it already has, quite a bit).

Does the base image off of a default 2008 R2 SP1 installation work on the system? I'm not sure how well imaging will work if the original system making the image was not UEFI-based, if it will even work at all. I've never tried, honestly.

The extended support end date for business customers using Windows 98 was July of 2006, so it would make sense that the site would no longer function at some point after July 2007. Microsoft says on their support lifecycle page that they will continue to provide online update availability for a minimum of 12 months after a product has reached it's end of support date, but they don't give any firm dates for how long afterwards. Given that milestones in a product's support lifecycle happen in 5 year increments otherwise, it would make sense that sometime around or after July 2011 that the v4 site would be retired, at the least.

Good question. Are the contents different if you extract them?

NOTE that when using PXE, you do not have to actually set the options for 66 and 67 if the client and WDS server are on the same LAN segment and subnet, as it is a broadcast request, unless you're trying to force clients to one PXE point. Also, looking at the WDS logs, it doesn't appear your WDS server knew which boot image to send to the client - did you install WDS in "legacy mode" (with RIS compat) or in native mode? Also, is DHCP on the same machine as WDS, or another box? Also, generally, when I see a failure here, there's some sort of networking device killing the PXE request, just fyi. Everything here appears to be on the up-and-up if you have a valid boot image on the WDS server that matches the client's detected architecture (x86 or x64). You haven't even gotten to the WDS server responding to the UDP request, it's all still in the BINLSVC IPHelper layer - at that point in the log, the BINLSVC helper has sent a message back to the client, but according to your client, it never got that response. There's a networking issue here, so network traces using mirrored switch ports or hubs are probably your next step. Either the boot file isn't found (which is possible, but not likely), or something is eating the POST response from the server. In either case, you need a network trace to confirm (simultaneously gathered at both ends, of course).

To make changes to your OU like this, you will probably need domain admin rights, not just delegated rights to your OU.

You might be able to get recovery media: http://support.dell.com/support/topics/global.aspx/support/kcs/document?c=us&l=en&s=gen&docid=DSN_331556&isLegacy=true

It can be, although when it comes to Javascript (at least for IE) it won't be. The 32bit browser is still the "better" one, as add-ins and the like generally are 32bit as well, as are the (for IE9) javascript performance improvements.

Note you're going to start seeing computer OEMs like Dell, Lenovo, and HP start to skip releasing XP drivers for hardware soon, and while building boxes on your own usually buys you more time in that arena, you still will find it near impossible in a short few years to get drivers for XP for even mainstream hardware. I would have to agree here with Zxian, Andre, and perhaps a few others - give it a try (180 day trial of Enterprise is indeed legal and free), and see if you can use Windows 7 or not. Generally, unless you're a diehard or have somewhat obscure hardware or software requirements, you can run Windows 7 without issue with your usual programs. Windows 7 is not change for change's sake, and a lot of the features really are useful. If you find after a trial that you just cannot change your computing habits a bit, though, you can always acquire a copy of XP from your favorite retailer and use that instead.

Then you were still viewing it in a 32bit browser (which is expected, and as it should be right now anyway). There is no 64bit version of Silverlight available as of yet.

If you do, let us know. Not all Dell machines, even those of the same model run, are necessarily equal. You may need to engage Dell, ultimately, to figure out what's different with the machines that aren't working compared to the ones that do.

CopyProfile needs to be done in the sysprep that is laying the image down onto new hardware. You can't, and shouldn't, try to do it during capture - only deploy. Also, you do not need to autologon, because the profile will exist if you logged on as admin in the original image and made the requisite modifications to have required CopyProfile in the first place. As to the error, it at least tells us something - that error code means "ERROR_PARTIAL_COPY", which is stating that it is having an issue either reading or writing some of what it is attempting to write from memory to disk. I don't know why, but either there's an issue with the profile in the captured image (not totally impossible), or there could be hardware issues with the destination machines.

The eventcode for this error is c0000184 as per your output, which you've already seen. This generally means that the driver has responded to the requesting IRP that a send request has been made on a pre-existing request built that is either not ready to send, or has already passed a state that it can be in to send. Note the other codes don't actually mean anything useful in this particular instance, so you don't have to continue to bang your head against the wall for those. Generally you see 2012s due to antivirus software that contains a network filter driver, a bad network driver (or teaming software driver), or external acceleration hardware. Assuming you can reproduce this on other switch ports with other machines making the same sorts of requests for the same data, you can at least rule out the machines and software on them (hopefully you can do this - if not, you might want to consider it in troubleshooting). Next, assuming you have forced speed and duplex on the NICs in your servers or clients seeing these 2012s to match the switch ports, that generally rules out the cabling and the autosense fabric. That leaves switch backplane or WAN accelerators.

Very true, although Toshiba probably will want proof of ownership before shipping out a recovery DVD (which will also likely not be free, knowing Toshiba). Last but not least, usage of that recovery DVD will wipe the disk and all contents, so backup your data before using, OP .

Note that you will have issues with any non-standard print drivers that require additional services or registry entries not backed up, and could end up with a broken print server on the other end. Always test before migrating.

You can install unsigned device drivers, but automating it (due to the warning about unsigned drivers, even with signing enforcement off) isn't really easy. Plus, permanently disabling driver signature enforcement puts the system in test mode, which will result in lots of reminders all over the desktop and elsewhere that you've gone into test mode (yes, you can get around this too, but I think you may start to see the trend I'm describing here). You could, however, install the software and drivers into your image pre-capture, and use the PersistAllDeviceInstalls parameter in your unattend xml to keep them there post-install. It's not as manageable, but it works. You'd still need to disable enforcement entirely on x64 to get them to load, so hopefully you're only using this on x86 (where you don't have to go into test mode to get unsigned drivers to work..........).

Does a stock Win7 install do this on the same hardware as well?

If that doesn't help, just open the event viewer, click on the System log in the Windows Logs folder, and filter on Kernel-Power events. You will see the machine go to sleep, and afterwards there will be another event showing the machine waking with the device, driver, or reason (if known) that triggered the wake event. Note that if a scheduled task wakes a machine, it should also go back to sleep after the timer has passed again after waking, so if the machine stays on it's usually a rogue program or a misbehaving driver.

Found it: http://support.microsoft.com/?id=828287

The problem is that the original source image also comes with a license/EULA, and re-imaging with that, depending on what that OEM installation EULA allows you to do, could in fact be illegal. You should very carefully read the EULA that ships with the OEM machine when you first turn it on, just in case. Microsoft generally doesn't allow mass imaging without using volume-license media (and with an OEM license underneath, to boot - not a "clean" machine), and OEM media doesn't fall under that umbrella.

I was wondering where you'd been .

Please do not double-post. Answering is happening in the other thread.