HostChecker won't launch on some stations

[muttbarker]

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.

[Jickfoo]

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 " 

http://www.netsplore.com/PublicPortal/blog.aspx?EntryID=45

[stine]

Now That is problem solving!   Good job.

[TRK-NKA]

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 ?

[Tessian]

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...

[Jickfoo]

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.

[Tessian]

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.

[TRK-NKA]

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

[Tessian]

Good thought, TRK-NKA, but I am using a GlobalSign SSL certificate.  It's signed by an intermediate CA, but all that meant is I had to install it in the intermediate CA store on the IVE

[gmatthews]

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.