Yes, policies should retry. I'm not sure on the interval, but I thought it was every day. I'll verify and get back to you.
I'll be gone from work tomorrow, but Friday I'll be back. If you haven't heard from me by Friday afternoon pop on here and leave a comment to remind me.
Is there a certain way my package needs to fail for it to retry? Right now, all I am doing is returning different values that match up with a return code template on the core. I am not sure the client really cares about return code templates, though...
According to the link in my first post, I set the retry interval for 15 minutes on one client just for testing. The client didn't retry
If you can supply your client side db3 file to me I'll open it and take a look. I'm not actively in support anymore so I can't remember off the top of my head what the schema looks like, but I remember it being pretty easy to navigate. If you'd like to use SQLite Browser and look through it to make sure there's no information you wouldn't want shared (there will be server names, etc. in there if that is a concern) and if not upload it here? If it is a concern I can let you know how to send it to me directly. When I'm back in the office on Friday I'll ask about whether or not the failure retry is entirely determined client side or if it is actually tied in to the error mapping on the core. It seems that the error mapping on the core might only be for the Console and the client side handling might be entirely client side, independent of whatever error code mappings you've set up. Before you run with that, though, let me verify, because my information is a bit outdated and rusty.
Quick follow up:
I opened my sqlite database file and it looks like you should be looking for the ReschedulePolicy table.
Also, I didn't mention where to get SQLite Browser (through SourceForge.net) or where the .db3 file is (%allusersprofile%\LANDesk\ManagementSuite\Database\LDClientDB.db3).
If the task is going to be rescheduled it will be in the reschedulepolicy table.
Here is a screenshot from my reschedule table on the client. It looks like it's rescheduled, but I would have expected it to execute again because my retry period is only 900 seconds. how do you interpret the rescheduleTimeT value?
Here is the policy retry
I can send you the the db3 file directly. I'd rather not post it.
Thanks for posting the screenshots. The time is a unix timestamp. If it's truly UTC time (which I don't think it is) then it's scheduled to run about 6 hours ago. [-8 If it's based on local time (which I think it is) then it's set to run Thursday at 2:23 AM your local time. If it is actually a true unix timestamp based on UTC time then there is likely a problem because it should have run already. You can verify that the policy client invoker service is running, because that is the service that actually maintains and utilizes the .db3 file and should kick off the task at the appropriate time. If it's running I'd wait until tomorrow morning and see if it attempted to run again and if the .db3 file got updated with a new rescheduleTimeT value.
Here's one website of many to convert unix timestamps:
Looks like the policy did retry last night at 11:42 PM local time. Not sure what's really driving the timing, though. Is Policy.Failed.WaitRetry honored in 9.0 SP2?
I'd like to speed up the retries. Not for production, but for testing so I don't need to wait a few days to test.
New screenshot from sqllite db on the client.
It looks like the rescheduleTime does contain the value "last time ran + Policy.Failed.WaitRetry". For example, the first run was at 9:07 local time. The waitretry was 15 minutes, so the rescheduleTime would be 9:23 PM, which is 13112150000 in timestamp lingo.
It ran again at 11:42 PM. The new timestamp is 11:57PM, or 1311224244 in timestamp lingo.
So, this begs the question, why didn't the policy re run at 9:23PM and 11:57PM and why did it run at 11:42PM?
Opened case 00545972 on it. In case I can get some support today on it...
Haven't heard from support yet, but it seems to be tied to policy sync's. The there was a policy sync at 11:42 and 9:07, when the installs actually ran. I am doing some more testing on it..
I updated a client db to retry failed policies every 5 minutes.
I intentionally fail a policy, I see that it's set to retry in 5 minutes by looking in the client db.
However, the job doesn't seem to retry unless I run a policy sync AND 5 minutes has elapsed.
Should it run regardless of policy sync's? If no, why have a retry interval at all considering you're dependent on the client policy sync schedule.
Hi! I'm back in the office. Looks like you've confirmed the current behavior, and internal testing looks like it indicates the same. The first question is if this expected behavior. If not this would be a defect that we could file with engineering. The second question is if this is desired behavior. (Hint: In your case it's definitely not.) In this scenario we could submit an enhancement request. Either way it looks like this is going to be bumped to engineering.
The good news is that now that we've determined the behavior you can easily test by running policy.sync.exe on your test system and tweak the retry time to test at will, so the negative impact can be managed. In production, of course, this behavior still needs to be sorted out.
What's the status regarding this behavior? Because I have the same issues, I'm not able to restart a failed policy quickl^y and for testing purpose it's not possible to wait so long... Changing the DB, then running Policy.Sync seems to work sometimes but not always...
Can I have the whole procedure regarding this? Please