There are a 101 ways of deploying software updates out there and you’ll undoubtedly get a different answer on the best way to deploy updates from every ConfigMgr admin you ask. Indeed it obviously depends on the environment and company politics how best the solution is implemented. This is my tuppence worth.
As an admin, you have enough to do in setting up the required updates in the first place. In many environments you’ll then have to raise the necessary change requests and all the headaches that entails. Then there is the deployment itself:
“Why did it install that?”
“Why didn’t it install that?”
My solution to this is to move the onus to the application or server owner to set up when their computers are patched.
1, STRATEGY:
Select you maintenance window(s). Ensure the window is of sufficient length to take into account all the updates that need deploying. If a ‘hard’ maintenance window is in force, bear in mind you might not finish installing and rebooting before it closes if it is set too short. For my example I will select three per day for different deployment types. This doesn’t mean there will necessarily be computers populated in all three collections, but the option is there. Agree these with all interested parties first. For example:
1800-2000 (Special applications)
2300-0100 (Workstations)
0300-0500 (Servers)
2. DURATION:
By duration I’m talking about how long to complete the deployment to the enterprise. For me, there are two scenarios here. I will typically roll out patches to the servers and/or workstations in my test domain before rolling out to live. The duration for the full rollout is 14 days for each environment (test/non prod and production). This (usually) leaves a few days in between patch Tuesday to download the new updates and deliver the update list for the coming month to interested parties to approve, before rollout on the following Sunday (‘Patch Sunday’). In many situations you may not have the advantages of a test environment to hand. In these situations you may potentially argue that a longer rollout period was necessary. However there are few situations I have ever seen where a 14 day cycle isn’t sufficient if proper testing is put in place.
3. DEFER OWNERSHIP:
As alluded to earlier, IMO the onus should be on the SCCM admin to set up the job but after that it should be up to the application owner or server team to administer when their servers are patched. Ideally the patch window for the server should be set at the server build stage and should be specified in the original request.
My approach to this is to ensure all the software update collections have a query rule assigned which defines a particular AD group that can be updated by the interested party. Responsibility then falls squarely on the owner for any problems related to when the machine is updated.
4. AD GROUPS, QUERIES AND COLLECTIONS
This is how I set up my collections in SCCM along with the queries and groups.
EXAMPLE AD GROUP:
Name: PR1-SCCM PRD-07-2300-0100 (Site PR1, Prod environment, day 7, 2300-0100)
EXAMPLE COLLECTION:
Software Updates – WK1 – Saturday – 2300-0100 or Software Updates – WK2 – Wednesday- 2300-0100
EXAMPLE QUERY RULE:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.SystemGroupName = ‘DOMAIN\\PR1-SCCM PRD-07-2300-0100’ and SMS_R_System.Name not in (select distinct SMS_R_System.Name from SMS_R_System where SMS_R_System.SystemGroupName = ‘DOMAIN\\MW Exception Group’)
Note:
DOMAIN\\MW Exception Group represents a group that a computer can be dropped into if for some reason it needs removing from its usual schedule temporarily.
5. NO REBOOT GROUP
In addition to the three daily maintenance window collections, another daily collection I have set up is one with no reboot. Indeed this is of particular interest to certain application owners who only have a narrow window where servers can be down. They take the responsibility on themselves to manually reboot these machines at a time convenient to them.
6. ADMINISTRATION
So…if should you decide the above all sounds like a great idea (that’s a big if, but go with me here) we’re talking about over 60 collections to deploy updates to. That’s going to take all week to set up isn’t it, particularly if there are a lot of update to deploy? Well yes, it is. If done manually. Powershell would traditionally be your friend here and when I first started this, that is exactly what I was using. What I found in practice though was even with this I wanted to see what was going to happen first and again you could write scripts to do this too. What I decided on though was to write a tool that would do everything for me. When I say everything, I am including creating collections, hard maintenance windows (if required), AD groups, queries and of course the selection, deployment schedule and deployment of the updates themselves. This tool is adaptable for different environments and should make the whole process very simple. Whilst I take no responsibility for how you use it in your environment, I have used it in live and prod environments at clients I have consulted and all sorts of different test environments. I include the download and source code at the end of this blog.
7. TO WRAP UP
This blog has detailed my specific approach but the high-level is really what it’s about. As I mentioned in my opening paragraph, one size does not fit all but I do believe some of the pressure (and work) can and should take a shift sideways. Some computers you’ll most likely always have to deal with, eg workstations/laptops. The systems that cause the most headaches though are the servers and I firmly believe ownership can and should be shifted here. It won’t work everywhere but it’s all about changing culture.
Toolio_SoftwareUpdateTool_Instructions
ToolioSoftwareUpdateTool_Source_v2.9.1 (C# source code)
Toolio_Installer_v2.9.1 (exe)
Let me know any issues you have and hopefully I’ll be able to help you out. Please make sure you test before putting into production and I take no responsibility for use!
Now the 10801 error seems somewhat ubiquitous regardless of what the actual issue is. For example, you’re as likely to receive it for a run book you’ve forgotten to check in as you are for using an account without publishing permissions. Unfortunately given how commonly this error seems to occur, there appears to be precious little about it on the internet. Indeed I have to confess I never found the proper solution to fix the problem. Anything vaguely approaching a solution seems to centre around running the following SQL script on the Orchestrator database. It might be worth trying this before attempting the workaround below:
