Conditional access is getting better and better and better

Yeah, I know, I’ve been using similar blog post titles recently. And yes, it might sound cheesy. However, looking specifically at conditional access, it’s easy to say that the current evolution, in the Azure portal, is better than it is in the Azure classic portal, which is better than it is in the Intune Silverlight portal. Based on that, maybe  “The evolution of conditional access” would have been a nice title also. In this post I will go through a little bit of history of conditional access, followed by going through the enhanced capabilities of conditional access in the Azure portal.

Little bit of history

Let’s start by looking at a little bit of history of conditional access. No, I won’t put all the evolutions on a timeline, but I will try to show the biggest changes. Conditional access started as a feature in the Intune Silverlight portal only. In that time it was limited to a few Office 365 services. Later on conditional access also became part of the Azure classic portal and the functionalities got expanded to include other cloud apps and published apps. Very recently conditional access also became part of the Azure portal (still in preview) and the functionalities got expanded to include multiple policies and many, many configuration options. Now let’s go through these evolution in a bit more detail.

Intune Silverlight portal – The Intune Silverlight portal is the portal were it all started for the conditional access functionalities. In the Intune Silverlight portal it’s possible to enable and configure conditional access for the following Microsoft cloud services:

  • Exchange Online;
  • Exchange On-premises;
  • Exchange Online Dedicated (new and legacy);
  • SharePoint Online;
  • Skype for Business Online;
  • Dynamics CRM Online.

Within the conditional access policies it’s possible to configure the following conditions:

  • Platforms (all or specific);
  • Browser (all or supported only);
  • Groups (targeted and/or exempted).
IntuneSilverlight_Example

Azure classic portal – The Azure classic portal is the portal that started with providing more capabilities by making conditional access configurations available as part of Azure AD. In the Azure classic portal it’s possible to configure conditional access for the following additional apps (in addition to the Intune Silverlight portal):

  • Software as a service (SaaS) apps connected to Azure AD;
  • On-premises apps published via the Azure AD Application Proxy.

Within the conditional access policies it’s possible to configure the following additional conditions (in addition to the Intune Silverlight portal):

  • Multi-factor authentication (always, when not at work, block when not at work).
AzureClassic_Example

Azure portal – The Azure portal is still in preview for the Azure AD functionalities. However, the Azure portal is were conditional access becomes  a grown-up functionality. The Azure portal also supports all the mentioned apps from the Azure classic portal and the Intune Silverlight portal. On top of that, it enables the ability to create one policy for all apps, or a policy per app, or even multiple policies per app.

Within the conditional access policies it’s also possible to configure all the mentioned conditions from the Azure classis portal and the Intune Silverlight portal. On top of that, it enables to ability to make every available combination of the available conditions.

Note: The Azure portal even includes the capability to configure conditional access for managed apps. This is part of the Intune mobile app management configuration.

Azure_Example

Note: At this moment all three locations are still available for configuring conditional access. When a conditional access policy is configured at multiple locations, the end-user only gets access when all requirements are met.

Conditional access in the Azure portal

This section is about a preview of the Azure AD management experience in the Azure portal.

Now let’s have a look at the new conditional access experience in the Azure portal and why these changes are really interesting. Let’s do this by going through the different controls and condition statements that are available in the Azure portal.

Policies

The first thing that’s important to know, is that there is no limit anymore in creating conditional access policies for specific apps. The configuration in the Azure portal enables the administrator to create multiple conditional access policies. Not just one per cloud app, but it can even be multiple policies per cloud app. Before every sign-in, Azure AD evaluates all applicable policies and ensures that all requirements are met before granting access to the end-user. Now let’s have a look at adding a policy in more detail.

Policy – When adding a new conditional access policies there are the following 4 sections that can be configured:

  • Name: Every conditional access policy requires a name. That name will be used to identify the policy;
  • Assignments: With assignments the administrator defines the criteria that need to be met, for the controls to be applied, in the form of a condition statement;
  • Controls: With controls the administrator can either block access or allow access. And by allowing access the administrator can also add additional requirements;
  • Enable policy: Every conditional access policy will only be applied when it’s enabled.

Azure_NewPolicy

Assignments

The next thing is to have a look the different assignments that can be part of the condition statement. The assignments can be configured for User and groups, Cloud apps and additional Conditions. When there are multiple assignments configured in the conditional access policy, all assignments are logically ANDed. If there are multiple assignment configured, all assignments must be satisfied.

User and groups – In the User and groups assignment, the administrator can configure to who the conditional access policy must be applied. This can be done by including all users, or by  selecting specific users and/or groups. When specific users must be excluded, that can be configured by adding those users in the exclude section of this assignment. Azure_UsersGroups
Cloud apps – In the Cloud apps assignment, the administrator can configure to what the conditional access policy must be applied. This can be done by including all cloud apps, or by selecting specific cloud apps. When specific apps must be excluded, that can be configured by adding those apps in the exclude section of this assignment. Azure_CloudApps

