Updating Windows Servers – SCCM Patch Deadline Behaviour

Posted on Updated on

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:

  1. Granular Deployment Control – Unlimited number of Collections based on Technology and Business requirements
  2. Automated Maintenance Windows – Patches will only deploy during scheduled maintenance windows
  3. Pre and Post Automation – Run Scripts before and after Updates (Example:  Create a VM snapshot)
  4. Restart Management – Control over Server restart behaviour
  5. Automated Deployment Rules – Automate repetitive business logic based patching scenarios based on predetermined selection criteria such as platform, product, classification etc.
  6. Update Templates – Create scenario based templates to accelerate patching and minimize errors
  7. Rich reporting – Dozens of canned reports for updates management and status as well as the option for custom reports
  8. 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.
  9. 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.
  10. 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.

Windows 10 Multi-Factor Authentication

Posted on Updated on

Introduction

Windows 10 Multi-Factor Authentication (MFA) is a security system that requires more than one method of authentication from independent categories of credentials to verify the user’s identity for a login or other transaction.  MFA provides additional protection against brute force and other password based attacks.  Three common MFA options available in Windows 10 include:

  1. Picture Password
  2. PIN
  3. Windows Hello (Biometric support for facial, iris, fingerprint recognition, companion device, etc.)

Active Directory Integration

All three of the MFA options in scope for this briefing can be enabled and disabled through Active Directory Group Policies.

Dependencies & Prerequisites

In order to implement Device Guard, the following capabilities need to be present:

 MFA Option  Requirement  Description 
Picture Password  Windows 8 or newer The PC must be running Windows 8, 8.1 or 10. Of course Windows 8 is no longer in mainstream support.
Picture Password  Touch Interface The device must support a touch interface
PIN  TPM The Trusted Platform Module is required to store the PIN and password hashes.
Windows Hello  PIN enabled Windows Hello requires that PIN access be enabled.
Windows Hello Facial Recognition  Supported Camera Windows Hello facial recognition requires a supported camera.  Currently the Intel RealSense 3D camera is one the most common supported.  Over time other cameras will also be supported
Windows Hello Fingerprint  Supported Fingerprint Reader Windows Hello fingerprint recognition requires a supported fingerprint reader.
Windows Hello Companion Device Supported Companion Device Use an authenticator app on a companion device such as a mobile phone or wearable to authorize access

Integration

Windows 10 MFA integrates with Microsoft Passport and with Active Directory to provide seamless authentication through a number of common use cases.

Functionality

The Microsoft MFA options considered for this briefing are typically intended to act as a substitute for regular password authentication.  Here will be scenarios where the password will still be required however for the majority of use cases, the password may not be required if the end user is using one of the described MFA options.

Microsoft MFA solutions addressed are designed to strike a balance between security and ease of use.  Most users report that using a MFA is convenient enough that they do not feel it is an undue burden.

MFA Option  Functionality Description 
Picture Password  They user must correctly reproduce three gestures on an image of his/her choosing.  Gestures can include, shapes, lines, and spots.
PIN  They user must correctly enter a PIN (complexity controlled through GPO).
Hello Facial Recognition  The device camera constantly looks for the users face.  Once detected, the device unlocks itself.
Hello Finger Print Recognition  The user must place a digit with a registered finger print on the devices finger print reader.  If it matches a registered print, the user is granted access to the device with the account with which the print is registered.
Hello Companion Device The user is prompted to authorize access on a companion device either with a PIN, Push, or biometric prompt

If the user fails one of the authentication methods, they will need to use a password to unlock the device.

Deployment Considerations

All of the MFA solutions considered can be deployed using GPO with minimal impact on current end user login methods.  Once enabled, additional options are regularly becoming available.

All of the addressed solutions consider the device as one of the authentication factors.  Pins, Picture passwords, and biometric signatures are not stored or managed centrally.  They will need to be managed on a per device basis.

It is recommended that end user training take place to ensure that staff understand the additional authentication options and any additional precautions that might be required to safeguard the additional factors.

Consider integrating with Azure Active Directory for more advance Conditional Access options

Issues and Caveats

There are known issues and methods to bypass some of the Microsoft MFA options addressed.

MFA Option  Known Issues 
Picture Password  Users must take care to avoid others from watching them while they enter a picture password.  This may not be ideal for crowded environments.  Additionally, users must take care to clean the device screen regularly to avoid leaving smudges that simplify guessing to reproduce the picture password.
PIN  Users must take care to avoid others from watching them while they enter a PIN.  This may not be ideal for crowded environments.  Additionally, users must take care to clean the device screen regularly to avoid leaving smudges that simplify reproducing the PIN.
Hello Facial Recognition  User can inadvertently unlock a device if they enter the camera’s field of view.  An unsuspecting user may also be “tricked” into unlocking a device by somebody who quickly “flashes” the device in front of them.

Hello Facial Recognition relies on infrared scanning of features and cannot be “fooled” by photographs or even identical twins.

Hello Finger Print Recognition  There are know issues with false negatives based on changes to digits based on injury or environmental conditions (cold, heat, humidity, etc.)

Co-management – Managing the transition

Posted on Updated on

This is a graphic that Microsoft used at Ignite to help illustrate the different journeys that organizations might take to get to modern management. Here’s a quick post on the last item in the table – the co-management path. Now that the key prerequisites for co-management have become available (SCCM 1710 and Windows 10 1709) have been out for a while, organizations that are considering co-management are looking at the management scenarios that are available to them. There is some new infrastructure that needs to be configured and there are a lot of good posts on those prerequisites like this one from the Microsoft Document Library so rather than focus on the technical details, I’d like to explore some of the management decisions that you might need to address:

  1. Co-management does not require a hybrid infrastructure of SCCM connected to Intune. It actually requires each platform to run in standalone mode. That means that if you have a hybrid environment, you will need to migrate to a standalone Intune model.
  2. Not all workloads are available in both platforms so you will need to choose what makes sense to move from SCCM to Intune. For instance, Win32 application management is easier in SCCM and most organizations already have an established release management process around it. Compliance policies on the other hand are often better suited to be managed with Intune as it provides a richer experience and more advanced controls for things like Device compliance policies, Resource access policies, and Windows Update policies.
  3. In other cases, the workload may not be available to be migrated to Intune or may not be an easy transition. Examples include Endpoint protection and Operating System Deployments. If you have a requirement for upgrading Windows 7 devices to Windows 10, SCCM is still the best option.
  4. Are you going to start with Intune managed devices and then add the SCCM client or are you going to start with SCCM Managed devices and enroll them into Intune?
  5. Ho do you want to address non-Windows 10 devices?

As exciting as new technology is, there is always value in understanding your use case scenarios and requirements before embarking on any new initiative. As a friend of mine constantly reminds me, “Businesses don’t care about the use of innovative technology but the innovative use of technology”.

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.