Can’t add HKCU entries via GroupPolicy Preferences

You're saying that you have user settings that you want to apply to users only when they logon to certain computers? Sounds difficult, eh? It's not difficult at all. It sounds like a job for loopback group policy processing!

Assume the following:

 [Domain] mydomain.com.org.net.local
  |
  |--[OU] Special Computers
  |   |
  |   |-- [Computer] COMPUTER 1
  |   |
  |   |-- [Computer] COMPUTER 2
  |   ...
  |
  |--[OU] User Accounts
      |
      |--[User] Bob
      |
      |--[User] Alice
      ...

You would like to apply a user setting (such as running a logon script, or applying other types of GPO user settings) for all users who logon to computers in the "Special Computers" OU. When they logon to computers located in other OUs, though, you do not want these special settings to apply.

Create and link a GPO to the "Special Computers" OU. Specify in that GPO all the user-related settings you want to apply.

("But wait, Evan! The user's account objects aren't in the 'Special Computers' OU!" Yes. I know that. Stay w/ me here. Most AD admins I've met don't understand loopback policy processing and get scared. I've seen horrible hacks like creating secondary user accounts for users to logon with when using "special computers", etc... >shudder<)

In the GPO you created, go into the COMPUTER "Administrative Templates", "System", "Group Policy", and locate the setting "User Group Policy loopback processing mode". Enable this setting. In the "Mode" box, choose "Replace" if you want all the user's "normal" group policy settings to be ignored and only the user policy settings in this new GPO to apply. Choose "Merge" if you want the user settings in the GPO to apply after all their normal user settings have applied.

My opinion is that this is a lot cleaner than "hacks" involving "If computer == blah" in logon scripts.

My advice to you would be to do what you're doing with a Group Policy Preference (GPP)registry settings, rather than with a logon script. It will apply one time, leaving default settings in the users' registry, but the user will be able to change the settings freely in the future without having them "smashed" each time they logon.

If these are Windows Server 2008 machines, like your tag says, then there's really no excuse not to use GPP registry settings. Have a look at the articles below for some more details. This is a really nice feature of W2K8, and something you should be taking advantage of.

http://www.microsoft.com/downloads/details.aspx?FamilyID=42e30e3f-6f01-4610-9d6e-f6e0fb7a0790&DisplayLang=en

http://blogs.technet.com/grouppolicy/archive/2008/03/04/gp-policy-vs-preference-vs-gp-preferences.aspx

Having JUST left an academic environment where we were ghosting 1200+ workstations each quarter and needed to keep University students from hacking them to smithereens, I feel your pain. As it happens I spent September through January hacking on that exact problem. I did not find a complete answer, but I did find out some things that helped:

• Nearly all problems are a result of setting up the default user profile for use by students.
• Machines that are properly sysprepped experience this problem a lot less often than profile-copy methods.
• When it happens, sometimes the access to the print server is actually the ghost-user or the profile-copy user, or some other cached credential on the image rather than the logged in user.
  • Jason Berg's delay method will make this work if this is what's nailing you. By the time the GPO fires, profile setup is completed and these cached-user accesses won't happen.
• Sometimes, going into the Options on the Preference and hard specifying "Run with user's permissions" make it work more often.
• This seems to rarely happen when the profile exists on the machine, such as happens when troubleshooting the problem :P. I haven't used Deep Freeze, so don't know if it leaves profiles behind after a login.
• Sometimes Deploying the printer to the user and also setting a GPO Preference to set the default printer works more reliably than Deploying to the computer. You're using loopback processing anyway, may as well just put everything in the User GPO that you can.

And I still didn't get it completely knocked down. It's a tough problem.