rds

RDS and the Case of the Mistaken PKI OID

Richard Green on

Earlier this morning, I was working with our support team to work out an issue they were having in an environment where Remote Desktop Services had stopped working. Trying to connect to a server via RDS simply failed with a Network Level Authentication warning, strange, given it was a domain environment and everything should be trusted and all good. The issue started life as support seeing Event ID 1058 and Event ID 36870 errors in the event log and they had been looking at https://blogs.technet.microsoft.com/askperf/2014/10/22/rdp-fails-with-event-id-1058-event-36870-with-remote-desktop-session-host-certificate-ssl-communication/ for guidance to this point with no success.

I quickly discovered that a GPO had recently been implemented that enforced NLA for RDS and also assigned a certificate template to use for Remote Desktop instead of the default self-signed version. I hopped onto the certificate authority to check out the certificate template that had been configured and compared it to the recommendations of the Microsoft article for assigning certificates to RDS sessions at https://blogs.technet.microsoft.com/enterprisemobility/2010/04/09/configuring-remote-desktop-certificates/ as this is an article I have referred to before and know it works.

Read more…

Non-Published Office 365 Directory Sync with Azure ExpressRoute

Richard Green on

In one of my recent sessions with a customer, the customer expressed an interest in protecting their communication between Office 365 and their on-premise environment for the purposes of making their directory synchronization server traffic invisible to the outside world. This got me thinking about Azure ExpressRoute which we know can provide very fast connectivity between your on-premise environments and Azure if you are using a supported MPLS network provider.

The customer in question is using Level 3 Networks as their carrier and Level 3 are on the supported carriers list for ExpressRoute on the ExpressRoute Technical Overview page at https://msdn.microsoft.com/en-us/library/azure/e224be0a-d7b2-4514-b868-86d61cee0ead#bkmk_Connection so I looked into it a little bit further as this was a really interesting proposition – to have Office 365 SaaS managed productivity with Exchange, SharePoint and Lync but to have all of the sync traffic traffic privately routed over ExpressRoute so that you weren’t passing any of that data over the public network (albeit encrypted with HTTPS SSL).

When I looked further, I found that on the ExpressRoute FAQ page at https://msdn.microsoft.com/library/azure/dn606292.aspx it explicitly defines which Azure services are accessible over an ExpressRoute connection and Azure Active Directory (AAD) is not listed nor is anything in relation to Office 365.

Unfortunately, it seems that this isn’t possible right now but it would be nice to see something added in the future to allow AAD to be access over ExpressRoute to allow us to hide and conceal our ADFS or AADSync traffic as this may well answer a security question that some more conscious customers have. The other reason this would be nice as it means we can have our internal users accessing their mail and SharePoint via the ExpressRoute connection so they will get a faster experience that over the companies internet link. Right now however, the best use case for ExpressRoute in my opnion is Azure RemoteApp, allowing you move some or all of the Remote Desktop Services terminal server farms that you may have to Azure and offload your RemoteApp applications to the cloud.

The Case of Remote Desktop Services Random Disconnections

Richard Green on

If you are running Windows Server 2008 R2 servers and you find yourself randomly being disconnected from RDS (Remote Desktop Services) sessions on your servers, or sometimes find your servers completely inaccessible you could be impacted by an issue as a result of servicing order (AKA, the order in which you install Windows Updates). The issue effects servers running Windows Server 2008 R2 with Service Pack 1 and with KB2667402 (Update for Terminal Service Denial of Service Vulnerability).

This is something I thought I had written about already as it effected us in a big way at work due to the way in which our virtual machine images were compiled but it seems actually, I hadn’t.

In Windows Server 2008 R2 RTM, the file version of the rdpcorekmts.dll file in Windows Server 2008 R2 RTM is 6.1.7600.16952. In Windows Server 2008 R2 with Service Pack 1, the file version of the rdpcorekmts.dll file is 6.1.7601.17767 and the file version of the rdpcorekmts.dll file after installing KB2667402 is 6.1.7601.17828.

If as a result of servicing order, you installed the KB2667402 update prior to installing Windows Server 2008 R2 Service Pack 1, the file version of rdpcorekmts.dll is downgraded from the KB2667402 version number to the SP1 version number and the hotfix is in essence removed. This causes the Remote Desktop Services service to fail and terminate itself repeatedly as the service believes that there is an attempt to modify it’s files occurring and as a failsafe, shuts down remote access.

