Once clientdbutil /validate runs it re-poplulates the local db. It is only scheduled to run once a day. After it runs the next time policy.sync.exe runs it should re-install your re-quired policies.
You can run clientdbutil /validate manually.
Interesting. This may cause some initial headaches, but thanks for the work around. So I see a Local Scheduler task for clientdbutil for 86400 so I'm assuming this is it but there is no /validate. What exactly does validate do? I really had my head around the whole amclient policy distribution method, and now it has changed. Is there going to be some form of public HLD released for this or maybe a Rex diagram?
Thanks again for the response. I'm going to see if it happens naturally before I try to kick it in it's ........
Ok, local scheduled task was scheduled properly.
Clientdbutil /validate was ran correctly - LocalSch.log indicates this.
Task still not ran on client.
Look in LDClientDB.db3 NO record of task.
Look in data folder no sdclient_tasklog
It runs and is successful
Look in LDClientDB.db3 no record of task.
Look in data folder and there is log file sdclient_task109.log but none named SDClientTask.CORENAME.109.log
So are pushes supposed to update LDClientDB.db3?
Why is the PSP not being ran after reimage?
Opened Case 00126900. Still an issue after SP1.
So are pushes supposed to update LDClientDB.db3? No. They are for policies only. If a PSP never becomes a policy it will never show up in that DB.
Why is the PSP not being ran after reimage? Because it's done. The policy thinks that the push successfully ran the task. The way you describe it working is the way I would expect it to.
I would only expect it to re-run it the job was a policy only...
I think the problem here is that you used a PSP and the task completed in the PUSH phase and was never considered a policy. In order for this to work the way you want, you would need to change the delivery method to just POLICY. Even though PSP converts to a policy after the initial job, it works more like legacy task completion than it does a strsight policy because of the machines that possibly completed the task during the PUSH phase.
So what I'm hearing is that this is a change from 8.7, and if this is true a drastic change (one in my opinion that kind of sucks). In 8.7 whether the machine recieved the task via a push or policy it always reinstalled after reimaging since the reg keys where not there. So what I'm hearing is that NO PSP tasks or Required Policies (yes required policies are not being be processed) can be redeployed after the machine is reimaged. I have tested this with a Required Once policy and it does not reapply. See the logs in the case.
I'm sure I'm not the only admin who will find this new twist rather troublesome, and in most cases unwanted. If this is all true, then IMO it will need to be fixed (yes I believe most admins will agree it is broke even though it is working as designed)?
Thanks for the update.
1 of 1 people found this helpful
It should have worked the same in 8.7. If you did a PSP and it completed in the PUSH phase, it never would have written to the registry key. Sounds like the apps that are re-installing are actually policies.
Yes sorry PSP will not get reinstalled (my bad). We Name our delivery methods very descriptively. CEG - PSP - Required, etc.... Apparently the name got altered. I was just looking at the Delivery method in the Scheduled Task Pane. When I went into the task it was a PSP but the name was changed - AAAARRRGGGGHHHH. I hate test servers. Sorry about that guys. I will rename it and use a required policy and retest.
Think it is time for a long vacation..... Too many sleepless nights lately..... :_| ZMan = Burntout.