Subscribe to Windows IT Pro

 

Get Newsletters

  • Get the Latest News
  • Product Updates
  • Helpful Tricks
  • Productivity Tips

Subscribe Now!

January 22, 2009 12:00 AM

Registry Tweak Restores Connection to a Remote Windows 2008 Server

Use the registry to change remote desktop options
Windows IT Pro
InstantDoc ID #100981
Rating: (1)

I recently faced a problem when trying to connect to a remote Windows Server 2008 server. I initially tried to connect with Remote Desktop Connection but was unsuccessful. Next, I tried to connect with the Microsoft Management Console (MMC) Remote Desktops snap-in, but the session was immediately disconnected. A quick ping test revealed that the server was running, so I decided to see whether I could use the Server Message Block (SMB) protocol to connect to an administrative share (C$). I successfully connected to the share.

Because the Server 2008 machine wasn't a critical server, decided to use the Shutdown command from my desktop to remotely shut it down. After rebooting, I tried both the Remote Desktops snap-in and Remote Desktop Connection with no luck. However, this time I received the following error message that proved helpful: The remote computer requires Network Level Authentication, which your computer does not support.

I don't use Network Level Authentication (NLA), so my Server 2008 machines are configured to allow connections from computers running any version of Remote Desktop Connection. (Curiously, even Remote Desktop Connection 6.0 doesn't support NLA on Windows XP.) However, for a reason I couldn't figure out, my remote server had reconfigured itself to accept only NLA RDP connections.

Physically visiting the remote Server 2008 machine to reconfigure the relevant option wasn't feasible, so I searched for an alternative. After I investigated some solutions, I had an idea: I'd try to tweak the remote server's registry to change the option.

After some research on the Internet, I found a blog—"Programmatically Determining Terminal Server Mode on Windows Server 2008"—that discusses remote desktop registry settings. So I opened regedit and connected to the remote server's registry. I then navigated to HKLM\System\CurrentControlSet\Control\Terminal Server and verified that fDenyTSConnections entry was already set to 0.

The SecurityLayer entry under HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp was already set to 1, but the UserAuthentication entry was set to 1. That's the reason I couldn't connect. I changed the value to 0.

After making this registry tweak, I tried to connect the remote server. This time, I successfully made the connection.

Related Content:

ARTICLE TOOLS

Comments
    There are no comments to display. Be the first one!
You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

White Papers

Get your Windows 7 deployment off to the right start by implementing PC lockdown. A locked-down environment is easier and cheaper to support since users are less likely to make unnecessary changes to the core system configuration - read more here!

Essential Guides

Is your iSCSI "lossy"? The reality is that most off-the-shelf Ethernet hardware deployed for iSCSI can lose packets, resulting in slow performance or application downtime. Learn how to assess your current iSCSI infrastructure and engineer an advanced iSCSI SAN infrastructure.

Web Seminars

What's the best way to keep your network safe from malware? In this web seminar, security expert Greg Shields suggests an alternative method to the traditional blacklisting approach that is common with anti-virus and anti-malware solutions.

eLearning Series

We bring the experts direct to you to share their real-world perspective and expertise. During each event, three sessions stream in real time, so you can learn, ask questions, and get solutions.
Upcoming event: Getting the Most with Exchange 2010 with Paul Robichaux

Subscribe to Windows IT Pro!

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.