SGD 4.3 - Sits at "loading" screen when launching SGD from Start Menu
Currently evaluating SGD 4.3 and having a strange problem.
Using Windows 2003 (Terminal Server) as my client, with IE6 or Mozilla 1.7. If I enable "Add Applications to Start Menu" -- but disable "Automatic Client Login", then when I try to click the Login shortcut from my start menu, it opens my browser and sits at a "Loading" screen indefinitely.
The strange thing is that if I launch IE6 and goto the SGD URL and then click "Login", it works fine. Also, if I specify my URL in my profile without using a domain name (ie. server1 instead of server1.domain.com), it works fine and I get the login screen. I do get a hostname mismatch if I use the server w/o a domain name since our SSL certificate specifically states the fully qualified domain name.
I have tried using Java 1.4.2_08, 1.4.2_12, 1.5.0_06 (these are all the JREs available for me to install) - Makes no difference. No errors are reported in the SGD logs, no errors are reported by tcc.
I have seen other posts recommending Java 1.5.0_10 or newer but most of our Windows users have no control over what JRE ends up on their desktop, and someone else controls their desktops. I'd like to be able to get this working with 1.4.2, does anyone have any ideas?
I have already tried pinging the server and it works fine, and telnetting to the server on port 3144 works fine. I don't believe this to be a DNS or network issue since it works fine for me except when I launch SGD from the Start Menu.
[1495 byte] By [
rjchunga] at [2007-11-26 17:39:29]
# 2
Thanks for your reply!
I don't have a Windows XP box to try it on but I did try it under Solaris 10 (JDS) with Mozilla 1.7 and a Java 1.50_01 system and the exact same thing happens, so I don't think the client OS makes a difference for this particular problem.
I read through the profile setup document that you linked and everything looks correctly configured for my user.
If it helps I also noticed at the bottom of the browser it says "Applet com.tarantella.tta.client.tcc.lwplugin.pluginG.TCCHelper started".
My profile incase this helps as well is configured like so:
Login URL: https://server1.domain/sgd/index.jsp (I have also tried just https://server1.domain/sgd as the client profile docs suggest) -- If I change this to just "https://server/sgd/index.jsp" it works, but of course this is not acceptable for use outside of our domain)
Checked - Connect on System Login
Checked - Add applications to Start Menu
Unchecked - Automatic Client Login
Client Options:
Alternative PDF Viewer: <blank>
Logging: All (I have also had this set as "Errors Only")
Preferred Language: en
Unchecked: Check for local X Server
Proxy:
Selected: Use default web browser settings (we have no proxy configured)
Unchecked: Establish proxy settings on session start
Unselected: Manual Proxy settings (and the rest of this stuff is blank)
Connection Failure:
Reconnect: Ask me if I want to reconnect (Have also tried Always attempt to reconnect)
Number of attempts: 6
Interval (secs): 10
Thanks for any help you can provide!!!!
-Ryan
# 3
We had the same issue as this and never got it resolved. Although we think it may well have been security settings within the antivirus software that stopped the helper working.
Our solution was to use the sgd/thin.jsp
this gets round the problem, but has its own little "issues" to deal with, but at least we could login.
# 6
I noticed that when TCC generates its HTML page to direct you to the SGD page that there's some interesting differences:
If i use the server short name (no domain) I'm provided with a different URL to goto than if I use the fully qualified domain name:
Short name forwards me to this URL:
https://server1/sgd/index.jsp?tccport=<port>?&langSelected=en&pro filename=Default&cid=<random number>:<another random number>:server1.domain&sid=server1.domain:<random number>:<random number>:<random number>:<random number>
The FQDN forwards me to this URL too:
https://server1.domain/sgd/index.jsp?tccport=<port>?&langSelected=en& #38;profilename=Default&cid=<random number>:<another random number>:server1.domain
There's no Session ID given from TCC.exe! ... This is definitely whats causing the problem, now I guess I just need to hope that SUN releases a patch for it. If anyone knows of a patch that already exists, please let me know.
Message was edited by:
rjchung
