Connect time to Citrix is 5 minutes, but runs fine once in 3

[Airforce1]

I have 3 users at the same location that experience a long delay while connecting to Citrix. They tell me sometimes it is as long as 5 minutes before they see the login screen!

Once, they are in, everything is fine; performance is ok. They are connecting through an ADSL connection (like many of our other users). They are all W2K clients, but we have other W2K clients in other locations who connect within 10 seconds.

 

[CitrixEngineer]

I agree that routing is probably also an issue, but because of the way ICA works with TCP/IP, if the client DNS is not properly configured, you can get exactly this sort of issue; I used to see it at remote offices connected by 2Mb links.

Also holes we plugged included removing Novell 802.3 and stopping all Win9.x machines from attempting to become browse masters. Broadcasts and ICA don't mix too well.

Each hole we plugged increased login time, so deduced that all were factors.

Over dial-up, the single biggest problem I've seen (apart from ISP-related) is client DNS entries. There needs to be one for the local LAN, one for the ISP (if poss) and one for the LAN being dialled into. Even if you connect to the Citrix server(s) using IP addresses, ICA will be trying some NetBIOS name resolutions along the way, eg client NetBIOS name. Hence routing is also a factor.

Also hence it's not WINS related in any way.

I won't bang on - just want to make sure all areas are covered

I really hope this one gets solved - I'd like to know how it was done! CitrixEngineer@yahoo.co.uk

 

[Highland]

Not sure that I totally agree with CitrixEngineer...!!!

We have NO DNS servers in our Domain....all Name Resolution is done using WINS.

My understanding is that because ICA is using the "resident" IP on the servers it does Name resolution based on the configuration of the IP stack....if theres no DNS then it wont use it....??? I thought ICA Master Browser was primarily used for locating Published Desktops/Apps, Citrix Admin etc....????

If you're just using the Servers IP address to connect you should only be concerned with the IP route to the destination (and back)..!!!

Anyway, hope u get to the bottom of this one, it sounds like quite a few of us want to know what the fault was....!!!!

 

[Airforce1]

Good points; this is what has troubled me with some of the answers. We have no DNS on our domain, and we are using the IP of the Citrix server; therefore, how would DNS even come into play? I always thought that DNS was used to resolve names to IPs. If you start with the IP, why do you even need DNS?

 

[DaveNamou]

Airforce1,
You are correct. DNS or WINS does not play a part in your problem!. Simply because you are using the IP address which needs no resolution from the DNS or WINS server.

Could you tell us more about your environment to help in this matter. Like...

Do you have a firewall in place? If you do, try taking the client who has the problem and placing him OUTSIDE of the firewall.

Your probably getting overwhelmed with all the suggestions! But we just need more info about the environment that this problem is occurring in.








Dave Namou, MCSE CCEA

 

[Airforce1]

ADSL Connection (768K/384K) through a $100 SMC Router employing NAT. No true firewall. You really cannot get much simpler than our setup at this location. ADSL/ISP is the local telco. On the server end, we employ a PIX firewall, Cisco router, and a dedicated T1 (256).

 

[CitrixEngineer]

Guess I'll have to concede that point too ;-)

I've never worked at an installation where DNS was not used - and, having done more research, it turns out that ICA only uses the NetBIOS name of the client if it can't resolve it using WFClient.ini.

Makes me wonder why investigating DNS has worked in the past...this has always been one of the first things I'd try. Just goes to show, really.

OK, one other wierd thing I read was that if you clear the client bitmap cache it can speed up logins for the Async client. This was in CTX952065, and ostensibly pertains to Anonymous users, but I can't see why it would only affect those.

I also can't see why it would affect WinTerm (or similar) users, since they can't download bitmaps into a cache...or is that the problem?

/Makes note to try out this particular scenario /


CE (Just "upgraded" my CCEA to CCEA(XP), and now feel like I know nothing!) CitrixEngineer@yahoo.co.uk

 

[kgouldsk]

