GPO Proxy Applied but Not Working: The Missing IE Engine on Windows Server

I recently ran into a classic “ghost in the machine” scenario: users on a new Windows Server 2019 terminal server reported that they couldn’t access the internet. The server had been recently stood up by a colleague, and like most RDS environments, we use a proxy configured via Group Policy.

Here’s the kicker: gpresult /r showed the policy as successfully applied to the user session. Everything looked perfect on paper. However, a quick check of the Internet Properties in Control Panel showed no proxy settings, and the registry values were completely missing.

PS C:\Profiles\testuser> gpresult /r

Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
© 2018 Microsoft Corporation. All rights reserved.

Created on ‎19.‎03.‎2026 at 9:17:34

RSOP data for DOMAIN\tester on TERMINAL-USER : Logging Mode
-------------------------------------------------------

OS Configuration:            Member Server
OS Version:                  10.0.17763
Site Name:                   N/A
Roaming Profile:             N/A
Local Profile:               C:\Profiles\tester
Connected over a slow link?: No

USER SETTINGS
--------------
    Last time Group Policy was applied: 19.03.2026 at 9:15:31
    Group Policy was applied from:      server-main.domain.com.ua
    Group Policy slow link threshold:   500 kbps
    Domain Name:                        DOMAIN
    Domain Type:                        Windows 2008 or later

    Applied Group Policy Objects
    -----------------------------
        gpo-SetProxySetting

The Battle-Tested Setup: Why It Should Have Worked

The configuration itself was a standard, rock-solid piece of our infrastructure. I was using Internet Explorer 10 Group Policy Preferences (GPP), located under User Configuration > Preferences > Control Panel Settings > Internet Settings.

This setup has been our “old reliable” for years. It works flawlessly across our entire fleet of Windows 10 and 11 workstations, as well as our legacy terminal servers running Windows Server 2012 R2 and 2016. The logic was simple and proven:

• LAN Settings: Proxy checkbox toggled “on.”
• Address/Port: Correct IP and port entered.
• The “F5” Magic: All settings were confirmed with those reassuring green underlines, ensuring they were active and ready to be pushed.

I had no reason to doubt the policy. It wasn’t a “newbie” configuration error or a faulty GPO link—this was a proven setup that had suddenly hit a brick wall on a specific Windows Server 2019 build.

The Ghost in the Shell: When Hardening Breaks the GPO Engine

The problem was far from obvious. After a deep dive into the OS components, the “Aha!” moment finally came. It turned out that my colleague, in a well-intentioned effort to harden the new server, had completely disabled the Internet Explorer optional feature.

To confirm that, I ran a PowerShell command to check the status of the Internet Explorer optional feature.

PS C:\Windows\system32> Get-WindowsOptionalFeature -Online -FeatureName "Internet-Explorer-Optional-amd64"
FeatureName      : Internet-Explorer-Optional-amd64
DisplayName      : Internet Explorer 11
Description      : Finds and displays information and Web sites on the Internet.
RestartRequired  : Required
State            : Disabled
CustomProperties :\SoftBlockLink : http://go.microsoft.com/fwlink/?LinkID=142507

Weighing the Options: Choosing the Right Fix

Once the cause was clear, I sat down with my colleague to figure out the best way forward. We had three main paths on the table:

Option 1: Re-enabling the IE Component

The most obvious “quick fix” would be to revert the changes and re-enable the Internet-Explorer-Optional-amd64 component. This would bring back the engine and restore the legacy GPO’s functionality immediately.

• The Verdict: My colleague (the one who hardened the server) flatly objected. He wanted a clean, secure OS without legacy browser bloat. I agreed: re-enabling IE in 2026 just to fix a proxy feels like moving backward.

Option 2: Transitioning to Microsoft Edge Templates

We could have abandoned the old “Internet Settings” entirely and moved to the modern ADMX templates for Microsoft Edge.

• The Verdict: While this is the “modern” way, it sometimes creates a split experience if users still use other tools or legacy apps that rely on system-wide proxy settings. We needed something universal that hits the OS level directly.

Option 3: Direct Registry Injection (The Winner)

The final and most robust choice was to write a new policy that targets the registry directly. By injecting the proxy settings straight into HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings, we bypass the need for any browser-specific “engines.”

• The Verdict: This was the winner. It’s clean, it’s fast, and it’s independent of which Windows features are enabled or disabled. We decided to create a surgical GPO that only lives on this specific server, ensuring zero impact on the rest of the infrastructure.

The Implementation: Bypassing the IE Engine with Registry GPP

Since we decided not to reinstall legacy components, we shifted our strategy to Registry Group Policy Preferences (GPP). This method is bulletproof because it writes the settings directly to the hive, completely ignoring whether Internet Explorer is present or not.

Here is the exact configuration I implemented under User Configuration > Preferences > Windows Settings > Registry:

1. Defining the Core Registry Keys

As shown in the screenshot, I created three Update actions targeting the path:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

• ProxyEnable (REG_DWORD): Set to 1. This is the master switch that tells Windows to use a proxy.
• ProxyServer (REG_SZ): Your proxy IP and port (e.g., 192.168.1.50:8080).
• ProxyOverride (REG_SZ): The exceptions list (e.g., <local>;*.yourdomain.com). This ensures internal traffic doesn’t loop through the proxy unnecessarily.

2. Surgical Precision with Item-Level Targeting

To keep this policy “leak-proof,” I didn’t just link it and hope for the best. I used Item-Level Targeting (ILT) on each registry item:

• Navigate to the Common tab of the registry item.
• Enable Item-level targeting and click Targeting….
• Add a Computer Name condition and specify our new 2019 Terminal Server.

Why this matters: Even though the GPO is linked to an OU that might contain other servers, these specific registry keys will only be written when a user logs into this specific terminal. This keeps our environment clean and predictable.

3. Loopback Processing

Because these are User Configuration settings being applied to a specific Computer, I ensured that Loopback Processing Mode was enabled (set to Merge) on the GPO linked to the Terminal Server’s OU.