Blog: RDP

There was a 2012 R2 server I had configured and been using to test with for several months. After a few months, I could no longer connect to the server with remote desktop. I could ping the server and browse the admin shares across the network. I logged in and verified the Remote Desktop Services service was started and enabled.

Looking at the event log, I could see that every time I tried to remote in, the System log was adding event 36870 – “A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.”

More research seemed to indicate that this was a problem with the Remote Desktop certificate on the system.  I opened the certificate manager for the local system, backed up the remote desktop certificate and then deleted it the certificate store.  Now, when I restarted the Remote Desktop Services service, I started getting a different event 1058 – “The RD Session Host Server has failed to replace the expired self-signed certificate used for RD Session Host Server authentication on SSL connections.  Access is denied.”

More research pointed me to checking the permissions in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.  When I tried to set a permission on the folder, it propagated to all the files within except for one which said that access was denied.  I was unable to modify the permissions on the file itself even though I was logged in as the local administrator.

Taking a chance, I stopped the Remote Desktop Services service and was able to delete the file with the permission issues.  I restarted the Remote Desktop Services service and observed that a new Remote Desktop certificate had been created as well as a new file in the MachineKeys folder.  I was now able to connect to the server using remote desktop.

PROBLEM: COM port redirection is not fully functional via ICA connection. The COM port redirection was occurring (determined by running a net use cmd within the Citrix session) and print was being sent to the printer, but the output on the printer was gibberish – symbols, etc.  In troubleshooting the issue, it was discovered that the COM port redirection was completely functional via an RDP session, and the COM port redirection was fully functional within an ICA session once an RDP session was initiated and information was sent to the redirected COM device. However, upon reboot of the client device, COM port redirection was no longer fully functional within an ICA session.[more]

CAUSE: According to the KB article, http://support.microsoft.com/kb/112841/en-us, the COM port settings for a device can be stored in two different locations – within the Control Panel and within the Command Prompt interface.  The settings used by the device will depend on how the application communicates with the port – via the Control Panel\registry or directly with the COM port via the command interface.  The settings are not dependent on each other and can be changed independently of one another.  COM port redirection via ICA and RDP use the settings set within the port itself.  To add to the complexity, it appears that the RDP protocol automatically sets the client device port settings when a session is initiated to match the settings for the COM port on the host server.  This was the reason that the application was working via RDP and any subsequent ICA session.

MODE.COM queries the port directly.  Default settings (Windows XP, 7E) are the following (MODE.COM did not seem to be available within XPe):

Status for Device COM1:

• Baud: 1200
• Parity: Even
• Data Bits: 7
• Stop Bits: 1
• Timeout: OFF
• XON/XOFF: OFF
• CTS handshaking: OFF
• DSR handshaking: OFF
• DSR sensitivity: OFF
• DTR circuit: ON
• RTS circuit: ON

Applications reset the mode of the COM port(s).  If, for example, you start Terminal and reset COM1 to 14400 baud, 7 data bits, odd parity, then exit Terminal, the new settings remain in effect until the computer is shut down.  Upon rebooting, the default settings are once again in effect.  The Control Panel settings, on the other hand, affect the registry.  An application that is appropriately written can query the registry for these values and use the Control Panel settings.  The default settings in the Ports option of Control Panel\Device Manager are:

Settings for COM1:

• Baud Rate: 9600
• Data Bits: 8
• Parity: None
• Stop Bits: 1
• Flow Control: None   

SOLUTION: You can manually set the COM port settings by using this command: “Mode COM1: 9600,n,8,1”. However, when you restart the system, you will find the settings revert back to the default. To resolve the issue, create a startup task or place a batch file in startup that sets the COM port to the required settings. 

Example: C:\windows\system32\mode.com com1: 9600,n,8,1

During the installation and setup of VMware Capacity Planner we ran across a couple of servers that were not receiving performance data. After looking at GPOs and permissions, the problem still existed. It was discovered faulty performance counters could cause the problem. We connected via remote desktop to the problematic servers and opened the performance monitor. There was no data present and all the monitor names were changed to numeric values. This meant the performance monitors were corrupt causing the problem with VMWare Capacity Planner. The bank staff said they would address the problem.

I recently ran into a situation wehre Windows 2003 SBS was refusing remote desktop connections completely because two people were logged in remotely. I had logged in to a customer’s Windows 2003 SBS to help troubleshoot various connectivity.  I needed to have the customer also be able to RDP to the server, but when they tried to connect to the server it said that it could not be reached.  This server was not running terminal services on it, which means that the server is limited to having two remote connections at a time.
 
Normally, on a regular Windows 2003 Server (not SBS), it will go ahead and allow the remote desktop connection to be established, but it will display an error message at login stating that the maximum number of sessions on the server has been reached.  In this case, it refused connections entirely for remote desktop, but the server could be pinged. What I didn’t realize initially was that there was another person logged into the server besides me.  When I logged off, then the customer could immediately contact the server again.
 

This is pretty straight forward, but comes up from time to time.  A customer called to say their screen is smaller (lower resolution) than it used to be after Windows Updates.
 
Notes about Terminal Server resolution:

• You cannot change the resolution while in a terminal server session.
• The Display tab in the RDP options before you connect is usually set to “Full Screen”.  It can be set to lower resolution sizes than your current PC or Thin Client settings, but not higher.

In order to fix the problem, close the terminal server connection.  Change the resolution size as needed on the local PC or Thin Client, and then reconnect to the terminal server.  The new resolution settings will be passed through automatically if the display settings are still set to “Full Screen”.

