Operations Management Suite connected with ConfigMgr

This blog post is about a pre-release feature, which means that it’s included in the product for early testing in a production environment, but should not be considered production ready.

This week another blog post about a pre-release feature. This time it’s the Pre-release – Microsoft Operation Management Suite (OMS) Connector feature that is also introduced in ConfigMgr 1606. It’s a good follow-up on my post of last week, as I can reuse Azure components that I created for the connection with the Windows Store for Business. Before starting with the configurations of this blog post, make sure to create an Operations Management Suite account here.

Introduction

The Operations Management Suite is a cloud-based IT management solution that helps IT organizations to manage and protect the on-premises and cloud infrastructure. IT organizations can use the Microsoft Operations Management Suite (OMS) Connector, at this moment, to import data of collections from ConfigMgr to the Operations Management Suite. This makes data from the ConfigMgr environment visible in the Operations Management Suite.

Note: At this moment only collection memberships can be imported to the Operation Management Suite. I wouldn’t be surprised to see more options at a later stage.

Configuration

Now lets have a look at the actual configurations that are required to get the Microsoft Operations Management Suite (OMS) Connector up-and-running. To connect the Operations Management Suite with ConfigMgr the following four steps are required.

Step 1: Enable pre-release feature in ConfigMgr

The first step, similar to last week, is to enable the Pre-release – Microsoft Operation Management Suite (OMS) Connector pre-release feature, as it must be turned on in ConfigMgr. This can be achieved by performing the following steps.

1 First open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Sites;
2 Select the top-level site in the hierarchy and select Hierarchy Settings, in the Home tab, to open the Hierarchy Settings Properties;
3 In the Hierarchy Settings Properties, navigate to the General tab, select Consent to use Pre-Release features and click OK;
4 Now navigate to Administration > Overview > Cloud Services > Updates and Servicing > Features;
5 Right-click Pre-release – Microsoft Operation Management Suite (OMS) Connector and select Turn on.

Step 2: Register ConfigMgr as web application in Azure AD

The second step, similar to last week, is to create an application in Azure AD. I actually used the same application, which is the reason why these steps are identical. That application doesn’t have to contain resolvable URLs, as it only will be used to create a connection between the Operations Management Suite and ConfigMgr. This can be achieved by performing the following steps.

1 In the Azure Management portal, select the related Azure AD and click APPLICATIONS > ADD to open the What do you want to do? dialog box;
2 In the What do you want to do? dialog box, click Add an application my organization is developing to open the ADD APPLICATION wizard;
3

AddApp_1On the Tell us about your application page, specify the following information and click on the Arrow sign;

  • Name: [Specify a unique name for the application]
  • Type: WEB APPLICATION AND/OR WEB API
4

AddApp_2On the Add properties page, specify the following information and click the Check sign to complete the wizard and to add the app.

  • Sign-on URL: [Specify any URL]
  • App ID URI: [Specify any URL]

Note: In both cases the URL doesn’t have to be a resolvable address.

5 In the created app click CONFIGURE;
6

AppKeysIn the category Keys select a duration and click SAVE;

Note: The key will be created after clicking SAVE and can only be retrieved while on this page

Step 3: Provide ConfigMgr with permissions on Operations Management Suite

The third steps is to provide the Azure AD app with permissions to access the Operations Management Suite. This will allow us to use the Azure AD app to connect ConfigMgr to the Operations Management Suite. This can be achieved by performing the following steps.

1 First open the Azure portal and select Browse > Log Analytics (OMS) to open the Log Analytics (OMS) blade;
2 On the Log Analytics (OMS) blade, click Add to open the OMS Workspace blade;
3

OMSWorkspaceOn the OMS Workspace blade, provide the following information and click OK;

  • OMS Workspace: [Specify a name]
  • Subscription: [Select the subscription]
  • Resource group: Create new [Specify a name]
  • Location: [Select a location]
  • Pricing tier: [Select a pricing tier]

Note: I’m specifically creating a new resource group to create the option to only provide ConfigMgr with permissions to that OMS Workspace. Simply because that’s the only thing within the resource group.

