How to Increase RDS Event Log Retention Via Group Policy To Better Troubleshoot Your RDS Environment

When I consult with companies to fix problems in a misbehaving Remote Desktop Services deployment, I first examine all of the metrics and performance counters our RDPSoft tools can collect. Then, I rifle through all of the various RDS channel event logs buried deep in the Event Viewer that admins often overlook. That said, more often than not, the information I need from those logs is long gone, overwritten days or hours prior when the log wrapped around. This is an especially common occurrence in larger RDS deployments where the brokers and gateways stay super busy handling incoming connections. To learn how to fix this common issue, please read on and watch my comprehensive RDPHard Channel video below which walks you through how to boost RDS event log sizes, step by step.

Why are missing events such a common occurrence? Well, for starters, most all of those channel event logs have a default retention of a single megabyte (e.g. 1024 kilobytes), and no one has ever bothered to adjust the log size up so more data can be stored before the log starts overwriting itself. And honestly, you can’t really blame an overworked admin for not addressing this problem. First of all, unlike many other settings that you can tweak in Group Policy, event log max size is ONLY configurable for the Application, System, Security, and Setup logs. And while you should up the max size for those core 4 event logs as well, there’s not an easy way to adjust log sizes for those newer channel event logs that pertain to RDS. Secondly, you have to actually know which of the myriad of channel event logs actually pertain to RDS and are relevant for troubleshooting in order to adjust their sizing.

Step 1 – Make Sure You Have a Special Organizational Unit That Houses Your RDS Servers in Active Directory

So, now I’m going to show you how to fix all of this. You will need to build a GPO that will target max log sizes for the most common RDS related event logs you’ll examine during periodic troubleshooting. I’m assuming you’ve got a tidy Active Directory environment where all of your RDS related servers (like session hosts, gateways, and brokers) live in their own Organizational Unit. If not, you should definitely set that up post haste, as RDS servers need many special GPO tweaks (FSLogix comes to mind) that don’t necessarily apply to the rest of your servers.

Step 2 – Create and Link a GPO To Your RDS Organizational Unit That Adjusts Channel Log Max File Sizes in the Registry

Once you’ve got a GPO put into place that just governs your RDS servers, you can start tackling max log size settings for your RDS channel event logs. But, to do this, we have to understand where those settings live. Not surprisingly, they are buried way down in an obscure registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels

When we explore the Channels subkey under the WINEVT key, we’ll see where Windows keeps all of its settings about the rest of the event logs on the system (beyond the Core 4).

The settings of interest here are the MaxSize and MaxSizeUpper settings. MaxSize is the value in bytes that the log will grow to until it starts wrapping and overwriting old events. I’m not sure what MaxSizeUpper is, but I suspect that it is for 64-bit versions of Windows where you want to create a maximum log size over 4 gigs, and this would be the upper DWORD of a 64 bit value, with MaxSize being the lower 32 bits value. Regardless, for our purposes, MaxSizeUpper will always remain zero, since we’re not setting these logs to a maximum size greater than 4 gigs.

Now that we know what registry values to target, we can get around the fact that Microsoft doesn’t have an explicit GPO setting for these channel event logs by creating a GPO to modify the maxsize registry values for the logs we want to adjust. We do this by navigating to Computer Configuration, Preferences, Windows Settings, and then Registry. We then right mouse click on the registry icon and choose New, Registry Item.

To make things easier, you can copy the registry key names of the channel event logs directly from the Registry Editor, and paste them into the dialog. Just make sure that you remove the HKEY_LOCAL_MACHINE specifier and start with SOFTWARE instead. I forgot to do that initially and things weren’t working properly. We want these entries to be an Update action, meaning that they will create these values under the channel event logs if they don’t exist, or will update the value if it does already exist.

Once you’ve defined the MaxSize and MaxSizeUpper values for one channel log, you can copy and paste them in the Registry GPO area, and then simply change the key name slightly to target a different channel log name. Once you’ve done this multiple times for multiple channel logs, you’ll have a nice assortment of these settings stored under the Registry area.

Step 3 – Download My XML File That Already Has These Channel Log Max Size Registry Entries Defined, and Import Them Into Your GPO To Save Time.

I want to make your work even easier, so I’ve exported all of the Registry values I created to adjust the max size of the most useful RDS channel logs into an XML file. Here are the channel logs included in the file:

Microsoft-Windows-TerminalServices-SessionBroker/Operational
Microsoft-Windows-TerminalServices-SessionBroker/Admin
Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
Microsoft-Windows-TerminalServices-SessionBroker-Client/Admin
Microsoft-Windows-TerminalServices-Licensing/Operational
Microsoft-Windows-TerminalServices-Licensing/Admin
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
Microsoft-Windows-TerminalServices-LocalSessionManager/Admin
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Admin
Microsoft-Windows-TerminalServices-Gateway/Operational
Microsoft-Windows-TerminalServices-Gateway/Admin

Right Mouse Click Here, and Select “Save Link As” To Download The RDSLogRetention.xml File

• 

• 

• 

• 

From there, open up the XML file in Notepad, perform a Select All, and then copy the XML file contents into your clipboard. In the Registry Settings of the GPO you’re working on, right mouse click and choose “Paste.” This will copy in all of these registry settings into the GPO for you, and your work is done.

Important Note: If possible, first test these settings in a GPO bound to a non-production server OU first, like a staging RDS deployment you use to audition new system settings first before pushing them into production. I’ve tested this XML file in multiple domains without issue, but caveat emptor!

Note 2: If you want to change the MaxSize value to something larger or smaller, you can do a global replace for the MaxSize I’m using (which is around 130 megabytes) in Notepad before you copy and paste the XML data into the GPO. Just make sure the value is a multiple of 64KBs and convert the number of bytes into a hexadecimal value before replacing.

Step 4 – Schedule a Maintenance Reboot For Your RDS Servers To Make Sure Everything Takes Effect

So after we have our GPO built with our max log size registry entries, doing a gpupdate /force should immediately adjust the max sizes up for these logs in the Event Viewer right? Not exactly. While we can see that the registry values updated, the Event Viewer does not show the new settings. However, if we restart the servers, and then launch Event Viewer, you will see that it then shows the correct MaxSize values. This may have something to do with the EventLog service needing to be restarted, I’m not sure, but for best results, I’d suggest pushing this GPO out before you conduct your nightly or weekly maintenance reboots of your servers.

Step 5 – Consider Using Our Special Consolidated RDS Event Log Viewer In Order To Speed Up Troubleshooting of Session Hosts, Brokers, and Gateways

So now that we have your RDS channel event logs holding on to enough data to be useful for troubleshooting, the only task left is to actually review them regularly. And while I suppose you can go “log by log” on each server in your RDS collection via the Event Viewer, that’s pretty painful. So I’m going to make a small shameless plug here and suggest that you learn more about the special RDS Event Viewer my company includes in both our Premium Management Features and Remote Desktop Commander Suite products. It quickly gathers up the most critical events from your RDS channel event logs and other relevant event logs from multiple hosts, and lets you group, sort, and filter the data in whatever fashion you want. You can also research events online or quickly export them to CSV and Excel. To learn more, please watch this RDPSoft Channel Youtube video which demonstrates all of its features in depth: