40 votesRyan Davisson commented
I'm not sure specifically of the ADR process, but it would also be important to make sure the ADR disables the Deployments it previously created before evaluating the updates/downloading/adding them to the SUG and resetting the deployment settings (ie. scheduling, enable/disable, etc.). We've had issues the past few months with SQL deadlocks during ADR processing that caused a failure, where an ADR had evaluated and pulled all of the updates in to the SUG and then updated the settings for some, but not all of the Deployments. This left us in a state where some old deployments were previously enabled and past-due on the deadline, but loaded with new updates. There wasn't a bug in that instance, but due to the manner in which the ADRs process through the steps, we had updates going out to our devices outside of the normal, expected schedule that the ADR was supposed to maintain. We now have to support a script on the site server that disables those deployments ahead of the ADR, just in case there are further errors during the ADR process. If the ADR were to disable previously created Deployments before doing anything else, that would build a fail-safe in the event of an error that disrupts the complete ADR process.