Bulk enrollment for Windows 10 devices

My first post after my vacation will be about bulk enrollment for Windows 10 devices. Not bulk enrollment for on-premises enrollment, but bulk enrollment for cloud enrollment. In other words, Microsoft Intune is required. This blog post will contain a short introduction about bulk enrollment, the configuration of bulk enrollment and the end-user and administrator experience with bulk enrollment.

Introduction

Bulk enrollment is a more automated method for enrolling devices, as compared to normal end-user enrollment, which requires end-users to enter their credentials to enroll the device. Bulk enrollment uses an enrollment package to authenticate the device during enrollment. That enrollment package also contains a certificate profile and optionally a Wi-Fi profile.

At this moment bulk enrollment for Windows 10 devices is not supported, or does not work, in all scenarios. Keep the following in mind when thinking about bulk enrollment for Windows 10 devices:

  • Bulk enrollment does not support Azure AD join;
  • Bulk enrollment does not work with Microsoft Intune standalone;
  • Bulk enrollment does work with Microsoft Intune hybrid, where the enrollment package is generated via the Configuration Manager console.

Configuration

Now let’s have a look at the configuration. The configuration of an enrollment profile for bulk enrollment contains two main steps. The first step is to create the enrollment profile and the second step is to create the enrollment package.

Step 1: Create enrollment profile

The first step is to create an enrollment profile. This can be achieved by performing the steps below. Before starting with the steps below, make sure that a certificate profile for the root certificate is available, as it’s a requirement during the creation of the enrollment certificate.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > All Corporate-owned Devices  > Windows > Enrollment Profile;
2 On the Home tab, click Create Enrollment Profile to open the Create Enrollment Profile wizard;
3

CEP_GeneralOn the General page, provide the following information and click Next;

  • Name: [Specify an unique name for the enrollment profile];
  • Description: [Specify details that help identifying the enrollment profile];
  • Select Cloud with Management Authority.
4

CEP_CertificateOn the Select Trusted Root Certificate page, select the required root certificate profile and click Next;

Note: The certificate profile is required during the creation of the enrollment profile.

5

CEP_WiFiOn the Select Wi-Fi profile page, optionally select a Wi-Fi profile and click Next;

Note: The Wi-Fi profile is optional during the creation of the enrollment profile. This can be useful when the device must be configured to connect to Internet first.

6 On the Summary page, click Next;
7 On the Completion page, click Close;

Step 2: Create enrollment package

The second step is to create the enrollment package. The enrollment package is the actual file that is used to bulk-enroll devices. This file is created via the Configuration Manager administration console and can eventually be opened with the Windows Image and Configuration Designer (ICD),. Within the Windows ICD the configuration can be verified. To create the enrollment package, perform the following steps.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > All Corporate-owned Devices  > Windows > Enrollment Profile;
2 Select the just created enrollment profile and on the Home tab, click Export to open the Export Enrollment Package dialog box;
3

IEEPn the Export Enrollment Package dialog box, provide the following information and click OK;

  • Validity period (days): [Specify an unique name for the enrollment profile];
  • Package File: [Specify details that help identifying the enrollment profile];
  • Select Encrypt Package.
4

EEPEPIn the Export Enrollment Package Encryption Password dialog box, select Copy to copy the encryption password and click OK to close the dialog box;

Note: The encryption password will not be saved. Make sure to store the encryption password to keep the ability to use the enrollment package.

Experience

Now it’s time to look at the experience, from both the end-user perspective and the administrator perspective. Both experiences show interesting information, which makes it good to show as part of this blog post.

End-user experience

From the end-user experience it’s interesting to show the usage of the enrollment package. Just to show how easy it works. However, the enrollment package must be physically delivered to the device of the end-user. Once the end-user double-clicks the enrollment package, the end-user receives the standard User Account Control (UAC) message followed by the messages show below. The first message is only applicable once the enrollment package is encrypted and the second message is always applicable. The second message simply show what the enrollment package will adjust and asks if the enrollment package is from a trusted source.

ppgk_Password ppgk_Trust

Once the enrollment is successful the end-user can verify the two places shown below. The first place is Settings > Accounts > Access work or school, which will show that the device is connected to MDM. The second place is Settings > Accounts > Access work or school > Add or remove a provisioning package, which will show the added provisioning package.

EnrollmentProfile EnrollmentPackage

Administrator experience

From the administrator experience it’s interesting to look at, at least, the two places in the Configuration Manager administration console shown below. The first place is Assets and Compliance > Overview > All Corporate-owned Devices > Windows > Enrollment Profile, which will show the created enrollment profile including interesting details like Device Count. That device count relates to the number of devices that are enrolled via the enrollment profile. The second place is Assets and Compliance > Overview > Devices, which simply shows the devices in the environment. This is interesting as it will show that the Device Owner is set to Company for (bulk) enrolled devices.

CM_EnrollmentProfile CM_EnrollmentProfileDevice

More information

For more information about bulk enrollment for Windows 10, please refer to:

Conditional access for Exchange Online to the max

This week I want to show another look at conditional for Exchange Online. I want to do that by providing a scenario. That scenario will cover more than just conditional access. Mainly because conditional access simply blocks access to non-compliant devices, but what if I want to take it one step further? What if I also want to prevent potential data leakage? In that case I can’t just look at conditional access. In that case I also need to add mobile app management to the playing field. This post will address those subjects for Exchange Online.

Scenario

