cluberti

If you're sure the OS was Win7 RTM, then it seems likely someone installed an RC of the RSAT tools (which is odd, considering the RTM package has been available since shortly after Win7 released in late 2009). However, you don't have to wait - uninstall the RC RSAT tools, reboot, and follow Andre's guide here to install the SP1 RSAT tools from the RTM package.

OK, so the policy is not set to apply. Time to check your AD configuration and make sure the computer objects are in an OU that has that GPO applying to it - if not (and that seems the case), it will have to be linked to wherever those computer objects are in the AD structure.

Well, assuming you're not using it for WinRE or storing information for bitlocker, you are correct - you don't need to back it up as part of an image, and if it becomes corrupt on an existing install you can technically recreate it and run repair from WinRE or the setup disc to fix it. You can even remove it and Windows will still boot once bcd is updated with the new information, and WinRE or the setup disc is used to repair startup info. I wouldn't recommend it, of course, and I've never done it myself, but from what is documented it would appear that it can be done .

6.1.7100 is Win7 RC - how do you have Win7 RC files on an RTM system? Did you perhaps upgrade from the RC to RTM on this machine at one point in time?

The ADM or ADMX/L files are not pushed to clients at all - they're used to generate policy files stored on sysvol, and those are run (from sysvol directly) via executables on the client. What you see in RSOP is simply the result of reading policy data, and only the .html file generated by RSOP is on the client (in temp files). Group Policy files are not ever placed onto the client directly, they're run from sysvol on the DC you're connected to.

That's odd that adding an xbootmgr trace wouldn't work. You can always configure the machine to crash via the keyboard if you have a PS/2 keyboard attached, and generate a full dump that way when it's hung.

Can you be more specific in your question? What you've asked makes no sense in English, sorry.

Both work fine. You happen to use substandard networking components (Micronet SP906GK devices are modified and re-branded Realtek 8185 devices) which don't work properly with the drivers provided (they make drivers for this device for Win9x - the chipset is considerably old). If you were to google Realtek 8185 and Windows 7 together, you'd find you are hardly the first that has significant troubles getting this to work in Windows 7 (and some folks had trouble under Vista as well with older revs of this chipset, it seems). Also, it appears that vendors can modify the Realtek chipset, and certain vendors seem to have more devices that work versus some others (Micronet, Zyxel) that do not. So, it would also seem that these are indeed Realtek 8185 devices, but they've been modified as such by the OEM reselling them (in your case, Micronet) which has caused them to work far worse than other vendor's devices using the same Realtek chipset. Again and as others have said, this is not Microsoft's fault, nor Bill Gates (he doesn't even work there anymore, and really hasn't since the middle of the last decade). I am sorry to hear that you are having issues with your network card under Windows 7 (and you should use what works for you), but your blind hatred of Microsoft is quite obvious, and has led you to place the blame where it does not belong. In the future, you may wish to consider purchasing devices from name-brand vendors rather than knock-off clones, which will probably reduce your frustration level and driver issues, for starters. Given this issue is resolved, I'm marking this thread as such in the title.

On the Win7 machines, run gpresult /h gpresult.htm, and then post the gpresult.htm here if possible.

Have you looked at gpresult /v to see if the group policy is even applying on the win7 clients?

What edition of Windows is this, and what was the default language of the original media you installed from?

I believe SP1 does enable the forcing of a logon if it was disabled previously, even with only one account (especially if you set a password). The old steps should still work though (replace the "control userpasswords2" with "netplwiz" in the steps): http://channel9.msdn.com/Blogs/coolstuff/Tip-Auto-Login-Your-Windows-7-User-Account

You know your connect #?

Are you seeing the problem immediately after installing Windows 7 SP1? If so, please get a trace.

You could use notmyfault as well, if you can get it to run and be available before you lock up. However, given what you've mentioned with numlock and clicking, you're locked up way above dispatch level. An NMI might be the only thing you've got if you can initiate an NMI dump from that motherboard.

Ask Microsoft? Might want to wait and see if they still exhibit symptoms in the release. It's quite a few builds after the RC available previously.

Unless you're forbidden from doing so, even Microsoft recommends using at least MDT to do most of this. I know a lot of actual OEMs cannot, but otherwise use MDT if you're doing a lot of building of machines and software .

+1 - PAE is for RAM over 4GB (and *only* works in 2000 Advanced server and Datacenter editions!), and /3GB has absolutely NOTHING to do with RAM.

Look into the <copyprofile> section of the unattend.xml. If you're sysprep'ing a VM and not using this in your unattended build of it afterwards, then yes, all customizations in the Admin profile are lost. This is expected behavior.

The question is why? It is actually useful, especially if you have recovery installed/enabled or ever plan to use bitlocker or another whole-drive encryption package.

Better to use a PS/2 keyboard though - the USB bus is a polling bus, so if you lock at a very high IRQL, the bugcheck won't occur (hence why there's a hotfix, but the instructions still suggest a PS/2 keyboard). PS/2 is an interrupt bus, and would fire no matter what IRQL the machine is at. Do yourself a favor and get a PS/2 keyboard on there, even temporarily, and set CrashOnCtrlScroll as per the dump instructions - reboot, and get that dump.

http://windowsteamblog.com/ie/b/ie/archive/2011/03/09/a-more-beautiful-web-launches-on-march-14th.aspx

Here's a question, assuming the drives in question are configured to be indexed - have we simply tried deleting and recreating the index itself from the control panel?

You'd probably be better off with two AD sites (one DC in each site) and separate them by IP subnet (a /21 at each site, rather than a campus-wide /20). You can set up DFS on the fileservers if you need data replication, otherwise what you're doing is fine. The architectural design of the network itself (for hosting AD) is overly complicated given other options that will work just as well, but what you have will work. Unless you're talking about thousands of seats in each particular portion of campus, splitting them physically makes little sense long-term. Let logical site representation segment logon and replication traffic, not physical design.

There's no such thing - you again could use a spare PC with FreeNAS, but to get a clusterable pre-built device you're going to spend a few thousand dollars for an iSCSI enclosure.