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.
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.
Is SCCM right for you or is InTune a better fit? Why choose? Use Both!
Beginning with the Fall Creators Update for Windows 10 (aka 1709) Windows 10 devices will be able to join both on premise AD domains as well as the Azure AD service. This opens the door to have devices managed by both SCCM and Intune. While administrators can use co-management to split up specific servicing workflows such as using SCCM for application deployment and Intune for update management so that devices get updates wherever they are, the co-management bridge is intended to simplify the migration to cloud based modern management services and not a long term solution. It would be really nice to be able to mix and match servicing scenarios so that as a device moves between on premise and off premise they are serviced by the most appropriate tool however at first glance this functionality is not readily apparent.
Now that Autopilot is available for Operating System Deployments, Intune + Autopilot provides a credible solution for full device lifecycle management for many use case scenarios. I expect to see more organizations using the co-management bridge to begin their migration to modern management.
I still use a Surface Pro 3 and many of my customers use SCCM to manage Surface devices. In fact, The Surface Pro is the tablet of choice in the Canadian federal government. So how is this related to SCCM 1706? While there are many new features in SCCM 1706 that you can read about here, there is a pre-release feature that is particularly interesting to anyone that has to manage Surface devices. The feature provides the ability to manage MS Surface driver updates with SCCM.
- All software update points must run Windows Server 2016.
- This is a pre-release feature that you must turn on for it to be available. For more information, see Use pre-release features from updates.
To manage Surface driver updates
- Enable Synchronization for Microsoft Surface drivers. Use the procedure in Configure classification and products and select the Include Microsoft Surface drivers and firmware updates checkbox on the Classifications tab to enable Surface drivers.
- Synchronize the Microsoft Surface drivers.
- Deploy synchronized Microsoft Surface drivers
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.
Love it or hate it, but Windows 8.1 was intended to be both a desktop and “device” operating system. There have been many articles written about how well it succeeds or fails at one or both of those objectives. Regardless of how you feel about Windows 8.1, if you are tasked with managing it in you enterprise, you don’t need another rant / rave post. You need some guidance on how to manage some of the intricacies that Windows 8.1 and some device form factors like the Surface bring into play. That’s what this series of posts aims to do.
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.
As part of Microsoft’s attempt to create an OS that is appealing to tablet device users, Microsoft introduced the Windows Store. The Windows Store is Microsoft’s version of Google Play, Apples iTunes App Store, the Amazon Appstore for Android and many other sources for device based apps. The current incarnation of the Windows Store showcases Modern UI (formerly known as Metro) applications.
Like the other AppStores, the Windows store is designed for consumers to purchase applications to run on their devices. Unlike the other AppStores, the Windows Store model needs to coexist with legacy software delivery methods in use by enterprise IT departments such as SCCM. While inconvenient, this is not a knock against the Windows Store. Other platforms don’t have this issue because they don’t have any legacy applications or enterprise software delivery models.
What can we do Today?
For now there are really two methods for managing Modern Apps in an enterprise setting:
- Requires Certificate to sign the app since it will bypass the store validation
- Requires .Appx Bundle from the application developer / vendor
- Applications can be inserted into image with DISM
- Applications can be distributed with System Center Configuration Manager
- Requires Windows Store account for each user (does not need to be linked to domain account)
- Associates application with user
- Applications cannot be included in image
- Still requires some user input (not truly silent)
Access to the Windows store can be controlled through group policy.
If you choose to permit users to access the store there is still the ability to restrict or allow specific applications with AppLocker.
Coming with Windows 10
Microsoft has announced that this will get easier with Windows 10. Organizations will be able to setup a private “boutique” within the Windows Store and curate which applications their users will be able to browse and install. Organizations will also be able to use a single store account to make volume purchases and download the installation files and distribute them in ways that make sense for their use cases (machines without internet access, reassigning applications, etc.).
Microsoft’s Surface Tablet/hybrid has been steadily gaining traction in as both a consumer device and a business tool. I use mine for both personal and business use. I haven’t turned on my iPad in over 5 months and I’m only using my laptop as a test bed for pre-release versions of Windows 10. My Surface Pro 3 has become my go to device. My mobile phone and Surface meet 95% of my requirements without any compromise.
Microsoft has been rolling out Surface drivers and firmware updates through the Windows Update service. This works great for personal devices but IT departments have struggled to keep the devices updated using their traditional tools.
Enterprises need the ability to roll out Surface Updates with procedures that adhere to best practices and integrate into the processes that are already in place for other domain joined devices such as Windows Intune and System Center Configuration Manager (SCCM).
The Homebrew Solution
What does a smart Sysadmin do to solve the problem? He (or she) builds their own cumulative update payload that includes all updates including (patches, firmware, and drivers). Make it easy to manage and install in unattended mode with a smart wrapper like PowerShell or Windows Installer / MSI.
The Microsoft Solution
Microsoft has released a solution that meets all of the requirements of the homebrew solution but you don’t have to build it yourself. Here’s a link to the January payload. There are multiple files that can be downloaded from the link. Select the Surface Pro 3 January 2015 MSI.zip
It will install all drivers and firmware that have been released through January 2015. As new updates are released new MSI files will be available for download.
- It doesn’t contain all Surface Pro 3 drivers, just the driver updates
- Touch firmware updates are not included
- It will create an entry into add/remove programs
- There is an option that allows the installation operations to be logged verbosely for troubleshooting
Here’s a good post with a step-by-step that explains how to use the MSI with System Center Configuration Manager (SCCM) and System Center Updates Publisher (SCUP).