4 Now select Browse > Resource groups to open the Resource groups blade;
5 On the Resource groups blade, select the just created resource group to open the Settings blade;
6 On the Settings blade, select Users to open the Users blade;
7 On the Users blade, select Add to open the Add access blade;
8

OMSRGAddAccessOn the Add access blade, select Select a role to configure the exact permissions, select Add users to select the Azure AD app and click OK;

Note: Without specifying these permissions there will be an error message during the configuration wizard in ConfigMgr.

Step 4: Create connection to Operations Management Suite in ConfigMgr

The fourth steps is to create the connection to the Operations Management Suite in ConfigMgr. This connection will be created by using the information of the Azure AD app. This can be achieved by performing the following steps.

1 In the Configuration Manager administration console, navigate to Administration > Overview > Cloud Service > OMS Connector;
2 On the Home tab, click Create connection to Operations Management Suite to open the Connection to Operations Management Suite Wizard;
3 On the General page, click Next;
4

OMSW_AzureADOn the Azure Active Directory page, specify the following information and click Next;

  • Tenant: [Specify the Azure AD tenant]
  • Client ID: [Specify the Client ID of the just created Azure AD app]
  • Client secret key: [Specify the Client secret key of the just created Azure AD app]
5

OMSW_OMSConnectionOn the OMS Connection page, specify the following information and click Next.

  • Azure subscriptions: [Select the subscription]
  • Azure resource group: [Select the just create resource group]
  • Operations Management Suite Workspace: [Select the just created workspace]
  • Select device collections that OMS can get data for: [Specify the collections that can be used]

Note: This information will be pre-selected once the Azure AD app has enough permissions on the resource group. Only the collections must still be configured.

6 On the Summary page, click Next.
7 On the Completion page, click Close.
Note: The documentation states that after a while the Microsoft Monitoring Agent will be installed. In my testing this was not the case and I installed the agent manually.

Administrator experience

After the configuration is completed the administrator can view the configuration details in the administration console via Administration > Overview > Cloud Services > OMS Connector. The administrator can use the Properties to add additional collections to the configuration.

OMSConOverview

To actually start importing information about the collection memberships, the administrator still has to do one little configuration within the Operation Management Suite console. This can be achieved by navigating to Settings > COMPUTER GROUPS > SCCM and selecting Import Configuration Manager collection memberships.

OMSDashboard

This is also a location where the administrator can view the information about the collection memberships that are imported in the Operations Management Suite. This can be achieved by simply clicking on <xx> computers with the collection memberships detected or <xx> Configuration Manager site server collections imported. That provides the administrator with an overview as show below and enables the administrator to look at some details. The same overview can be achieved by simply using Log search.

OMSOverview

More information

For more information about syncing data from ConfigMgr to the Operations Management Suite, please refer to this article about Sync data from Configuration Manager to the Microsoft Operations Management Suite.

Share

Windows Store for Business synchronized with ConfigMgr

This blog post is about a pre-release feature, which means that it’s included in the product for early testing in a production environment, but should not be considered production ready.

This week a blog post about the Windows Store for Business Integration feature that is introduced in ConfigMgr 1606. This feature is introduced as a pre-release feature. Before starting with the configurations of this blog post., make sure to sign up for Windows Store for Business here.

Introduction

The Windows Store for Business is where organizations can find and purchase Windows apps. By connecting the Windows Store for Business to ConfigMgr, organizations can synchronize the list of apps with ConfigMgr, view these in the ConfigMgr administration console, and deploy them like any other app. The Windows Store for Business supports two types of licensed app:

  • Online – This license type requires users and devices to connect to the Windows Store for Business to get an app and its license. It requires Windows 10 devices to be Azure AD domain-joined;
  • Offline – This license type enables organizations to cache apps and licenses to deploy them directly within their on-premises network, without connecting to the Windows Store for Business or having a connection to the Internet.

It’s also good to know that ConfigMgr supports managing Windows Store for Business apps on Windows 10 devices running the ConfigMgr client and Windows 10 devices that are enrolled via MDM.

Note: At this moment there is no support for paid apps from the Windows Store for Business.

Configuration

Now lets have a look at the actual configurations. The configuration requires the following four steps to synchronize the Windows Store for Business with ConfigMgr.

Step 1: Enable pre-release feature in ConfigMgr

The first step is to enable the Windows Store for Business integration pre-release feature, as it must be turned on in ConfigMgr. This can be achieved by performing the following steps.

1 First open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Sites;
2 Select the top-level site in the hierarchy and select Hierarchy Settings, in the Home tab, to open the Hierarchy Settings Properties;
3 In the Hierarchy Settings Properties, navigate to the General tab, select Consent to use Pre-Release features and click OK;
4 Now navigate to Administration > Overview > Cloud Services > Updates and Servicing > Features;
5 Right-click Windows Store for Business integration and select Turn on.

Step 2: Register ConfigMgr as web application in Azure AD

The second step is to create an application in Azure AD. That application doesn’t have to contain resolvable URLs, as it only will be used to create a link between the Windows Store for Business and ConfigMgr. This can be achieved by performing the following steps.

1 In the Azure Management portal, select the related Azure AD and click APPLICATIONS > ADD to open the What do you want to do? dialog box;
2 In the What do you want to do? dialog box, click Add an application my organization is developing to open the ADD APPLICATION wizard;
3

AddApp_1On the Tell us about your application page, specify the following information and click on the Arrow sign;

  • Name: [Specify a unique name for the application]
  • Type: WEB APPLICATION AND/OR WEB API
4

AddApp_2On the Add properties page, specify the following information and click the Check sign to complete the wizard and to add the app.

  • Sign-on URL: [Specify any URL]
  • App ID URI: [Specify any URL]

Note: In both cases the URL doesn’t have to be a resolvable address.

5 In the created app click CONFIGURE;
6

AppKeysIn the category Keys select a duration and click SAVE;

Note: The key will be created after clicking SAVE and can only be retrieved while on this page

Step 3: Configure ConfigMgr as management tool in the Windows Store for Business

The third steps is to configure the Azure AD app as a management tool in the Windows Store for Business. This will create a link between the Azure AD app and the Windows Store for Business, which will allow us to connect ConfigMgr to the Windows Store for Business. This can be achieved by performing the following steps.

1 In the Windows Store for Business portal, select Settings > Management tools;
2 On the Management tools page, click Add a management tool to open the Add a management tool dialog box;
3 AddManagementToolOn the Add a management tool dialog box, search for the just created and configured app and click Add to return to the Management tools page;
4

ActivateManagementBack on the Management tools page, click Activate next to the just added management tool.

Note: Only one management tool can be active for the Windows Store for Business.

Step 4: Add Windows Store for Business account to ConfigMgr

The fourth steps is to add the Windows Store for Business account to ConfigMgr. This will create a link between the Windows Store for Business and ConfigMgr by using the information of the Azure AD app. This can be achieved by performing the following steps.

1 In the Configuration Manager administration console, navigate to Administration > Overview > Cloud Service > Windows Store for Business;
2 On the Home tab click Add Windows Store for Business Account to open the Windows Store for Business Configuration Wizard;
3 On the General page, click Next;
4

WSfB_ConfigurationOn the Configuration page, specify the following information and click Next;

  • Tenant: [Specify the Windows Store for Business tenant]
  • Client ID: [Specify the Client ID of the just created Azure AD app]
  • Client secret key: [Specify the Client secret key of the just created Azure AD app]
  • Location to store application content downloaded from the Windows Store for Business: [Specify the location to store the content of the offline licensed Windows Store for Business apps]
5 WSfB_LanguageOn the Language page, select the languages that should have Application Catalog entries for the synchronized apps and click Next.
6 On the Summary page, click Next.
7 On the Completion page, click Close.

Administrator experience

After the configuration is completed the administrator can view the sync status and the configuration details in the administration console via Administration > Overview > Cloud Services > Windows Store for Business.

WSfBOverview

Once the synchronization is completed the administrator can view the synchronized apps in the administration console via Software Library > Overview > Application Management > License Information for Store Apps.

WSfBLicensedApps

This is also the location where the administrator can create applications based on the information synchronized from the Windows Store for Business. This can be achieved by simply selecting an application from the list and clicking Create Application.