Conditions – In the Conditions assignment, the administrator can configure how the conditional access must be applied. This can be done by configuring conditions in the following areas:

  • Sign-in risk: In the Sign-in risk condition, the administrator can configure to which risk the conditional access policy must be applied. This can be done by selecting the risk level of High, Medium, Low and No risk;
  • Device platforms: In the Device platforms condition, the administrator can configure to which platforms the conditional access policy must be applied. This can be done by including all platforms, or by selecting specific platforms. When specific platforms must be excluded, that can be configured by adding those platforms in the exclude section of this condition;
  • Locations: In the Location condition, the administrator can configure to which locations the conditional access policy must be applied. The location is identified by the IP address of the device used by the end-user. This can be done by including all locations, or by selecting specific trusted IPs. When trusted IPs must be excluded, that can be configured by selecting those trusted IPs in the exclude section of this condition;
  • Clients apps: In the Client apps condition, the administrator can configure to which apps the conditional access policy must be applied. This can be done by selecting Browser and/or Mobile apps and desktop app.
Azure_Conditions

Controls

Let’s end this post by having a look at the different controls. The controls can be used to either block or allow access. And by allowing access the administrator can, and also must, add additional requirements.

Grant – In the Grant control, the administrator can configure what must be done when the configured conditions happen. This can be done by selecting Block access or Allow access. When the control is used to allow access at least one of the following requirements must be configured:

  • Require multi-factor authentication: The multi-factor authentication requirement can be used to require strong authentication. This can be used in combination with Azure multi-factor authentication, or with an on-premises multi-factor authentication provider (in combination with ADFS);
  • Require compliant device: The compliant device requirement can be used to require a device to be compliant to an additional device compliancy policy. That compliancy policy can be targeted through Microsoft Intune (or any other MDM management solution);
  • Require domain joined device: The domain joined device requirement can be used to require a device to be domain joined to an on-premises AD. The domain join requires automatic registration of the domain joined device in Azure AD.

When multiple requirements are configured in the conditional access policy, the administrator can choose to require all the selected controls or just one of them.

Azure_Grant

Note: Currently, when the control requires multi-factor authentication or a compliant device, the user will be prompted for multi-factor authentication irrespective of the device compliance state.

More information

For more information about conditional access via the Azure portal, the Azure classic portal, or the Intune Silverlight portal, please refer to:

Share

Managing Windows 10 IoT Core devices via MDM

This week a new challenge for a new blog post, managing Windows 10 IoT Core devices. The nice thing about Windows 10, even Windows 10 IoT Core, is the availability of MDM. The availability of MDM is what will help me with managing Windows 10 IoT Core devices. In this post I’ll go through the steps to create an enrollment profile to enroll Windows 10 IoT Core devices in Microsoft Intune hybrid. I’ll end this post with an overview of the end result in Configuration Manager

Configuration

Let’s start by looking at the configuration in Configuration Manager. To create an enrollment profile, for Windows 10 IoT Core devices, it’s required to provide a certificate profile and it’s optionally to provide a Wi-Fi profile.

Create certificate profile

The required component of the enrollment profile is, as mentioned before, a certificate profile. The certificate profile is used to automatically provision a trusted root certificate to the enrolled device. As part of preparing for the certificate profile, export a root certificate.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Compliance Settings > Company Resources > Certificate Profiles;
2 On the Home tab, in the Create group, click Create Certificate Profile to open the Create Certificate Profile Wizard;
3

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

  • Name: Provide a unique name for the certificate profile (max. 256 characters);
  • Description: (Optional) Provide a description about the certificate profile;
  • Select Trusted CA certificate.
4

CCP_TCACOn the Trusted CA Certificate page, provide the following information and click Next;

  • Browse to and select the Certificate file;
  • Select Computer certificate store – Root;
  • Certificate thumbprint will automatically populate.
5

CCPW_SPOn the Supported Platforms page, select Windows 10 and click Next;

Note: Windows 10 IoT Core doesn’t have it’s own platform option, which means that the generic Windows 10 should be used to make it applicable to all Windows 10 devices.

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

(Optional) Create Wi-Fi profile

The optional component of the enrollment profile is, as mentioned before, a Wi-Fi profile. In some scenarios this might be a required component, but it’s not required for the creation of an enrollment profile. Including a Wi-Fi profile in the enrollment profile can be useful when the Windows 10 IoT Core device needs the Wi-Fi profile for connecting with the Internet.

Create enrollment profile

After creating the required and optional components for the enrollment profile, it’s time to create the enrollment profile. The enrollment profile specifies settings that are required for the Windows 10 IoT Core device enrollment, including a certificate profile that will dynamically provision a trusted root certificate to the device and a Wi-Fi profile that will provision network settings if required.

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

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

  • Name: Provide a unique name for the enrollment profile (max. 256 characters);
  • Description: (Optional) Provide a description about the enrollment profile;
  • Select as management authority Cloud.
4

CEPW_TrustedRootCertificateOn the Select Trusted Root Certificate page, select the earlier created certificate profile and click Next

5 On the Wi-Fi profiles page, optionally select the earlier created Wi-Fi profile and click Next;
6 On the Summary page, click Next;
7 On the Completion page, click Close.

Enrollment

After creating the enrollment profile and its required components, it’s time to look at delivering the enrollment profile to the Windows 10 IoT Core device. A Windows 10 IoT Core device doesn’t have the full-blown Windows 10 capabilities to perform a MDM enrollment. However, that doesn’t mean that they’re not capable. That’s were the enrollment package comes into the picture.

Export enrollment package

The first step in bringing the enrollment profile to the Windows 10 IoT Core device, is exporting the enrollment profile as an enrollment package.

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

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

  • EEP_GeneralValidity Period (days): Select the number of days that this package is valid;
  • Package File: Provide a unique name for the enrollment package;
  • Do not select the checkbox with Encrypt Package.
