Windows 10 Updates – Order from the Chaos

Posted on Updated on

Since the original release in July of 2015 there have been six versions of Windows 10 released in total:

  1. Version 1507 (Codenamed Threshold 1)
  2. Version 1511 (Codenamed Threshold 2 aka the November Update)
  3. Version 1607 (Codenamed Redstone aka the Anniversary Update)
  4. Version 1703 (Codenamed Redstone 2 aka the Creators Update)
  5. Version 1709 (Codenamed Redstone 3 aka the Fall Creators Update)
  6. 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).

  1. Automatic Deployment Rules (ADRs)
  2. Filters

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:

  1. The 64 bit Windows 10 1703
  2. Updates that haven’t been superseded
  3. 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.

Windows 10 Updates – The Rules they are a Changing

Posted on Updated on

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.

Windows 10 SCCM & Intune Co-Management

Posted on Updated on

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.

Windows Autopilot vs System Center Configuration Manager

Posted on Updated on

I previously mentioned that I was excited to compare Windows Autopilot with System Center Configuration Manager (SCCM). Well, we finally have more details about Windows Autopilot and I’m finally able to give you a comparison of Autopilot and SCCM for Windows 10 deployments.

System Center Configuration Manager

Before I dive into Windows Autopilot, let us review the typical use cases for SCCM so that we have a basis for comparison. SCCM is an on premise tool that performs many functions in addition to Operating System Deployment (OSD) however; I will just focus on the OSD portion for now. Here are the three most common OSD scenarios:

Scenario 1 – Boot Media

This is a Light Touch deployment requiring physical access to each device. It is well suited to small remote offices or a small staging area without OSD infrastructure (Distribution Points etc.).

  1. SysAdmin creates a custom Windows Image, driver package(s) and task sequence
  2. SysAdmin either creates boot media
  3. Boot media is distributed to required locations
  4. Each device is booted with the boot media and the task sequence builds the device
  5. Applications can be added in the task sequence or post OSD through SCCM’s Software Deployment functionality

Pros

  • Minimal network impact
  • Minimal infrastructure requirements

Cons

  • Requires visiting each device (Light Touch)
  • Boot media management overhead

Scenario 2 – PXE Boot

This is a Light Touch deployment requiring physical access to each device to enter PXE boot – This can be made Zero Touch if the boot order is set to PXE first however, this is not a sustainable configuration. It is well suited to a large staging are or small remote offices with OSD infrastructure (Distribution Points etc.).

  1. SysAdmin creates a custom Windows Image, driver package(s) and task sequence
  2. Sysadmin deploys task sequence to a collection of devices
  3. Devices are booted and forced into network boot
  4. The device finds a boot image from the SCCM Distribution Point and
  5. Each device is booted with the boot media and the task sequence builds the device
  6. Applications can be added in the task sequence or post OSD through SCCM’s Software Deployment functionality

Pros

  • No media management
  • Easy modification of task sequences, boot images and driver packages

Cons

  • Requires visiting each device (Light Touch)
  • Requires complex infrastructure

Scenario 3 – Deployed Task Sequence

