AutoMatic Deployment Rules for Updates

[legion99]

We are in an SCCM 2012 Windows 7 environment and would like to use Automatic Deployment Rules to deploy updates. I have worked out a strategy of using the Custom Severity to allow us to manually choose which updates we want to apply as well as creating multiple rules for multiple locations to spread out the distribution throughout our environment. They have been tested and work correctly.

 

However our SCCM co-administrator is demonstrating what is in my opinion an extreme over abundance of caution regarding these rules and does not want them applied in our environment.

 

The two concerns expressed are:

 

-When we do the sync with Microsoft something will go wrong and the wrong updates will be applied to the wrong computers (I can't possibly see this happening)

 

-There will be issues when we eventually upgrade to R2. (I have not been able to find any evidence that this would happen)

 

Has anyone experienced issues with ADR bad enough to not use it?

 

 

Can someone help me assure my co-administrator and manager that this level of caution is not necessary?

[GarthMJ]

As a consultant, I don't recommend using ADR for anything but SCEP updates. Everything else is done via the defined process.

 

Healthy concern is good but honestly what more orgs are missing: is documenting the process they will use for both day to day and in an emergency. Then they have to review it every 12 months to ensure it still work for them.

 

What exactly is you process to ensure that the risk is minimized? What SU are you going to deploy and why? What SU Products are you going to deploy and why? How many groups will be deploy to and when? How can I stop the process if something goes wrong? Who can stop the process? Once stop then what? etc....

 

Once you write the process down, it is easy to deploy SU to 1 or 400, 000 computers.

[legion99]

But as a consultant have you seen ADR cause issues with the two concerns I mentioned? That is the question.

 

Obviously we have a valid reason for using ADR and are going to document a plan.

[GarthMJ]

As a consultant I would never recommend use ADR for anything other that SCEP update. IMO it is a bad idea with too much risk.

[legion99]

What risk are you referring to? That's what I'm trying to understand.

 

We test and pilot our updates before we approve them for ADR and we spread out our updates over a two week period in an environment of 8000 machines so we can stop the scheduling any time there are issues. And we wait a month after "Patch Tuesday" before testing patches in case there are revisions.

[GarthMJ]

We test and pilot our updates before we approve them for ADR and we spread out our updates over a two week period in an environment of 8000 machines so we can stop the scheduling any time there are issues. And we wait a month after "Patch Tuesday" before testing patches in case there are revisions.

 

This statement contradicts itself. ADR be definition automatic push out SU to computers. This is the risk as no testing is done on the SU. Hence the reason why I only use ADR for SCEP updates.

 

It sound like you are trying to use ADR instead of setting up SU groups and deploying them in a tested and staggered fashion.

[legion99]

Sorry but no it doesn't contradict anything if you use ADR's a certain way. You don't have to let ADR have complete control of deployments. The rule would be based on Custom Severity which by default is none. After we properly test the update we would set the severity so it's included in the rule, until you manually set the severity it won't be deployed so testing is not an issue. It's not complicated and not risky.

 

We would still be testing and deploying in a staggered fashion as I already described. Again this is not difficult with ADR, you can have more than one rule and more than one schedule. We have device collections based on location so staggering and scheduling is no issue at all.

[GarthMJ]

The rule would be based on Custom Severity which by default is none. After we properly test the update we would set the severity so it's included in the rule, until you manually set the severity it won't be deployed so testing is not an issue. It's not complicated and not risky.

I see no advantage of updating each SU with a custom then have ARD come into play, this seem like a lot of manual work. Why set hundreds of SU to have a custom severity, instead of just creating a SU group and deploy it?

 

Why not simply:

• Create SU Group
• Deploy it to your pilot group 4-5 people
• Deploy it to your test group (~1-3% of your computers)
• Deploy it to 1/3 of your computers
• Deploy it to the next 1/3 of your computers
• Deploy it to everyone.

This ensure that you are always testing against the same SU group and therefore there are no surprise. if there is a problem you can stop it and you don't affect everyone.

[legion99]

We do have them split into SU Groups. We do deploy to a pilot group and test, using ADRS would only involve one additional step which would be after the updates are piloted and working highlight them all and set the Custom severity, it's 4 clicks extra which is obviously not a lot of extra work. And we would have the ADRs deploying to different areas at different times as I have already explained. So we already have it planned exactly as you suggest.

 

The difference is we would be using ADR's which would mean we can deploy to slow network sites in the middle of the night after hours instead of during the day because it's automated. During the day the updates use up too much bandwidth in certain slow network sites and users complain about slow networks so night time deployments work best, we don't have maintenance windows or BITs throttling. Currently we have person who is actually deploying to these sites manually in the middle of the night which is outside our business ours and clearly not a sustainable solution.

[GarthMJ]

We do have them split into SU Groups. We do deploy to a pilot group and test, using ADRS would only involve one additional step which would be after the updates are piloted and working highlight them all and set the Custom severity, it's 4 clicks extra which is obviously not a lot of extra work. And we would have the ADRs deploying to different areas at different times as I have already explained. So we already have it planned exactly as you suggest.

 

The difference is we would be using ADR's which would mean we can deploy to slow network sites in the middle of the night after hours instead of during the day because it's automated. During the day the updates use up too much bandwidth in certain slow network sites and users complain about slow networks so night time deployments work best, we don't have maintenance windows or BITs throttling. Currently we have person who is actually deploying to these sites manually in the middle of the night which is outside our business ours and clearly not a sustainable solution.

 

IMO There are of things that can be done better. Like "bandwidth" has nothing to do with using ADR or not. The same is true for you deploys as they happen now, aka there is no need for middle of the night deployments. Why not use BITS?? Why not use Branchcache??? How are you DPs laid out? etc., etc., etc...

[legion99]

The original question was about risk. What risk is there is using ADR? It makes sense to us to use ADR to deploy updates at night when it won't affect users bandwidth, not sure why that doesn't make sense to you but that's not the question. As I said we don't have BIT's throttling, if it were up to me we would but we don't. We only have one DP, again not my decision. I'm trying to work with what we have.