4 On the Export Enrollment Package dialog box, click OK;

Deploy enrollment package

The second step in bringing the enrollment profile to the Windows 10 IoT Core device, is copying the exported enrollment package to the Windows 10 IoT Core device. An alternative could be adding the enrollment package as a provisioning package to a Windows 10 IoT Core image.

1 Open File Explorer and remotely connect to the Windows 10 IoT Core device;
2 Copy the earlier created enrollment package to C:\Windows\Provisioning\Package;
3 Restart the Windows 10 IoT Core device.

End result

Now let’s end this post by looking at some of the information that will flow through the MDM channel into Configuration Manager. After restarting the Windows 10 IoT Core device it can take a couple of minutes before the device appears in Configuration Manager. The Windows 10 IoT Core device will show as a mobile device with the operating system IoTUAP (as shown below).

ConsoleOverview

After the first inventory of the Windows 10 IoT Core device, the information of the deivce will populate in the Resource Explorer. In my case, I used a Raspberry Pi 3 (as shown below on the left) and I installed a custom app (as shown below on the right).

RBP_DeviceInformation RBP_InstalledApps

The nice thing is that, as Windows 10 MDM is used in combination with Configuration Manager, I can extend the inventory (see the PTCLOUD entry above) and I can configure settings. For this I can use the available configuration service providers (CSP).

More information

For more about managing Windows 10 IoT Core devices and enrollment profiles (documentation for on-premises MDM), please refer to:

Share

The Software Center experience is getting better and better

Throughout my blog posts I always think its important to mention the end-user experience. This blog post will be mainly focused on the end-user experience in Software Center. Software Center went, from an end-user experience, through a complete revamp. The best thing is, it’s only getting better and better. Except for a few items, related to the devices of the end-user, Software Center is becoming the one place for the end-user to be. In this post I want to go through the latest changes to Software Center and show the related end-user experience.

Changes

Now let’s start with the latest changes to Software Center. It all started with a new modern look for Software Center and it quickly evolved to a easy customizable app. Especially in combination with a Microsoft Intune subscription. With the latest update to the Company Portal app, with a little bit imagination, one might say that both apps are starting to look like each other.

Look-and-feel

A lot has changed for the look-and-feel of Software Center. Starting with the, at this moment, latest build of Configuration Manager, the branding of Software Center and the Software Center dialogs can be applied according to the following rules:

  • If the Application Catalog website point site server is not installed, then Software Center and Software Center dialogs will only display the organization name as specified in the Client Settings;
  • If the Application Catalog website point site server is installed, then Software Center and Software Center dialogs will display the organization and name and color as specified in the Application Catalog website point site server properties;
  • If a Microsoft Intune subscription is configuration and connected to the Configuration Manager environment, then Software Center and Software Center dialogs will display the organization name, color and company logo as specified in the Microsoft Intune subscription properties.

Another nice addition to  the look-and-feel of Software Center is the improvement help end-users understand what software is new. The new apps will show with a clear notification.

Nowadays the look-and-feel of Software Center also provides a better separation between Applications, Updates and Operating Systems. All with their own section. Updates can be installed all together and Operating Systems provide an additional company branded Software Center dialog. Another new section is about Device compliance. This provides the end-user with a clear insight about the device compliancy and the possible access to resources.

Functional

Besides only look-and-feel adjustments, Software Center also received many functional adjustments. It started by the great addition to add user-targeted apps to the Application section. The latest and greatest functional adjustment builds on that addition and is the addition of the application approval process to Software Center. The end-user can now use Software Center to request applications that require administrator approval.

Another nice addition to the functional adjustments, is more on the background. Starting with the, at this moment, latest build of Configuration Manager, the administrator can now also deny a previously approved application.

End-user experience

Now let’s end this post with a scenario that will cover as many as possible great additions to Software Center as possible. I thought that using an application request scenario would cover as many as possible of these great additions. The only thing not shown in this scenario is the company branded Software Center dialogs, but, believe me, it looks great!

During the following scenario the end-user and the administrator will touch the complete application approval process by using, request, cancel, approve and deny.

1 SC_AppsOverviewThe end-user opens Software Center and enjoys the beautiful icons and notifications about new apps.
2 SC_AppRequestThe end-user would like to install Notepad++ 7.3.5 and notices that the app requires approval. The end-user provides optional information and clicks Request.
3 SC_AppRequestSubmittedThe end-user immediately receives the message that the request was submitted successfully.
4 The administrator approves the app request.
5 Toast_AppApprovedThe end-user receives a toast message that a requested app is approved.
6 SC_AppRequestApprovedThe end-user opens Software Center and now has the option to install Notepad++ 7.3.5. The end-user installs the app, by clicking Install and is happy.
7 The end-user no longer needs the app and the app is uninstalled.
8

The administrator denies the existing app request.

Note: When an administrator denies an already approved app the app is not automatically uninstalled from the end-user device.

9

SC_AppRequestDeniedThe end-user opens Software Center again and notices that Notepad++ 7.3.5 can no longer be installed.

Note: At this moment it looks like information about approved apps is stored locally on the device.

10 SC_AppRequestAgainThe end-user gets a new assignment and requests Notepad++ 7.3.5 again by providing optional information and clicking Requests.
11 SC_AppRequestAgainSubmittedThe end-user immediately receives the message again that the request was submitted successfully.
12 SC_AppRequestAgainCancelledThe end-user changes its mind and cancels the request for Notepad++ 7.3.5 by clicking Cancel request.

More information

More information about what’s new in the different current branch versions, please refer to this article about What’s new in System Center Configuration Manager incremental versions.

Share

Block and allow apps on Samsung KNOX devices

This week a blog post about the capabilities to block apps from starting and to allow apps to install on Samsung KNOX devices. I thought it would be good to mention these capabilities, as many are only familiar with the capability to work with compliant or noncompliant apps on Android. That capability can only be used for reporting functionalities. These capabilities are specifically for Samsung KNOX devices and can truly, and literally, block apps from starting. During this post I’ll go through the high-level steps to configure a blocked app and the end-user experience for both capabilities.

Information

Let’s start with some information about what can be achieved by using the block apps from starting and the allow apps to install capabilities. When using the block apps from starting capability, a list must be created of apps that are blocked from running on the device. Apps in this list are blocked from being run, even if they were already installed when the policy was applied. This list doesn’t prevent users from installing the apps. When using the the allow apps to install capability, a list must be created of apps that users of the device are allowed to install from the Google Play store. Only the apps in this list can be installed. No other apps can be installed from the store. This list doesn’t prevent users from starting the apps.

Configuration

Now let’s have a look at the high-level steps for these configuration. However, before I’m going to look at these steps, it’s good to mention that the configurations can be achieved by using OMA-URI settings. The following OMA-URI settings are available for these configurations:

  • To create a block apps from starting list, use the following OMA-URI: ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/PreventStartPackages
  • To create an allow apps to install list, use the following OMA-URI: ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/AllowInstallPackages

To find the value for these OMA-URI settings, the Google Play Store can be used. The app identifier that is used within the store, is what is needed to add a value to the block or allow lists. For example, when I’m looking at the OWA for Android app, in the store, the bold section, in the following URL, represents the required value: https://play.google.com/store/apps/details?id=com.microsoft.exchange.mowa&hl=en.

Now let’s have a look at how these two come together in the configurations for Microsoft Intune hybrid and Microsoft Intune standalone.

Environment Configuration
Microsoft Intune hybrid

PreventStartPackages_MSIhThe configuration in Microsoft Intune hybrid can be performed by starting the Create Configuration Item Wizard in the Configuration Manager administration console. Make sure to select Android and Samsung KNOW (below Settings for devices managed without the Configuration Manager client) on the General page and to select Android KNOX Samsung Standard 4.0 and higher on the Supported Platforms page. Now select Configure additional settings that are not in the default setting groups on the Device Settings page and the configuration can begin by using the earlier mentioned OMA-URI settings.

Once the configuration is finished the created configuration item can be added to a configuration baseline and can be deployed to Samsung KNOX devices.

Microsoft Intune standalone

PreventStartPackages_MSIsThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for Custom Configuration (Android 4.0 and later, Samsung KNOX Standard 4.0 and later) in the Microsoft Intune administration console. Navigate to the OMA-URI Settings section and the custom settings can be added.

Once the configuration is finished the policy can be saved and can be deployed to Samsung KNOX.

Note: When the block or allow lists must contain multiple apps, one of the following four characters ; : , | can be used as a delimiter.

End-user experience

Let’s end this blog post by having a look at the end-user experience. Below, on the left, is the end-user experience when the end-user starts an app that is blocked from starting. It’s indeed correct that it doesn’t show a screenshot. Reason behind that is because it actually lacks a real end-user experience. When the end-user tries to start a blocked app, the app won’t start and the end-user won’t get any notifications. Below, on the right, is the end-user experience when the end-user tries to install an app that is not allowed to install. The end-user will receive an error message accompanied by the message “Security policy prevents installation of this application”, which is a clear end-user experience.

Block app from starting Allow app to install
The app won’t start and the end-user won’t get a notification about what’s happening. Screenshot_20170122-125800

More information

Fore more information about blocking and allowing apps on Android devices, please refer to:

Share

Managing Windows Defender via Windows 10 MDM is getting easier and easier

This post is an updated version of a blog post that I did one-and-a-half year ago about managing Windows Defender, of Windows 10, via OMA-DM. As I still get questions about that post and the OMA-URI settings that are used in that post, I thought it would be good to mention that easier methods are available nowadays. Starting with Configuration Manager 1610 and the Microsoft Intune standalone update around March/ April 2016, it’s simply configurable through the console. No need anymore to configure all those OMA-URI settings manually.

Within this post I’ll provide a quick overview of the configuration options, followed by an overview of the end result. That end result will show how the configured settings simply translate to the known OMA-URI settings.

Configuration

Now let’s have a quick look at the required configurations for Microsoft Intune hybrid and Microsoft Intune standalone. I won’t provide a step-by-step guidance, but I will show were to find the settings and what to do with them.

Environment Configuration
Microsoft Intune hybrid

CCIW_WinDefThe configuration in Microsoft Intune hybrid can be performed by starting the Create Configuration Item Wizard in the Configuration Manager administration console. Make sure to select select Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page. Now select Windows Defender on the Device Settings page and the configuration can begin.