More information

For more information about managing apps from the Windows Store for Business, please refer to this article about Manage apps from the Windows Store for Business with System Center Configuration Manager.

Share

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:

Share

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:

Share

Microsoft MVP 2016!

Awesome! Yesterday I received that great email that I’m awarded the 2016 Microsoft MVP Award in Enterprise Mobility (contribution area ConfigMgr & Microsoft Intune).

MVP2016

Probably many already read this on Twitter or on Facebook, but I just had to write a small post on my blog. Not just because I’m very honored, very proud and very exited of receiving my second award in a row, but also because I just need to let everyone know that it’s made possible by my great family. Without their support, this blog wouldn’t exist! A really big thank you to my wife and kids for letting me do my “thing”.

I’m ready for another community driven year!

Share

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:

Share

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
  • 0 (default) – User gets upgrades from Current Branch (CB). 
  • 1 – User gets 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:

Share

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:

Share

Controlling Microsoft Passport for Work on Windows 10 via OMA-DM

This week another blog post about Windows 10 and OMA-DM. However, this time it might not be that obvious. In this post I’ll go through the configuration of enabling the provisioning of Microsoft Passport for Work on Windows 10 devices. Maybe even more important, I’ll go through the PassportForWork configuration service provider (CSP) that is used to provision that configuration.

During this blog post I’ll go through the PassportForWork CSP, the configuration steps in Microsoft Intune hybrid and standalone and the end-user experience.

PassportForWork CSP

Before starting with the configuration of enabling the provisioning of Microsoft Passport for Work on Windows 10 devices, it’s good to get a better understanding  of what is actually used to get the configuration in place. The configuration through Microsoft Intune hybrid and standalone uses the PassportForWork CSP. That CSP is used to provision Microsoft Passport for Work, which allows the end-user to login to Windows using the AD, or Azure AD, account and replace passwords, smartcards, and virtual smart cards for that specific device. Microsoft Passport for Work lets the end-user use a user gesture to login, instead of a password. A user gesture can be a simple PIN, biometric authentication, or an external device.

Below is an overview of the nodes of the PassportForWork CSP. I won’t go through the nodes in detail, as that information will come during the configuration, but make sure to switch back a couple of times to connect the configuration with the CSP.

User configuration Device configuration
UserConfigDiagram DeviceConfigDiagram

Configuration

Now it’s time to start with the configuration of enabling the provisioning of Microsoft Passport for Work on Windows 10 devices. I’ll walk through the configuration steps for Microsoft Intune hybrid and standalone and I’ll provide the configuration options. While going through the configuration options, please make sure to switch back to the PassportForWork CSP a few times and connect the configuration options with the CSP nodes.

Microsoft Intune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to configure Microsoft Passport for Work for enrolled Windows 10 devices.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Cloud Services > Microsoft Intune Subscriptions;
2 Select Microsoft Intune Subscription and on the Home tab, click Configure Platforms > Windows to open the Microsoft Intune Subscription Properties;
3

On the Passport for Work tab, select Enable Passport for Work for enrolled devices, configure the following required settings and click OK;

  • MIHybrid_PropertiesUse a Trusted Platform Module (TPM): Select [Required] or [Preferred] to require or prefer the use of TPM. If TPM is preferred and not available, software encryption is used;
  • Require minimum PIN length: [Specify a minimum PIN length of at least 4 characters];
  • Require maximum PIN length: [Specify a maximum PIN length of up to 127 characters];
  • Require upper-case letters in PIN: Select [Not allowed] or [Required] to specify whether uppercase letters should be used or not;
  • Require lower-case letters in PIN: Select [Not allowed] or [Required] to specify whether lowercase letters should be used or not;
  • Require special characters: Select [Not allowed] or [Required] to specify whether special characters should be used or not;
  • Require PIN expiration: If enabled, [Specify a number of days before PIN must be changed];
  • Prevent reuse of previous PINs: If enabled, [Specify a number of previous PINs that are restricted from reuse];
  • Enable biometric gestures: Select [Yes] or [No] to enable biometric gestures for authentication. If enabled, end-users must still configure PIN in case biometric authentication fails;
  • Use enhanced anti-spoofing, when available: Select [Not configured], [Yes] or [No] to enable the support for anti-spoofing, when available;
  • Use Remote Passport: Select [Yes] or [No] to enable the support for remote passport for Azure AD joined devices or not.

Microsoft Intune standalone

Let’s continue with the same configuration within Microsoft Intune standalone. I’ll walk through the required steps to configure Microsoft Passport for Work for enrolled Windows 10 devices.

1 In the Microsoft Intune administration console, navigate to ADMIN > Mobile Device Management > Windows > Passport for Work;
2

On the Passport for Work page, select Enable Passport for Work on enrolled devices, configure the following required settings and click Save;

  • MIStandalone_PropertiesUse a Trusted Platform Module (TPM): Select [Required] or [Preferred] to require or prefer the use of TPM. If TPM is preferred and not available, software encryption is used;
  • Require minimum PIN length: [Specify a minimum PIN length of at least 4 characters];
  • Require maximum PIN length: [Specify a maximum PIN length of up to 127 characters];
  • Require lowercase letters in PIN: Select [Not allowed], [Allowed] or [Required] to specify whether lowercase letters should be used or not;
  • Require uppercase letters in PIN: Select [Not allowed], [Allowed] or [Required] to specify whether uppercase letters should be used or not;
  • Require special characters: Select [Not allowed], [Allowed] or [Required] to specify whether special characters should be used or not;
  • PIN expiration (days): If enabled, [Specify a number of days before PIN must be changed];
  • Remember PIN history: If enabled, [Specify a number of previous PINs that are restricted from reuse];
  • Enable biometric gestures: Select [Yes] or [No] to enable biometric gestures for authentication. If enabled, end-users must still configure PIN in case biometric authentication fails;
  • Use enhanced anti-spoofing, when available: Select [Not configured], [Yes] or [No] to enable the support for anti-spoofing, when available;
  • Use Remote Passport: Select [Yes] or [No] to enable the support for remote passport for Azure AD joined devices or not.

End-user experience

Let’s end this post with the most important thing, the end-user experience. After the device is registered in Azure AD and enrolled into Microsoft Intune hybrid, or standalone, Microsoft Passport for Work will be provisioned for the end-user. On a fresh device the end-user will be prompted to set up a PIN during the initial logon. A successful configuration will be logged in the User Device Registration node in the Event Viewer with Event ID 300.

End-user experience Event Viewer
PINConfig PINConfig_EV

More information

Fore more information about Microsoft Passport for Work on Windows 10 and the PassportForWork CSP, please refer to:

Share

Setting up kiosk mode on Windows 10 via OMA-DM

A while ago I did a blog post about managing AppLocker on Windows 10 via OMA-DM. During that post I showed how to use OMA-DM, via Microsoft Intune hybrid and standalone, to configure AppLocker. In this post I’ll do something similar for setting up kiosk mode on Windows 10. Windows 10 Enterprise and Windows 10 Education provide a configuration service provider (CSP) for setting up kiosk mode. That’s the AssignedAccess CSP.

During this blog post I’ll go through the AssignedAccess CSP, and its required input, I’ll go through the configuration steps in Microsoft Intune hybrid and standalone and I’ll show the end-user experience with the Twitter app as an example.

AssignedAccess CSP

Before using the AssignedAccess CSP it’s good to get a better understanding  of the CSP. The CSP is used to set up the Windows 10 device to run in kiosk mode. Once the CSP has been executed, then the next user login, that is associated with the kiosk mode, puts the Windows 10 device in the kiosk mode running the specified application. Let’s go through the nodes of the AssignedAccess CSP.

  • AA_CSP./Vendor/MSFT/AssignedAccess– Defines the root node for the AssignedAccess configuration service provider;

  • ApplicationLaunchRestrictions – Defines a JSON string that contains the user account name and the Application User Model ID (AUMID) of the Kiosk mode app
    • The JSON string should look like the following example: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    • The account name can be a domain account as well as a local account. When a local account is used, the domain name should be the name of the device;
    • The Application User Model ID (AUMID) can be easily received through PowerShell. The following example can help with collecting the information:
      foreach ($App in (Get-AppxPackage)) { foreach ($Id in (Get-AppxPackageManifest $App).package.applications.application.id) { Write-Output ($App.packagefamilyname + "!" + $Id) } }