There are a few questions I'd like to ask here:
1. If I understand correctly, these are Windows terminals. Have you tried a PC using the Citrix client, and if so, how does it behave?
2. If you have a PC, is it able to immediately ping the Citrix server? (Undoubtedly it will be able to-I don't feel this is a routing issue, either it would still be slow after connect, or subsequent connections from the same client would likely be faster).
3. With the PC, after the initial "good" test, force an ip address change, deliberately unconfigure WINS (disable DHCP) and reboot. Try to connect again.

What I'm hypothesizing here is that on the server side, while the connection is being set up, the server is trying to resolve the client name several times and is must time out for each attempt. A Winterm may not be configured to register in WINS. A further test would be to put the client addresses in the %SYSTEMROOT%\system32\drivers\etc\hosts file, copied from hosts.sam. This should allow the server to resolve them regardless of whether they are in WINS. Since you indicate that you're coming through a NAT connection, all of this may be mute, and you may need to register the NAT device in your hosts table if there is no resolvable entry in WINS. Test that it's working by trying to ping by name. To figure out what address to register, do a netstat -a from the command line on the server and hunt for the address the client is coming in from. If your server is busy, this may be tough if you aren't fairly aware of the addressing scheme at your site - you may need to ask for help from your network group.

I notice several people above making reference to profile sizes, then correcting themselves for profiles being local. The original statement was very clear - "5 minutes before they see the login screen". No profiles involved at all.

 

[Airforce1]

Someone else who added to this thread is having the same problem with Win Terms. My problem is with PCs, WK Pro PCs which are CAD machines runnings lots of memory with 32 MB dual head Matrox graphic cards. Yes, they can ping the server immediately.

 

[Highland]

There have been a couple of posts in this forum recently regarding Graphics adapters and "strange" issues regarding connections to servers......??? Was just wondering if you had tried a basic client at this site (VGA graphics etc..???); is it only the 3 hi-spec clients at the site...??? Where is the route from the remote site defined for the clients..??? Are they configured to look to a default gateway or is each PC given a static route...??? Why does "ping" work immediately...???!!!!

Have you tried setting up a drive mapping to the server from the clients...???? Just wondering if this is affected in the same way...???

It might even be worth looking for a hardware problem...??? Try moving your hub/switch connections, cabling etc....???

CitrixEngineer chill out...!!!!!! We think ur great....!!!!

 

[GaryL]

Don't have a lot of time to wade through the details, so this may not be close at all, but.... I'd check for latest firmware on remote routers/firewall devices. Ran into issue where Linksys home router wouldn't pass IPSec properly through NAT without firmware update. As a test, I'd bypass any remote firewall/router devices and test using a public IP temporarily on the remote client hooked up directly to the cable/dsl modem/router.

 

[crodrigues]

What if they logon using someone's else username/password (one that you know does not take long)?
If it works fast, the problem is a profile issue. Period.
If it takes the same long time, you have a communication problem somewhere.
As others suggested, try the RDP client also to see what happens. Remember that port TCP 3389 must be opened. Cláudio Rodrigues
Microsoft MVP
Windows 2000/NT Server - Terminal Services

http://www.terminal-services.net

 

[Edwardjm]

I am going to post a reply to the slow login problem using any client.

First what operating system are your Citrix servers running. If you are running Windows NT4.0 Terminal Sevices and any version of Citrix Metaframe then DNS is not the problem. However if you are running Windows 2000 server with Citrix Metaframe of any version, the slow login is because your clients does not point to an internal DNS server. You might be running DNS but one thats external from your ISP. What happens is that the terminals goes out and searches the internet first and then when it gives up it comes internally and finds the Citrix server on your WAN that is why its taking so long to login and why it works well after it has logged on. You can seee this same problem if you have Windows 2000 or XP clients logging into a Windows 2000 Domain and your DNS servers in your TCP/IP configuration is pointing to an external DNS server. Your client will sit there saying its loading the profile for 3-5 minutes and then finally log in to the servers. Now if you point to an internal DNS server and have that DNS server take care of resolving external addresses.

I hope this helps.

 

[Airforce1]

Thanks for your inputs; it seems there is such a wide variation in opinion on what is causing this problem. It sure will be interesting to get to the bottom of it.

I hope to travel to the site with the problem in the near future to try out all the great suggestions.

Ane, BTW, we are running W2K Server on the Citrix server end.

 

[FrenchBoy]

Hello i have the same problem with some pc with windows 2000 pro. We are all on a lan, the citrix version is XPa on a winddows 2000 server. And to correct the problem i have install the sp2 on the workstation and everything goes find now.

 

[Hof]

Hi
Here is another tip for a problem that can cause long connect times when connecting to Citrix/Terminal Servers

SYNOPSIS:
> When You try to make a connection to a NT4 Terminal Server from a W2k
> Professional the connection takes more than a minute.
>
> VERSION:
> NT4 Terminal Server
> W2k Professional (Swedish)
>
> SOLUTION:
> The problem lies in the Microsoft Licensing and is caused due to
> insufficient userrights. Give the usergroup "users" the rights Full
> Controll
> to the following key in the registry:
> HKLM\SOFTWARE\Microsoft\MSLicensing
>
> MORE INFORMATION:
> Since this is a Microsoft-related error, please contact Microsoft support
> if
> you need additional information.

Hope this helps

/Hof

 

[behind]

Hi.
The login mask comes up, you tipped the username and the password. Then it goes 10 minutes, right?
What you see in the citrix server administraton? du you see the connection afew seconds later or at least after 9 min?
If you see the connection, it could´nt be Firewall, DNS etc. problem. A big logonscript or anything else.

 

[woonbronmaasoevers]

I had this problem also.. Also W2k clients. It connected immideatly. the screen stays black for 5 minutes.

Give them administrator rights locally.. that solved my problem!

so many response.. and a easy solution!

 

[Airforce1]

I cannot for the life of me understand how giving them Admin rights locally would make a difference, but I will try this one first, then all the other ideas if it doesn't help.

Thanks again to everyone for your inputs/suggestions.

 

[woonbronmaasoevers]

I KNOW! i couldnt believe it either.. i found out when i used that machine with the administrator account locally.. bill gates never stops to amaze me with his foolishness.

greets,
Danny

 

[LKT]

I have seen this issue on a few routed remote networks.

The link speed or protocol enabled on the network werent the issue in those cases. After alot of network Sniffing and auditing every possible event on the Terminal Server I found the following to be the causes, also these only affected logins not "logged in connections":

- The Routers were not utilising established tcp level connections properly, a delay occured on outgoing packets to the remote sites. Also, the NAT port forwarding on the routers were taking ages to open, this was related to the way the router was re-writing the data frames with the new mac addresses. This was corrected by simply replacing the routers. Not sure whether this is a step that you want to undertake.

- Switches at the server end were misconfigured and thus a emulation of a Denial of Service attack was occuring. The server in return was struggling to deal with the bombardment of inbound packets and thus logins took ages.

- Routing loops were occuring within the VPN at the ISP. After they pulled their finger out and sorted it, the situation was improved.

- The Windows Licensing System was "damaged" and low on client access licenses for Terminal Services. This was rectified by re-applying service pack 2 for 2000 and forcing CAL reactivation. Also buying more licenses helped!

Hope that helps, Cheers Andy.

Andy Simpson CNE, MCSE+I, CCA, N+