Once the configuration is finished the created configuration item can be added to a configuration baseline and can be deployed to Windows 10 devices managed via the MDM channel.

Microsoft Intune standalone

WinDef_MSISThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for General Configuration (Windows 10 Desktop and Mobile and later) in the Microsoft Intune administration console. Navigate to the Endpoint Protection section and the Windows Defender settings will show.

Once the configuration is finished the policy can be saved and can be deployed to Windows 10 devices managed via the MDM channel.

Note: That these configuration options are available nowadays, doesn’t mean that it’s not possible anymore to create custom OMA-URI settings. That is still a valid method to configure these type of settings and changes to these types of settings will always be the first available via custom OMA-URI settings.

End result

Let’s finish this post by looking at the end result. I could do this by showing the Windows Defender section in the Settings panel on a Windows 10 device, but that will only show grayed out settings and the message Some settings are managed by your organization. I think it’s more interesting to link the created settings to the OMA-URI settings. A great place to look at that is the Deployments node in the Configuration Manager administration console. When I’m looking at the compliance state of the deployment, it will show the Setting Name and the related Instance (in this case the OMA-URI setting), as shown below.

WinDef_Compl

Like last week, I can use a combination of PSEXEC and my favorite WMI Explorer, to locate the created instance with the results of the created policies. As should be familiar by now, the Policy/Result node groups the evaluated policies from all available providers that can be configured. That’s the reason why the example below shows the MDM_Policy_Result01_Defender02 class instead of the MDM_Policy_Config01_Defender02 class. The first class relates to the Policy/Result node and the second class relates to the Policy/Config node.

MDM_Defender02

More information

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

Share

Automatic edition upgrade for Windows devices

My first blog post in this new year will be about the feature to automatically upgrade the edition of Windows devices. This is already possible, for a while, for Windows 10 devices managed via the MDM channel. However, starting with Configuration Manager 1610 this is now also possible for Windows 10 devices managed via the Configuration Manager client.

In this post I’ll provide the general information and configuration settings that are applicable for Microsoft Intune hybrid and Microsoft Intune standalone. I’ll end this post by showing the details of the end result on a Windows 10 device managed via the Configuration Manager client. Think about details like how this is achieved and the relation to the MDM channel.

Information

The edition upgrade feature can be used to, for example, automatically upgrade devices bought with Windows 10 Pro to Windows 10 Enterprise, without the requirement to reimage the devices. This enables users to buy their own device and get their license upgraded after enrollment. With the new addition to Configuration Manager 1610, the following management scenarios are supported for Windows 10 devices:

  1. Managed via the MDM channel by Microsoft Intune standalone;
  2. Managed via the MDM channel by Microsoft Intune hybrid;
  3. Managed via the Configuration Manager client by Microsoft Intune hybrid (or Configuration Manager standalone).

Within each of those management scenarios the following upgrade paths are supported.

From edition To edition
Windows 10 Pro Windows 10 Enterprise
Windows 10 Pro N Windows 10 Enterprise N
Windows 10 Home Windows 10 Education
Windows 10 Home N Windows 10 Education N
Windows 10 Mobile Windows 10 Mobile Enterprise
Windows 10 Holographic Windows 10 Holographic Enterprise

Configuration

Now let’s have a quick look at the configuration. To perform an edition upgrade, Microsoft Intune hybrid and Microsoft Intune standalone, both require the following information during the creation of the policy:

  • Name: A name for the edition upgrade policy;
  • Description (optional): A description for the edition upgrade policy;
  • SKU to upgrade device to/ Edition to upgrade to: A selected edition that the edition upgrade policy should upgrade to;
  • Product Key: For Windows 10 Desktop, a valid product key that can be used by the edition upgrade policy to install the new version of Windows. This can be either Multiple Activation Keys (MAK) or Key Management Server (KMS) keys;
  • License File: For Windows 10 Mobile and Windows 10 Holographic, a valid license file that can be used by the edition upgrade policy to install the new version of Windows.

This information is requested during different wizards, in Microsoft Intune hybrid and Microsoft Intune standalone, as shown below.

Microsoft Intune hybrid Microsoft Intune standalone
EdiUpgrPol_MSIH EdiUpgrPol_MSIS

End result

Let’s end this post by looking at the end result. In this case it’s not really interesting to look at a screenshot of before and after, as it will simply show a different edition. It’s a lot more interesting to look at how it’s achieved. For Windows 10 devices that are managed via the MDM channel, the WindowsLicensing CSP is used.

Now let’s have a look at how this is achieved on Windows 10 devices that are managed via the Configuration Manager client. As the edition upgrade policy is applied like a configuration baseline, a good place to start with looking is the DcmWmiProvider.log. Below is a log snippet about a successful edition upgrade.

>>>>>>Starting PutInstanceAsync in OsEditionUpgradeProvider<<<<<<
Class name: MDM_WindowsLicensing
>>>>>>Starting PopulateKeyValueParameters in OsEditionUpgradeProvider<<<<<<
Getting properties of wrapper class MDM_WindowsLicensing.
>>>>>>Finished PopulateKeyValueParameters in OsEditionUpgradeProvider<<<<<<
Using created object instance __PATH = \\.\root\cimv2\mdm\dmmap:MDM_WindowsLicensing.ParentID=’./Vendor/MSFT’,InstanceID=’WindowsLicensing’
Creating parameters for method CheckApplicabilityMethod
Requesting productkey for EditionUpgrade
Successfully requested productkey for EditionUpgrade
Calling method CheckApplicabilityMethod
Successfully Executed method CheckApplicabilityMethod, return value 0
Calling method UpgradeEditionWithProductKeyMethod
Successfully Executed method UpgradeEditionWithProductKeyMethod, return value 0
PutInstanceAsync Succeeded
>>>>>>Finished PutInstanceAsync in OsEditionUpgradeProvider<<<<<<

