Saturday, November 28, 2015

Finding users who still have the RDP 7.1 client

As an RDS administrator, one of the frequent problems I deal with is the fact that users have difficulty launching an RDS RemoteApp from home. Maybe they receive an error message, maybe single sign-on isn't working to a pooled desktop collection, or possibly a RemoteApp launches, but there is display corruption of some sort.

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.
Event ID 1301 - Request for Redirection
Event ID 1301 - Request for Redirection
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:

  • 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
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:

  • Event Level: Verbose
  • Event Log: Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
  • Event ID: 1301
Creating the default view
Creating the default view
Now that the base view is created, check out the results. You should have a list of each time a user launches a RemoteApp or Virtual Desktop, regardless of RDP client version. There is no option to refine further using the default filtering options, so next we need to dive directly into the XML behind the view. Click on the XML tab at the top of the custom 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
The XML tab showing the query in XPath format
We're going to edit the query manually in order to display only events with an RDP Client Version of 4. But how do we know how to edit the query? What modifications need to be made? We can look at an existing event to figure out what fields are required. Open an existing event and go to the details tab, then select XML view.

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.
An event entry in XML view.
Open up the custom view, check the box to allow editing the query manually and paste the following code, replacing the current contents.

<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
Adding the custom XML to the query
Your query should look like the screenshot above. Click OK a few times to save the view, and then check out the results. Now your custom view will only display users who have launched a RemoteApp or Virtual Desktop from an RDP 7.1 client. Now that you have easy access to this information, you can target those users to upgrade to the RDP 8.1 client.

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.

$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
Grabbing the events with PowerShell
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!

1 comment:

  1. 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