1 of 1 people found this helpful
Well - for one, the "LANDesk.Gateway@..." stuff is quite normal, whether you use a Gateway or not. In short, the LANDesk client doesn't know whether or not it's in gateway mode - all of that stuff goes through the LANDesk proxy which determines this. The rest of the agentry just sends its data to the proxy - and the proxy is the one that either talks to the LDMG or the Core direct. So that part can be ignored.
The interesting thing here is going to be what IP 192.168.0.63 is. Is that your Core?
Because if it is, I'm suspecting that your agents are (mis-?)configured in terms of trying to address the Core by IP rather than by name / FQDN.
Clients need to - for ANY software task - talk to the Core (to get the task manifest) - it's the manifest that contains the file-list and hash-values for them.
The "other files" download fine as - I suspect - they're on a package share which isn't obfuscated to the clients in some form.
Though I'm a bit curious that you say that the package files are downloaded ... usually clients go for the task manifest FIRST (so that they know WHAT to download and where from) ... so not quite sure how that's possible without a task manifest?
LANDesk EMEA Technical Lead
The IP is the core server (Internal IP, the external IP that the NAT clients talk to is a 10.0.0.0 range address.
The packages are served via HTTP from the core as the NAT clients can't access UNC shares on the core server.
The clients are all configured to use the FQDN of the server (In this instance ldcore.wolvespct.nhs.uk)
There are quite a few "Tue, 15 Jul 2008 14:06:08 ..\AdditionalFiles.cpp(205): (800708CA): Failed to download file http://ldcore.wolvespct.nhs.uk/ldpackages/SophosGP/setupita.dll : (800708CA)" entries on the software log, but the SDMCache on the machine appears to have most of the files in it. It does appear that the manifests have been downloaded as they're in the .\sdmcache\landesk\file\ folder on the client.
For the record, I can download all of the "failed" files directly from the client machine, so it doesn't seem to be a pure connectivity issue.
It's confusing me, to be honest, because we haven't had any real issues pushing out software to these sites in the past. I suppose it's possible that the clients just keep getting disconnected and then retrying later, meaning that they will eventually have all the files they need to install the package.
Correction, some of the clients are starting to repeat the same errors on every retry now, specifically:
Wed, 16 Jul 2008 15:27:25 File (http://ldcore.wolvespct.nhs.uk/ldpackages/SophosGP/setup.exe) is cached locally
Wed, 16 Jul 2008 15:27:48 ..\AdditionalFiles.cpp(63): (8DAC4026): Failed to download file http://LANDesk.Gateway@192.168.0.63/ldlogon/FileLists/taskmanifest.WVPLDCORE1.128.22.ini : (801901F7)
Wed, 16 Jul 2008 15:27:48 processing of package is complete, result -1918091226 (0x8dac4026 - code 16422)
Which implies to me that it's got all the files it needs cached locally but is then, for some reason is trying to get the manifest (again?) and failing.
I don't know if this is of any significance, but it looks like all the taskmanifest files in the .\ManagementSuite\ldlogon\FileLists\ created after SP1 was applied are named with the core server's hostname, whereas the old ones all had the FQDN. Same applies to the pullcmds.xml files for each task. I've checked the download paths in the Packages and they all use the FQDN.
Message was edited by: Spad
Unfortunately incorrect reading.
The "package complete" means only "I've finished trying to download - here's the result code" it's not a "I've successfully downloaded all the files bar the TASKMANIFEST.
A "Unhealthy -> Healthy" log is here (I've "cheated" by simply fiddling with HOSTS entries) to show you the difference.
"Bad" attempt (with a bad DNS to resolve to) --> from beginning of the log up to (and including) the entry @ 15:28:18.
"Good" attempt (with the DNS fixed) --> from 15:30:56 to the end of the log.
If you "really" want to see proof that the taskmanifest gets downloaded first, you can enable debug-logging for LDDWNLD and have a read at that.
In this case, I'm still curious how your clients resolve their Core to that IP-address ... that information must be coming from somewhere...?
LANDesk EMEA Technical Lead
sdclient_task3.log 2.0 K
Our network setup is complex to say the least. We're an NHS site which means that in addition to our core network, we also manage 60-odd Doctor's surgeries. These surgeries are on their own domains and IP ranges.
Our networks are connected over N3, which is the NHS private network. Our core server is published to N3 on a NAT'd N3 IP address (10.0.0.0 range) with a DNS name published to N3's DNS servers (which the surgeries use for name resolution). Internally, we also publish our core server on the same DNS name on our own DNS servers, so that we can have a consistant FQDN for all clients, even though the IPs are different.
As N3 is accessable by all NHS sites plus various 3rd parties, there's fairly heavy control over which IP ranges and which ports are open both on our firewall and the surgeries'. Because of this, we publish all our software distribution packages via HTTP on the core server rather than UNC share.
As the agent packages all pre-date SP1, the only way the NAT'd clients can be getting the internal IP is if the core server is sending it with the package or the SP1 update to the client agents has broken something.