Configuration

Now it’s time to use the AssignedAccess CSP to set up Windows 10 devices in kiosk mode. In this configuration I’m going to use the Twitter app as an example for my domain user account and I’m going to show the required configuration for Microsoft Intune standalone and hybrid.

Microsoft Intune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to configure the required Configuration Item.

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

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

  • Name: [Specify a unique name for the configuration item]
  • Description: [Specify details that help identifying the configuration item]
  • Select Windows 8.1 and Windows 10 with Settings for devices managed without the Configuration Manager client.
4

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

  • All Windows 10 (64-bit)
  • All Windows 10 (32-bit)
5 On the Device Settings page, select Configure additional settings that are not in the default settings groups and click Next;
6 On the Additional Settings page, click Add to open the Browse Settings dialog box.
7 In the Browse Settings dialog box, click Create Setting to open the Create Setting dialog box;
8

KioskModeAppIn the Create Setting dialog box, specify the following information and click OK to return to the Browse Settings dialog box;

  • Name: [Specify a unique name for the setting]
  • Description: [Specify details that help identifying the setting]
  • Setting type: OMA-URI
  • Data type: String
  • OMA-URI (Case Sensitive): ./Vendor/MSFT/AssignedAccess/KioskModeApp
    9 In the Browse Settings dialog box, select the newly created setting and click Select to open the Create Rule dialog box;
    10

    KioskModeApp_RuleIn the Create Rule dialog box, specify the following information and click OK to return to the Browse Settings dialog box;

    • Name: [Specify a unique name for the rule]
    • Description: [Specify details that help identifying the rule]
    • Rule type: Value
    • The setting must comply with the following rule: Equals
    • the following values: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    • Select Remediate noncompliant rules when supported
    11 In the Browse Settings dialog box, click Close to return to the Additional Settings page;
    12 On the Additional Settings page, click Next;
    13 On the Platform Applicability page, click Next;
    14 On the Summary page, click Next;
    14 On the Completion page, click Close;

    Note: This created a configuration item that can be deployed like any other configuration item, as a part of a configuration baseline.

    Microsoft Intune hybrid

    Let’s continue with the same configuration within Microsoft Intune standalone. I’ll walk through the required steps to configure the required Configuration Policy.

    1 In the Microsoft Intune administration console, navigate to Policy > Configuration Policies and click Add to open the Create a New Policy dialog box;
    2 In the Create a New Policy dialog box, select Windows > Custom Configuration (Windows 10 Desktop and Mobile and later) and click Create Policy to open the Create Policy page;
    3

    On the Create Policy page, specify the following information in the General section and click Add in the OMA-URI Settings section to open the Add or edit OMA-URI Setting dialog box;

    • Name: [Specify a unique name for the policy]
    • Description: [Specify details that help identifying the policy]
    4

    KioskModeApp_SAIn the Add or edit OMA-URI Setting dialog box, specify the following information and click OK to return to the Create Policy page;

    • Setting name: [Specify a unique name for the setting]
    • Setting description: [Specify details that help identifying the setting]
    • Data type: String
    • OMA-URI (case sensitive): ./Vendor/MSFT/AssignedAccess/KioskModeApp
    • Value: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    5 On the Create Policy page, click Save Policy to open the Deploy Policy dialog box;
    6 In the Deploy Policy dialog box, click Yes to open the Manage Deployment dialog box;
    7 In the Manage Deployment dialog box, select a group click Add and click OK.

    End-user experience

    Let’s end this post with the most important thing, the end-user experience. After the device receives the new configuration and the configured end-user logs on, the end-user will receive a full screen Twitter app as shown below. The end-user won’t be able to close the Twitter app and can only get out of the kiosk mode by pressing Ctrl+Alt+Del. That will bring the end-user back to the logon screen.

    End-user experience
    TwitterApp

    More information

    Fore more information about kiosk mode on Windows 10, the AssignedAccess CSP and the AUMID, please refer to:

    Share