Can you determine the IP that is being returned in the .ica file?
Main Topics
Browse All TopicsExperts,
Current Setting:
Xenapp4.5 WI5.0 CSG3.0
WI/SG on the same server
Web Interface Site: https://citrix.company.com
Gateway Server Detail: servername1.company.com
STAs: http://servername2.company
http://servername3.company
Gateway Direct for client access method.
WI /CSG (20.x.x.x)
CTX2 server (10.x.x.x), CTX3 server (10.x.x.x)
XML:8080
SSL:444
80, 443 opened for access
telnet 1494 works
No blocks from router.
Issue: Users can hit the WI, however, when they click on apps they all get the same error.
Do I need to setup some kinda WI rules and client access tables?
Thanks,
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
NO IP, only the servername...
++++++++++++++++++++++++++
[Encoding]
InputEncoding=UTF8
[WFClient]
CPMAllowed=On
ClientName=WI_f9dT3cgVZhYc
ProxyFavorIEConnectionSett
ProxyTimeout=30000
ProxyType=Auto
ProxyUseFQDN=Off
RemoveICAFile=yes
TransparentKeyPassthrough=
TransportReconnectEnabled=
VSLAllowed=On
Version=2
VirtualCOMPortEmulation=Of
[ApplicationServers]
Admins - CTX1 Desktop=
[Admins - CTX1 Desktop]
Address=servername.company
AutologonAllowed=ON
BrowserProtocol=HTTPonTCP
CGPAddress=*:2598
ClearPassword=F3F12AE84386
ClientAudio=Off
ConnectionBar=1
DesiredColor=8
DoNotUseDefaultCSL=On
Domain=\56373383B3A80A7E
EncryptionLevelSession=Enc
FontSmoothingType=0
InitialProgram=#Admins - CTX1 Desktop
LPWD=0
Launcher=WI
LocHttpBrowserAddress=!
LogonTicket=F3F12AE8438615
LogonTicketType=CTXS1
LongCommandLine=
NRWD=0
ProxyTimeout=30000
ProxyType=Auto
SFRAllowed=Off
SSLEnable=Off
ScreenPercent=90
SessionsharingKey=-OrDZXz1
StartIFDCD=1251384908862
StartSCD=1251384908862
TRWD=0
TWIMode=Off
TransportDriver=TCP/IP
UILocale=en
WinStationDriver=ICA 3.0
[Compress]
DriverNameWin16=pdcompw.dl
DriverNameWin32=pdcompn.dl
[EncRC5-0]
DriverNameWin16=pdc0w.dll
DriverNameWin32=pdc0n.dll
[EncRC5-128]
DriverNameWin16=pdc128w.dl
DriverNameWin32=pdc128n.dl
[EncRC5-40]
DriverNameWin16=pdc40w.dll
DriverNmeWin32=pdc40n.dll
[EncRC5-56]
DriverNameWin16=pdc56w.dll
DriverNameWin32=pdc56n.dll
Ok, you are not going through the CSG based on this:
Address=servername.company
1494 is not used for CSG, everything goes through 443. The screen shot tells us the issue at hand though. Edit your STA entries to reflect port 8080:
http://servername2.company
Your entry will use port 80 (http's default port, get it?)
First, make sure that your test machine has its Root Certificates updated. I see tons of people run Express on their Windows Updates and never get their roots updated. Now open your mmc, add the certificates snapin and look around the trusted certification authorities for a cert that matches yours. I use GoDaddy for example (they are cheap and local); here and there I find users who don't have the Intermediate cert we go through but, for the most part, it works without intervention. That is the whole point of buying certificates.
Now I did a search for DoD certificates and I immediately found a site telling you how to install the certificates on client machines. Sounds like they are not preloaded on common operating systems or pushed via Root Certificate updates.
https://acc.dau.mil/ifc/do
BLIpman,
I think we are almost there... :)
I have one user manually installed the latest DoD certs and have him test with IE7 and IE8 settings.
I have about 5 ctx server desktops published for the user, right now he say that the connections to the server desktops vary. Sometimes he can connect and sometimes he gets "The Citrix SSL server you have selected is not accepting connections." Again, it is random...
He will update me on Monday with his testing results.
Thanks,
Ok, do you have 5 separate desktops published and each goes to one different server but the problem is random or do you have one desktop published to 5 servers, it load balances, and the problem appears to be random? For testing individual servers I like to publish something like notepad and will label them Notepad on Server 1, Notepad on Server 2, etc. This is handy for checking servers individually and for testing printing while you are at it.
Yep, then let me know which ones you are having issues with and we can work them out from there. Connection issues will often present themselves in the event viewer of the application server and or the web interface/secure gateway server so post anything you see that might be interesting. Also, compare working launch.ica files to those from servers that are not working.
WI/CSG LOGs
Secure Gateway Logs:
1.Connection was broken by either client or server. 2:05:39 ID:169 CORE
2.Client IP 10.101.7.172 sent bad ticket, connection dropped. 2:05:43 ID:100 Ticketing
3.Socks Session [3] failed ticket check. Client IP [10.101.7.172]. 2:05:43 ID:190 SOCKS
4.Client IP 10.101.7.172 sent bad ticket, connection dropped. 2:07:25 ID:100 Ticketing
5.Socks Session [7] failed ticket check. Client IP [10.101.7.172]. 2:07:25 ID:190 SOCKS
Connection was broken by either client or server. 2:09:47 ID:169 CORE
App Logs:
1. Site path: c:\inetpub\wwwroot\Citrix\
A socket has been forcibly destroyed by the transaction layer. [Log ID: bbb31685] 2:05:01 PM
2. Site path: c:\inetpub\wwwroot\Citrix\
The Citrix servers sent HTTP headers indicating that an error occurred: 400 Bad Request. This message was reported from the XML Service at address http://CTX5:8080/scripts/w
3. Site path: c:\inetpub\wwwroot\Citrix\
An error occurred while attempting to connect to the server CTX3 on port 8080. Verify that the Citrix XML Service is running and is using the correct port. If the XML Service is configured to share ports with IIS, verify that IIS is running. This message was reported from the XML Service at address http://CTX3:8080/scripts/w
4. svchost (856) The database engine stopped. 2:05:27 PM
5. Site path: c:\inetpub\wwwroot\Citrix\
The Citrix servers reported that they are too busy to provide access to the selected published resource. This message was reported from the XML Service at address http://CTX4:8080 [com.citrix.xml.NFuseProto
This might be useful for the first error but let's try to clear the others up first, I am not convinced you have a corrupted application:
http://support.citrix.com/
Verify that all servers running your published applications are using 8080 for XML (you can check the properties of each in the AMC to verify this). Then, assuming you are on the right port and didn't accidentally set 80/share with IIS on one of them, reset the XML service, make sure it comes up without generating new events, try that server again.
Verified that all CTX servers are using 8080 for XML port. Still waiting on external user's test outputs.
Meanwhile, I have published notepad from each server such as notepad_CTX1, notepad_CTX2, and so on, and I still get "Cannot connect to the Citrix XenApp server. The Citrix SSL server you have selected is not accepting connections." randomly. However, if I try a few more times I finally get connected. User load should be less than 3. Any ideas? Thanks.
I am sorry, got tied up with some issues at work. I am glad you are using a load balancer because it makes the issue much easier to solve. You need to enable sticky sessions (or whatever your load balancer calls "persistence"). If you start a session with one server and then the load balancer takes you to another the session ID won't be recognized and the new server will drop the connection. Then, finally, the LB takes you back and the original server can work. It explains your issue pretty neatly.
Let me get one thing cleared up first, do you have more than one Web Interface or CSG server? If not, then is the load balancer in the back end trying to balance connections to the Citrix farm?
Citrix does it's own load balancing to farm servers and will do a better job than any hardware LB you will put in place; it has all sorts of server metrics it can use to better distribute load. To load balance Web Interface or CSG servers you must guarantee that a "flow" (a user's session or a combination of a unique IP/port combination) always goes to the same server it started on.
Load balancers can usually sticky on things like:
-source IP
-SSL session ID
-URL cookie
-file based cookie
etc...
Thanks for coming back :) :)
Here is little change took place in the past 48 hrs.
Due to the DoD Cert mismatch I had to move the WI/SG in the trusted network. (10.x.x.x) from DMZ, and it is operational.
I only have one WI/SG for now. Eventually will have one more.
LB sits in the DMZ and it is just forwarding ips from external to internal (sort of NATing, it is not LBing) and not balancing connections to the CTX farm. Hope this answers your question.
My question is if I still experience this behavior below what would you suggest?
["Cannot connect to the Citrix XenApp server. The Citrix SSL server you have selected is not accepting connections." randomly. However, if I try a few more times I finally get connected.]
Thank you,
So on the LB device, you have a Virtual IP which defines some sort of "service" and that forwards traffic in to your WI server right? You only have one real server defined thus far though so it shouldn't be trying to go anywhere else. I am not sure this is the issue but it is a suspect. When you say you try and try and eventually it works I start thinking about the IP layer and what might be going on there.
Are you still getting errors on the WI/CSG or on the individual Citrix servers? Another thing to try is taking out all but one of the STA entries to make sure you are not hitting a bad one (or somehow misconfigured) but you should see event log entries for any STA failures.
Based on the info you provided;
Your using the SG therefore you only need to have port 443 open on your firewall to access this. This allows outside clients to communicate to the SG, the rest of the communication e.g. 1494, 2598, 8080 happens inside the network and shouldn’t need to be open to the outside.
The other problem I see is your running XML on port 8080, which is fine but you have your STA links listening on port 80 (hence the http:// only) try changing your STA links to:
http://servername2.company
http://servername3.company
This should resolve your issue(s)
Business Accounts
Answer for Membership
by: BLipmanPosted on 2009-08-27 at 12:18:06ID: 25201641
Do they get the same error from the LAN as from outside the network? Would you post the contents of a launch.ica file so we can see what you are getting out of the WI?