Jason said:
On XP Pro, I could open an RDC from any other computer in the house
with ease. Now, I'm trying to get that to work with Win 7. The
"target" machine is running Win 7 Pro, the client trying to connect
is running Home Premium. I think I have done the steps properly to
allow the connection, yet it is always refused after about 20
seconds. There may be a Group Policy issue here, but I don't know
where to look. Any suggestions for debugging this?
In the Remote Desktop Client, are you using the "Browse" dialog to find
the remote host through discovery? When you browse your workgroup (the
same one as your local host), is the remote host listed in that same
workgroup?
Are you using the GUI app where you select computer and username (on the
remote host) or are you using a command line with parameters to specify
the target/remote host? See:
http://windows.microsoft.com/en-us/...ine-parameters-with-Remote-Desktop-Connection
Or are you using a previously save .rdp file for configuration
parameters of the remote host? Are you telling the GUI client to load a
previously saved .rdp file or double-clicking on an .rdp file? If using
an old .rdp file, have you tried just using the GUI client and entering
the info yourself without reusing old config data for the remote host?
Does the remote host have a username (account) defined on it with the
same name as the username (account) on the local computer where you are
running the RDP client? Are you logging on using a different username
(account) on the remote host? Is the account you are trying to use to
logon the remote host actually defined on that remote host? Is that
account defined on the remote host in the Administrators group or in the
Remote Desktop Users group?
Remote Desktop can be disabled via group policy. All policies are
merely registry settings. The Home edition of any Windows version does
not include the local/group policy editor. Policies are normally pushed
when logging into domains and Home hosts cannot participate in a hosts
(there may be hacks but they are not supported). Since they are
registry settings, some security software, tweaker, or user can modify
the registry to effect those policies. That you don't get an policy
editor to modify them in an app but have to edit the registry doesn't
mean policies are not enforced. They're just registry entries.
http://support.microsoft.com/kb/306300
But you won't have gpedit.msc (group policy editor) to check the policy
setting. You'll have to view the registry to go look there to see if
the policy was defined (registry changes don't require a policy editor,
a registry editor, or any particular app as there is a registry API that
any program can use to set registry values). I don't remember where are
all the policy settings that affect Terminal Services (and why I use the
group policy editor in a non-Home version of Windows). If I needed to
know where they are, I'd take a snapshot using an install monitor, make
the policy change using the policy editor, take another snapshot with
the install monitor, and compare the snapshots to see what changed in
the registry. Using a Google search, like:
http://www.google.com/search?q=terminal+services+policy+registry
finds articles (and others), like:
http://etutorials.org/Microsoft+Pro...Registry/Registry+Keys+for+Terminal+Services/
Those are registry entries defining the behaviors of Terminal Services
on the host where those registry entries are enforced. As for policy
entries, I thought they would be under some Policy registry key (e.g.,
HKLM\SOFTWARE\Policies, HKCU\Software\Policies).
Besides policies (whether you have an editor for them or not), another
reason you cannot connect is perhaps you didn't enable Remote Desktop
access (usability) on the remote host. I'm not at a Win7 host right
now. On WinXP, right-click on the My Computer desktop icon, select
Properties, go to the Remote tab, and make sure the "Allow users to
connect remotely to this computer" is enabled. If it is disabled, you
cannot connect there using RDP. This setting affects the following
registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
Data item name: fDenyTSConnections
Data item value: 0 = no deny (allow), 1 = deny (not allow)
Remember that this is a setting on the *remote* host to which you are
trying to connect. It affects inbound RDP connection requests. On the
host where you set this, it determines if that host allows incoming RDP
connections.
In the RDP client, under the Advanced tab, what mode do you use for
server authentication? No, not the default setting when you load the
RDP client but when you actually attempt the connection to the remote
host? If you're using an .rdp file to reuses a saved config, load it in
RDP and look here to see if you configured RDP to simply abort the
connection without prompt.
Under the Experience tab, what did you configure DURING the connection
for the connection speed? What resources did you enable for transfer
over the RDP connection?
Make sure the clocks are in sync on both hosts. If SSL is involved, it
passes datestamped tokens during the handshaking to establish an
encrypted connection. If the datestamps are off by a few minutes, one
end is going to think the token has expired. To secure the connection,
the handshaking has to complete quickly. You need to have the clocks on
both hosts within a couple minutes of each other (within a few seconds
would be better). The timesync service in Windows doesn't sync your
clock at often enough intervals. Get a clock sync utility on all your
hosts.
http://technet.microsoft.com/en-us/magazine/ff458357.aspx
When you are through with an RDP session, do you actually logoff that
RDP session or do you just exit the RDP client? If you just exit the
RDP client then you haven't actually exited your RDP session and it is
still active. Depending on how many concurrent RDP sessions are allowed
per host, you trying to reload the RDP client and login might result in
exceeding the concurrent session count limit (I think it's 2 on
workstations). You either have to go to the remote host to kill those
still-existing RDP sessions or you have to use the admin feature of RDP
(from the command line) to get an RDP-admin session that will let you
kill the other existing RDP sessions. It has been way too long since I
had to use admin mode with RDP but do remember that way too many times
the RDP users would just kill the RDP client rather than logout of their
RDP session. The result was that all the concurrent RDP sessions got
used up and were still active. I could go to the remote host (if it was
in another room or floor in the same building) to kill off the lingering
RDP session but that was a hassle and not doable when the remote host
was off-site, like in another state. I had to use admin mode in an RDP
session to get onto the remote host where I could then kill off the
abandoned RDP sessions. See:
http://www.mydigitallife.info/how-t...op-terminal-services-connections-or-sessions/
There are other articles describing how to terminate lingering RDP
sessions but most require that you are connecting to a Terminal Services
host (a Windows server host) for availability to their TSC tools. As I
recall, and for the crippled TSC available on workstation versions of
Windows with the 2-session limit (plus admin session), I probably just
go onto the remote host to reboot it which killed off the lingering and
abandoned remote sessions. Disconnecting your RDP session or killing
the RDP client does *not* terminate the RDP session on the remote host.
For example, you might want to disconnect for now but reconnect later so
you're back at the same place you were before (providing no one had
physical access to the remote host to change its state). You might
start a long program compile on the remote host, disconnect, and
reconnect later to check if the compile has finished. Disconnecting
does NOT end an existing RDP session! You can disconnect using the RDP
client, powering down your local host, or clicking the X titlebar button
at the top of the RDP screen (showing the remote host). Your session is
still active and counts against the maximum concurrent session count.
With many users trying to share the same remote host, users that
regularly disconnect, get warned after having to terminate their
abandoned session, and ignoring the warnings were removed from access to
the remote host until they talked with their manager and they convinced
us that further abuse would not occur from this user. Sorry, I don't
remember the behavior of the local RDP client that you use when it
encounters a remote host where all of its maximum concurrent session
counts have been consumed.