That log snippet provides clear information about the class (MDM_WindowsLicensing) and the methods (CheckApplicabilityMethod and UpgradeEditionWithProductKeyMethod) that are used to upgrade the edition by creating a new instance. By using a combination of PSEXEC and my favorite WMI Explorer, I can simply locate the created instance, as shown below.

MDM_WindowsLicensing

After locating the MDM_WindowsLicensing class, or after a logic interpretation of the name of the class, and the created instance, it’s pretty clear that the MDM Bridge WMI Provider is used to perform the edition upgrade action. In other words, the Configuration Manager client is simply using the existing MDM capabilities. Basically this means that all management scenarios use the same configuration method, but just use another path to get the job done.

More information

Fore more information about the Windows edition upgrade policy, the Windows licensing CSP and the Windows licensing WMI class, please refer to:

Share

Updated tool: Remote Mobile Device Manager

My early Christmas present, for the community, is an updated version of my Remote Mobile Device Manager tool! This version includes a couple of bug fixes, a couple of added functionalities and a couple of look-and-feel adjustments. In this blog post I’ll provide an overview of those changes, I’ll provide an overview of the new look-and-feel and I’ll show the usage. For an overview of all the previously available features, please refer to my blog post about the previous version of my Remote Mobile Device Manager tool.

>> The updated version is now available for download <<

Changes

Now let’s start with a quick overview of the changes to this new release of my Remote Mobile Device Manager tool. This version includes the following changes and bug fixes:

  • Bug fix 1: In the previous release it was possible to perform remote actions on Windows 10 devices that were not applicable. This has been adjusted by first verifying the platform of the selected device, before providing the list of applicable remote actions;
  • Bug fix 2: In the previous release it could happen that devices were shown that didn’t belong to the provided user. This has been adjusted by adjusting the query, to select the devices of a user, to join on device identifier instead of device name (thanks for the suggestion Iain Fairbairn);
  • Functional 1: Added functionality to sent a sync request to
    de selected device (new functionality starting with Configuration Manager 1610);
  • Functional 2: Added functionality to get the status of a
    sync request for the selected device (new functionality starting with
    Configuration Manager 1610);
  • Look-and-feel 1: In the previous release it would show a button for every remote action. This has been adjusted to a combo box that shows applicable items based on the platform of the selected device (thanks for the suggestion Nickolaj);
  • Look-and-feel 2: Added additional columns to provide information about the serial number and the IMEI of the device (thanks for the suggestion Kent).

Overview

Let’s continue with how these changes impact the new look-and-feel of my Remote Mobile Device Manager tool. This version provides the following look-and-feel.

RMDM_v12

In this look-and-feel there are three sections that I would really like to highlight:

  1. The Remote Actions section has changed. It now provides a combo box and a single button. This combo box will only show the remote actions that are applicable to the platform of the selected device;
  2. The Sync Request and Sync Request State remote actions have been added. The Sync Request remote action will trigger a device to check for new polices and the Sync Request State remote action will show the status of the Sync Request remote action. These remote actions require Configuration Manager 1610;
  3. The Serial number and IMEI columns have been added. These columns provide information that can help with easily getting an overview of relevant information for a device.

Usage

Let’s end this post with the usage of my Remote Mobile Device Manager tool. The good news is. this hasn’t changed. It’s still built on WMI and it still doesn’t require the Configuration Manager cmdlets. Also, to start this tool the following parameters are still available:

  • SiteServer: This parameter is mandatory and should point to a server containing the SMS provider;
  • AllowWipe: This switch is optional and enables the button to wipe (factory reset) a device.
Share

Send sync request to devices

In preparation for an upcoming new release of my Remote Mobile Device Manager tool, this week a short blog post about the Send Sync Request feature. This feature enables the administrator, in a Microsoft Intune hybrid environment, to remotely trigger a synchronization of a device and is available starting with Configuration Manager 1610. In this post I’ll provide some basic information, go through the methods to trigger this action, the Configuration Manager console and PowerShell, and I’ll provide some information about the administrator experience.

Information

Before showing the methods to use the Send Sync Request feature, it’s good to provide some information about when a device typically checks in. The first thing to keep in mind is that when an app, or policy, is deployed, Microsoft Intune will immediately attempt to notify the targeted devices to check in. This should take less than five minutes. If the device doesn’t check in to get the deployed app, or policy, Microsoft Intune tries three more times. When Microsoft Intune couldn’t reach the device, the device will get the deployed app, or policy, on the next scheduled check in. The default check in interval is shown in the table below.

Platform Just enrolled device Default
iOS and Mac OS X Every 15 minutes for 6 hours Every 6 hours
Android Every 3 minutes for 15 minutes, then every 15 minutes for 2 hours Every 8 hours
Windows Phone Every 5 minutes for 15 minutes, then every 15 minutes for 2 hours Every 8 hours
Windows 8.1/10 PCs Every 3 minutes for 30 minutes Every 8 hours

