Remote device fails some Host Checker policies with Reason: ". (i.e. no reason)

[Stuarta_]

We're experiencing a strange problem whereby a remote user's PC is failing two of three Host Checker policies but no reason is being given either on the remote device or on the SA2500 user log. The relevant user log messages are:

2009-11-19 08:53:32 - ive - [ww.xx.yy.zz] System()[] - Host Checker policy '<Policy A>' failed on host ww.xx.yy.zz . Reason: ''.

2009-11-19 08:53:32 - ive - [ww.xx.yy.zz] System()[] - Host Checker policy '<Policy B>' failed on host ww.xx.yy.zz . Reason: ''.

2009-11-19 08:53:32 - ive - [ww.xx.yy.zz] System()[] - Host Checker policy '<Policy C>' passed on host ww.xx.yy.zz .

As you can see, one Host Checker policy is being passed which makes me think Host Checker itself installs okay. The two policies that fail are checking for Windows and application critical patches, but I'm assured by the device owner that the device is patched up-to-date (and even if it wasn't I should see what patches are missing). Unfortunately I have no access to the device itself. Other users/devices are connecting successfully to the same SA2500.

A previous poster had a similar log message and fixed it by upgrading the ESAP, but we are already running the latest version (1.5.4). The SA2500 is running 6.5R1 (build 14599).

Any advice gratefully received.

[kenlars_]

Have you looked at the debuglog.log file on the PC itself? It will show you the rules checked by Host Checker in excruciating detail. Not sure it will be helpful, but there is one more resource for debugging.

Ken

[Stuarta_]

Thanks for the tip Ken, I haven't looked at the debuglog.log so I've requested it from the user (and from another user who is experiencing a similar problem). We'll see what the files reveal...

[PG_]

Restart the services - we had a similar problem with the newr ESAP upgrade and it turns out the IVE services needed to be restarted in order to install the fix.

[Stuarta_]

I've tried restarting the SA2500 services but the problem remains.

Further investigation reveals that the problem only occurs to users with limited rights on the remote device - a user with admin rights on the same machine passes host checker successfully. This appears to be the case even if the Juniper Installer Service is running on the remote device.

Attached are debuglogs from an affected machine - "debuglog_adminrights" is that for a session (up to getting the SA2500 login prompt) where the user has admin rights on the remote device, and "debuglog_limitedrights" is that for a session (up to the Host Checker failure message described in my original post) where the user has limited rights on the remote device. Having compared the two files there are as far as I can see only two differences:

Limited rights:

00180,09 2009/12/02 11:29:10.281 3 <username> dsHostChecker.exe dsHostChecker p0512 t2C4 PluginLog.cpp:47 - 'HttpNAR' Juniper Networks - Shavlik IMC(ID: 0x4, CID: 0x1): Shavlik Scan Started

00181,09 2009/12/02 11:29:10.281 3 <username> dsHostChecker.exe dsHostChecker p0512 t2C4 PluginLog.cpp:47 - 'HttpNAR' Juniper Networks - Shavlik IMC(ID: 0x4, CID: 0x1): Shavlik Scan Finished

00202,09 2009/12/02 11:29:10.281 1 <username> dsHostChecker.exe dsHostChecker p0512 t2C4 PluginLog.cpp:41 - 'HttpNAR' Juniper Networks - Shavlik IMC(ID: 0x4, CID: 0x1): Error retrieving scan data from XML object

00182,09 2009/12/02 11:29:10.281 3 <username> dsHostChecker.exe dsHostChecker p0512 t2C4 PluginLog.cpp:47 - 'HttpNAR' Sending message from IMC 0x4 on connection 0x1. Length 189, type 0x58309.

Admin rights:

00185,09 2009/12/02 11:31:11.437 3 Administrator dsHostChecker.exe dsHostChecker p1640 tF70 PluginLog.cpp:47 - 'HttpNAR' Juniper Networks - Shavlik IMC(ID: 0x4, CID: 0x1): Shavlik Scan Started

00186,09 2009/12/02 11:31:19.421 3 Administrator dsHostChecker.exe dsHostChecker p1640 tF70 PluginLog.cpp:47 - 'HttpNAR' Juniper Networks - Shavlik IMC(ID: 0x4, CID: 0x1): Shavlik Scan Finished

00188,09 2009/12/02 11:31:19.421 3 Administrator dsHostChecker.exe dsHostChecker p1640 tF70 PluginLog.cpp:47 - 'HttpNAR' Sending message from IMC 0x4 on connection 0x1. Length 2953, type 0x58309.

Limited rights:

00131,09 2009/12/02 11:29:11.546 3 <username> dsHostChecker.exe dsWinClient p0512 t2C4 dsThread.cpp:259 - 'DSThreadMonitor::release()' ended

00170,09 2009/12/02 11:29:11.546 3 <username> dsHostChecker.exe dsHostChecker p0512 t2C4 PluginLog.cpp:47 - 'HttpNAR' Connection 0x1 on NAR 0x58b27b91 changed state to `Isolated'.

Admin rights:

00136,09 2009/12/02 11:31:25.078 3 Administrator dsHostChecker.exe dsWinClient p1640 tF70 dsThread.cpp:259 - 'DSThreadMonitor::release()' ended

00171,09 2009/12/02 11:31:25.078 3 Administrator dsHostChecker.exe dsHostChecker p1640 tF70 PluginLog.cpp:47 - 'HttpNAR' Connection 0x1 on NAR 0x58b27f59 changed state to `Open'.

I haven't a clue on how to interpret these logs, and can't find any documentation on them. Anyone got any further thoughts?

Thanks in advance,

Stuart

[cbarcellos_]

Nice find in the logs. I did some research and found a what looks to be a similar report that is currently being worked on. I can't tell at first glance if it is the same issue, but the report sounds the same.

if you are on vista you can try configuring dshostchecker.exe to "run as administrator"

I'd reccomend opening up a JTAC case.

[Stuarta_]

I logged this with JTAC as suggested (via our support partner), and they have eventually stated that it is a bug which will be fixed in ESAP 1.5.8, which they say should be out on the 15th of February. We've been supplied with a non-public release of ESAP which includes a fix as a short term remedy to our problems; I suggest anyone else experiencing similar issues gets in touch with JTAC for the same. Stuart