My LDAPPL3.template file updates every night on the server--the content does not change but the date of the file does. This happens around 11pm every night. This causes the ini file to go to all computers every morning since the file date has changed -- results in unnecessary network traffic. What's the deal?
Are you sure it's the template file? That is not the file that clients check for so if it gets updated it will not cause the LDAPPL to get downloaded. The clients check the .PAZ and .BASE.
If you are on 8.7 or later one thing that could be happening is that new products are being discovered on machines which causes the LDAPPL to get updated and thus downloaded. Is this a newer install or upgrade?
Hmmm, very strange I just checked mine and it is also being modified (at least last evening). I checked and it is being changed at the same time the inventory service does a DB maintainance (check your application log for the same time as the modified date). Sounds like a bug in the inventory service when it does a db maintainance. 8.7 sp3.
Anyone else have this issue?
I'm not sure what file gets updated first on the server but all files are updated relating to ldappl3--the .ini, .ldz, .pat, .paz, and .template files all have the same time and all update every night.
We're running 8.7 SP4
Are you also on SP3 like Zman? You probably need to bring this to LANDesk's attention by calling Support and opening a case.
1 of 1 people found this helpful
Sorry missed this post. I still think you should call LANDesk Support. I don't see this issue on the post SP4 or SP5 patch notes, but maybe they slipped in the fix with another one.
we've the same, since we migrated from 8.5 to 8.7 SP3/SP4.
I've heard that it may be caused by things changing (probably product definitions) and that is causing the ldappl to change. If I get sometime I will complete a file comparison, before and after.
Hey veryone, we have the same thing going on here. LD 8.7 SP4 on W2K3. Crazy amounts of traffic going over the WAN over HTTP 80 from the core; the network guys were complaining that our Core server had spewed 400 MBs over 4 hours. I'm sniffing the traffic now to see what's in the packets. Looks the LDAPPL3.ini has a new datestamp generated every night also.
So, I'm very interested in this thread.
Our traffic is coming from TCP port 445. Our workstations are XP SP2 and the core is on a W2K3 SP1 server. This traffic is non-existant if I disable the landesk inventory service on the core.
Well, I read in the documentation where a new ldappl3.ini file is created by combing both ldappl.baz and .paz files (these sizes correlate with the traffic reported by our Network group). Using wireshark, when I look at the payload of the packets being sent I can see the baz and paz files (size wize) and if I follow the tcp stream I can read the actual lines that will be used to created the ldappl3.ini files. So I know the files are being sent from the core.
Our single core server is set to do an inventory scan nightly and the timestamp of the ldappl3.ini file is always a few minutes after the scan is finished. Since the ldappl3.ini file has a newer timestamp, it's being pushed daily to all clients. My question: what is the recommended frequency for this scan? I have not found any documentation stating what is recommended and I would like to reduce some of the traffic going across our WAN. What are the caveats to changing the scan frequency on the core? Does the client phone home, compare file datestamps and then request a new one or does the server see the client has an older ldappl file?
Any ideas? Let me know. Thanks.
There are no "official" recommendations for most settings, because the best part of them are a case of "it depends on what you're trying to achieve" and what your environment is like.
There's simply too much variety to cater for here.
Clients CAN "phone home" (assuming they can hit the Core - either through a Gateway or the corporate LAN) if you configure them to do so (Local Scheduler is used for this, with various filters) ... or at least they can try to.
Depending on how many clients you have, you may want to add random filters or stagger your clients' windows. Having - say - 10,000 clients all hit the Core server at once is not the best ways of ensuring you'll get any kind of decent response.
Now, clients - by default - will ALWAYS compare their LDAPPL versus the Core's, and if the Core has an update, they'll get the newer one. This shouldn't happen an awful lot once things get settled, since there shouldn't be many updates coming in to the LDAPPL very frequently. (So - in answer to your question - the client compares his LDAPPL versus what's on the Core, and it decides whether it is out of date or up to date).
So - trying to understand your environment a bit better and what you're trying to acheive exactly would help.
LANDesk EMEA Technical Lead.
Is anyone on SP5 and experiencing this same issue?
I have two SP5 cores running neither have updated the ldappl3 in over a week...