My first suggestion based on the size of your shop would be to lengthen the time that amclient runs in the local scheduler (you indicated every 15 minutes). Depending on your node count this could really put a load on the core. I would say every 6/12 hours.
LANDesk has always had issues with resolving user based ldap queries when amclient runs via the local scheduler. The reason is that it is running under the local system account and it could not figure out who was logged on. There are several patches for this (and the reg key you mentioned). I've never been able to get it to work consistently.
Depending on how long you have the scheduler set for on the core (I think it defaults to 60 minutes) any additions to the ldap group should be reflected in the scheduled tasks target list. It appears you are using computer objects for your ldap target. Are you using an OU?
Look in your ldmain folder for a log file called schedldapresolver.exe.log. Open the file and look for something like:
2/1/2008 2:33:48 PM : Resolving LDAP object for task 1186
Check for any errors and make sure your task is being resolved.
Other log files on the core to evaluate:
SchedQry.exe.log & SchedQry.log
It should work as long as the machine at the time the task runs has access to the domain.
Policies run as the user if the user is a Local Admin. So when amclient runs, it can run as
1) a local non-admin user,
2) a local admin user,
3) a domain user that is a local admin,
4) a domain user that is not a local admin,
5) as Local System
If a user is a local or domain user but not an administrator or if no user is logged in it runs as local system. If the machine is a member of the domain, it can access the domain using the Local System account because it is a member of "Domain computers". However, the new amclient.exe design did not include to do check the domain when running as local system, so a CR was submitted and I have not tested it but it is supposed to work now in 8.7 SP5 (fixed after 8.8 was finished but 8.8 doesn't even use amclient it uses policysync so 8.8 may or may not work but I haven't tested). So it should work now.
If it is a domain user that is a local admin, it will run as the domain user and work.
If a user is a local user and an administrator to the local box, policies running as that user have no access to active directory and so it cannot find out the LDAP information. If amclient runs as this user, it won't apply ldap policies. This should now as of SP5 be the only time when it fails.
We have been investagating this with out LANDesk partners and one anomoly they have discovered is the tasks on the local scheduler. We have the usual tasks (ie 555, 600 etc) but we also have some strange ones with handles like 1202897075. Does anyone have any information on these?
It was explained to me that 1 - 1000 is reserved for LANDesk and 1001 - 2000 is user queries.
Does anybody know if this got fixed in 8.8?
We are soon starting our deployment, and I want to know the best way to set this up.
I´ve found a solution for you. Our company also uses Active Directory Groups to deploy Software and we encounterd the same problem as you.
The problem is that Landesk Managment Suite only synchronizes the ldap-query of Active-Directory and shows the object only as "Unknown" but the LDAP Object name is correctly resolved. This is not enough for Landesk to deploy the package to this computer. After hours of searching in several log-files i´ve found a way to correct this. Only SchedQry.exe is starting every 60 minutes automatically but you also have to start schedldapresolver.exe (this is not started automatically). I´ve created my own Microsoft Scheduled Tasks where i execute this (ldapsync.cmd):
start /wait SchedQry.exe /allqueries
start /wait schedldapresolver.exe policies
This solution works perfect and i hope that Landesk will correct this as soon as possible. It would also be nice if i can set a custom time for the SchedQry.exe because now it runs every 60 minutes. I hope this helps you and your deployment will work as it should be The best way to deploy software is to use AD-Groups, isn´t it?