I am often asked which version of Windows 10 an organization should select. I am astounded by the number of IT Pros involved in Windows 10 migrations and deployments that are unaware of the servicing windows for each of the semi-annual feature updates of Windows 10. For background, it is important to understand that Microsoft releases two feature updates to Windows 10 each year through the semi-annual update channel. The versions in this servicing channel are released in the spring ad the fall. Sometimes there is a specific name for the version but lately they have typically been referred to as one of the following:
- Spring / Fall Update
- March/September Update (Note that the general availability does not always align perfectly to these months
- YYMM (E.g. 1903 vs 1909)
- H1/H2 (First half vs second half of the year)
Regardless of what you call the update, the impact of your version selection has a big impact on your next mandatory update. Most important to note is that all versions of Windows 10 have an 18 month servicing window with the exception of the September (H2, Fall) update for Enterprises and Education customers which has a 30 month servicing window. This means that there will not be any quality and security updates beyond 18 months for these versions.
If you have access to enterprise or Education versions of Windows 10, you get 30 months of servicing support. Consider that, if you install 1903 the day it is released you will get a shorter support window than if you installed 1809 the very same day.
Pro Tip: Unless you have a compelling reason to use a specific H1 version of Windows 10, you should install an H2 version of Windows 10 Enterprise (or Education) to maximize the servicing window and provide more runway between mandatory upgrades.
March* feature updates
September* feature updates
Windows 10 Enterprise
Serviced for 18 months from release date
Serviced for 30 months from release date
Windows 10 Pro
Serviced for 18 months from release date, however based on your setting, the latest feature update may be automatically installed on your device upon availability.
Serviced for 18 months from release date, however based on your setting, the latest feature update may be automatically installed on your device upon availability.
* Feature updates will be released twice annually with a target of March and September.
Note: There is also a Long Term Servicing Channel that provides five or more years of support to specific Long Term Servicing Branch versions of Windows 10. These versions are outside of the scope of this discussion.
More information about this and related topics can be found in the
Windows lifecycle fact sheet
In 2018 Microsoft became the fifth largest PC vendor in North America. Of course much of this is fueled by Surface lineup that has moved rapidly from an enthusiast or secondary device to become the preferred device of many enterprises. I do a lot of work with the Canadian Federal Government and many departments have chosen the Surface Pro as the standard device for all employees.
Of course the combination of Surface and Windows 10 has some distinct advantages such as:
- Windows 10 is tested heavily against Surface Devices
- Configuration Manager has a Surface Device Dashboard built in showing device models, firmware, etc.
- Configuration Manager uses Surface Devices as pilot devices for prerelease testing
- Surface Hardware supports advanced Windows 10 features such as Hello and WiDi
As the Surface continues to be more heavily deployed in enterprises, administrators have had special concerns about managing the devices. In response, Microsoft has released a series of tools and utilities to ease the management burden.
|Cisco EAP Supplicant Installer||Enable PEAP, EAP-FAST, and Cisco LEAP on Surface devices|
|SEMM||Surface Enterprise Management Mode tools for managing UEFI firmware|
|SP3_Firmware_Powershell_Scripts.zip||Surface Pro 3 firmware deployment scripts|
|Surface Diagnostics Tools||Investigate, troubleshoot, and resolve hardware, software, and firmware issues with Surface devices|
|Surface Data Eraser||Perform a secure wipe of all data from a Surface device|
|Surface Deployment Accelerator||Rapid reimaging environment for Surface devices|
|Surface Dock Updater||Check and update Surface dock firmware|
|Surface Brightness Control||App for managing screens of always on devices like POS and Kiosks|
|Surface UEFI Configurator and Manager||Tool for managing SEMM enrolments|
|Surface WOL||Manage Wake-On-LAN for Surface Devices|
The Surface Tools for IT can be downloaded here.
Microsoft just announced preview support for Corporate Owned Fully Managed Android Enterprise devices. What does this mean for the administrator of these devices? Well the landscape has been changing a lot lately in the device management space. So before going on to the new stuff let’s review the classic scenarios
COBO – Corporate Owned Business Only – In this scenario, the enterprise buys the device and issues it to an employee. The device is intended for business use only and there is no/minimal personal use or data on the device. In this scenario the device can be wiped at the discretion of the owner (the enterprise). This scenario commonly has a small number of standard devices to ease procurement and management.
BYOD – Bring Your Own Device – In this scenario employees supply their own device and connect to corporate services with it. If the device is managed there is usually some segregation or containerization of personal and corporate data and apps. If the employee changes devices or leave the organization, the enterprise typically only wipes the corporate portion of the device leaving personal apps and data intact as the device is personally owned. It can be difficult to manage BYOD as there is minimal control over the types of devices employees may use.
CYOD – Chose Your Own Device – This scenario is very similar to BYOD with the exception of a set list of supported devices is provided by the employer and the employee must chose from that list. Often there is a small allowance allocated to help offset the cost to the employee to offset the increased cost associated with the loss of choice. This typically has an element of standardization associated with it by design.
COPE – Corporate Owned Personally Enabled – This scenario has the employer purchasing and owning device with the employee having the ability to use personal apps and data. This typically requires some segregation between corporate and personal apps and data. In this scenario the ability to wipe the device may or not differentiate between personal and corporate apps and data depending on the corporate policies.
Until recently, the most common secured Android platform was Samsung Knox which leveraged available Android APIs to create a secured container and additional management policies and restrictions. This eased the administration scenarios that required some form of corporate and personal segregation. In many cases MDM vendors created their own container models to provide similar experiences on non-Knox devices.
Android Enterprise changes the landscape once again by providing much of the functionality of Knox across devices from dozens of Android vendors. There is an ever growing list of Android Enterprise Recommended devices. Notice that Samsung is on the list as well. It’s not clear to me at this time what the future of Samsung Knox is however in my most recent testing of Android Enterprise controls I found that they were at best a subset of the controls available in Knox. This is a rapidly changing landscape and I expect parity or near parity very quickly as hardware vendors expose more to the Android Enterprise APIs.
So to circle back to the Microsoft announcement – In short it means that Intune now supports the Android Enterprise version of COBO.
There’s a great standalone tool that you can use to help troubleshoot Windows 10 upgrade issues. This tool only works on Windows 10 with .Net Framework 4.6 installed. You can download the tool from here.
Setupdiag.exe is a command line tool that parses all of the log files associated with windows upgrades and looks for known failure signatures. Simply running the command on a windows 10 system will page up all of the log files into a zip file in the directory from which the command was run.
There are many command line switches (some for controlling output destinations) and as usual you can get a list of the options by typing SetupDiag.exe /?.
Here are some examples of the output from SeupDiag.exe on a system that had a successful upgrade:
Note that I use the Configuration Manager Trace Log Tool as my default log file viewer. More on the setupdiage.exe can be found here.
As Microsoft has integrated previously independent products evolved into a massive cloud service provider, disparate access methods and portals developed by individual product teams has lead to a an overwhelming number of different ways of accessing your MS cloud services. Examples include Office365, Azure AD, Dynamics, OMS, Intune and of course Azure.
While I applaud Microsoft’s movement to simplified, streamlined and unified portals where they make sense, it has been a bumpy ride. Up until earlier this year both Azure and Intune had two portals for a period. If that’s not confusing enough, not all functions are/were available in both portals. Some features are/were only available in the classic portal while others are/were only available in the modern portal.
To make it even more difficult for administrators, because of the Silverlight dependency, the classic portal does not support all modern browsers.
Here’s an article that outlines the browser support for each portal.
Let’s focus on Intune for now. Until the Windows 7 End of Life in January 2020 Microsoft will need to continue to support the classic Silverlight based portal to continue to provide support for Windows 7 devices that rely on agent based management. As organization move away from Windows 7 no agent required as OMA-DM is baked into Windows 10 the Azure service based version of the Intune portal can be used exclusively.
Figure 1- Classic Silverlight based Intune Portal
Figure 2- Azure “Ibiza” Portal
It’s hard to believe that something as simple (and revenue generating for Microsoft) like license assignment can be confusing. Intune has additional confusion beyond the two Intune specific portals in that license management can be done from either the Azure AD blade or from within Office365.
Of course, you can also assign the licenses using PowerShell from a computer with the Azure Active Directory Module for Windows PowerShell installed. I like this option as it can be integrated into a more complete automated user provisioning process. For example, you could create a PowerShell script that does the following:
- Create a user in AD (or Azure AD)
- Add the user to appropriate groups
- Assign an Office 365 license
- Turn on MFA
- Create a mailbox
- Assign an Intune Licence
In this short video I’ll show you three ways to assign Intune (or EMS) licenses to users:
- Office365 Portal
- Azure Portal
Apologies, the video link is not working. will be up again shortly.
I previously posted about changes to Microsoft’s Windows 10 support and things are changing again. While Microsoft continues with twice yearly feature releases of Windows 10 Microsoft has announced that it will now provide 30 months of support for Enterprise and Education versions of Windows 10 released in the fall and 18 months of support for Pro and Home versions. Spring releases stay the same at 18 months. Is that confusing? Remember that the twice yearly releases are targeted for release in March and September and as such are referred to as Year+Spring and Year+Fall or YYH1 and YYH2 releases. So the release targeted for March 2018 would be referred to as Spring 2018 or 18H1. Understanding that, here’s a table to help sort out the support models:
|Windows 10 Enterprise||H1 (Spring)||18 Months|
|H2 (Fall)||30 Months|
|Windows 10 Education||H1 (Spring)||18 Months|
|H2 (Fall)||30 Months|
|Windows 10 Pro||H1 (Spring)||18 Months|
|H2 (Fall)||18 Months|
|Windows 10 Home||H1 (Spring)||18 Months|
|H2 (Fall)||18 Months|
It’s great that organizations that can’t keep up with the 18 month upgrade pace either permanently or temporarily can opt for slowing down once on a fall release. Organizations that want the feature upgrades faster (often for updated new security features) can still upgrade before the 30 month end of support either to a spring or a fall release depending on the cadence that they want to adopt. This gives them an option to mix and match with fully supported upgrade cycles that can be 6,12,18,24 and 30 months as required.
This is great news for Windows 10 customers but there are still many organizations struggling to upgrade from Windows 7 before extended support runs out on January 14, 2020. As part of the same post Microsoft also released information about paid Extended Security Updates (ESU) for Windows 7 until 2023.
As Microsoft Surface devices continue to gain use in enterprise environments, Microsoft has been releasing tools to ease the management of these somewhat unique devices and enable administrators to use more modern technologies in a streamlined way.
One of the biggest security improvements in Windows 10 (and Windows 8.1) over Windows 7 is UEFI. It ahs traditionally been difficult to automate the move from BIOS based firmware to UEFI without some form of manual intervention. Microsoft addressed this with specialized task sequences in SCCM. Microsoft has improved the ongoing management of the UEFI firmware once again with Surface Enterprise Management Mode (SEMM).
Once devices are enrolled with SEMM you can enable or disable the following devices:
Docking USB Port
Micro SD Card
Infrared Camera, for Windows Hello
Wi-Fi and Bluetooth
You can configure the following advanced settings with SEMM:
IPv6 support for PXE boot
Alternate boot order, where the Volume Down button and Power button can be pressed together during boot, to boot directly to a USB or Ethernet device
Lock the boot order to prevent changes
Support for booting to USB devices
Enable Network Stack boot settings
Enable Auto Power On boot settings
Display of the Surface UEFI Security page
Display of the Surface UEFI Devices page
Display of the Surface UEFI Boot page
Display of the Surface UEFI DateTime page
The configurations are changed by running configuration packages on enrolled devices. Of course, you can uses System Center Configuration Manger to send the enrollment and configuration packages to managed devices.
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.
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:
- Picture Password
- 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:
|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|
Windows 10 MFA integrates with Microsoft Passport and with Active Directory to provide seamless authentication through a number of common use cases.
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.
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.)|
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:
- 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.
- 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.
- 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.
- 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?
- 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”.