I recently was working with a client that had an odd, yet steady issue – remote control of desktop sessions from the 2008 R2 Remote Desktop Services Manager mmc console would disconnect the remote user when the administrator ended the session shadow.
After some research related to the issue, I found this to only occur with Windows XP RDP clients. Vista or 7 clients had no such issue.
Furthermore, it seemed to be related to some sort of RDP compression algorithm change. The default in R2 doesn’t play well with XP clients unless a hotfix is applied.
Instead of the hotifx from Microsoft (sorry…can’t remember the KB at this time!), just set the RDP listener to use a different compression method. Set it as shown below – click the thumbnail for the complete image.
After the change is applied, you will once again be able to shadow and disconnect from RDP sessions with no troubles!
Just when you believed you could trust that Microsoft stuff was case-insensitive when it came to virtually all kinds of sys admin tasks, MS dev guys show you a thing or two.
Recently ran into this bizarre error message when a user utilizing TS 2008 RemoteApp Office 2007 applications (namely Word, Excel) – “This RDP file has settings that cannot be overridden by command line. The remote connection cannot be started.”
What does that mean, you ask? Good question. This is Microsoftease for “we decided not to accept any extensions for remoteapp association other than those listed in the .rdp file”.
If you break open a .rdp file association for RemoteApp (i.e. the “fancy” icon created for Excel that really just launches Excel on an RDP session), you will see a list of extensions which get created when you publish an MSI package for the RemoteApp. This creates the magic for launching a local Word document and having it really open on the TS box when you have no local installation of Word.
I recently had a challenging experience with Windows XP clients using single-sign-on (SSO) for terminal server (TS) 2008 RemoteApp.
After Windows XP service pack 3 is applied, you are able to “turn on” the feature by following an article such as this…Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3. Note that while the article says you can’t control the client’s settings for SSO servers, you can…if you upgrade your group policy objects on your sysvol share and use Vista or Windows 2008 to manage group policy! You must follow the article to enable SSO, but you can control which server connections make use of it via a GPO.
This magic is already present in Vista and 7 when used as TS clients for RemoteApp.
My experience was different, as I applied the proper registry tweaks…but my RemoteApp window was still prompting users for login to the TS environment instead of merely passing the username/password on!
After banging my head on my desk for awhile, I finally “googled” the right combination of words to find a nifty hotfix for credssp and the exact issue I was experiencing!
Behold (it is properly named!) – When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server.
I created a batch file to apply both hotfixes silently at start up…seems to do the trick…the magic now works as stated!