Now lets start with the scenario that I want to cover. Even though I know that I will use Microsoft Intune and related technologies to do the configuration, I want the scenario to describe functional requirements. The configuration should address the following requirements:

  • Email access is only allowed on managed and compliant devices;
  • Email data leakage must be prevented on managed and compliant devices;
  • Email access is available via the browser;
  • Email access is supported on iOS, Android and Windows 10.

Configuration

Now lets have a look at what I need to configure to address that scenario. The good news is that I can support this scenario with Microsoft Intune. However, the default configuration is not sufficient. I need to get creative. To address this scenario I need to make sure that email access is only available through browsers and apps that can be managed by mobile app management (MAM) policies or by Enterprise Data Protection (EDP)/ Windows Information Protection (WIP). No back doors allowed. That means that to address this scenario I need to add the following technical configurations on top of the standard conditional access and MAM (and WIP):

  • The OWA app for iOS and Android must be blocked;
  • ActiveSync apps that use basic authentication must be blocked;
  • The default browsers on iOS and Android must be blocked.

Block the OWA app

ADFS_DenyOWAThe first thing that I want to configure is a deny for the Microsoft OWA app. That specific app bypasses every form of conditional access. Luckily that doesn’t mean that there is nothing that I can do to block the app. I can use AD FS to deny specific client user agent claims for the Microsoft OWA app. 

The following example claim will deny every active claim that arrives via the AD FS proxy with a client user agent that contains MOWAHost. That should be distinctive enough to only deny the Microsoft OWA app. However, keep in mind that the Microsoft OWA app will only be blocked once it tries to verify the credentials.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/services/trust/2005/usernamemixed”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “MOWAHost”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Block Exchange ActiveSync apps with basic authentication

The second thing I want to configure is a deny on every Exchange ActiveSync app with basic authentication, like the default mail app on iOS and Android. Those apps are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those apps can still leak data. The combination of the following three components allows me to only allow the Microsoft Outlook app, which is capable of working with MAM policies, on mobile devices.

1

ExchangeOnlinePolicy_EASThe first component that I need to address is the Exchange Online Policy for conditional access. I don’t want Microsoft Intune to control the access for the Exchange ActiveSync apps with basic authentication, I want Exchange Online to take care of those apps. Within Exchange Online I’ve got the ability to easily block or allow access to specific device families and models. Microsoft Outlook is available as a device family.

To achieve that Microsoft Intune doesn’t control those apps, I need to make sure that the setting Block non-compliant devices on platforms supported by Microsoft Intune and the setting Block all other devices on platforms not supported by Microsoft Intune are disabled in the conditional access policy for Exchange Online.

2

EA_AccessSettingsThe second component that I need to address are the Exchange ActiveSync access settings. Within these settings I can define the default behavior of Exchange Online when a device isn’t managed by a rule or personal exemption. In this case I want to block access to all mobile devices that are not part of the rule that I will define.

To achieve that every device is blocked when it’s not managed by a rule, I need to configure the Exchange ActiveSync Access settings to Block access.

3

EA_DeviceAccessThe third component that I need to address is the Device Access Rule. With a rule like this I can define which device families and models are allowed, blocked or quarantined. In this case I want to allow access to all mobile devices that use Outlook to connect.

To achieve that all mobile devices that use Outlook are allowed, I need to create a Device Access Rule with the Outlook device family and for All models.

Note: It’s even possible to specifically select Outlook for iOS and Android as model, but at this moment that cannot be enforced.

Block default browsers on iOS and Android

The third thing that I want to configure is a deny on the default browsers on iOS (Safari) and Android (Chrome). Those browsers are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those browsers can still leak data. Luckily that doesn’t mean that there is nothing that I can do to block those browsers.

ADFS_DenySafariDefault browser iOS (Safari)
I can use AD FS to deny specific client user agent claims for the Safari browser. However, the Safari browser is tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Safari. That isn’t only applicable to iOS, but also to Android and Windows.

The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Safari, but doesn’t contain Windows or Android. That should be distinctive enough to deny the Safari browser on iOS devices.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Safari/”])
  && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Windows|Android”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

ADFS_DenyChrome

Default browser Android (Chrome)
I can also use AD FS to deny specific client user agent claims for the Chrome browser. However, the Chrome browser is also tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Chrome. That isn’t only applicable to Android, but also to iOS and Windows.

The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Chrome and Android, but doesn’t contain PKeyAuth or ManagedBrowser. That should be distinctive enough to deny the Chrome browser on Android devices.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Chrome/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Android”])
  && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “PKeyAuth|ManagedBrowser|Windows”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Result

The result is awesome, in my personal opinion. I’ve successfully tested this configurations on iOS, Android and Windows 10 devices with multiple browsers and apps. This configuration, in combination with conditional access and MAM (and WIP), provides the following results:

  • Email access is only available on managed and compliant iOS and Android devices via the Managed Browser and on managed and compliant Windows 10 devices via Internet Explorer and Microsoft Edge. These browsers can be managed via MAM and WIP to prevent data leakage. Other browsers will be blocked by conditional access, or AD FS;
  • Email access is only available on managed and compliant iOS and Android devices via the Microsoft Outlook app on managed and compliant Windows 10 devices via Outlook. These apps can be managed via MAM and WIP to prevent data leakage. Other apps will be blocked by Exchange Online;
  • Known back doors are closed. The OWA app will be blocked by AD FS.

More information

Fore more information about conditional access for Exchange Online and mobile app management, please refer to:

Conditional access for browsers

This week I’ll provide an overview about the latest addition to conditional access, which is conditional access for browsers. It’s a feature that many have been waiting for and a feature that is indeed a pretty welcome addition to conditional access. This post will provide the basics about conditional for browses, the configuration of conditional access for browsers and the end-user experience with conditional access for browsers. It will also be the introduction for something much better next week.

Introduction

Conditional access allows IT organizations to manage access to corporate email, files and other resources based on customizable conditions that ensure security and compliance. The addition of conditional access for browsers addresses the backdoor that still existed for end-users connecting to the Outlook Web App (OWA) and end-users using browser access to SharePoint and OneDrive for Business. It’s now possible to restrict Outlook Web App (OWA) and browser access to SharePoint and OneDrive for Business when accessed from a browser on iOS and Android devices. Access is only allowed from the following supported browsers, on compliant devices, while unsupported browsers are simply blocked:

  • Safari (iOS);
  • Chrome (Android);
  • Managed Browser (iOS and Android).

Note: Keep in mind that this does not block access via the OWA app. More about that in my post next week.

Configuration

Now let’s have a look at the configuration of conditional access for browsers. The configuration is the same for Microsoft Intune standalone and Microsoft Intune hybrid, as the configuration is part of the conditional access policies. It’s actually nothing more than one simple checkbox that belongs to one specific setting. That specific setting is Block non-compliant devices on the same platform as Outlook in the Exchange Online Policy and Block non-compliant devices on the same platforms as OneDrive for Business in the SharePoint Online Policy. That specific setting can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online SharePoint Online
OWAExchangeOnline OFBSharePointOnline

End-user experience

Now it’s time to look at the end-user experience, which is the most important part of this feature. Below I’ve got examples for compliant and non-compliant devices and supported and unsupported browsers. In all examples I’m trying to access https://outlook.office.com.

Android

Here is an example on an Android device using the supported Chrome browser and using the unsupported Firefox browser. The left column shows the non-compliant examples and the right column shows the compliant examples. Notice the clear message in the unsupported browser about using supported browsers for access.

Non-compliant Compliant
Screenshot_20160708-203644 Screenshot_20160710-181822
Screenshot_20160708-203757 Screenshot_20160708-204830

iOS

Here is an example on an iOS device using the supported Safari browser and using the unsupported Firefox browser. The left column shows the non-compliant examples and the right column shows the compliant examples. I haven’t been able to receive the same clear messages yet, as shown on my Android device, but the access is definitely blocked.

Non-compliant Compliant
IMG_0058 IMG_0056
IMG_0059 IMG_0057

Windows 10

I’ve also managed to successfully test conditional access for browsers on Windows 10, with Internet Explorer and Microsoft Edge, in combination with Microsoft Intune standalone and Microsoft Intune hybrid. Even in combination with Windows 10, fully managed by ConfigMgr. More about those awesome scenario’s once it’s listed as a supported platform with supported browsers.

More information

Fore more information about conditional access for browsers with Exchange Online and SharePoint Online, please refer to:

Windows 10 MDM and the MDM Bridge WMI Provider

This week another blog post about Windows 10 and OMA-DM, but this week will be short and different. Starting this week I won’t be referring to OMA-DM anymore, instead I’ll be referring to Windows 10 MDM. The main reason for that is change is to align with Microsoft. Also, it simply makes more sense. OMA-DM is the standards based protocol on which the Windows 10 MDM protocol is based. In other words, Windows 10 MDM is not exactly the same as the OMA-DM standards. Technically speaking it’s not wrong to refer to OMA-DM, but it simply makes more sense to refer to Windows 10 MDM.

That being said, this blog post will be different for another reason. This week I’ll try to bring Windows 10 MDM closer to the regular methods, by simply pointing out the existence of the MDM Bridge WMI Provider. This post is all about creating awareness.

MDM Bridge WMI Provider

One of the most heard comments about Windows 10 MDM is related to the lack of knowing what’s happening. Well, I can’t really take that away, maybe the newly introduced logging in 1607 can, but I can show how to see the changes of the Windows 10 MDM configurations.

The MDM Bridge WMI Provider is the bridge to the Windows 10 MDM capabilities. An easy method to see what’s happening is using a WMI Explorer, or something simple as Windows Management Instrumentation Tester (wbemtest). Simply connecting to the root\cimv2\mdm\dmmap namespace is similar to connecting to the MDM Bridge WMI Provider. The classes in this namespace all translate to a configuration service provider (CSP) of Windows 10 MDM. This makes it fairly easy to see what’s happening to the configurations done via Windows 10 MDM.

Below is an example of the MDM_Policy_Result01_Experience02 class, in which the AllowManualMDMUnenrollment instance property was changed during the enrollment of the device. That class and instance property relates to the configuration OMA-URI of ./Vendor/MSFT/Policy/Config/Experience/AllowManualMDMUnenrollment.

Before After
BeforeEnroll AfterEnroll

Knowing this immediately opens up another world. This enables everyone to get information through the MDM Bridge WMI Provider by simply using PowerShell. Looking at the previous example, I can simply use the following PowerShell command, as there is only one instance, to get the information as shown in the table below.

Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" ` -ClassName "MDM_Policy_Result01_Experience02"

Before After
BeforeEnroll_PS AfterEnroll_PS

This also means that the MDM Bridge WMI Provider can be used to trigger configuration changes through Windows 10 MDM. For now, I’ll leave that up to everyone’s imagination.