This is a true Zero Touch deployment that can be used a Self-Service option as well as a scheduled mandatory deployment. It can even be coupled with Wake-on-Lan to target devices that are powered off (but still connected to the network. This is well suited to upgrading or refreshing large numbers of devices currently in use as it requires that each device is already managed with SCCM.

  1. SysAdmin creates a custom Windows Image, driver package(s) and task sequence
  2. Sysadmin deploys task sequence to a collection of devices
  3. Task sequence is executed on device (Self-serve or scheduled)
  4. Required files are copied to the device and the device reboots and the task sequence deploys the operating system
  5. Applications can be added in the task sequence or post OSD through SCCM’s Software Deployment functionality

Pros

  • No requirement to visit each device (True Zero Touch)
  • No media management
  • Easy modification of task sequences, boot images and driver packages
  • Supports Self Service
  • Supports Scheduling

Cons

  • Requires complex infrastructure
  • Only available to existing SCCM clients

Windows Autopilot

Windows Autopilot is a cloud-based service that does not require any special infrastructure. Here’s a typical OSD scenario using Windows Autopilot:

  1. SysAdmin creates device profile(s)
  2. Sysadmin registers the device(s) with the Windows Autopilot service
  3. SysAdmin assigns a profile to the device(s)
  4. Device is booted end user
  5. Device is connected to network (any Network – home, work, public)
  6. User provides enterprise credentials, Language and Keyboard settings
  7. Device self configures based on assigned profiles
  8. If the organization uses Intune additional polices and applications may be delivered to the device

Pros

  • No requirement to visit each device (Near Zero Touch)
  • No media management
  • Easy modification of profiles
  • Supports Self Service

Cons

  • Cloud service (may be a con for some organizations)
  • Eliminates requirement of staging areas and internal device shipping
  • No support for system upgrade (maintaining user data and state information)
  • No support for complex configurations (multi partition, etc.)

Conclusion

InTune has been evolving rapidly over the last few years and has been able to provide much of the same functionality as SCCM such as hardware and software inventory, application management, software updates etc. The one feature that missing was OSD. Coupled with Windows Autopilot, Microsoft InTune is a credible end-to-end lifecycle management platform for many use cases that requires no on premise infrastructure. While it cannot service all of the use cases that SCCM can, it can save time and money for organizations where it is a good fit.

SCCM as a Service – Upgrade Checklist

Posted on Updated on

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:

  1. 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
  2. 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.
  3. Perform the prerequisite check
  4. 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.
  5. Use Pre-pilot collections to test client agents. This is a great way to minimize the impact of client agent defects.
  6. Check that all of your site systems have been upgraded
  7. 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.
  8. Test task sequences especially if there was an ADK upgrade involved
  9. 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
  10. Test the console update and any extensions such as Report Builder
  11. Test any pre-release features that you were previously using. Are they now released? Do you need to reenable the functionality as pre-release?
  12. Is this version available as a baseline build? Do you want to keep an ISO handy?
  13. Check for any post upgrade hotfixes.

Co-management – The Best of Both Worlds?

Posted on Updated on

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.

SCCM 1706 Feature Favourite – Managing Surface Drivers

Posted on Updated on

As many of you know, I am the cohost of the Universal Windows Podcast that started as the SurfaceSmiths Podcast – focussed on the Microsoft Surface.

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.

Prerequisites

  • 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

  1. 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.
  2. Synchronize the Microsoft Surface drivers.
  3. Deploy synchronized Microsoft Surface drivers

Introducing WinPE Peer Cache

Posted on Updated on

WinPE Peer Cache is a new feature of SCCM CB 1610. It functions in a similar manner to BranchCache however, it is only available for content access from the Windows Preinstallation Environment (WinPE). WinPE Peer cache is configured and managed as part of the SCCM CB client management settings.

A task sequence configured to use Windows PE Peer Cache can get the following content objects from a local peer while running in Windows PE:

  1. Operating system image
  2. Driver package
  3. Packages and Programs (When the client continues to run the task sequence in the full operating system, the client gets this content from a peer cache source if the task sequence was originally configured for peer cache when running in Windows PE.)
  4. Additional boot images

It is important to understand that WinPE Peer Cache is targeted at OSD scenarios and does not replace Distribution Points and BranchCache as locations for other types of content. For example, the following content objects never transfer using peer cache. Instead, they transfer from a distribution point or by Windows BranchCache if you have configured Windows BranchCache in your environment:

  1. Applications
  2. Software updates

WinPE Peer Cache only supports OSD scenarios that include a WinPE boot such as PXE boot or Boot Media.

WinPE Peer Cache is very new and is evolving very rapidly. To avoid possible issues with the model, Microsoft is adding features to create higher deployment success rates. Beginning with SCCM CB 1702, a peer cache source computer will reject a request for content when the peer cache source computer meets any of the following conditions:

  1. Is in low battery mode.
  2. CPU load exceeds 80% at the time the content is requested.
  3. Disk I/O has an AvgDiskQueueLength that exceeds 10.
  4. There are no more available connections to the computer.

Microsoft Education Event – Surface Laptop and Windows Autopilot

Posted on Updated on

At the Microsoft Education Event this past week, there were many announcements that we covered in the Universal Windows Podcast Episode 66. While most of the show was dedicated to the Education sector and Windows 10s, there were two announcements that I was particularly excited intrigued about. Specifically the new Surface laptop and Windows Autopilot.

When I try the Surface Laptop later this month I will check out the lapability but from the specs, there are definitely a couple of missing features that would fit my use cases. I’d really like to see a full USB-C port and built in LTE. From a USB-C perspective, I have run into issues with USB resources with my Surface Pro 3 and I think USB-C is the future. As the Surface Laptop is a premium device, for me to justify the price tag, I’d like to feel like the device has a long useful life ahead whether I keep it myself, hand it down to a family member or sell it. USB-C gives it a longer useful life in my opinion.

As far as LTE, I firmly believe the future is BYON (Bring Your Own Network). We won’t need to be hunting for free WiFi at Starbucks or airports and other locations with unknown risks and tethering while useful can be inconvenient and drain your mobile’s battery. There rumours that an LTE version might be out in the fall.

The most exciting reveal for me was Windows Autopilot. It appears to be a simple to use, Windows 10 mass deployment tool built for the classroom scenario. As I do a lot of work with SCCM, the de facto Enterprise class Operating System deployment tool, I am curious to see how this stacks up. I will do a side-by-side comparison once more details of Autopilot are available. Stay tuned.

When the Stars Align – Office365 and Windows Release Schedules

Posted on Updated on

This week Microsoft announced that Windows 10, Office 365 and System Center Configuration Manager would align their release schedules. They are looking at a spring and fall release most likely in March and September. This is great news for businesses that have being struggling to adapt to the new Windows-as-a-Service model align with Office-as-a-Service. There are definitely inter-dependencies between Windows and Office as well as SCCM the tool commonly used to deploy, update and manage both Windows and Office.

From an IT Management perspective, organizations have been trying to accelerate the engineering efforts previously put into Windows and Office deployments and operationalize the process but the various product release schedules with low predictability have made it difficult. This should help by providing regular milestones and predictability. Good Job Microsoft.

Here is a link to the release from Microsoft