Managing Windows as a Service (WaaS)

Introduction

Prior to Windows 10, Microsoft released new versions of Windows every few years, this schedule stalled the release of new features and caused headaches for IT to upskill staff due to significant changes in the Operating System. Microsoft have stated that Windows 10 will be the last major OS release but by no means has development slowed down. Two major feature releases are planned each year (March and September) therefore it is important to understand what this means from a management perspective. This servicing model is referred to as Windows as a Service. WaaS essentially means that you have predefined lifecycle timespans which looks like this:

 

Transitioning an estate to the WaaS model initially imposes a significant amount of preparation, however, once this is completed the ongoing management of Windows becomes much simpler. WaaS means continuous development, testing, piloting and deployment.

Names/Servicing Channels

Microsoft recently adjusted the names of Windows 10 servicing releases to closely resemble Office 365.

• Windows Insider Program – Refers to preview releases of the next upcoming Windows 10 iteration, only to be deployed to a select few test users, not to be used in production.
• Semi-Annual Channel – Refers to Current Branch (CB) as “Semi-Annual Channel (Targeted)”, while Current Branch for Business (CBB) refers to “Semi-Annual Channel”.
• Long-Term Servicing Channel – The Long-Term Servicing Branch (LTSB) will be referred to as Long-Term Servicing Channel (LTSC).

 

Servicing option	Version	OS build	Availability date	Latest revision date
Semi-Annual Channel (Targeted)	1709	16299.19	10/17/2017	10/17/2017
Current Branch (CB)	1703	15063.674	4/11/2017	10/10/2017
Current Branch (CB)	1607	14393.1794	8/2/2016	10/17/2017
Current Branch (CB)	1511	10586.1176	11/12/2015	10/10/2017
Semi-Annual Channel	1703	15063.674	7/11/2017	10/10/2017
Current Branch for Business (CBB)	1607	14393.1794	11/29/2016	10/17/2017
Current Branch for Business (CBB)	1511	10586.1176	4/8/2016	10/10/2017
Long-Term Servicing Branch (LTSB)	1607	14393.1794	8/2/2016	10/17/2017
Long-Term Servicing Branch (LTSB)	1507 (RTM)	10240.17643	7/29/2015	10/10/2017

Windows Insider Program releases of Windows 10 should be tested internally within IT to review and test some of the planned feature updates and changes that will eventually make their way into release.

Semi-Annual Channel is defined in two states, ‘Targeted’ and ‘Broad’. The reality is the only difference between these two states is a cumulative update applied after Microsoft defines the release as ‘Broad’ deployment (ready for business). This change in definition is usually announced about 4 months after the release of each feature set. As of writing the current release of Windows 10 defined as ‘Broad’ (ready for business) is Windows 10 1703. Each release of Windows 10 will have an 18-month servicing timeline where it is supported (from the date of release).

As an example, the current release of Windows 10 is 1709 (referred to as the ‘Fall Creators Update’). The 18-month support clock starts from 09/2017. After approximately 4 months 1709 will be transitioned into ‘Broad’ deployment and support for 1709 is now at 14 months. At around about March 2019, 1709 will fall out of support.

Long-Term Servicing Channel has a planned release of every 2-3 years. LTSC should only be considered for deployment to specialised machines. Specialised would be any systems attached to production critical machinery. As a general guideline, a PC with Microsoft Office installed is a general-purpose device, and therefore it is better suited for the Semi-Annual servicing channel. Basically, if it’s not controlling an airport, factory or MRI machine, don’t use it.  It is important to note that LTSC will only support silicon released at the time of the release of the LTSC. The LTSC release of Windows 10 does not contain many in-box applications such as Edge, Cortana, Store etc. LTSB will not receive any feature updates but will receive security/bug fixes for a maximum of 10 years.

The suggested approach to manage Windows releases would be to;

1. If required, identify LTSC devices and treat these separately to the below recommendations.
2. Identify users to enroll into the Windows Insider Program (IT only). Deploy insider releases when they are available.
3. Identify group(s) of users who will always be on the Semi-Annual (Targeted) release. These users should get transition to the next Windows release as soon as it becomes available. This group will test and confirm compatibility of line of business applications (LoB) and any new features before adoption to the rest of the fleet. This group should not be isolated to IT only as this is not a true indication of a production environment.
4. At the time of ‘Broad’ (Ready for Business) announcement, transition all other workstations to that release.

This cycle for Insider, Targeted and Broad releases is continuous.

 

Updates

 

Updates for Windows 10 are referred to by two names;

Feature Updates – Updates released twice per year (March & September). These ‘feature’ updates should (but not always) be released with new base media alongside an upgrade package.

Quality Updates – Updates released monthly (patch Tuesday). Quality updates are security enhancements and fixes, these do not introduce new features.