Important notes

There are a few important notes about the MDM Bridge WMI Provider that should be known and I’ll try to summarize them briefly:

  • Administrative permissions are required to connect with the MDM Bridge WMI Provider. Without those permissions there will be an access denied error when connecting to the MDM Bridge WMI Provider;
  • The local system context is required to view and adjust device settings. This can be achieved by using something like PsExec.exe;
  • Be aware that there is a difference between user settings and device settings. Specific user settings won’t show when connected in the system context and specific device settings won’t show when connected in the user context;
  • Be aware that my example mixed Config and Result properties and nodes. That’s related to the design of the Policy CSP. The Config section handles the configurations requests and the Result section provides a read-only path to the actual configuration.

More information

Fore more information about Windows 10 MDM, the Windows 10 CSP and the MDM Bridge WMI Provider, please refer to:

Managing Windows Update for Business on Windows 10 via OMA-DM

WUfB_DeferThis week another blog post about Windows 10 and OMA-DM. This week I’m going to have a look at managing Windows Update for Business on Windows 10. However, this time I’ll group the currently available policy settings per subject, to easily provide some more background information. Also, by now I assume that I don’t have to go through all the steps to create a Configuration Item or a Configuration Policy anymore.

To manage Windows Update for Business, IT organizations can use the Policy configuration service provider (CSP) and to report about Windows Update for Business IT organizations can mainly use the Update CSP. During this blog post I’ll provide more information about Windows Update for Business, the Policy CSP, the Update CSP and the available policy configurations. I’ll end this post with configuration examples for Microsoft Intune standalone and Microsoft Intune hybrid.

Introduction

Let’s start with a short introduction about Windows Update for Business. What is it and how is different from Windows Update and Windows Server Update Services (WSUS). Windows Update for Business enables IT organizations to keep the Windows 10 devices always up to date with the latest security updates and Windows features by directly connecting these devices to Windows Update. By only using policies, Windows Update for Business is an easily established and implemented system which enables IT organizations to exercise control on how their Windows 10 devices are updated.

IT organizations can specify which devices go first in an update wave, and which devices will come later, and can make the delivery of updates to branch offices and remote sites, with limited bandwidth, very efficient.
Windows Update for Business can even be used in combination with existing management tools, such as ConfigMgr. It basically allows IT organizations to manage how and when Windows 10 devices receive updates and upgrades and provides controls to help organizations validate update quality as well as time their update deployments.

Configuration

Now let’s have a look at the configuration options for Windows Update for Business via OMA-DM. I’ll have a look at how to defer updates and upgrades, how to pause updates and upgrades and how to optimize the deployment. However, it should be noted that at this moment not everything can be configured via OMA-DM, yet.

Policy CSP & Update CSP

Before really looking at the configuration scenarios, it’s good to have a quick look at the Policy CSP and the Update CSP. The Policy CSP enables IT organizations to configure company policies on Windows 10 devices. Those policies also include the configuration options for Windows Update for Business, The Update CSP enables IT organizations to get information about the update status of Windows 10 devices. Below is a quick overview of both CSPs.

Policy CSP Update CSP
PolicyCSP UpdateCSP

Defer upgrades

To use Windows Update for Business, Windows 10 devices must be configured to Current Branch for Business (CBB). This can be configured by using one of the following policies.

Policy Description
Update/BranchReadinessLevel

  • 16 (default) – Systems takes upgrades from Current Branch (CB). 
  • 32 – System takes upgrades from Current Branch for Business (CBB).
New for Windows 10, version 1607. Allows the IT organization to set a device to the Current Branch or the Current Branch for Business servicing branch.
Update/RequireDeferUpgrade

  • 0 (default) – User gets upgrades from Current Branch (CB).
  • 1 – User gets upgrades from Current Branch for Business (CBB).
Allows the IT organization to set a device to the Current Branch or the Current Branch for Business servicing branch.

Defer upgrade and update periods

Windows Update for Business provides IT organizations the ability  to control when updates and upgrades are deployed to their Windows 10 devices. This can be achieved by specifying deferral windows from when the updates and upgrades are initially made available on Windows Update. There are restrictions as to how long IT organizations can delay updates and upgrades. The following table details the deferral periods and supported values.

Policy Description
Update/DeferFeatureUpdatePeriodInDays

  • Supported values are 0-180.
New for Windows 10, version 1607. Allows the IT organization to defer Feature Updates for up to 180 days.
Update/DeferQualityUpdatePeriodInDays

  • Supported values are 0-30.
New for Windows 10, version 1607. Allows the IT organization to defer Quality Updates for up to 30 days.
Update/DeferUpdatePeriod

  • Supported values are 0-4.
Allows the IT organization to delay updates for up to 4 weeks.
Update/DeferUpgradePeriod

  • Supported values are 0-8.
Allows the IT organization to delay upgrades for up to 8 months.

Pause upgrades and updates

Windows Update for Business also provides IT organizations the ability to pause updates and upgrades on a per device basis. This pause functionality ensures that no updates or upgrades will be made available for the specified device. The device will remain in this state until the configured period has passed or when the device is specifically “unpaused”. At that point updates are auto-resumed. The following table details the pause options and the supported values.

Policy Description
Update/PauseDeferrals

  • 0 (default) – Deferrals are not paused.
  • 1 – Deferrals are paused.
