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.