Besides the mentioned check in interval of the device, the end-user can always use the Company Portal app to immediately make the device check for policies. New in this chain is the ability of the administrator to use the Send Sync Request feature. This will request a policy sync on the device.

Method 1: Configuration Manager console

Now let’s start with the easiest method to use the Send Sync Request feature, which is using the Configuration Manager console. This can be achieved by simply performing the next steps.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Devices.

2

MenuOptionSelect a device, managed via Microsoft Intune, right click the device and select Remote Device Actions > Send Sync Request.

Note: The same action is available when selecting a device, managed via Microsoft Intune, and selecting Remote Device Actions > Send Sync Request in the Device section of the Home tab.

Method 2: PowerShell

Next is the method that was the trigger for this blog post, which is using PowerShell. The first thing I noticed is that the Send Sync Request feature is not yet available via the Invoke-CMDeviceAction cmdlet. Not a problem, as I wanted to use WMI. Using WMI removes the requirement of the Configuration Manager cmdlets, which is great for my tool.

This can be achieved by using the Invoke-WmiMethod cmdlet. First connect to the site server (ComputerName) and the correct namespace (Namespace). Now use the SyncNow (Name) method, of SMS_DeviceMethods (Class), with the device identifier as parameter (ArgumentList). Below is an example that brings these parameters together.

