In the last few years SCCM has been introducing new features to the software update workflow to help with server update scenarios. Features such as Server Groups, maintenance windows, and Pre and Post deployment actions allow an unprecedented level of control over how and when servers are patched.
Top 10 Reasons to use SCCM for Server Updates
So what are some of the benefits of using SCCM to update servers compared to other tools like WSUS? Consider the following:
- Granular Deployment Control – Unlimited number of Collections based on Technology and Business requirements
- Automated Maintenance Windows – Patches will only deploy during scheduled maintenance windows
- Pre and Post Automation – Run Scripts before and after Updates (Example: Create a VM snapshot)
- Restart Management – Control over Server restart behaviour
- Automated Deployment Rules – Automate repetitive business logic based patching scenarios based on predetermined selection criteria such as platform, product, classification etc.
- Update Templates – Create scenario based templates to accelerate patching and minimize errors
- Rich reporting – Dozens of canned reports for updates management and status as well as the option for custom reports
- Bandwidth management and optimization – Use local repositories and peer caching to minimize the amount of network load and accelerate deployments. Schedule and throttle bandwidth usage based on time of day.
- Server Group Control – Logic based on number, percent and order of servers to be patched at any given time. Ideal for clusters and load balanced services.
- Query based targeting – richer targeting based on asset inventory data
That’s a lot of control and conceptually difficult to understand. I used to love the superflows in the old SMS documentation. I’ve created a miniflow of my own to help you understand how some of the new features can be used to take better control of the server update process.
Since the original release in July of 2015 there have been six versions of Windows 10 released in total:
- Version 1507 (Codenamed Threshold 1)
- Version 1511 (Codenamed Threshold 2 aka the November Update)
- Version 1607 (Codenamed Redstone aka the Anniversary Update)
- Version 1703 (Codenamed Redstone 2 aka the Creators Update)
- Version 1709 (Codenamed Redstone 3 aka the Fall Creators Update)
- Version 1803 (Codenamed Redstone 4 aka the Spring Creators Update)
Microsoft’s near term roadmap is to release two more feature updates every year. Version 1809 (Codenamed Redstone 5) is due later this year.
The number and frequency of releases coupled with new servicing models has led to a lot of confusion in the industry around managing servicing branches, quality updates vs. feature updates and the cadence of the release cycle of Windows as a Service (WaaS). In this post I’d like to focus on two simple things you can do to simplify your windows 10 updates if you are using System Center Configuration Manager (SCCM).
- Automatic Deployment Rules (ADRs)
ADRs let you automate how, when and what software updates are applied to your systems using repeatable, template, scheduled business rules. There are many good posts on ADRs and some very good videos by Jason Sandys (A fellow MVP) so I’m going to focus on Filters.
If you are using SCCM to update your Windows 10 systems you will notice that in the Software Updates there are a lot of Windows 10 updates. That is because as we know there are many different Windows 10 versions. Most organization will not be running all versions and do not need to be bothered with many of the available updates. For instance, if you search for all Windows 10 updates, you will see more than 150 updates. If you are only running Windows 10 1703 the majority of those updates will not apply to you. If you use a filter, you can reduce the number of irrelevant updates significantly. Consider this ADR filter:
It returns at all updates for Windows 10 limited in the following ways:
- The 64 bit Windows 10 1703
- Updates that haven’t been superseded
Updates that are classified as either Critical, Security, Update Rollups or Updates
This filter reduces the number of updates in the update group from over 150 to just 4 items. A little bit more manageable.
You may also notice that I have added the keyword “Malicious” to include the Malicious Software Removal Tool (MSRT) as I find it useful to include in my ADRs.
You can use the search criteria in a similar way if you are creating software update groups manually.
I use filters regularly to help organize my software update groups and create some order from the chaos that is Windows 10 updating.
Microsoft announced on February 1st that they will be adding another six months to the supprot of Windows 10 version 1607, 1703, and 1709.
|Release||Release Date||End of Support||End of Additional Servicing for Enterprise & Education|
|Windows 10 1511||November 10, 2015||October 10, 2017||April 10, 2018|
|Windows 10 1607||August 2, 2016||April 10, 2018||October 9, 2018|
|Windows 10 1703||April 5, 2017||October 9, 2018||April 9, 2019|
|Windows 10 1709||October 17, 2017||April 9, 2019||October 9, 2019|
Up to this point Microsoft has offered 18 months of support for each Windows 10 release. This extension seems a direct repsonse from enterprise customers struggling to keep pace with the rapid release cycle and short support windows associated with Windows as a Service.
Windows as a Service isnto only new for customers. It’s new for Microsoft as well. As they figure out how fast customers can ingest all of the innovatiosn comign out of Redmond, we’ll see the release cycles stabailze and balance update frequency with upgrade readiness.
For organizations that are having trouble transitioning engineerg efforts traditional associated with operating system updates to a more operational model, tools like Intune and SCCM can help accelerate the transion. I’ll be writng a few pieces in the future on how to take advantage of these types of tools to simplify Windows 10 update management.
As System Center Configuration Manager (SCCM) matures into an “as a Service” model, the ability to rapidly upgrade an infrastructure has come a long way. It used to be complex and time consuming to upgrade SCCM as you would have to download all the prerequisite media test everything in your lab and then schedule the downtime in your production environment. With the advent of SCCM Current Branch (CB) the ability to upgrade directly from the console has made this much less complex and in theory less error prone. This doesn’t mean you shouldn’t take precautions and test before rolling to production. Here’s some advice on how to manage the risk associated with the upgrade:
- Backup your environment and test the restore in case you need to rollback. You do this regularly anyways right? There are several supported backup options for you select from based on your particular requirements. Here is some backup and recovery guidance just in case
- Check your site and component status to make sure you don’t have any unresolved issues that might impact the upgrade. Check them again post upgrade.
- Perform the prerequisite check
- Test everything in your lab, sandbox, or test environment before upgrading in production. You don’t have a test environment. Well you do you just like to call it “production”. You can setup a really simple and inexpensive virtual lab in Azure that you can spin down when not in use.
- Use Pre-pilot collections to test client agents. This is a great way to minimize the impact of client agent defects.
- Check that all of your site systems have been upgraded
- Test basic functionality such as HW and SW inventory and Software Updates. This puts the basic components such as MPs, DPs, SUPs and client agents through a smoke test.
- Test task sequences especially if there was an ADK upgrade involved
- Check if there is a newer version of MDT available / required in order to work with particular ADK you are using and to support any required servicing branches
- Test the console update and any extensions such as Report Builder
- Test any pre-release features that you were previously using. Are they now released? Do you need to reenable the functionality as pre-release?
- Is this version available as a baseline build? Do you want to keep an ISO handy?
- Check for any post upgrade hotfixes.
As organizations move to modern management to be more agile in the way they manage multiple types of devices and cloud based services, the legacy management models associated with traditional PC management can lead to multiple consoles for managing different types of devices and services. At Microsoft Ignite this year, a hybrid approach called “Co-management” was announced. to bring organizations closer to modern management while still maintaining traditional management methods. In the past it has been difficult to use more than one management platform for the same device. Windows 10 1709 opens the doo this co-management by allowing devices to be managed simultaneously with SCCM 1710 and with Intune. What are the benefits of co-management? Here’s a few that come to mind.
- Manage devices where they live. Use SCCM to manage devices that are primarily on premise and use Intune to manage the same device when it is roaming.
- Transition workloads to Intune as you are ready
- Add modern management functionality to traditionally managed devices. Consider device compliance policies, resource access policies, Conditional access, selective wipe, factory reset etc.
- Single pane of glass for consolidated views of all devices such as mobile phones, tablets, Macs, PCs.
- Transition Windows 10 devices to Intune while managing legacy (Windows 7) devices with SCCM until they are upgraded or lifecycled.
- Self-provisioning of devices by end users
- Simplified BYOD scenarios
- Enhanced mobile workforce management
So, is this the best of both worlds? Nto really. Microsoft views this as a transitional step on the journey to modern management. Nonetheless I’m excited about the new opportunities for organizations to deliver a better user experience.
As organizations upgrade to Windows 10 there are many opportunities for security and performance improvements. Many of these enhancements rely of functionality that is only available with UEFI firmware as it is required for secure boot which is often a prerequisite for enhanced security features such as Device Guard and Credential Guard. Since Windows 7 did/does not support UEFI, most organizations will need to convert device firmware to UEFI as part of the Windows 10 upgrade. As upgrading to Windows 10 can be a long process, organizations have looked to tools like SCCM and MDT to automate and accelerate the process. Often time performing zero touch installations of hours or through self-service. Converting Bios to UEFI as part of the process ahs been problematic as each device may have different methods for converting and it typically requires visiting the device since the change happens in the before the operating system loads.
Microsoft has just made this problem a little easier to manage. SCCM 1702 introduces the ability to include UEFI conversion as part of a Task Sequence if the device supports it. I’m looking forward to accelerating many Windows 10 migrations with this functionality.
Managing Windows 8.1 and the MS Surface in the Enterprise – Part 2: Deployment with System Center Configuration Manager
I’ve been selected to deliver a session next month as part of the Microsoft MVP Virtual Conference – You can register here. My session is focussed on the managing the MS Surface in the Enterprise and as part of my preparation I’ve been assembling lots of nuggets that will be scattered throughout the presentation. This blog post series is an attempt to aggregate some of the more significant pieces from the session that may have broader appeal. This is the second installment in the series. Here is a link to part 1 – Who’s Minding the Store.
As more and more organizations are deploying Surface devices there are some special considerations when deploying with Configuration Manager:
- Since the Surface doesn’t have a physical NIC, if you will probably need a USB NIC or docking station. If you are reusing the same dock or USB NIC, Configuration Manager will need to have the MAC address of the NIC cleaned out after each deployment. This blog provides more information on the issue and provides a script that can be used for the cleanup.
- The Surface Pro 3 Class 3 UEFI device. In order to support PXE bot for such a device Windows Deployment Services(WDS) must be at least Windows Server 2008R2 with Windows Server 2012 Boot image (Windows Server 2012R2 WDS with 2012R2 boot image is recommended)
- DHCP Scope Options 66/67 will not work with mix of BIOS and UEFI systems. Ip helpers must be used instead.
You may want to download the Deployment and Administration Guide for Surface Pro 3.