In 9.6 and newer, client side databases don't exist. The policies are downloaded and contained under ProgramData\Landesk\Policies. Is this behavior consistent with on-network devices? Can you append the policysync.log and policysync.exe.log file for review (programdata\landesk\log).

I thought as much in terms of the client side database. Strange that it exists on these clients unless the agent hasn't upgraded correctly. Removing the client side database does seem to change things a little in terms of what is displayed in the portal, however required tasks still aren't running.The device currently has one old executed policy, one required policy and one optional policy scheduled against it. Logs are below:

deactivateduser20. There lies your problem. In the PolicySync.log file we are have an issue getting the computer info from the registry: Tue, 23 Aug 2016 09:33:00 GetCachedInfo: QueryMultiStringValue failed ldap group info for Computer Groups - err=2

I would say you are bang on the money however the server and client do have SU4 applied. It does kick in and sporadically work however it doesn't seem to have any consistancy. I'm open to any suggestions at this point as the manual execution of the portal refresh and policysync.exe manually seems to have no effect. It's as though only the locally scheduled policysync works.

Some more info, All devices are either workgroup or on separate domains to the Core server that is in a workgroup.

deactivateduser20 we all hate inconsistencies. So if we are not on domain, let's make sure the targeted devices aren't being targeted via LDAP query. I would also log into one of the problem devices as a local admin and see if the issue still exist. If you are able to capture the occurrence via process monitor trace (unfiltered) I can review it.

So after further investigation I worked out that the policies being picked up wasn't as random as first seen. Infact I could pretty much guess when a policy was going ot be available and run a policy sync just in time for it to run.

The root cause? The clock time being wrong on the database server. I managed to replicate the issue in my pilot environment perfectly and was able to both cause and rectify the issue.

I've since put a request in to the hosted environment provider to have this resolved!