Remote Destop Connection trouble

Discussion in 'alt.windows7.general' started by Jason, Jun 25, 2012.

  1. Jason

    Jason Guest

    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?

    Thanks,
    Jason
    Jason, Jun 25, 2012
    #1
  2. Per Jason:
    >There may be
    >a Group Policy issue here, but I don't know where to look. Any
    >suggestions for debugging this?


    Dump RD in favor of TeamViewer.

    I'm using it on XP boxes, Windows 7 boxes, a Vista box, an iPod,
    and an iPad. Seems like about five years now and I never even
    considered going back.

    Faster/easier connections, more options, vastly superior IMHO....
    and the price is right for the freebie version.

    --
    Pete Cresswell
    (PeteCresswell), Jun 25, 2012
    #2
  3. Jason

    s|b Guest

    On Mon, 25 Jun 2012 14:29:38 -0400, (PeteCresswell) wrote:

    > Dump RD in favor of TeamViewer.


    Or UltraVNC.

    --
    s|b
    s|b, Jun 25, 2012
    #3
  4. Jason

    VanguardLH Guest

    Jason wrote:

    > 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.
    VanguardLH, Jun 25, 2012
    #4
  5. Jason

    Jason Guest

    On Mon, 25 Jun 2012 14:29:38 -0400 "(PeteCresswell)" <> wrote
    in article <>
    >


    > Dump RD in favor of TeamViewer.
    >
    > I'm using it on XP boxes, Windows 7 boxes, a Vista box, an iPod,
    > and an iPad. Seems like about five years now and I never even
    > considered going back.
    >
    > Faster/easier connections, more options, vastly superior IMHO....
    > and the price is right for the freebie version.


    Thanks! It works fine. It seems a bit slower with screen updates than I
    recall, but that may just be me.
    Jason, Jun 26, 2012
    #5
  6. Jason

    Jason Guest

    On Mon, 25 Jun 2012 16:00:36 -0500 "VanguardLH" <> wrote in
    article <jsajhb$3ds$>
    >
    > Jason wrote:
    >
    > > 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?


    Yes.

    >
    > 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?


    There is not an old .rdp file; I made sure.

    >
    > 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?


    I have identical id's (and passwords) on both ends of the failing
    connection.

    > Is that
    > account defined on the remote host in the Administrators group or in the
    > Remote Desktop Users group?


    Accounts on both ends have Admin privileges. I wasn't aware of RD Users
    group...will look into that, 'tho in the XP days I didn't have to do
    anything since I wasn't even aware of such a 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.


    I do have gpedit on the target (Win 7 Pro) machine. From what I can see,
    there shouldn't be anything blocking RDC.

    >
    > 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)


    It's enabled on the target (Pro) machine.

    >
    > 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.


    The machines are in sync to within a second. I use them with software for
    weak-signal reception processing which requires that the system clock
    remains accurate to the second (or two).

    >
    > 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).


    There will be only one concurrent connection.

    > 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.


    Thanks so much! I have lots more things to check now and am working
    through them.

    Jason
    Jason, Jun 26, 2012
    #6
  7. Jason

    VanguardLH Guest

    Another possibility is your router. Some can be configured to allow
    Internet access by your hosts but block intranet communication between
    them. I used to have a router with that feature. That way, I didn't
    have to concern myself with sharing files with my own intranet hosts but
    I could block any access to my hosts from any other hosts my family was
    using. I didn't want them getting at my hosts. The router let me
    specify which, if any, intranet hosts could connect to each other.

    If you have a router and you don't know of any special configuration you
    did in its options or firewall then see if resetting it will help.
    VanguardLH, Jun 26, 2012
    #7
  8. Jason

    Jason Guest

    On Tue, 26 Jun 2012 13:33:14 -0500 "VanguardLH" <> wrote in
    article <jscv96$chm$>
    >
    > Another possibility is your router. Some can be configured to allow
    > Internet access by your hosts but block intranet communication between
    > them. I used to have a router with that feature. That way, I didn't
    > have to concern myself with sharing files with my own intranet hosts but
    > I could block any access to my hosts from any other hosts my family was
    > using. I didn't want them getting at my hosts. The router let me
    > specify which, if any, intranet hosts could connect to each other.
    >
    > If you have a router and you don't know of any special configuration you
    > did in its options or firewall then see if resetting it will help.


    I have looked into that. I didn't have to make any changes for things to
    work under XP, so I suspect that Win 7 will be the same, but an
    experiment to try is to disable its firewall feature and see what
    happens. I didn't have to allow any particular ports before but perhaps
    that has changed.
    Jason, Jun 27, 2012
    #8

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. MrWhitey

    Remote connection login issues

    MrWhitey, Dec 29, 2009, in forum: Windows 7 Support
    Replies:
    1
    Views:
    739
    ISV_Developers
    Dec 29, 2009
  2. hannabreaux

    Remote Access Trouble

    hannabreaux, Feb 5, 2010, in forum: Software
    Replies:
    0
    Views:
    992
    hannabreaux
    Feb 5, 2010
  3. Guest

    Help with Remote Desktop Connection

    Guest, Mar 5, 2011, in forum: alt.windows7.general
    Replies:
    1
    Views:
    520
    Char Jackson
    Mar 5, 2011
  4. CanutoOnline

    Remote Desktop Web Connection NLA error

    CanutoOnline, Aug 2, 2011, in forum: General Discussion
    Replies:
    4
    Views:
    1,741
    CanutoOnline
    Aug 5, 2011
  5. Jason

    Remote Desktop trouble..again

    Jason, Jul 21, 2012, in forum: alt.windows7.general
    Replies:
    41
    Views:
    911
    Char Jackson
    Jul 23, 2012
Loading...

Share This Page