PowerShell Problem Solver: Active Directory Remote Desktop Settings

Posted on June 25, 2015 by Jeff Hicks in PowerShell with 0 Comments

During my recent PowerShell workshop in Finland, an attendee asked about Active Directory cmdlets from Microsoft in regards to remote desktop user settings. Although you can readily see the settings in Active Directory Users and Computers, Get-ADUser doesn’t retrieve them. I haven’t worked with Remote Desktop Services in quite a while, but I told him I’d look into this long-standing problem.

Let’s look at the problem. In Active Directory Users and Computers, you might have a setting like this:

Active Directory Users and Computers settings. (Image Credit: Jeff Hicks)

Active Directory Users and Computers settings. (Image Credit: Jeff Hicks)

I don’t have a Remote Desktop server, so I’m just improvising values. You would think that when you run Get-ADUser, you would see these properties somewhere.

But you don’t. However, if you happen to be using the ActiveRoles cmdlets from Dell (formerly part of Quest Software), then you can easily get these settings.

Using the ActiveRoles cmdlets from Dell. (Image Credit: Jeff Hicks)

Using the ActiveRoles cmdlets from Dell. (Image Credit: Jeff Hicks)

What’s going on here?

After a bit of research, I discovered this is a long-standing issue that seems to originate with a design decision made by the Terminal Services team. Instead of populating the user account with appropriate properties, they elected to store the information in a blob that’s part of the UserParameters property.

The UserParameters property. (Image Credit: Jeff Hicks)

The UserParameters property. (Image Credit: Jeff Hicks)

That’s unfortunate for us or at least those of us who don’t want to have to write complicated code to decode this data. I looked, and I found examples and thought about converting them to PowerShell, but it would be a ridiculously complicated process. Quest’s developers took the time to write the necessary code to extract the information. I don’t have that much time.

Instead, we can revert to some old-school techniques to get this information. This requires traditional LDAP connections to a domain controller. First, we need to create an ADSI object for the user account.

Creating an ADSI object for the user account. (Image Credit: Jeff Hicks)

Creating an ADSI object for the user account. (Image Credit: Jeff Hicks)

By using the COM object, the terminal services properties are easily retrieved.

Retrieving the terminal services properties. (Image Credit: Jeff Hicks)

Retrieving the terminal services properties. (Image Credit: Jeff Hicks)

I can also easily change them.

As you can imagine, this would be a lot of work to do manually, so I wrote a function to get remote desktop settings from the ADUC tab that I’ve been showing you.

Sponsored

To use the command, you can either specify a samaccountname or a distinguishedname. I wrote it so that you could use it in conjunction with Get-ADUser.

Using the Get-rDUserSetting function in Windows PowerShell. (Image Credit: Jeff Hicks)

Using the Get-rDUserSetting function in Windows PowerShell. (Image Credit: Jeff Hicks)

I always encourage people to write tools that can take advantage of the pipeline.

Using our function in the pipeline. (Image Credit: Jeff Hicks)

Using our function in the pipeline. (Image Credit: Jeff Hicks)

The function doesn’t have much in the way of help, but you can specify a search path if searching by account name. You can also specify a domain controller.

Of course, you need a corresponding command to set these settings.

Normally I’m not a big fan of parameters that take Boolean values, but it was the simplest solution in this case. Now I can easily set remote desktop settings for multiple user accounts.

You might also need to configure settings from the Sessions tab. Those settings can be set the same way. You can either modify my functions or write your own. The property names are:

  • MaxConnectionTime
  • MaxDisconnectionTime
  • MaxIdleTime
  • ReconnectionAction
  • BrokenConnectionAction

The time settings are in minutes.

Sponsored

I would recommend putting these functions into a module. This is definitely something you will want to test in a non-production setting.

Sponsored

Tagged with