psuwtb
asked on
Remote Desktop Connection Slow to Establish Initial Connection - Normal After Login
Recently we began experiencing a weird issue while using remote desktop from several Windows XP systems within our domain. All systems are running Windows XP SP2. When initiating a remote desktop connection, using the command "mstsc /console," several computers (laptops and desktops) take 2-3 minutes before the Windows login prompt appears. During this time only a blue background is visible at which point the windows login box finally appears. After logging in, everything works as a normal and refresh speeds are comparable to those systems that do not experience the 2-3 lag at logon.
I have tested with approximately six PCs. Two of which connect immediately, without the 2-3 minute delay, while all others experience the same delay. The firewall software is standard and active on all systems. Initiating a remote desktop connection from a problem PC to a "good" PC, logs directly in without the delay that is seen when connecting in the opposite direction. All PCs are members of the same domain but may have been configured at different times (i.e. using different images). All PCs are located on the same network switch (GB Foundry).
All signs (my best guess) point to some type of software issue. Any ideas where to look?
I have tested with approximately six PCs. Two of which connect immediately, without the 2-3 minute delay, while all others experience the same delay. The firewall software is standard and active on all systems. Initiating a remote desktop connection from a problem PC to a "good" PC, logs directly in without the delay that is seen when connecting in the opposite direction. All PCs are members of the same domain but may have been configured at different times (i.e. using different images). All PCs are located on the same network switch (GB Foundry).
All signs (my best guess) point to some type of software issue. Any ideas where to look?
debuggerau
please try mstsc /admin for a console connection, this should be quicker, and provide the functionality you require.
ASKER
I tried using mstsc /admin but had the same results.
My understanding was that the "mstsc /console" switch had been simply renamed to "mstsc /admin" in Vista.
My understanding was that the "mstsc /console" switch had been simply renamed to "mstsc /admin" in Vista.
Sure, but your question has a Windows XP tag..
Anyways, I find delays like yours with third party screen savers, google desktop and Windows Search software.
There may be others, and indexing the hard drive wouldnt help, neither would large background images (not active content though). But for my HP boxes when they distribute the OEM build that contains their logo - have a slight delay in addition to my others.
Hope that helps.
Anyways, I find delays like yours with third party screen savers, google desktop and Windows Search software.
There may be others, and indexing the hard drive wouldnt help, neither would large background images (not active content though). But for my HP boxes when they distribute the OEM build that contains their logo - have a slight delay in addition to my others.
Hope that helps.
ASKER
Unfortunately, none of those symptoms are present. All systems have the same Group Policy, which enforces screen saver, disallows software installs, etc.
This delay is more on the magnitude of 2-3 minutes.
This delay is more on the magnitude of 2-3 minutes.
Any chance you could run performance monitor to see how hard the workstations are working when connecting, maybe they are virus scanning or something...
Also, I wonder if using a program like smsniff might show something also, especially when compared with a working unit.
Also, I wonder if using a program like smsniff might show something also, especially when compared with a working unit.
plus the available memory and pagefile usage at the time of connecting?
Is it constant? or just occasional?
Is it constant? or just occasional?
ASKER
I just attempted to remotely connect to a laptop on my desk and can conclude the following information:
1. It took a good 2 minutes before the Windows prompt was displayed using mstsc /admin as I have seen before.
2. I closely monitored Task Manager and saw that the remote system was at 99% System Idle Process during the entire connection process. The remote system has 2GB of RAM and there were no open programs.
3. I ran smsniff on the remote system and saw the remote IP connecting over the RDP exactly as I had clicked connect. Unfortunately, there was very little network traffic and nothing appeared out of the ordinary.
I have now tried to connect over a dozen times at various times throughout the day and from/to various systems. This should eliminate the possibility of virus scanning and other high CPU usage processes. On the systems where the delay occurs, the problem is seen all of the time. Likewise, for those systems that have not experienced the problem, they always connect immediately.
1. It took a good 2 minutes before the Windows prompt was displayed using mstsc /admin as I have seen before.
2. I closely monitored Task Manager and saw that the remote system was at 99% System Idle Process during the entire connection process. The remote system has 2GB of RAM and there were no open programs.
3. I ran smsniff on the remote system and saw the remote IP connecting over the RDP exactly as I had clicked connect. Unfortunately, there was very little network traffic and nothing appeared out of the ordinary.
I have now tried to connect over a dozen times at various times throughout the day and from/to various systems. This should eliminate the possibility of virus scanning and other high CPU usage processes. On the systems where the delay occurs, the problem is seen all of the time. Likewise, for those systems that have not experienced the problem, they always connect immediately.
Ok, been doing some reading and it appears that there are some issues with different versions of remote desktop.
I'm not sure if your running version 6, but it may affect other versions, so I'm wondering if you could compare the working system with the other system using DRTCP. Its a program that displays (can change) the TCP window size amongst other things.
I'm not sure if your running version 6, but it may affect other versions, so I'm wondering if you could compare the working system with the other system using DRTCP. Its a program that displays (can change) the TCP window size amongst other things.
ASKER
I am running version 6 and will try testing a few computers with the older version to see if that resolves the problem. I'll let you know!
Thanks!
Thanks!
ASKER
I just tried connecting to a known good PC and a slow one using both version 5.2 and 6.1. I had identical responses using both clients. The slow PC took ~2 minutes for the login prompt to appear, while the good PC appeared with 2-3 seconds. It must be something on the receiving PC that is delaying the connection...
and have you tries drtcp?
http://www.dslreports.com/drtcp
I'd like to see the variances between the two please.
http://www.dslreports.com/drtcp
I'd like to see the variances between the two please.
ASKER
After running DrTCP on both systems (good/bad), the text boxes were either empty or listed as Default. These settings were the identical on both systems (see attached).
DrTCP.jpg
DrTCP.jpg
hmmm, I dont have much more to go on, will have another look next week.
Just came across something about broadcom adaptors having an old driver, same symptoms.. Is this the case with you also?
ASKER
I thought for sure that you had found the problem since all of our Dell laptops use Broadcom adapters. Unfortunately, I just updated both sides to the latest Broadcom drivers (http://www.broadcom.com/support/ethernet_nic/netlink.php) and still am experiencing the extreme delay when trying to remotely connect.
I'm afraid that the next step will be a trace..
I'd use smsniff, which is tiny, but gives a timestamp and the packets, if not too plentiful.
We should be able to see if its name lookups, or an internal delay.
Then we use this information to track down either the network, or PC settings...
I'd use smsniff, which is tiny, but gives a timestamp and the packets, if not too plentiful.
We should be able to see if its name lookups, or an internal delay.
Then we use this information to track down either the network, or PC settings...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.