Allows the IT organization to pause updates and upgrades for up to 5 weeks. Paused deferrals will automatically be reset after 5 weeks, or when the value is set back to 0.
Update/PauseFeatureUpdates

  • 0 (default) – Feature Updates are not paused.
  • 1 – Feature Updates are paused for 60 days.
New in Windows 10, version 1607. Allows the IT organization to pause Feature Updates for up to 60 days. Paused Feature Updates will automatically be reset after 60 days, or when the value is set back to 0.
Update/PauseQualityUpdates

  • 0 (default) – Quality Updates are not paused.
  • 1 – Quality Updates are paused for 35 days.
New in Windows 10, version 1607. Allows IT Admins to pause Quality Updates. Paused Quality Updates will automatically be reset after 35 days, or when the value is set back to 0.

Optimize delivery

By grouping machines into similar deferral periods, IT organizations can cluster devices into deployment or validation groups which can be used as a quality control measure as updates are deployed in Windows 10. With deferral windows and the ability to pause, IT organizations can effectively control and measure update deployments by rolling out to a small pool of devices first to verify quality, prior to a broader roll-out in the organization.

At this moment Windows 10 doesn’t provide configuration options via OMA-DM to specifically configure a device in a specific group. However, it’s still possible to configure a specific set of devices with a similar deferral period and to take advantage of the default configuration in Windows 10 to get updates from PCs on my local network,

Update approval

Windows Update for Business also provides IT organizations with the ability to restrict the updates that are installed on a device to only those on the update approval list. That list can be configured via the Update CSP and enables the IT organization to accept the End User License Agreement (EULA) on behalf of the end-user. This can be configured by using the following policy.

Policy Description
Update/RequireUpdateApproval

  • 0 – The device installs all applicable updates.
  • 1 – The device only installs updates that are both applicable and on the Approved Updates list.
Allows the IT organization to restrict the updates that are installed on a device to only those on an update approval list. It enables the IT organization to accept the EULA associated with the approved update on behalf of the end-user.

Example configuration

Now let’s end this post slightly different as usual. This time not with the end-user experience, but with example configurations, as I didn’t provide any throughout this post. Also, the biggest end-user experience is already shown in the picture at the beginning of this post, which is showing a grayed-out Defer upgrades setting. Below is an example of the RequireDeferUpgrade setting in Microsoft Intune hybrid (Configuration Item) and Microsoft Intune standalone (Configuration Policy).

Microsoft Intune hybrid Microsoft Intune standalone
WUfB_MIH WUfB_MISA

More information

Fore more information about Windows Update for Business, the Update CSP and the Policy CSP, please refer to:

Reporting Windows Defender health on Windows 10 via OMA-DM

About a year ago I did a blog post about managing Windows Defender on Windows 10 via OMA-DM, by using the available policies in the Policy CSP. This week I’m going to have another look at Windows Defender, on Windows 10, but this time from a reporting perspective. This time I want to report about the health of Windows Defender on the Windows 10 devices that are managed via OMA-DM. To get that type of information I can use the Defender configuration service provider (CSP). The Defender CSP contains the information about the health of Windows Defender.

During this blog post I’ll go through the Defender CSP, the required configuration to get the Windows Defender health information and the administrator experience.

Defender CSP

DefenderCSPBefore starting with the required configuration to get the information about the health of Windows Defender, it’s good to have a quick look at the Defender CSP. That CSP is used to configure various Windows Defender actions across the enterprise. More specifically, I will go through the Health node. That node contains the information about the Windows Defender health status that I’m looking for.

  • ComputerState: This node provides the current state of the device;
  • DefenderEnabled: This node shows if the Windows Defender service is running;
  • RtpEnabled: This node shows if the real-time protection is running;
  • NisEnabled: This node shows if the network protection is running;
  • QuickScanOverdue: This node shows if a Windows Defender quick scan is overdue;
  • FullScanOverdue: This node shows if a Windows Defender full scan is overdue;
  • SignatureOutOfDate: This node shows if the Windows Defender signature is outdated;
  • RebootRequired: This node shows if a reboot is required;
  • FullScanRequired: This node shows if a Windows Defender full scan is required;
  • EngineVersion: This node shows the version number of the Windows Defender engine;
  • SignatureVersion: This node shows the version of the Windows Defender signatures;
  • DefenderVersion: This node shows the version of Windows Defender;
  • QuickScanTime: This node shows the time of the last Windows Defender quick scan;
  • FullScanTime: This node shows the time of the last Windows Defender full scan;
  • QuickScanSigVersion: This node shows the signature version used during the last quick scan;
  • FullScanSigVersion: This node shows the signature version used during the last full scan.

Configuration

Now it’s time to start with the required configuration to enable the ability to report about the Windows Defender health of Windows 10 devices managed via OMA-DM. However, it’s good to note that this is currently only possible in Microsoft Intune hybrid, as we need to extend the inventory on Windows 10 devices.

The Health node of the Defender CSP contains exactly the information that I’m looking for and that I would like to add to the inventory of my Windows 10 devices. Luckily, in a Microsoft Intune hybrid environment I can extend the hardware inventory to include specific OMA-URI settings. OMA-URI settings that can be added to the hardware inventory are shown, in the picture above, in a rectangular shape (and are documented with a supported Get operation).

All of the available settings, in the Health node of the Defender CSP, support the Get operation. If I want to add a custom class to the hardware inventory, with all the the available settings of the Health node, I can use the following in a MOF file.

