An extremely common problem I see is that many users with Windows 7 at home have not read our instructions and installed the RDP 8.1 client. Microsoft was able to add some pretty cool functionality and fix a ton of bugs with the RDP 8.1 client - at this point, it's basically a must-have piece of software for RDS administrators. If a user if having an RDS issue and they don't have the RDP 8.1 client, that's the first thing I recommend installing.
The challenge is how to determine when a user is still using the RDP 7.1 client, especially in remote access scenarios where you can't look at their PC or run a report using SCCM. I've found one place in the RDS logs where you can grab this information and I'll be showing a couple of different methods on how to easily search out and grab that info.
The Event Log
On your Connection Broker servers, you can browse to the Applications and Services Logs > Microsoft > Windows > TerminalServices-SessionBroker-Client > Operational log and search for Event ID 1301. This event is logged anytime the RD Connection Broker receives a request for redirection from a user. Interestingly enough, it also logs the RDP Client Version, though it's a bit misleading, as you'll see.
You'll notice in the screenshot above, in the message of the event, an RDP client version is listed. This screenshot was taken from a client connecting with the RDP 8.1 client on a Windows 7 device. So why does it say RDP Client Version 5? Honestly, I'm not entirely sure why Microsoft lists the version numbers the way they do, but here is what you need to know about this event ID:
![]() |
Event ID 1301 - Request for Redirection |
- RDP Client Version 4 means the user has the RDP 7.1 client installed.
- RDP Client Version 5 means the user has the RDP 8.0 client or above installed.
In the screenshot below, you can see a client connecting with the RDP 7.1 client. This is logged on the RD Connection Broker as RDP Client Version 4.
![]() |
RDP Client Version 4 signifying the RDP 7.1 client is in use |
Building a custom view in Event Viewer
It's easy enough to build a custom view in Event Viewer, and search for Event ID 1301 in the TerminalServices-SessionBroker-Client/Operational log. The only problem with this method is that you'll show any redirection requests, whether they are using RDP Client Version 4 or 5. You would still have to resort to searching through the view to find RDP 7.1 clients. What if you only want to see events with RDP Client Version 4?
We'll start by creating the custom view above. In event viewer, create a new custom view with the following parameters:
We'll start by creating the custom view above. In event viewer, create a new custom view with the following parameters:
- Event Level: Verbose
- Event Log: Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
- Event ID: 1301
![]() |
Creating the default view |
When you are looking at the XML tab, you are seeing the query in XPath form. If you look closely at the code, you can see all of the criteria that was already specified using the graphical interface. When you build a custom view, the options you select get transformed into XPath code, and this is what event viewer reads to grab and display the correct events for the custom view.
![]() |
The XML tab showing the query in XPath format |
This shows the contents of the event entry in XML format. Everything under the System node is specific to this event. We're interested in the UserData section, specifically the parameters. Param1 is the domain, param2 is the user, and param3 is the RDP Client Version. So we need to modify the XPath code of the view and only show events where param3 is equal to 4, indicating an RDP 7.1 client in use.
![]() |
An event entry in XML view. |
<QueryList> <Query Id="0" Path="Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational"> <Select Path="Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational">*[System[(Level=5) and (EventID=1301)]] and *[UserData[EventXML[(param3=4)]]]</Select> </Query> </QueryList>
![]() |
Adding the custom XML to the query |
Now let's PowerShell it!
A custom view in Event Viewer is great if you want to take a quick glance or search for a specific user. But if you are looking to harvest larger amounts of data or look for trends, custom views are limited. Fortunately, we can use PowerShell to gather the exact same information the custom view is pulling using the same XML code we used for the view!
The Get-WinEvent cmdlet, which pulls events from the event logs, supports using XML to query the event log. Take the XML code we used for the custom view, store it as a here-string, and pass the variable into Get-WinEvent using the -FilterXML parameter.
When we run this code, Get-WinEvent will pull all events from the TerminalServices-SessionBroker-Client/Operational log with an event ID of 1301, event level of verbose, and whose param3 is set to 4, as shown below.
The Get-WinEvent cmdlet will return each item as an object, so you can dive deeper into the data by using some of PowerShell's built-in filtering functionality. Or maybe you want to easily export the list for a management report using the Export-CSV cmdlet? With PowerShell and objects, the possibilities are endless! And now you are armed with the information you need to rid your environment of the RDP 7.1 client. Enjoy!
The Get-WinEvent cmdlet, which pulls events from the event logs, supports using XML to query the event log. Take the XML code we used for the custom view, store it as a here-string, and pass the variable into Get-WinEvent using the -FilterXML parameter.
$filterxml = @" <QueryList> <Query Id="0" Path="Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational"> <Select Path="Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational">*[System[(Level=5) and (EventID=1301)]] and *[UserData[EventXML[(param3=4)]]]</Select> </Query> </QueryList> "@ Get-WinEvent -FilterXML $filterxml
When we run this code, Get-WinEvent will pull all events from the TerminalServices-SessionBroker-Client/Operational log with an event ID of 1301, event level of verbose, and whose param3 is set to 4, as shown below.
![]() |
Grabbing the events with PowerShell |
Wonderful explanation, thank you. But what's really strange is a very different behaviour with MacBooks running Client Version 4 or 5: our business application runs 10 times faster with the older client 4 than with the newer version 5.
ReplyDelete