One of our network consulting clients complained of being unable to use remote logon for shadowing sessions on a terminal server.  Upon testing I was able to use remote logon fine.  I did eventually find a user that I could not shadow.  I received an error, “Access is Denied” when attempting to use remote logon with their session.   Further investigation found that users that had two monitors setup and were using both with remote desktop 7 were the ones I could not remote to.  This had been confusing because sometimes it appeared to work and others it did not.  The customer was in the process of moving all users to a two monitor setup so the problem had been progressively getting worse.  Various forums and Microsoft articles referenced this problem.  Shadowing of dual monitor sessions is not currently supported by Remote Desktop Services Manager.

As part of a Citrix environment overhaul, another network engineer and I discovered a very frustrating limitation of using group policy with Citrix published applications. The problem centers around the inability to apply IE group policy settings using loopback mode processing. I'll warn you ahead of time, there are lots of details so hang with me....and remember this is all going to converge at the application of group policy. Here is what we found...

When a user with an empty roaming profile (new user) has their profile created as the result of running a published application, the user portion of the registry hive (ntuser.dat) is not created in its entirety. The users' hive can be loaded and a number of noticeable differences exist between it and the default user registry hive. If the user profile is created by logging on locally (console), via RDP to the same machine, or via Citrix published desktop on the same machine, the profile that is created is complete. I was unable to find any noticeable differences between the default user registry hive and that of the newly created roaming user profile when the profile was created in this way. Additionally, once an incomplete profile had been created via published application session, the profile could NOT be "fixed" by logging on via RDP or published desktop. Once the registry hive was created in an incomplete fashion, it seemed to be affected from then on. So why are we talking profiles...I thought this was about group policy? Well, it is...I'm getting there. [more]

We found that users running published applications did not have group policy correctly applied. We were trying to set policies on Internet Explorer using Internet Control Panel settings in the user portion of the GPO. Specifically, IE security zone settings such as trusted and intranet sites would not apply. We also noticed that each security zone seemed to be locked. In the Security tab of the Internet Options dialog box, all the icons were the same....blue IE symbol with a lock next to it. The "Sites" button and the "Custom Level" button were also grayed out. So, here is the where the profile problem merges with the group policy problem. I found that by manually exporting certain keys from the default user profile registry hive under \Software\Microsoft\Windows\CurrentVersion\Internet Settings\ and importing them into in a incomplete user registry hive, I could fix the problem. That is, once the keys existed in the user registry hive that pertained to the settings I was trying to set via group policy, the policy was applied correctly...no issues. Makes sense right....if the group policy is setting registry keys in order to apply certain policies, it’s not going to work if the keys don't exist in the first place.

So things have come full circle. Group policy isn't working because the user profile is messed up. So why is the user profile not getting created correctly? Well, this is actually a Microsoft problem --> http://support.microsoft.com/kb/899270. And the script they provide doesn’t work…we tried it. Actually, there is more to the problem than that, but here is a summary of the information that we gathered. By design, Citrix published applications, remote applications in Windows 2008, and the "start this application on connection" functionality of RDP (mstsc.exe) running against Windows 2003 servers implement limited logon functionality so that the session footprint is smaller than a normal desktop session. Part of the "limited functionality" is that the user session does not start explorer.exe. So, any application that depends wholly or in part on explorer.exe could have issues. Some of the important pieces of functionality that explorer.exe implements are the following:

1. The run registry entry
2. The RunOne registry entry
3. Startup applications 

If you have ever noticed the small gray box that is displayed the first time you log on as a new user, you have seen the effects of explorer.exe running at session logon. It goes by fast, but it says something like "applying internet explorer customizations", "setting up windows media player..."...stuff like that. That little box is normally initiated by explorer.exe. It is called runonce.exe. What we found was that if we initiated runonce.exe in a logon script, the user was created correctly when running published application; thus, group policy was applied correctly as well. Testing also showed that this process could also fix a previously created broken user registry hive (ntuser.dat). All we had to do is add the following to our logon.bat file

start /MIN %windir%\system32\runonce.exe /AlternateShellStartup

Citrix has documented this problem in a support article (http://support.citrix.com/article/CTX104374) and they refer back to the previous MS KB listed above. Numerous forums threads exist on this issue and we were unable to find a resolution elsewhere that did not include scripting registry imports to the user profile at logon. This workaround seems to be a more flexible and reliable.

I had applied Windows updates to a customer’s Windows 2008 R2 server that had Microsoft Threat Management Gateway installed, and I could not RDP to the server after rebooting.  I connected to the server locally and could tell from netstat that the server was not listening at all on port 3389.

It turns out that there was a problem with the RDP-tcp protocol not working because it was configured to listen on all available network adapters.  This being a proxy server, it had internal and dmz network adapters.  To fix this issue, set the RDP-tcp protocol to only bind to the internal network adapter. [more]

• Open Remote Desktop Session Host Configuration.
• Open th/e properties of the RDP-Tcp protocol underneath Connections.
• In the Network Adapter tab, change the setting from “All network adapters configured with this protocol” to the specified internal network adapter and hit apply.
• On the Actions bar to the right, click Disable Connection and then Enable Connection to reset it.
• Run netstat to confirm that the server is listening on port 3389 again.

I recently worked on a problem where a user had a PC with a network printer added utilizing HP’s Univeral Print Driver. The user RDP’s to a Terminal Server and this “local” network printer is redirected through to their Terminal Server Session. When the user attempted to print to the redirected network printer, they received the following error message:

"The selected printer 'HP Universal Printing PCL6' is not a supported HP device"

Printing from the PC to the network printer as well as printing from the TS directly to the network printer worked. [more]

Knowing that the UPD utilizes bidirectional communication when printing, it is my best guess that this was not working via the TS port that was created when the redirected network printer was auto-generated at login. This behavior does not occur with all model printers.

I enabled and configured SNMP with an established SNMP community name on both the network printer port on the print server as well as through the Web Interface on the network printer. Once that was done, printing via the redirected network printer worked.