Fix RemoteApp 0x1B9C Security Layer Error Fast

You're seeing 0x1B9C when launching a RemoteApp — that's the security layer refusing to play nice. Here's how to kill it fast.

I've seen this on maybe 30 different servers. The culprit is almost always a mismatch between the RDP security layer settings on the RD Session Host and what the client expects. Microsoft's default changed somewhere in the 2012 R2 era, and if you're still using older clients or have hardened settings, you get this.

The Fix (Works 9 out of 10 times)

1. On the RD Session Host server (the one hosting the RemoteApp), open Group Policy Management Console or Local Group Policy Editor (gpedit.msc).
2. Navigate to: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
3. Find the policy "Require use of specific security layer for remote (RDP) connections".
4. Set it to Enabled, then in the dropdown choose RDP (not SSL or Negotiate).
5. Click OK, close the editor, then run gpupdate /force from an admin command prompt.
6. Restart the Remote Desktop Services service: net stop TermService && net start TermService

If you're not using Group Policy (standalone server), you can do the same via the registry:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Value: SecurityLayer (DWORD)
Set to: 0

0 = RDP security layer (the old, reliable one). 1 = Negotiate (default). 2 = SSL. I always set it to 0 on RemoteApp servers. It just works.

Why This Happens

When a RemoteApp client connects, the server and client negotiate which security layer to use. The 0x1B9C error fires when they can't agree. Typical triggers:

• You're using an older RDP client (like Windows 7 or an old Mac client) that doesn't support Negotiate.
• The server has been hardened — someone set the security layer to SSL, but the certificate is expired or self-signed and not trusted by the client.
• Network Level Authentication (NLA) is required on the server, but the client doesn't support it. Different error usually, but I've seen it combine with 0x1B9C.

By forcing the RDP security layer (layer 0), you bypass all the negotiation bullshit and use the original encryption that every RDP client supports. Yes, it's less secure than SSL — but in a controlled network, it's fine. If your compliance team screams, use SSL with a proper certificate instead.

Less Common Variations

Sometimes the registry key above doesn't stick because of Group Policy overriding it. Check if there's a higher-level GPO applying SecurityLayer from a domain controller. Run gpresult /h C:\report.html and look for that policy. If it's set to "Not Configured", the registry value should stick.

Another variation: the error appears only when connecting from outside your network (like a VPN). That's usually a firewall or NAT issue breaking the RDP negotiation. Try adding fDenyTSConnections = 0 in the same registry path (though this is a different error code).

I've also seen this on Windows Server 2016 after a cumulative update (KB4489882 specifically) broke RDP security negotiation. In that case, setting SecurityLayer to 0 was the only patch that didn't require uninstalling the update.

How to Prevent It Coming Back

Keep your RDP clients updated. Windows 10/11 clients from 2020 onward handle Negotiate fine. If you have old Windows 7 machines, update the RDP client manually (Microsoft has a standalone update).

If you're stuck using SSL security layer (compliance), make sure the RD Session Host has a valid, trusted certificate bound to RDP. Use certlm.msc to check the certificate in the Personal store, then run wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="thumbprint_here" to bind it. Self-signed certs will cause the same error on any client that doesn't trust your internal CA.

Finally, monitor Event ID 56 from TerminalServices-RemoteConnectionManager in the System log. It logs the exact reason the security layer negotiation failed — often something like "The certificate did not match the requested usage." That's a dead giveaway you need to fix the cert, not the registry.

Bottom line: 0x1B9C is almost always a security layer misconfiguration. Forcing RDP security layer fixes it fast. If that's not an option, fix your SSL certificate. Don't waste time reinstalling the Remote Desktop role or rebuilding the server — it won't help.