Microsoft will release cumulative updates (CU) for Windows 10 each month. These updates include all the fixes from the previous months release and will supersede the previous CU. Updates should be controlled via Configuration Manager only. We would recommend enabling the Group Policy located at: System/Internet Communication Management/Internet Communication settings/Turn off access to all Windows Update features which will remove the ability for users to ‘self-update’ and will give administrators total control over when updates are published. Group Policy settings such as ‘Select when Feature Updates are received’ and ‘Select when Quality Updates are received’ are applicable for Windows Update for Business (WuFB) and should not be configured.

Note: This does not affect updates or applications self-provisioned from the Windows Store. You could also hide the entire settings pane, see here for more information.  

 Transitioning to Windows 10 from an earlier version of Windows (XP,7,8x) should be done by using a ‘wipe and load’ scenario. This method is the most fool-proof approach to move workstations to Windows 10.
Moving between versions of Windows 10 with Configuration Manager can be achieved by using an in-place upgrade. There are two ways to achieve this.

1. Deploy the upgrade by utilising a Configuration Manager Task Sequence. This method gives the greatest control and allows for as many pre and post-upgrade tasks as required.
2. Deploy the upgrade package, this update is treated like a normal monthly update package and will simply upgrade to the next version of Windows. This method is quite autonomous but is NOT recommended. Typically, when upgrading Windows, administrators like to use the opportunity to perform additional maintenance such as BIOS, language pack, driver or application remediation which is not possible by using this method. This method is usually configured by creating a Servicing Plan (essentially an Automatic Deployment Rule) from the Windows 10 Servicing dashboard (only used from 10 to 10)

The method of upgrading workstations between releases should follow the rough guideline outlined earlier. A typical scenario would be to deploy the update Task Sequence (TS) to your early adoption group as a Required TS with a deadline of X days. This allows users to self-provision the upgrade until the deadline time. When rolling out to the rest of the fleet (when the release becomes ready for business), you can use the same model, however, this is usually staggered between departments or geographical locations. To identify different Windows 10 versions within the estate, you can create collections based on the OS Version value.

Of course, the biggest pain point for IT here is communication with users.

Windows 10 Features

Windows 10 brings a variety of features, including;

Secure Boot: Unified Extensible Firmware Interface (UEFI) Secure Boot is a security standard for firmware built in to PCs by manufacturers beginning with Windows 8. It helps to protect the boot process and firmware against tampering, such as from a physically present attacker or from forms of malware that run early in the boot process or in kernel after startup.

Device Guard: Device Guard includes a Code Integrity policy that you create; a whitelist of trusted apps—the only apps allowed to run in your organization. Device Guard also includes a powerful system mitigation called hypervisor-protected code integrity (HVCI), which leverages virtualization-based security (VBS) to protect Windows’ kernel-mode code integrity validation process. HVCI has specific hardware requirements and works with Code Integrity policies to help stop attacks even if they gain access to the kernel.

Credential Guard: Credential Guard uses virtualization-based security to isolate secrets, such as NTLM password hashes and Kerberos Ticket Granting Tickets, so that only privileged system software can access them thus reducing the possibility of Pass-the-Hash or Pass-the-Ticket attacks.

See this post for more information.

Deploying Device Guard broadly is a much more significant undertaking than Credential Guard. It’s ok to implement Credential Guard and Device Guard later if deemed necessary as both features are easily enabled via a group policy. The difference between utilising Device Guard vs just Credential Guard is the configuration of the policy within Computer Configuration > Administrative Templates > System > Device Guard. Within complex environments Device Guard would be quite difficult to manage, therefore is not recommended without significant investigation into its benefits and applicability in your estate. Secure Boot should be enabled on all supporting computers along with TPM to allow BitLocker to function.

Things to consider

Language Packs – Language packs are specific to each release of Windows 10. A Windows 10 1607 language pack cannot be used on a 1703 release of Windows 10 therefore these must be upgraded alongside the OS. Language packs are downloadable from the VLSC, packs are split into Language Packs (Multilingual) which contain the language packs per language ID and Language Feature Packs (2 ISO’s) which contain handwriting, speech enhancements etc. See here for more information.

Drivers – Drivers are updated regularly by vendors so should be treated as any other resource in your environment. Drivers referenced during OSD should be tested and deployed with the latest revisions.

BIOS – Like Drivers, BIOS versions should be revised and can be managed during OSD or beforehand. Vendors such as Dell, Lenovo and HP provide BIOS management tools to allow administrators to enable/disable BIOS features (such as Secure Boot and TPM) and updates during OSD. To reduce human interaction with each deployment, its suggested to utilise these tools.

OS Customisations – Keeping customisations to a minimum is important now that Windows is now an ‘agile’ OS. Implementing significant changes to default Windows behaviour could cause issues when moving between versions.

Reference Image Maintenance – It’s a good idea to maintain your Windows 10 reference image(s) with the latest updates to reduce deployment time during OSD. The ‘Schedule Updates’ option within Configuration Manager (offline servicing) makes it easy to inject updates offline. Note, this doesn’t install all updates fully but stages them ready for installation, they will complete the install process during deployment time. At this point in time, I have moved away from building reference images, it’s much less work to simply reference the stock Windows 10 ‘install.wim’ and provide customisations during OSD.