[ SMS_Report (TRUE),
   SMS_Group_Name (“PTCLOUD Windows10 DefenderHealth”),
   SMS_Class_ID (“MICROSOFT|Windows10_DefenderHealth|1.0”),
   Namespace (“Reserved”),
   SMS_DEVICE_URI (“”) ]


class Windows10_DefenderHealth : SMS_Class_Template
{
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/ComputerState”)]
      String ComputerState;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/DefenderEnabled”)]
      Boolean DefenderEnabled;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/RtpEnabled”)]
      Boolean RtpEnabled;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/NisEnabled”)]
      Boolean NisEnabled;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/QuickScanOverdue”)]
      Boolean QuickScanOverdue;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanOverdue”)]
      Boolean FullScanOverdue;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/SignatureOutOfDate”)]
      Boolean SignatureOutOfDate;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/RebootRequired”)]
      Boolean RebootRequired;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanRequired”)]
      Boolean FullScanRequired;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/EngineVersion”)]
      String EngineVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/SignatureVersion”)]
      String SignatureVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/DefenderVersion”)]
      String DefenderVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/QuickScanTime”)]
      String QuickScanTime;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanTime”)]
      String FullScanTime;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/QuickScanSigVersion”)]
      String QuickScanSigVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanSigVersion”)]
      String FullScanSigVersion;
};

This MOF file can be used to extend the hardware inventory by simply performing the following steps in the Configuration Manager console.

1 In the Configuration Manager console, and navigate to Administration > Overview > Client Settings;
2 Open the Default Client Settings, navigate to Hardware Inventory and click Set Classes;
3

WindowsDefenderInvIn the Hardware Inventory Classes, click Import and Open the new MOF file.

This will add the new class for the inventory and will show it between the existing classes.

Also note that the dataldr.log will show the creation of the new class.

Result

Now let’s end this post with the most important thing, the visualization. The extension to the hardware inventory will make sure that the information about the Windows Defender health is reported by Windows 10 devices that are managed via OMA-DM. It will add the information, like every extension to the hardware inventory, to a custom table, with it’s own custom view, in the database. That will make it relatively easy to create a custom report, as shown below, to display the information in a readable form to the administrative users.

Administrator experience
WDExampleReport

Also, keep in mind that the information will also be available in the Resource Explorer, of the Configuration Manager console, for the Windows 10 devices that are managed via OMA-DM.

More information

Fore more information about the Defender CSP and the Policy CSP, please refer to:

Conditional access, Windows 10 and Microsoft Intune: What are the compliance options?

Recently Microsoft released a couple of blog posts about The Path to Modernizing Windows Management and about Clear & Simple Guidance: When ConfigMgr and Intune should be used with Windows 10, which should be really helpful with deciding how to managing the Windows 10 devices within an organization. I would really recommend everybody to read those posts. This blog post will not be directly related, but will continue on a more detailed level about the options for conditional access and Windows 10 devices.

In this blog post I will provide nice tables of the different compliance rules, for Windows 10 devices, that are currently available for Microsoft Intune standalone and Microsoft Intune hybrid. In those tables I’ll show the different management scenarios and the currently available applicable compliance rules.

Overview

Before I’ll start with the overview, it’s good to provide a short explanation about the distinction between the conditional access policy and the compliance policy.

The conditional access policy is a required configuration to enable conditional access on a particular service and to help secure access to that particular service. In the conditional access policy, the targeted platforms and the targeted users of devices are configured. Also, important for Windows 10 devices, in the conditional access policy it is possible to determine if Windows 10 devices must be compliant or domain joined.

The compliance policies, on the other hand, are optional additional rules that can evaluate settings like PIN and encryption. The devices of targeted users must be compliant to those additional rules. When there are no compliance policies deployed, the device will automatically be evaluated as compliant.

Microsoft Intune standalone

Now let’s start with the overview of available compliance rules in Microsoft Intune standalone. In Microsoft Intune standalone, a Windows 10 device can be managed by the Microsoft Intune client and it can be enrolled as a mobile device. Those two options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined the only additional configuration for those devices.

Intune client MDM
Allow simple passwords N/A Yes (Mobile only)
Maximum Windows Phone or Windows 10 Mobile version N/A Yes (Mobile only)
Maximum Windows version N/A Yes (Desktop only)
Minutes of inactivity before password is required N/A Yes
Minimum password length N/A Yes
Minimum Windows Phone or Windows 10 Mobile version N/A Yes (Mobile only)
Minimum Windows version N/A Yes (Desktop only)
Require a password to unlock an idle device N/A Yes (Mobile only)
Password expiration N/A Yes
Remember password history – Prevent reuse of previous passwords N/A Yes
Required password type – Minimum number of character sets N/A Yes
Require a password to unlock mobile devices N/A Yes (Mobile only)
Require devices to be reported as healthy N/A Yes
Require encryption on mobile device N/A Yes

Microsoft Intune hybrid

Let’s continue with the overview of available compliance rules in Microsoft Intune hybrid. In Microsoft Intune hybrid, a Windows 10 device can be managed by the Microsoft Intune client, the ConfigMgr client and it can be enrolled as a mobile device. Those three options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined  the only additional configuration for those devices.

