09-16-2009 05:14 AM
I've ran into something weird with my 6.4R3 SA4500 cluster:
I use HostChecker to perform pre-auth validation on my clients.
On a station, one browser might work (IE or Safari) but Firefox won't. The problem occurs on Linux, Mac and Windows stations.
I've seen something in the KB, but it's related to 5.x versions so I guess this should be fixed.
I've noticed the same problems on a SA2500 lab cluster too. Problem was noticed on 6.4R2 and is still in 6.4R3.
Am I the only one seeing this problem ? I'm starting to think that our datacenter is built upon an indian cemetery...
Thanks for your help !
09-16-2009 12:29 PM - edited 09-16-2009 12:55 PM
09-16-2009 12:55 PM
We have the same issue:
"Host Checker did not get installed properly."
The weird thing is clients can go to different URL/Sign in Policies which use the same HC Policy and it works fine.
09-16-2009 01:02 PM
09-16-2009 02:08 PM
I dont know what you mean by "connection missing" ? For the URL, we are pointing to a REALM, the Realm in question is pointing to a host checker policy.
The user goes to the site, attempts to launch host checker and gets ' Host Checker could not be installed '.
We are evaluating the Cisco ASA VPN so far, so good, and much cheaper. This issue has been haunting us since day 1. Juniper has no interest in fixing any of the Host Checker/Net Connect problems. They are only interested in adding useless features. If I sound bitter its because I am.
09-16-2009 02:17 PM
When I meant "Connection" I meant if you had checked the appropriate Host Checker Policy. But from your response it seems you already have. Have you tried unchecking it then logout then logback in and recheck. I know it sounds stupid and Windows like but when I run into problems that do not make sense I try not to overlook anyting or discount any "strange" possibilities. We're on 6.4R1 and fortunately always been able to resolve the no host checker problems that come up.
I wish you luck man. I feel your pain.
09-17-2009 04:41 AM
Thanks for all the answers, good to see that I'm not the only one who's experiencing this bug.
It might be a browser update problem, but I got the symptoms on the latest Firefox and/or IE8.
Giving admin privileges to the Windows users helped, but it's not an acceptable workaround.
I'll try the "remove/recreate" method, I know from experience with web resources that this is actually a solution.
09-22-2009 08:03 AM
Even stranger, users can log into the same host checker policy on a different URL.
I just updated Firefox with the lastest Java Code and now it works from Firefox but not on IE.
09-22-2009 08:36 AM
We have several users out of about 100 that do the same thing. Some folks it works in I.E. only, others it works in Firefox only. It should work in both. Sometimes I've fixed this by removing the host checker from Add/Remove Programs, then reboot and install the Host Checker 'Manually' with the install from Installers from the SA. Reboot and try again. This has fixed the I.E. only or Firefox only issue for most machines.
I've just upgraded our SA4000 to 6.4R3 without issue. I know it's off the subject but has anyone tried the WAN Accelleration offered in 6.5? We have Juniper WXC's in all offices and was curious what 6.5 would offer.
09-22-2009 09:08 AM
I can comment on the WAN acceleration. This is not really a feature of 6.5 per se. 6.5 now provides the ability to implement the WXC WAN acceleration client in a seamless manner to network connect users through the Host Check feature. That is the integration offered. If you want to implement the Juniper WAN acceleration client in an NC environment then it is a nice feature for you.
As for the client itself - that is a different topic. I beta tested it and have the production version up and running in my lab now and could offer you my 2cents if you cared.
09-22-2009 11:04 AM
The solution described at the below site (towards the bottom of the site) resolved one of my longstanding Host Checker issues. It has to do with the Agent String being too long. A dead giveaway of this being your problem occurs when you do a Help, About in IE. If you get a Error 53 then this is probably your issue. It could be your issue even if this doesnt happen. Once we removed some entries from the key described on the site our issue went away.
When the Host Checker tried to launch we would also get an error in the lower left of the screen saying " Setup failed due to inadequate client capabilities "
10-06-2009 02:05 AM
You guys having problems do you have a proper CA certificate.
What I see from the UAC HC is that I really need to trust everything always with a self signed cert.
Remember that both the browser and the java has a keystore.
Just curious if u're seeing this with self-signed or with a proper certifcate where the client has the CA cert in the relevant keystores.
Another thing is if you are connected directly to the IF of the device or your have firewall policies/filters infront of the device ?
10-08-2009 06:28 AM
I have been experiencing a VERY similar issue immediately after upgrading to 6.4R3 (from 6.2R5). Host Checker is required for nearly all our users to sign in, and many would get "You are not allowed to sign in" because Host Checker failed to launch / upgrade. No other errors or popups on the user side; they would type in their credentials, hit sign in, and a few seconds later get that error. The only solution we found was to have the user manually install Host Checker.
Has anyone found a solution to this? It destroyed my smooth upgrade track record with the IVE and caused some serious production issues. I have a ticket open with Juniper to find a root cause but they keep asking for debug logs I don't have because obviously getting the users to log in was more important than collecting log files from them.
It almost seems to be part of a larger issue... a few % of my users will continually experience issues with the client software and have to reinstall them from scratch. Can't find any rhyme or reason other than there's something horribly glitchy about this release... and here I thought it was safe to upgrade to an R3 release...
10-08-2009 06:32 AM
All I can say is this happens to us as well. Not just with this upgrade, with all upgrades. The upgrade process is broken. It always has been. Host Checker should be part of the NetConnect client, not a seperate application.
People will tell you to make sure the Installer Service is rolled out but it will not help much.
10-08-2009 06:40 AM
I've been using this SA4000 cluster for 3 years now... back as far as 5.2 releases I think, and I never had an issue like this with an upgrade. It wasn't until this last upgrade that I had to make the Host Checker / Juniper Installer Service installers available to my users publically... every other upgrade for years has been smooth, although I will admit it's only been in the past year (15 months) that I've started using Host Checker much. This change was so disruptive I'm now forced to change my upgrade schedule that I've been following for years.
Half of my users require SVW, and another quarter require Host Checker passes to log in... I agree something definitely has to be done about this shoddy automatic upgrade mechanism. I cannot perform another upgrade of the IVE if this is going to happen again; we lost too many production hours to it.
10-08-2009 06:56 AM
Again, certificates really solved a lot of problem for me.
Reallife cert with no chaining that both browsers and java has a CA cert for
10-08-2009 07:54 AM
10-08-2009 02:43 PM
I have experienced the same issues. I require role level hostchecker policies for all users. I recently tried to upgrade from 6.1R4 to 6.4R2 and experienced random users who could not log in.
The user would enter their username/password and hit submit. There would be a short paused followed by a "login denied". In the user log files on the server, it says "no roles". The users have role assignments, it's just the failure of the hostchecker policy. The "chain" from Realm -> Roles is preserved. The issue can affect some people in a role while others are fine. All my users are administrators on their machines. They are all running Windows XP SP2 will all patches. They are all running IE 7 with the VPN domain added as a trusted site. I can find no rhyme or reason to the failures.
The only solution that I have found, which has worked every single time so far, is to clear the cookies. Specifically the ones named "dana-an/" and "url_default/". If you delete those, you can login, upgrade your Host Checker and be on your way. I really hope this gets fixed. I had to rollback my upgrade from last night after my NOC got flooded with calls.
The other workarounds are rediculous. I'm not going to have my helpdesk field hundreds of calls and have to find a way to manually uninstall and reinstall hostcheckers. What a huge waste of resources. I might as well as go back to an IPSEC VPN with a thick client.