Invoke-WmiMethod -ComputerName $SiteServer ` -Namespace root/SMS/site_$($SiteCode) ` -Class SMS_DeviceMethods ` -Name SyncNow ` -ArgumentList ($MobileDeviceId) ` -ErrorAction Stop

Administrator experience

Usually I’ll end my post with showing the end-user experience, but in this case it’s more interesting to look at the administrator experience. The administrator can add an additional column, named Sync Request State, in the Configuration Manager administration console, when looking at devices. That column will provide the status of the sync request, as shown below.

SyncAdminConsole

Another interesting location, to look at, is the SMSProv.log. That log file shows the execution of the sync request. Once the administrator uses the Send Sync Request feature, a similar activity, as shown below, will be available in the log file.

SyncSMSProv

More information

Fore more information about the Send Sync Request feature and the device check in interval, please refer to:

Share

Conditional access for managed apps

After a great MVP Summit and a session at a great Experts Live, it’s finally time for a new blog post. This blog post will be about conditional access for managed apps (MAM CA). About a month ago, I did a first post about this feature when it was still in preview. The good news is that the first part of this feature is now production ready for all tenants. In this post I’ll go through an introduction of MAM CA, the flow of MAM CA, the prerequisites of MAM CA, the configuration of MAM CA and the end-user experience of MAM CA.

Introduction

By now, I think, everybody should be familiar with the mobile app management without enrollment (MAM-WE, previously also referred to as MDM-less MAM) feature. MAM-WE helps with making sure that company data and resources are protected, even though the device is not managed. MAM CA adds an additional layer to that picture. MAM CA helps with making sure that only mobile apps that support Intune MAM policies are allowed to access Office 365 services (for now only Exchange Online). That enables us to allow access to Office 365 services, without the need to require enrollment and only for apps that can be managed.

Flow

Now let’s have a look at the flow that is used by MAM CA, by going through the steps in the picture shown below.

CA_MAMWE

Note: In the above picture CP is referring to the Company Portal app on Android and AA is referring to the Azure Authenticator app on iOS.

  1. Start: The end-user signs in to a managed app;
  2. App Approved?: When the end-user is restricted with MAM CA policies, a check is done to see if it’s an approved app. The approved apps are stored on a list in Azure AD and during the sign-in the app is validated with that list. When the app is not on the list, the end-user will be prompted that it’s not allowed to sign in via the app;
  3. CP/AA Present?: When it’s an approved app, a check is done to see if the broker app is installed on the device. On iOS this is the Azure Authenticator app and on Android this is the Company Portal app. When the broker app is not installed on the device, the end-user will be prompted to install the app;
  4. AAD Registered?: When the broker app is installed, and the end-user is signed in, a check is done to see if the device is registered in Azure AD. When the device is not registered in Azure AD, the end-user will be prompted to register the device.
  5. Approved: When the device is registered in Azure AD, the end-user can access Exchange Online via the managed app.

Note: The device registration in Azure AD will create a device record and certificate against which tokens are issued. There is no management profile installed on the device and there are no policies applied to the device. The device record in Azure AD only contains the alternativeSecurityIds, the deviceOSType, the deviceOSVersion and the displayName properties.

Configuration

After knowing what MAM CA is and knowing how MAM CA works, it’s time to look at the perquisites and the configuration.

Prerequisites

Before starting looking at the configuration, it’s good to be aware of the following prerequisites/ requirements/ limitation.

  • The end-user must be licensed for Enterprise Mobility + Security or Azure Active Directory premium;
  • At this moment MAM CA is only available for Exchange Online;
  • The end-user must install the broker app on their device;
  • MAM CA relies on modern authentication.

Configuration options

Now let’s have a look at the configuration options for MAM CA. The MAM CA polices contain three different configuration sections. These three sections together are the targeted MAM CA policy. Let’s go through these three section and see how they can be used.

1

MAMCA_AllAppsThe first configuration section is Allowed apps. The Allowed apps is used to select the mobile apps for iOS and Android that are allowed to access Exchange Online.

MAMCA_ManagedAppsTo allow apps to connect to Exchange Online the administrator can choose between selecting Allow all apps and Allow apps that support Intune app policies. The latter selection currently contains Skype for Business, Excel, PowerPoint, Word, OneNote, Outlook, Microsoft SharePoint and OneDrive for Android and iOS.

2 MAMCA_RestrUsGrThe second configuration section is Restricted user groups. The Restricted user groups section is used as the targeting mechanism for the MAM CA policy. Every available group in Azure AD can be selected. The selected group will be restricted by the MAM CA policy, immediately after saving the MAM CA policy.
3 petervanderwoude.nlThe third configuration part is Exempted user groups. The Targeted apps section is used as an exemption mechanism for the MAM CA policy. Every available group in Azure AD can be selected. The selected group will be exempted from the MAM CA policy, immediately after saving the MAM CA policy.

Additional considerations

An additional consideration for MAM CA is to close the gap for apps that don’t support modern authentication. Without closing that gap, apps that don’t support conditional access might still be able to connect. Let’s go through a method to close that gap.

4

ADFS_ModernAuthAn additional consideration is to use AD FS to block non-modern authentication. This can be achieved in AD FS 2016 by creating an Access Control Policy and assigning it to the Microsoft Office 365 Identity Platform Relying Party Trust.

That Access Control Policy must contain at least a rule to Permit users with Endpoint Path contains (/adfs/ls)|(/adfs/oauth2) in the request. This will make sure that only apps, using modern authentication, can connect to any cloud services that uses the Microsoft Office 365 Identity Platform Relying Party Trust.

End-user experience

After configuring MAM CA, it’s time to have a look at the end-user experience. I’m going to show the end-user experience of an end-user signing in to an approved app. However, before showing that experience it’s good to mention a few important facts about the end-user experience.

  • Every Exchange Active Sync mail client, including the built-in mail clients on iOS and Android, will be blocked. Instead end-users receive an email informing them that they need to use the Outlook mail app (see also this post);
  • If an end-user is targeted with MAM CA and “normal” conditional access (Device CA) policies, the end-user must meet one of the two requirements:
    • The used app is allowed by MAM CA;
    • The used device is managed by Microsoft Intune (hybrid or standalone) and compliant, or it’s a domain-joined PC.

Now let’s have a look at the Microsoft Outlook app and the flow that I described earlier. The end-user signs in to the Microsoft Outlook app and is prompted to install the Azure Authenticator app (see first screenshot). Once the end-user signs in to the Microsoft Outlook app and the Azure Authenticator app is installed, the end-user is prompted to open the Azure Authenticator app (see second screenshot).

Azure Authenticator app not installed Azure Authenticator app is installed
IMG_0098 IMG_0099

After switching to, and signing in to, the Azure Authenticator app, and the device is not registered, the end-user is prompted to register the device (see first screenshot). Once the device is successfully registered, and the end-user is successfully signed in, the end-user will be allowed access and receive the configured MAM policies (see second screenshot).

Device is not registered Device is registered
IMG_0100 IMG_0101

More information

Fore more information about MAM CA and related components, please refer to:

Share

Managing browser settings via Windows 10 MDM

This week a short blog post about managing browser settings via Windows 10 MDM. Most of these settings are not very special and are very well documented in the Policy CSP. However, the configuration of the home page is a small exception. Not just because the documentation is slightly off, but also because of an important change with the anniversary update of Windows 10. As most of the settings are very well documented, this post will be focused on managing the home page. I’ll provide basic information, the configuration information and show the end-user experience.

Information

Before starting about the configuration of home pages, via Windows 10 MDM, it’s good to mention a few important notes:

  • Browser settings for Microsoft Edge can be managed;
  • Browser settings for Internet Explorer cannot be managed;
  • HTTP is the default for home pages;
  • Multiple home pages can be enforced;
  • Home pages are supported on all Windows 10 for desktop editions;
  • Starting the anniversary update of Windows 10, the end-user cannot change the enforced home page.

Configuration

With this information in mind, let’s have a look at the options for configuring the home page in Microsoft Edge. The home page can be configured with a single page and with multiple pages. Per configured home page, a new tab will be opened. When a single home page must be configured, the URL alone is enough. When multiple home pages must be configured, the URLs must be separated by using the XML-escaped characters < and >.  Below is the required OMA-URI and example values, including configuration examples for Microsoft Intune standalone and Microsoft Intune hybrid.

  • OMA-URI: ./Vendor/MSFT/Policy/Config/Browser/Homepages
  • Values (single home page): petervanderwoude.nl
  • Values (multiple home pages): <petervanderwoude.nl><https://petervanderwoude.nl>
Microsoft Intune hybrid Microsoft Intune standalone
MIH_W10_Homepages MIS_W10_Homepages

End-user experience

Now let’s end with the end-user experience, starting with the anniversary update of Windows 10. When the end-user starts Microsoft Edge, the configured home page will show. When the end-user navigates to the settings of Microsoft Edge, the Open Microsoft Edge with setting is grayed out and shows the configured home page. Below are examples of that setting with a single home page and with multiple home pages.

Single homepage Multiple homepages
CSP_Homepage CSP_Homepage_2

More information

Fore more information about configuring browser settings via Windows 10 MDM, please refer to the documentation about the Policy CSP.

Share