SSL Certificate Revocation lists when using Internal CA

Recently, we were making some changes to eliminate some of the pop ups when using Remote Desktop Web Access.  Certificates on an RDP deployment have to be on point, the article over at is an awesome resource on the topic.

Well when using an Internal CA (certificate authority) for certificate signing, one thing that can be easily overlooked  is the CRL Distribution Point (CDP).  The Certificate Revocation List is essentially a text file of certificates that the issuing CA has revoked.  Certificate revocation allows for the quick repeal of an otherwise valid certificate.  If you take a look at the extensions in any SSL certificate, you’ll see an entry for the CDP (the method in how this list is distributed).

When using an Internal CA, by default it will use an ldap path for the CDP. And it will work just fine for domain joined computers.  However, non domain joined computer can’t navigate to the ldap path (lack of computer credentials) and the checking for the revocation list prompts an error.  If using RDP, you’ll get the familiar yellow error pop up stating as such.  Accepting the error will allow the connection to be made.

The fix is to configure the CDP to point to an http:// site  (its supposed to use Http, not https).  Using an https:// site will create a “chicken and egg” issue, how can you check the revocation status of a site that it itself might be on that list hosted by that very site. In other words, just use http, its supposed to be reachable. is another great resource that walks you through these steps.  Configure the http CDP and then you’ll have to reissue the certificate in question.  Reapply to whatever resources and now non domain joined won’t get prompted for that revocation error!

Happy troubleshooting,


james gonzales / June 13, 2016 / Active Directory, Certificates, Remote Desktop Services / 0 Comments

Server 2012R2 RDP sessions disconnect at periodic intervals

When users get disconnected from a Remote Desktop Server, the cause can be a hundred different things.  Maybe a blip on their internet connection, or a wayward GPO, or incorrect licensing.  Do a quick google search and more than likely you will read 50 different posts with 50 different causes.

A little bit about the RDP environment in question:

All Server 2012 R2, all licensed (windows and RDS CALs, all updated fully, etc)

1 RD Gateway (properly installed certificates)

1 RD Web Access (role installed on same machine as RD Gateway

1 RD Connection Broker

1 RD Session Host in collection

For us, we had a customer who had a seemingly unique problem, with a not so unique symptom.  Users (about 10 total) would get disconnected, one by one, every 700 seconds.  (700 seconds was the time connected in the event log).  Their session would go black and the “Reconnecting…” box would pop up, and then the session would reconnect a couple of seconds later.  This happened to all users every 700 seconds or so, give or take a few seconds. During the time they were connected, there were no problems to report, other than the aforementioned issue.

All users were using different flavors of Windows, 7, 8,8.1 at varying patch levels.  The only unifying characteristic was their LAN.

We could see the event id signaling the disconnects, but just reason codes were given. (which we never found out what they mean). This was the error on the Session host, TerminalServices-LocalSessionManager event id 40


We could also see the corresponding disconnect messages on the RD Gateway. The session duration always ranged in 700-706 range, for every user. The connection protocol was UDP and sometimes HTTP.   TerminalServices-Gateway event id 303.


We eventually made our way to their firewall to look at their rules.  They had a HTTPS proxy rule setup, but it wasn’t really doing anything.   The HTTPS web blocker feature was expired but the rule was still in place.(remember, since we are using a Gateway, RDP goes over port 443 instead of 3389)

And of particular note, in the HTTPS proxy rule, there was a “Idle Timeout Timer” set to 10 minutes.  I removed the rule, and everything is now working!  Sessions can now stay connected longer than 10 minutes at a time.

I figure, 30 some seconds for the firewall to signal the connection is idle, 10 minutes of idle time for disconnect, 30 some seconds for RDP to signal network connectivity lost, and that would roughly equal the 700-706 seconds session duration we were seeing.  Not exact but you see where I’m going with this.

So, if the user was in an active RDP session, why would the firewall treat it as idle?  Well my best guess is this. The gateway (and RDP for that matter) doesn’t use just 1 protocol stream in Server 2012 R2.  It can use a few depending on the version of the client being used.  You can verify this by the monitoring tab in the Remote Desktop Gateway Manager tool on the gateway. Once the connection is made, additional streams are opened and my guess is they were timing out (HTTPS proxy idle). The session then freaks out and the user is disconnected.  Only to be reconnect again and the timer reset.  Without getting into the underbelly and details of the protocol itself, this is my best guesstimate.

The secondary ports that RDP uses is discussed here

I hope this post helps someone along the way, I found a whole bunch of posts out there regarding disconnections.  But most ended up being abandoned or no solution ever found.

Happy troubleshooting!


james gonzales / December 2, 2015 / Remote Desktop Services / 0 Comments

Removing pinned shortcuts from taskbar Server Manager and Powershell on Server 2012 R2

Sometimes, it’s those little nuances that can drive you crazy.  Most of the time our templates are pretty spot on but every now and then, we need to create a RDS machine from scratch. In doing so, all those little tweaks have to be rediscovered.   One such tweak is removing the Server Manager and Powershell shortcuts from the taskbar on Server 2012 R2 for non-admin RDP users.

Now, prior to 2012R2, there was a Group Policy setting to remove these items.  However, in R2, it seems that is gone (I havn’t been able to find it again).  There was also another way, by changing permissions on the source .lnk so that users didn’t have permission to the shortcut and it wouldnt be copied over to their profile upon creation.  But again, in R2 the exact paths got changed and muddled, so where exactly do you change permissions?

I googled the question and eventually ended up at which solved the issue for me.

By deleting the source .lnk from C:\ProgramData…, a new user won’t get the pinned shortcut.  Of course, it won’t retroactively apply either, but helps when first setting up the server.  Also, it won’t create the shortcuts for admins either, but surely, hopefully, your admin users will be able to do that manually =)

james gonzales / October 22, 2015 / Remote Desktop Services / 0 Comments