Intune client ConfigMgr client MDM
All required updates installed with a deadline older than X days N/A Yes N/A
Allow simple passwords N/A N/A Yes (Mobile only)
File encryption on mobile device N/A N/A Yes
Maximum operating system version N/a N/A Yes
Minimum classification of required updates N/A N/A Yes
Minimum operating system version N/A N/A Yes
Minimum password length N/A N/A Yes
Minutes of inactivity before password is required N/A N/A Yes
Require a password to unlock an idle device N/A N/A Yes (Mobile only)
Reported as healthy by Health Attestation Service N/A N/A Yes
Require Antimalware N/A Yes N/A
Require BitLocker drive encryption N/A Yes N/A
Require password settings on mobile devices N/A N/A Yes
Require registration in Azure Active Directory N/A Yes N/A

More information

For information about about conditional for Windows 10 devices with Microsoft Intune standalone or Microsoft Intune hybrid, please refer to:

Conditional access and health attestation

This week another blog post about conditional access. And another blog post that is triggered by a feature that is introduced in ConfigMgr 1602. However, this time it’s about a feature that already did exist in Microsoft Intune standalone. I’m talking about the new conditional access rule that uses the Health Attestation Service. This new rule creates the ability to ensure that Windows 10 devices have trustworthy BIOS, TPM, and boot software configurations enabled.

In this blog post I’ll show the detailed configuration steps for Microsoft Intune hybrid and I’ll briefly note the most important configurations for Microsoft Intune standalone.

Introduction

Device health attestation is an additional level of restricting access to Exchange Online and SharePoint Online for Windows 10 devices. Currently only available for Windows 10 devices that are managed via OMA-DM. It adds the ability to create compliance policies that require Windows 10 devices to report as healthy. Device health attestation can be used to ensure that the following trustworthy configurations are enabled:

  • BitLocker: BitLocker provides encryption for all data stored on the Windows operating system volume.
  • Code integrity: Code Integrity provides improvements to the security of the operating system by validating the integrity of a driver, or system file, each time it is loaded into memory.
  • Early-launch antimalware (only applies to PCs): Early launch anti-malware (ELAM) provides protection for computers when they start up and before third-party drivers initialize.
  • Secure boot: Secure boot provides a security standard, which is developed by members of the PC industry, to help make sure that a PC boots with only software that is trusted by the PC manufacturer.

Note: A Windows 10 device must be compliant to all of the applicable configurations to be reported as healthy by the Health Attestation Service.

Pre-configuration

Before looking at the configuration of conditional access and device health attestation, I will begin with mentioning a new client setting and the health attestation dashboard. This is at least as important, as it will provide a good understanding about the impact of using conditional access based on the status reported by the Health Attestation Service.

Default client settings

To start with collecting information about the status, reported by the Health Attestation Service, of Windows 10 devices, it’s good to start with enabling the communication with the Health Attestation Service,. The following 2 steps will make sure that the information will be collected.

1 In the Configuration Manager administration console, navigate to Administration > Overview > Client Settings and open the Default Client Settings;
2

CA_ClientSettings_HAIn the Default Client Setting, navigate to Computer Agent and select Yes with Enable communication with Health Attestation Service and click OK to close the Default Client Settings..

Health attestation dashboard

After configuring the Default Client Settings, the information of the Health Attestation Service, on Windows 10 devices, will start showing in the health attestation dashboard and the List of devices by Health Attestation state report. This information can be used to get a good understanding about the impact of enabling conditional access based on the  status reported by the Health Attestation Service. The health attestation dashboard is available by navigating to Monitoring > Overview > Security > Health Attestation and will look like the following example.

CA_Intune_HealthAttestation

Note: In Microsoft Intune standalone similar reports are available, in the Reports section, named Health Attestation Reports.

Configuration

Let’s continue with looking at the real configuration for conditional access. I will start with briefly mentioning the conditional access policy and I’ll end this configuration section with going through all the required steps for creating the compliance policy.

Conditional access policy

Now that I know what the impact will be of using the health of a Windows 10 device, reported by the Health Attestation Service, I can start with enabling conditional access. Just like last week, I’ll only mention the conditional access policy briefly. It’s important that the setting Windows must meet the following requirements is selected and configured to Devices must be compliant. Also, for supporting Windows 10 mobile, it’s important to also select Windows 10 Mobile. These settings can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online Policy SharePoint Online Policy
CA_ExchOnl_Win10 CA_SPOnl_Win10

Compliance policy

Like last week, the more interesting configuration is the configuration of the new compliance policy. The following 9 steps will go through the creation of the compliance policy. After the creation of the compliancy policy, it can be deployed, like any other policy, to users.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies;
2 On the Home tab, click Create Compliance Policy to open the Create Compliance Policy Wizard;
3

On the General page, specify the following information and click Next;

  • CA_ConfigMgrIntune_CP_GeneralName: [Specify a unique name for the compliance policy]
  • Description: [Specify details that help identifying the compliance policy]
  • Select Compliance rules for devices managed without the Configuration Manager client with Specify the type of compliance policy that you want to create
    • Select Windows 8.1 and Windows 10

Note: Select Windows Phone and Windows 10 Mobile for supporting the configuration on Windows 10 Mobile devices.

4

On the Supported Platforms page, select the following platforms and click Next;

  • CA_ConfigMgrIntune_CP_PlatformAll Windows 10 (64-bit)
  • All Windows 10 (32-bit)

Note: Select All Windows 10 Mobile and higher for supporting the configuration on Windows 10 Mobile devices.

5 On the Rules page, click New… to open the Add Rule dialog box;
6

ICA_ConfigMgrIntune_CP_AddRulen the Add Rule dialog box, select the Reported as healthy by the Health Attestation Service rule and click OK to return to the Rules page;

