The “Run in Logged on User’s Security Context” option is one of the least understood (and used) features of Group Policy Preferences. Understanding how to use it (and when) can save you hours of frustrating and fruitless troubleshooting! In this post, we will cover a practical example showing when to use “Run in Logged on User’s Security Context”. First, a little introduction on this cool little Group Policy setting:
“Run in Logged on User’s Security Context” is one of the 5 common options found within each Group Policy Preference CSE. You are probably familiar with other Common Options through the use of the “Apply Once and Do Not Reapply” as well as the massive filtering add-on “Item Level Targeting”. Understandably, this option is only available under the User Configuration node because it can change the preference security context.
Security Context in Group Policy Preferences
Group Policy Preferences are so easy to setup and use because of the simplified security context. Every preference item applied is processed under the local SYSTEM account. This applies to preference items created under both the Computer and User Configuration nodes.
When you select “Run in Logged on User’s Security Context”, the security context is changed from SYSTEM to the current logged-in User. This is a huge distinction when you are creating preferences for Files, Shortcuts, or Drive Mappings! Basically, any preference that touches a network device can be altered with this common option.
0x8007005 Access is Denied? Preferences Say What?
Knowing that Group Policy Preferences run as SYSTEM by default, the error message below might seem a bit baffling:
A simple Group Policy Files preference is failing because “Access is denied”. Looking closer, you will see two warning messages above. It appears that two File Preferences are failing and both are in the same GPO. Both are getting the same “Access is denied” warning. Let’s take a look inside that GPO to figure out why.
This GPO starts by deleting any file named “NutriKids Menu Planning.lnk” from the %DesktopDir%\. We know that the Delete preference will process first because it’s order is “1”. As a reminder, %DesktopDir% is a GPP variable for the current user’s desktop. You can see every variable (plus how to access them) by downloading these Group Policy notes.
Our second preference creates a new shortcut. It copies that shortcut from a server (\\msi\) and places it on the current user’s desktop. This two step process (Delete,Create) is a real easy way to ensure that any user created shortcuts point to their correct locations. It is also handy when you are migrating servers/shares and don’t want to end up with a bunch of broken shortcuts.
So What is the Common Factor?
The two preferences above have one thing in common – they are both attempting to write to %DesktopDir%\. Because we redirect our user’s desktop to a server, the local SYSTEM account get denied! SYSTEM can’t write to a server without the correct permissions. Even if you enabled Loopback Policy Processing and set it to OverLord Tank mode, the shortcut won’t ever get created!
The simplest solution is to open the Common tab on both preferences and enable “Run in Logged on User’s Security Context”. After a single GPUpdate or a 90 minute (relative) wait, the File preferences will apply and magically appear!
Microsoft has a little more information about the Common options. That information can be found here.
“Run in Logged on User’s Security Context” is a pretty simple solution to a complicated issue. I am working on a part 2 to the “Troubeshooting Group Policy Preferences” checklist and this setting will be on that list. But I need your help!
What problems have you experienced with Group Policy Preferences? How did you fix it? Leave a comment below and your solution might be on second troubleshooting guide (with credit to you)!