System Context versus User Context

System Context and User Context are concepts related to how applications or processes interact with the operating system and network resources. They are important in understanding the security, privileges, and settings that different applications or tasks have when connecting to the internet or other network resources.

In this article, we will explore the significance of System Context and User Context, examining how they impact the way non-interactive Windows services and applications connect to the internet. We will also dive into common methods used to set network proxies for these distinct contexts, providing best practices for ensuring seamless connectivity. Additionally, we’ll discuss quick and effective approaches to identify network connectivity issues and how to determine if network proxy settings are in use.

This post is inspired by the sharing from SEE Seven Li

---

1. System Context and User Context

From a network connection perspective, non-interactive Windows services or background tasks run in “System Context” and utilize the WinHTTP API to connect to the internet. Examples include services running with the Local System account and the Automatic-Device-Join scheduler task.

On the other hand, applications that leverage the WinINET API to connect to the internet run in “User Context” Each user logging into Windows OS will have their own “context”, which explains why the IE proxy settings are different per user by default.

https://docs.microsoft.com/en-us/windows/win32/wininet/wininet-vs-winhttp

1.1 Examples

Processes that running with SYSTEM account and USER (Administrator) account:

Services that running with Local System Account:

In the Hybrid Azure AD Join scheduled task, the task is running under SYSTEM account:

When launching the application, it operates within the User Context, specifically under the User account:

---

2. Common methods to set network proxy for different contexts

Both WinINET and WinHTTP can be configured to use network proxies using different mechanisms:
a. Proxy auto-configuration scripts.
b. Auto-discovery.
c. Manual configuration.

We can configure the network proxy settings in the Internet Properties for WinINET (User context), and use netsh winhttp set proxy for WinHTTP (System context).

Both WinINET and WinHTTP can be configured with WPAD (Web Proxy Auto-Discovery).
Web Proxy Auto-Discovery Protocol – Wikipedia

3. Quickly identifying network connectivity issues (Hybrid Azure AD Join)

3.1 Use the dsregtool PowerShell script to quickly test internet connectivity under the system context

Download the dsregtool here: Device Registration Troubleshooter Tool – Code Samples | Microsoft Learn.

The script schedules quick background tasks (under system context) to test the connectivity with DRS endpoints.

3.2 Leverage PsExec Tool to run either IE or PowerShell for testing connectivity.

Refer to this post: Execute Processes Remotely with PsExec Tool – Ruian’s Tech Troubleshooting Toolbox (ruianding.com)

Please keep in mind that successful access from the browser without PsExec only confirms the connection is good for the user context.

3.3 Capture the network trace

---

4. Identify if we are using the network proxy settings

4.1 For WinHTTP proxy settings (System context)

Check the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
Key Name: WinHttpSettings
Type: REG_BINARY

Also use the CMD netsh winhttp show proxy

Reference: WinHTTP Proxy Settings deployed by GPO | Microsoft Learn

4.2 For WinINET proxy settings (User context)

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Key Name: ProxyServer
Type: REG_SZ

Reference: How to configure Proxy Settings for IE10 and IE11 as IEM is not available | Microsoft Learn