cluberti

The product you are discussing requires both the installation of Terminal Services (the full TS install) and TS CALs to allow more than 2 remote connections (also known as "Remote Desktop for Administration", the default mode that you're trying to bypass). If you want to use TS to allow more than 2 remote connections, you MUST install Terminal Services and purchase CALs for the number of remote users (or devices, if you purchase device CALs). Hacking a binary on the machine to bypass this would be a violation of the EULA for Windows Server 2003 and would fall in violation of rule 1.a: From the forum rules: Be mindful of the rules going forward - any further discussions that run afoul of rule 1.a will result in a ban.

In gpedit, Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options - User Account Control: Switch to the secure desktop when prompting for elevation (disable). Sometimes this is caused by the switchover to the secure desktop - if the above doesn't fix it, you may have to work on getting an audio driver that doesn't have the delay. I had a machine with Realtek onboard audio that would do the same thing until I changed the prompt off the secure desktop as above, and the problem went away, so it's worth a shot.

Go to the properties of the user's account in ADUC - you can use the profile tab to set a logon script for the user account itself. If the script is already in the domain netlogon share, you can just use the name of the file itself as the logon script.

Did you set the logon script in the GPO, or in the user's profile in ADUC? If you set it in the GPO itself, if it's not a local GPO, it will indeed only run once (I haven't tried this on a 2008/R2 domain yet, but I remember this happening in a 2003 domain hence my work-around). Unless the logon script differs from the one they would get on a normal machine, using the profile itself is a better place to set it.

Assuming the profiles aren't roaming profiles, not really. I normally suggest mandatory profiles for TS and loopback GPOs and logon scripts specific for TS environments, but that may or may not be feasible depending on how your users utilize the TS servers in your environment.

To build a WinPE disc, you'll need a copy of the WAIK and some hard disk space. The instructions for making a WinPE disc are here, here, or here.

I would concur - folder redirection policies are not under the Administrative folder in gpedit, meaning they're not policy settings - they're registry tatoos. If you delete the policy, the registry settings are not deleted (unless you check the box to delete the setting if the policy is removed, which isn't 100% effective). It would be best when using non-administrative policies (like folder redirection and IE Maintenance policies) to have a backup of the previous registry that you can push back down in a logon script after you remove a registry tatoo policy like IEM or Folder Redir to be safe. Lessons learned, I think.

The short answer is no, currently none of the tools can create a scheduled task natively in an offline image. However, the use of oobe and setupcomplete to configure this can be done in WSIM (or editing the unattend xml file directly) to do just what the previous poster said. You'll end up with the same outcome, except if you ever want to remove the task in the future from the imaging process it'll be easier to do.

I prefer MDT to the old RIS-style installs if you're going to do "flat" builds, but MDT can't deploy an XP or 2003 WIM image file if you do decide to "image" an existing XP install. Your best bet, if you have a 2003 server with WDS, is to consider building the XP machine the way you want, sysprep'ing it, and capturing it (via a WDS Capture Image) to the WDS server. Mordac85 is right though, all of your options are going to require a good deal of work and some knowledge of Microsoft deployment technologies (whichever route you end up choosing - RIS build, MDT, WDS/capture, etc).

Are we sure the CAT5 cable is good? I can't think of any other reason if you've tried that much.

Well, you went from a destkop-oriented chip (it's all smoke and mirrors with the Intel chips, mind you, but they do score higher than most older discrete video cards in the business graphics). Note the business graphics tests specifically test only the DX interfaces that are used to display the desktop, and anything 3.0 and over is considered "good" for this and will run Aero just fine. The gaming graphics tests run the gamut of DX tests, where a card doing what the Intel does (again, driver "smoke and mirrors" to do a lot of DX work) will fall down whereas a "gaming" graphics card like the 8400 will do much better. The Intel drivers are likely designed and tuned specifically to score "well" in the business graphics test, rather than actually be a good video chipset. And, as you probably know, they're fine for onboard graphics, but anything graphics-intensive will indeed give it trouble. Honestly, given the age of the chipset in an 8400, your scores seem quite normal to me. I'd consider it an upgrade anyway, even if it scores lower in some areas.

bonezzz, your post is almost completely irrelevant - you save yourself with suggesting other utilities, but overall it screams of flamebait. As to the OP, I'd have to say that I'm getting pretty much full saturation of a Gb link when copying large (multi-GB) files and thousands of small files (under 10k) from a Win7 machine to a 2008 R2 box, and only slightly less when copying to 2003 servers and an XP machine. The behavior is manifesting as if it was a filter driver, network driver, or even switch issue to me. I cannot repro this, and I'm copying from a physical HP workstation running Win7 to physical and virtual hosts running a few different Windows OSes as above.

ULs are being updated over the next week or so, Vista x86 and x64 (SP1 and SP2) IE7 ULs are up now.

If you downloaded the zipped .exe driver packages from Dell, you need to first run the .exe to extract the driver components - nlite can't integrate .exe files as drivers, it needs the raw package (including the extracted .sys, .inf, and .dll files). If you run the Dell driver .exe's, they generally ask you where you want to extract the files before the driver setup package runs - select a folder location, let the driver extract, and then cancel the setup when it continues. Do this for all the .exe driver packages you downloaded from Dell, and then point nLite at those new folders. It should work.

They're stored in a temporary folder and executed, although the uninstall information is stored on disk in the Windows directory. If you're just looking to download packages to redistribute to your machines, consider one of the projects here (like WUD) for this.

Sort of, yes. What you do is create a domain security group, put all the domain users you want to be able to use RDP in there, and then add that domain group to the local Remote Desktop Users group on the TS itself. That way you can add/remove users from the domain group without ever having to go back to the TS to configure rdp rights.

On the TS Server itself, there should be a local group called "Remote Desktop Users" - this is not the same as the domain group. You MUST be in the local admins group or the remote desktop users local group on the TS itself. Assuming one domain controller, the change should be immediate. Unless you've explicitly added it to a local group, no, it's not surprising.

Did you install the AD role after installing TS on the DC? I'm assuming you've got all these roles on one server - if so, you won't find it. A domain controller can have no local groups, and the RDU group is a local group created by the TS role installer. You'll have to remove the TS role and features and reinstall if this is the case.

What version of IE, and what OS?

I dunno - probably because Vista supports exFAT for everything else, I'd guess.

The only time I've ever seen this is antivirus (or, I suppose, any file system filter driver) scanning and holding handles open to the CSC. Can you reproduce this on a clean XP machine with just your drivers?

I've also found that using x64 WAIK to create mixed x64/x86 images (and the converse) ends up doing this. Consider using GImageX to re-export the images from this WIM to a new WIM, which seems to work (creates new .clg files during the process) - this has worked for me multiple times.

The readyboost driver in Vista indeed does not support exFAT, but Win7's does.

Minidumps are indeed held in \windows\minidump, but they're notoriously useless. If you configure your machine for a kernel or complete dump, it will create the .dmp file directly in the Windows folder.Minidumps are only good to tell you about very obvious crashes.