Configuration Manager Baselines: System and User Contexts
Configuration Manager’s baselines are one of the most powerful tools in your systems management toolbox. A baseline allows you to put in place preferences and settings, and then enforce them with reporting. Recently, I needed to change the quick access area in Explorer. Before I could use a baseline, I needed to create a configuration item setting. In systems management, there are a couple of contexts that programs, scripts, etc. will run in. They are system and user contexts. I first tried running the configuration item script in the system context, but I saw no change. Basically, nothing happened. However, when I ran it in the user context, it worked perfectly and updated the quick access area.
In this blog post, I’m going to cover system and user contexts so you can get a better understanding about when to use each one.
System and User Contexts
Context makes a big difference when it comes to how installations or scripts react when being run on a device. Based on the context, variables will point to different places, actions are either allowed or denied, and end results can be completely different when running the exact same script.
File / Folder Differences
These are some examples of a few variables and how they differ:
- System = c:\windows\temp
- User = c:\Users\username\AppData\Local\Temp
- System = c:\windows\system32\config\systemprofile
- User = c:\Users\username
The same issues can arise when making registry changes in your script. If you’re trying to make changes to the user’s registry [HKEY_Current_User], it’s easiest running under the user’s context of the registry that you need to change. If you’re running as a system, but you want to make a change to an end user’s registry, it can be quite difficult or potentially not possible. This is where Group Policy is really handy. You can use Group Policy to target an end user, or you can use it to have a process run as the end user.
How Do ConfigMgr Baselines Help?
Baselines consist of one or several configuration items. Configuration items consist of one or several settings. Each setting can run using the system or user contexts. When using the user context, you need to check the “Run scripts by using the logged on user credentials” box (see the image below).
Most of the time, I run configuration item settings as a system because I’m making changes to the system. An end user wouldn’t typically have rights to the changes I’m making, so it wouldn’t make sense to run the configuration item setting as a user. I also want the configuration item to be able to run if no user is logged on. However, from time to time, I want to change a user setting, which forces me to run the configuration item in the user context to make a change to their profile. Another example of using the user context would be if I want to do something that interacts with the end user.
Real World Examples – System and User Contexts
As I mentioned earlier, I needed to change the quick access area in Explorer. I first tried running the script as a system, but I saw no change – nothing happened. When I ran the script as a user, it worked perfectly by updating the quick access area.
You can see in the screenshot above, that there are several default Quick access folders. This is before I ran the baseline.
Then, after the baseline runs, the default folders are gone, and my custom ones are added.
If you need to do something similar, the scripts for that baseline are located on GitHub.
Community Examples and More Resources
Another option I’ve also seen is to have a configuration item in a baseline trigger under the user context. If you’d like to learn more about this method, please check out these posts:
Here are some more resources:
ConfigMgr Configuration Baselines – A Beginners Guide – Maurice Daly
Configuration Baseline Remediation – Configuration Item – Garth Jones
If you have any questions about baselines, and system and user contexts, please let me know on Twitter @gwblok.