What date/time field is evaluated when using the "Monitor threshold for failed deployments to prevent false flags" setting?
We can see that it's not using the DateTime (aka request date) column value , because the timer doesn't start until any applicable approvals are satisfied, but I assume it's one of the other DateTime values in the WD_PackageRequests table....
Is it the "LastTime" or "LastStateTime" value? Or something else?
@CharlesW WRT this timer: What is the expected behavior in the UI that we should see?
Scenario: Timer is set to 7 days to monitor for false flags. Catalog item is requested today and the deployment fails due to a content download issue. I would expect to see a failure status in the UI, but on the backend App Portal will continue monitoring SCCM for a change in status and then will update the status in the UI if the status changes? Unless 7 days passes in which App Portal will enter a final status of failed and discontinue monitoring.
Is this the correct thought process?
That is my understanding (and I think coincides with the behaviors I've seen), but I'd be interested to hear Charlie's input.
The "Monitor threshold for failed deployments" functionality uses the LastStateTime column in WD_PackageRequests.. If a failure status is received from Config Mgr, then the failure status will be written WD_PackageRequests table under the lastStateID and LastStatusID columns.. The LastStateTime colum will also be updated with the time that the (initial) failure occurred. The Monitor flag will remain set to 1 (true). App Broker will continue to monitor the status until X hours has elapsed, as compared to the LastStateTime column.. Once this time has elapsed with no change in status, the monitor flag will be set to 0, and notifications and events tied to "on failure" will be processed.. As monitor is now 0, no further processing will occur on this request..
The end user should see a failed status under my requests, but they will see this change to success if the deployment is eventually successful within the threshold period.
@CharlesW @jdempsey From your experience have you seen a max time that you would recommend for this timer to be set for? We currently have it set for 168 hours, but in our environment MECM re-evaluates the deployment state every 168 hours (7 days) so we are not actually seeing that change of status if the application ends up successfully installing after a failure. We are weighing the pros and cons of lowering the MECM re-evaluation policy vs increasing the monitoring timer on the App Portal side.
It really comes down to SLA's and end-user expectations. If I'm an end-user requesting an application and I haven't seen it get installed within a week, I'm probably calling IT to find out why it hasn't been installed yet. In your situation, if MECM isn't going to retry again for 7 days, it probably isn't very helpful for this purpose, so I would suggest not setting this App Broker timer (i.e. let it expire immediately when a failure is reported). That way, IT gets notified right away and can take proactive measures to resolve it before the end-user gets frustrated and reaches out to IT for answers. On the other hand, if you have defined SLA's that are longer and the end-user knows it could take up to 2 weeks to get an application installed, then you could simply increase the timeout from 168 hours to 192 hours, and that should allow MECM to try again and only report a failure if it fails a second time.
Well, in theory you could, if the site gets a ton of request volume. But I wouldn't really expect it to be noticeable just changing it by a day versus 7 days. In general, I suggest keeping the retry interval shorter (e.g. daily) and keeping the false failure timer lower (probably no more than 48 hours, but depends on the retry interval). But you have to weigh the benefits of faster software delivery against the impacts of changing the retry interval (MECM system load, network load, etc.).