In order to resolve the issue, Microsoft re-released KB2667402 as KB2667402v2 which allows you to re-install the update after an installation of Service Pack 1 to bring the file version back up to 6.1.7601.17828 and to allow the Remote Desktop Services service to work again as normal. Trying to re-install the original release of KB2667402 will result in a message that the update is already installed and does not apply to this computer.

You can download the version 2 release of the update from the Microsoft Download Center at http://www.microsoft.com/en-us/download/details.aspx?id=29169. The update is 327KB and requests a reboot, however you can install the update and delay the restart by simply manually restarting the Remote Desktop Services service. You should still restart the server at some point in time though as the pending reboot will block operations such as installation of roles and features.

Media Center Auto-Start on Windows 8

Richard Green on

With my backend server update to Windows Server 2012, I was keen to get my media front-end up to Windows 8 also to take advantage of SMB 3.0 for improved performance of opening and accessing the media stored on the server. I rebuilt the front-end about two weeks ago, taking advantage of the free Media Pack upgrade prior January 31st. I had already tested the components I use to make my media center tick including Shark007 Codec Pack, MyMovies and MediaControl so I knew all was good.

After installing Windows, the software needed and configuring auto-login for the media center service account, I proceeded to copy the shortcut I used in Windows 7 to launch the Media Center application into the Startup start menu group for the account. In Windows 8, the Startup group can be found in %AppData%MicrosoftWindowsStart MenuProgrmsStart-Up. With the shortcut added, I restarted the machine to test the result.

In Windows 8, to help attract people to the new Start Screen, the Start Screen automatically opens at login of any account. What I found was that this screen would pop over the Windows Media Center application which is hardly seamless for a keyboard and mouse free front-end. Using the remote, I clicked the Desktop tile on the Start Screen and Media Center appeared as expected, but I couldn’t control it. The reason was that although the application was now visible, it didn’t have focus so any inputs were ignored. Attaching a mouse to the machine and clicking anywhere in the Media Center interface restored focus but short of writing an AutoIt macro to do that for me (which is a nasty hack) this isn’t what I wanted or needed.

Luckily, a colleague pointed me in the direction of a Group Policy setting used sometimes in Remote Desktop Services or kiosk computer scenarios where the Explorer interface is hidden and a default application launched in it’s place. The setting still existed in Windows 8, so I gave it a shot and guess what? It works perfectly. I’m in the fortunate position that I am using Windows Server 2012 Essentials in a domain scenario so I was able to apply the Group Policy from the server, however this fix will work equally well for a non-domain scenario.

The policy setting can be found under User Settings > Administrative Templates > System. The setting is named Custom User Interface.

Enable the setting and specify the name of the application you want to launch. In my case, it is %WinDir%eHomeeShell.exe /nostartupanimation /mediamode.

It’s highly recommended to use environment variables here and not local paths if you can as I have done above. This will also work for Windows XP, Vista and 7 along with working for XBMC, Plex and other media clients you may use besides Windows Media Center. The byproduct of this is that startup performance is actually improved as you are no longer waiting for the Explorer shell interface to launch, and it prevents a few processes from running on the machine, giving you a little more CPU and Memory available.

As you will see, I use a couple of switches with my Windows Media Center startup to control the behaviour of it, which I would also recommend. These two switches stop the animation of the Media Center logo upon startup which I find saves about a second in load times and the second enters Media Mode. In this mode, Media Center’s close and minimize buttons are disabled causing Media Center to always run full screen and cannot be closed unless you use the manual Exit Media Mode option in the menu.

In the next couple of days, I’ll try and get a YouTube video up demonstrating the process for configuring this setting both via Windows Server 2012 Essentials domain and locally using the Local Group Policy Editor.

Remote Desktop Protocol 8

Richard Green on

Just a real quick post to say that I noticed my desktop PC at home running Windows 7 had an optional update listed for Remote Desktop Protocol 8, the version included in Windows 8 and Windows Server 2012 natively.

The update is available for Windows 7 and Windows Server 2008 R2 with SP1.

The KB article for the changes and improvements in the protocol version at available at http://support.microsoft.com/kb/2592687.

The ky features appear to be support for VoIP applications via RemoteFX, Improved SSO for RDS Web Access, RemoteApp Reconnection. It’s also worth noting that Shadowing (Remote Control) of RDS sessions and Aero Glass Remoting are now deprecated, so if you are using Shared Session Virtualization as a VDI infrastructure, you might what to think about testing this update first if your users like their Desktop Experience RDS sessions.