NemetFox wrote:

The computers we have meet the requirements for NLA (Win 7 Pro for client, 2008 R2 for server). Using version 6.3.9600 of Remote Desktop Connection. Passwords are not expired.

What is the protocol version?

check your remote desktop settings, maybe they defaulted to allow connections only from computers running NLA

What client OS are you using? NLA has been around for quite some time and should be supported.

Also make sure your password isn't expired NLA enabled machines will not allow you to change your password on connect.

Only options available are Don't allow, or allow only on computers with NLA. NLA is what we want though.

The computers we have meet the requirements for NLA (Win 7 Pro for client, 2008 R2 for server). Using version 6.3.9600 of Remote Desktop Connection. Passwords are not expired.

We can get in fine using vSphere, but would prefer to use the Remote Desktop Connection.

Also we're able to get to our other servers with RDC.

NemetFox wrote:

The computers we have meet the requirements for NLA (Win 7 Pro for client, 2008 R2 for server). Using version 6.3.9600 of Remote Desktop Connection. Passwords are not expired.

What is the protocol version?

It's showing as 8.1 for me.

Also are you connecting via IP or hostname?

If IP try using the FQDN. Also double check the clocks on both machines.

Lastly, Disable NLA through the registry:

Text

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp Find the value SecurityLayer and change the data to 0 (that is a zero).

I've tried both FQDN and IP with the same result.

Clocks show the correct time, date and time zone on client and server.

I have security concerns about disabling NLA on the server, so I will not be doing that.

A colleague of mine is also working on this and is accessing the DC using vSphere, and we've noticed that it says it's on a Public network. We'll be changing that over to a Work network and I'llpost againabout howthat goes.

NemetFox wrote:

I've tried both FQDN and IP with the same result.

Clocks show the correct time, date and time zone on client and server.

I have security concerns about disabling NLA on the server, so I will not be doing that.

A colleague of mine is also working on this and is accessing the DC using vSphere, and we've noticed that it says it's on a Public network. We'll be changing that over to a Work network and I'llpost againabout howthat goes.

It should be set to domain network if its a DC. Double check the IP settings for DNS. If correct run dcdiag on the machine and resolve any errors.

NemetFox wrote:

A colleague of mine is also working on this and is accessing the DC using vSphere, and we've noticed that it says it's on a Public network. We'll be changing that over to a Work network and I'llpost againabout howthat goes.

Many times when this happens, restarting the 'Network Location Awareness' service will bring it back to the 'correct' setting(domain network).
Generally it gets set to 'public' if there is no DNS server available at the time the server/PC was rebooted

Surprise surprise, restart fixed it.

Thanks for all your help guys!