7

CA_ConfigMgrIntune_CP_RulesBack on the Rules page, verify the created configuration and click Next;

8 On the Summary page, click Next
9 On the Completion page, click Close.
CA_Intune_CompliancePolicyNote: In Microsoft Intune standalone a similar compliance policy setting is available, in the Device Health section, named Require devices to be reported as healthy.

End-user experience

Now it’s time to look at the end-user experience. This time I won’t show the end-user experience of a non-compliant device connecting to Exchange Online, or SharePoint Online, as it’s similar to the messages shown during last weeks post. This time I’ll only show the end-user experience in the Company Portal app on a Windows 10 Desktop device and a Windows 10 Mobile device. The messages will be similar as shown below. It will not just show a non-compliant device, it will actually show which configuration is reported as not healthy by the Health Attestation Service.

Non-compliant Compliant
CA_Intune_CompanyPortal CA_Intune_CompanyPortal2
wp_ss_20160319_0001 wp_ss_20160319_0002

More information

For more information about conditional access, Windows 10 device health attestation and the HealthAttestation CSP, please refer to:

Quick tip: Working with the device enrollment manager and automatic enrollment

This is another short and quick blog post. This time about the device enrollment manager in combination with the automatic enrollment in Microsoft Intune, which is powered by Azure AD. The device enrollment manager is a configuration within Microsoft Intune standalone, or Microsoft Intune hybrid (starting with ConfigMgr 1511). However, with really active use of the device enrollment manager, it is possible to run into some default configuration challenges. This post will provide a quick tip about those challenges.

Configuration

The documentation about the device enrollment manager contains a note that device enrollment manager user accounts, with more than 20 devices enrolled, might have problems using the Company Portal app. In case that potential problem is not an issue, for the usage within the company, it’s good to know that those 20 devices are not a hard limit to the maximum number of enrolled devices.

However, in case more than 20 devices must be enrolled, in combination with automatic device enrollment of Azure AD, make sure to adjust the following configuration. Without this adjustment problems will occur with the Azure AD join, simply because the default maximum number of devices is set to 20 per user.

  • MaxDevicesIn the Microsoft Azure
    portal, navigate to ACTIVE DIRECTORY >
    [Directory];
  • Select the CONFIGURE tab and scroll down to the devices section;
  • Adjust the number with MAXIMUM NUMBER OF DEVICES PER
    USER
    .

More information

For more information about the device enrollment manager, in Microsoft Intune standalone and hybrid, and automatic enrollment, please refer to:

How the settings in ConfigMgr translate to the command line of the Windows 10 upgrade

DefaultSettingsThis week a short post about the settings in the Upgrade Operating System task sequence step and how these settings translate to the parameters used during the Windows 10 upgrade. I will go through the standard parameters, for the Windows 10 upgrade, used by the Upgrade Operating System task sequence step and I will go through the effect, of the configuration options in the Upgrade Operating System task sequence step, on the Windows 10 upgrade parameters.

Configuration options

Now let’s start by having a look at the standard parameters for the Windows Setup of the Windows 10 upgrade, used by the Upgrade Operating System task sequence step. To do this, let’s start with an Upgrade Operating System task sequence step with only Upgrade package selected. That setting will translate to a command line like this: “C:\_SMSTaskSequence\Packages\PCP0000F\SETUP.EXE” /ImageIndex 1 /auto Upgrade /quiet /noreboot /postoobe “C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd” /postrollback “C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd” /DynamicUpdate Disable

Based on that command line it’s possible to see the standard configurations of the Upgrade Operating System task sequence step. By default the Upgrade Operating System task sequence step performs an upgrade of Windows and saves apps and data (/auto Upgrade), suppresses any Setup end-user experience (/quiet), instructs Windows Setup not to restart the computer after the down-level phase of Windows Setup completes (/noreboot), runs a script after the Setup is complete (/postoobe), runs a script if the end-user rolls back Windows (/postrollback) and disables the dynamic update operations (/dynamicupdate Disable).

Now let’s have a look at the effect of the remaining configuration options option of the Upgrade Operating System task sequence step. The following table lists the configuration option, the parameter that it translates to, and a short description.

Option Command Description
Source path /InstallFrom Specifies a local, or network path, to the Windows 10 media, that is to be used.
Product key /PKey <ProductKey> Specifies the product key to apply to the upgrade process.
Provide the following driver content to Windows Setup during upgrade /Driver Specifies the drivers that need to be added to the destination computer during the upgrade process.
Time-out (minutes) N/A Specifies the number of minutes Setup has to run before ConfigMgr will fail the task sequence step.
Perform Windows Setup compatibility scan without starting upgrade /Compat ScanOnly Specifies to perform the Windows Setup compatibility scan without starting the upgrade process.
Ignore any dismissible compatibility messages /Compat IgnoreWarning Specifies that Setup completes the installation, ignoring any dismissible compatibility messages.
Dynamically update Windows Setup with Windows Update /DynamicUpdate Enable Specifies whether setup will perform dynamic update operations, such as search, download, and install updates.
Override policy and use default Microsoft Update N/A Specifies to temporarily override the local policy in realtime to run dynamic update operations and have the computer get updates from Windows Update.

Note: When dynamic update is enabled, ignore warnings is not allowed. That results in the task sequence ignoring the /compat switch.

More information

For more information about the Windows 10 upgrade and the different task sequence steps, please refer to: