Jump to content


legion99

AutoMatic Deployment Rules for Updates

Recommended Posts

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?

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

All I will say is test it.. as a consultant this is not what I would recommend. With 8000 computers, it is recommend to have at least two DPs.

Share this post


Link to post
Share on other sites

Branchecache does not work for updates on the version of SCCM that I have stated we have, like I said we haven't updated yet.

 

Also as I have stated I am not looking for a recommendation on what you think we need to do in our environment. You don't know our environment or why we have things setup the way we do. And our environment has been in place for 2 years we're not changing it.

 

Again the question is about the risks involved in using ADR's please only answer the question asked.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...