Hi,
Is there anything interesting in the Windows Log files ? What happens if you try to manually start the service on an affected device?
Nothing in the event logs. The scheduler service is running and if we create a new task on an affected PC, then that task works. It appears to be affecting those tasks (namely vulscan and ldiscn32) that were setup during the client install. Yet, both of these work fine on some of the systems.
What do you see if you get the local schedular to dump out a list of all the tasks that it has scheduled on a device - from the LDClient Directory run "localsch /tasks > task.txt" and post the contents ?
Did you check the vulscan.log in %ALLUSERSPROFILE%\Application Data\vulscan\
and
the logs vulscan.log, LOCALSCH.log and LDIScn32.log in %ProgramFiles%\LANDesk\LDClient ?
Regards
Axel
I checked the results of the localsch /tasks and both the working and non-working PC's are the same.
My LocalSch.log files differ only in that the log file from the PC that isn't working does not have any entries in it for LDIScn32.exe whereas the other log file does.
From the LDIScan log file, I did see a difference where the system that is not working was having problems connecting to the LD server. So that is something that I can see that might be causing problems. However, the odd thing is that the log file does not show any entries after April 18th. It's as if the process just gave up. And it did scan once successfully before the 18th.
Below is a snippet from the logs (LDISCAN) from both a working and non-working PC:
From working PC -
Sun, 04 May 2008 04:38:20 Firewall is enabled
Sun, 04 May 2008 04:38:30 open key Software\Utimaco\SGEasy with flags 0x20019 returns handle 0, status 2
Mon, 05 May 2008 05:12:03 Performing TCP connection with a timeout of 2500 milliseconds
Mon, 05 May 2008 05:12:06 Download information for HTTP://SERVERNAME/LDLOGON/LDAPPL3.PAZ : 89,785 bytes in 0:00:00.094 seconds, bandwidth 932.7730 kb/s
From non-working PC -
Wed, 16 Apr 2008 11:25:55 open key Software\Utimaco\SGEasy with flags 0x20019 returns handle 0, status 2
Fri, 18 Apr 2008 04:56:02 Response for 'HTTP://SERVERNAME/LDLOGON/LDAPPL3.INI' was not a successful http request (503)
Fri, 18 Apr 2008 04:56:02 Response for 'HTTP://SERVERNAME/LDLOGON/LDAPPL3.BAZ' was not a successful http request (503)
Fri, 18 Apr 2008 04:56:03 Response for 'HTTP://SERVERNAME/LDLOGON/LDAPPL3.BAZ' was not a successful http request (503)
Fri, 18 Apr 2008 04:56:03 Response for 'HTTP://SERVERNAME/LDLOGON/LDAPPL3.PAZ' was not a successful http request (503)
Fri, 18 Apr 2008 04:56:03 Response for 'HTTP://SERVERNAME/LDLOGON/LDAPPL3.PAZ' was not a successful http request (503)
Fri, 18 Apr 2008 04:56:05 Response for 'HTTP://SERVERNAME/LDLOGON/LDAPPL3.INI' was not a successful http request (503)
Check your Application Pool settings of IIS...
In the following doc you can find some informations about: http://community.landesk.com/support/docs/DOC-1071
Take a short look in the logfiles of IIS here: %WINDIR%\system32\LogFiles\W3SVC1
Regards
Axel
My mistake. Those Server No Responses in the logs are from when the user was trying to run the scan manually.
What's troubling is that when we look in the log (localsch.log), there is no indication of LDISCN32.EXE even attempting to run. And we just checked and about 50% of our systems are behaving this way.
May 6, 2008 5:23 AM
Hmm - OK - so is the Local Scheduler service even running?
Also - is it possible that there's permission problems on the registry? If you happen to have one such device which behaves strangely in your test bed, configure the inventory scan to run every (say) 2 minutes ... checking with REGMON, you should see local scheduler polling the info every few seconds ...
If the scheduler service is running, there's got to be something that's denying us access here. Either that, or the inventory scan IS started, but the client cannot contact the Core (which sounds like a possibility on account of you stating that there's errors even when you try to launch a manual inventory scan) ?
Paul Hoffmann
LANDesk EMEA Technical Lead.
zeetwoeight - Did you manage to get to the bottom of this? I'm seeing similar on a lot of my machines.
Mar 6, 2009 4:59 AM
Simon,
if you're seeing something similar, I would suggest you look at the troubleshooting tips given by others and myself here too. Logfiles, registry permissions (REGMON at a push) - there's quite a few things that can help out with the "why" here, potentially.
(That said, it's still darn odd, I'll say)
Paul Hoffmann
LANDesk EMEA Technical Lead
I've been looking through the tips to try and get to the bottom of it, what I've gathered is that the affected machines can be found if LDIScn32.exe isn't in the scheduled tasks - I find this but looking at it's inventory scan on the core, pics attached show a good and bad machine.
Good
Bad
It's affecting 161 out of nearly 4000 machines according to my query so I'll try an agent reinstall to see if it reduces the number over a period of time.
Strangely enough the "last updated by inventory server" date is current, but the last software and scan dates aren't.
Mar 6, 2009 5:35 AM
The following would explain the discrepancy you're seeing.
Last Hardware Scan Date: Last time hardware information was gathered on a particular device. By default, every instance of the LANDesk Inventory Scanner will gather hardware information, unless the no hardware switch (/nh)is specified.
Last Software Scan Date: Last time hardware information was gathered on a particular device. During this scan, the Software License Monitoring information is gathered. Delta scans do not include software scans.
Last Updated by Inventory Server: Any time a particular record is modified, this value gets reset. Any of the LANDesk tools (vulscan.exe, ldiscn32.exe, amclient.exe) can cause this value to get updated.
Also, there's mini-scans, boot-up time scans, there's plenty of possibilities outside of locally scheduled task to get inventory to come in. Certainly, it looks like you've found the culprit in this case, and an agent update should take care of the lack of locally scheduled tasks.
Paul Hoffmann
LANDesk EMEA Technical Lead
The agent reinstall made a difference to the devices that didn't have LDIScn32.exe in the local scheduler service but the numbers didn't go down that much so I've done a bit more investigating and found that on a these devices there is no local scheduler entry on inventory record at all -
Does that mean that it's not installed at all or has been disabled?
Mar 6, 2009 7:23 AM
It means at least that we've not reported in through inventory.
I'd suggest running the following command on the client:
""
C:\Program Files\LANDesk\LDClient\localsch /tasks >mytasks.txt
""
and then have a look at "mytasks.txt" (now in human readable format) ... if this is empty, it's possible that the registry permissions are borked on the tree/branches where we'd normally save this to, which is here:
""
HKLM\SOFTWARE\Intel\LANDesk\Local Scheduler\Local Tasks\
""
Alternatively, you're having problems with upgrading the agents - just to be sure, you're aware of / have applied the patch from this article and are using the advanced agent?
http://community.landesk.com/support/docs/DOC-4449
Paul Hoffmann
LANDesk EMEA Technical Lead
