Conditional access and legacy authentication

This week is still all about conditional access. More specifically, the recently introduced feature to create conditions based on the use of legacy authentication (including older Office versions), which is currently still in preview. By now, I’ve done my fair share of posts regarding blocking legacy authentication (see for example here and here), but now it’s literally getting super easy. And no need for AD FS anymore. This helps with easily closing another backdoor, as previously legacy authentication simply bypassed any conditional access policy. In this post I’ll walk through the required configurations followed by the end-user experience.

Configuration

Before going through the configuration let’s start with a quick reminder about legacy authentication. Very simplistically said, legacy authentication is basic authentication that uses a single authentication factor in the form of a username and password and cannot force a second authentication factor (think about protocols like, POP3, IMAP, SMTP, MAPI and EWS and apps like, Office 2010). As I have no need for legacy authentication in my environment, I will block all legacy authentication to my apps. The following seven steps walk through the simple configuration to create a conditional access policy that blocks the access to all cloud apps for all users when using legacy clients.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups02On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps02On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5 AAD_CA_ClientApps02On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps (preview) to open the Client apps (preview) blade. On the Client apps (preview) blade, click Yes with Configure, select Mobile apps and desktop clients > Other clients and click Done and Done;
6

AAD_CA_Grant02On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select.

Note: Make sure that there are no apps within the environment that still need basic authentication, as this configuration will block all of it.

7 Open the New blade, select On with Enable policy and click Create;

Note: It can take up to 24 hours for the policy to take effect.

End-user experience

One of the best use cases is an old Office version. Office 2010 and the default configuration of Office 2013, both use basic authentication. Office 2016 and later use modern authentication by default. Due to the way basic authentication works the end-user experience is not pretty and will not be pretty. Below is an example of the end-user experience when using Outlook 2010 for connection to Exchange Online. As mentioned, it’s effective and not pretty.

BlockOutlook

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Client apps.

Join us at Experts Live Netherlands in Ede

A bit more than a week from now, June 19, Experts Live Netherlands will be in Ede. Experts Live Netherlands is the biggest Microsoft community event of the BeNeLux, with over a 1000 visitors. Together with my finest colleague, Arjan Vroege, I will deliver a session about your ultimate hybrid workplace. And we hope to see you there!

EL_social_tempate_speakers_Arjan

About our session

During this session we will take you into the world of the hybrid workplace. The modern workplace is a great story, for cloud only organizations, but the reality is often that there are a lot of components still on-premises. During this session we will touch the different delegate subjects from identity until apps and from management until connectivity. That means, a lot of ground to cover and a lot of choices to be made. Besides that we will have a couple of cool demos, here is a small list with a sneak preview of subjects that will be part of our session:  Pass-through authentication, Co-management, MSIX and Azure AD Application Proxy. Make sure that you don’t miss this!

Additional giveaway

As my employer, KPN ICT Consulting, is one of the Gold Partners of Experts Live Netherlands 2018, we also have a partner session. During that sessions my colleagues, Arjan Vroege and Nicolien Warnars, will explain how we internally migrated to a Microsoft 365 workplace for over 12.000 users. Very interesting for organizations that are looking for a great reference case.

Conditional access and device state

This week back in conditional access again. More specifically, the recently introduced feature to exclude devices based on the device state, which is currently still in preview. This enables organizations to exclude managed devices (Hybrid Azure AD joined and/ or compliant) from a conditional access policy. That means that the conditional access policy will only be applicable to unmanaged devices. This enables new scenarios and makes existing scenarios easier. Think about using session controls to enable a limited experience within cloud apps, for unmanaged devices only. In this post I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

The configurations that make the most sense for using the device state are related to the access controls. At least, in my opinion. All other scenario’s can also be created by using the already available options. It just makes it a bit easier. By looking at the access controls, the session related controls are the most obvious configuration to start with. The Use app enforced restrictions session control enables organizations to enable a limited experience within a cloud app, for, in this case, unmanaged devices and the Use proxy enforced restrictions session control enables organizations to sent the user sign-in information to Microsoft Cloud App Security, also for, in this case, unmanaged devices. That enables additional actions based on the users sign-in activity. The following seven steps walk through the simple configuration to create a conditional access policy that uses the proxy enforced restriction session control.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups01On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps01On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5

AAD_CA_DeviceState01On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device state (preview) to open the Device state (preview) blade. On the Device state (preview) blade, click Yes with Configure, click Exclude, select Device Hybrid Azure AD joined and Device marked as compliant and click Done and Done;

Note: Think about the easier scenarios that can be created by using the option to exclude domain joined devices from the conditional access policy.

6

AAD_CA_Session01On the New blade, select the Session access control to open the Session blade. On the Session blade, select Use proxy enforced restrictions (preview) and click Select.

Note: Optionally configure additional a Cloud App Security Access policy or Cloud App Security Session policy to enable additional behavior based on the sign-in information of the user. For example, block the sign-in for a specific cloud app.

7 Open the New blade, select On with Enable policy and click Create;

Note: Basically the Azure AD conditional access policy and the Conditional Access App Control access or session policy will work together to perform real-time monitoring and control.

End-user experience

Let’s end this post with the end-user experience, followed with the administrator experience. As I only have connectors for Office 365 and Microsoft Azure in my Cloud App Security, I can only create access policies for the connected apps. These access policies can be used to simply monitor the activity or to actually block the session and display a custom block message. Besides that, the policy can also create alerts. In the dashboard, via email and via text message.

I created a policy that would block the session of the end-user with a custom message as shown below. Yes, I could have blocked the session already with conditional access itself, but this provides me with some more information about the sign-in.

CloudAppSecurity_Blocked01

When I’m now looking in the Cloud App Security dashboard, I can already see the alerts. When I navigate to either Investigate > Activity log or Alerts, I can look at the information as shown below. That provides me with the source, which, in this case. is Azure AD conditional access, the matched policy and information about the user and the device (as shown below). Pretty nice.

AppDashboard01

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Device state.

Windows enrollment status page

This week is all about the enrollment status page for Windows 10, version 1803 and later, devices. Yes, I know that I’m not the first to write about this subject and I won’t be the last either, but I really thought that this feature deserves and demands a place on my blog. With the recent updates to Microsoft Intune, it’s now possible to enable the enrollment status page, as a preview feature, for Windows 10, version 1803 and later devices. This feature is often mentioned in combination with Windows AutoPilot, and it’s a great addition, but it’s good to remember that it’s actually applicable to any Azure AD joined (and Intune managed) Windows device. Not just Windows AutoPilot. In this post I’ll walk through the configuration options, followed by the end-user experience related to the configuration options.

Configuration options

Let’s start by walking through the configuration options for the Windows enrollment status page. The following 5 steps walk through those configuration options, with step 4 detailing the actual configuration options and the related behavior.

1 Open the Azure portal and navigate to Intune > Windows enrollment > Enrollment Status Page (Preview) to open the Enrollment Status Page (Preview) blade;
2 EnrollmentStatusPageOn the Enrollment Status Page (Preview) blade, select Default to open the All Users blade;
3 On the All Users blade, select Settings to open the All Users – Settings blade;
4a

Windows-enrollment-status_Config03On the All Users – Settings blade, select Yes with Show app and profile installation progress to enable the enrollment status page during OOBE;

4b Windows-enrollment-status_Config02On the All Users – Settings blade, select Yes with Block device use until all apps and profiles are installed to prevent users from using the device before it’s completely configured and to enable further configuration options for the enrollment status page during OOBE;
4c Windows-enrollment-status_Config01On the All Users – Settings blade,

  • select Yes with Allow users to reset device if installation error occurs to enable end-users to reset the device after a failure during OOBE;
  • select Yes with Allow users to use device if installation error occurs to enable end-users to use the device after a failure during OOBE;
  • configure [number] with Show error when installation takes longer than specified number of minutes to determine how long, in minutes, an installation can take before showing a failure during OOBE;
  • select Yes with Show custom message when an error occurs to enable a custom error message that will be shown to the end-user after a failure during OOBE;
  • select Yes with Allow users to collect logs about installation errors to enable end-users to collect log files of any installation failure during OOBE;
5 On the All Users – Settings blade, click Save;

Note: At this moment I haven’t been able to see my custom error message during OOBE and I haven’t found out how to collect the log files related to the installation failures as an end-user.

Configuration results

Now let’s have a look at the effect of the different configuration options. When configuring the basics, which is simply enabling the enrollment status page (steps 4a), the end-user will get the experience as shown below. It shows the end-user the current status and enables the end-user to click Continue anyway at any point during the enrollment status page.

Windows-enrollment-status_Continue

When configuring all the available options, which is basically enabling all the options (step 4b and 4c), the end-user will get the experience as shown below. It shows the en-user the current status and only provides the end-user with options after a failure. The Reset button is available because of the Allow users to reset device if installation error occurs setting and the Continue anyway link is available because of the Allow users to use device if installation error occurs setting.

Windows-enrollment-status-page_Failure

Note: Not all components are actually tracking something yet. For an up-to-date list of the different tracked components, see the more information URL.

More information

For more information about the enrollment status page, please refer to this article about Set up an enrollment status page.

App protection policies and device management state

This week is all about creating some additional awareness for the capability of assigning app protection policies and differentiating between the management state of the devices of the user. Since recently it’s possible to assign app protection policies to either Intune managed devices or unmanaged devices. This can help with differentiating between Intune managed devices and unmanaged (MAM only) devices. For example, have more strict data loss prevention configurations for MAM only devices compared to MDM managed devices. In this post I’ll show the available configuration followed by results from an administrator perspective.

Configuration

Let’s start by having a look at the available configuration options. I’ll do that by walking through the steps for creating and configuring an app protection policy. These steps are shown below, with an extra focus on the targeted app types (see step 3a and 3b). After the creation of the app protection policy, simply assign it the applicable user group.

1 Open the Azure portal and navigate to Intune > Mobile apps > App protection policies;
2 On the Mobile apps – App protection policies blade, click Add a policy to open the Add a policy blade. Depending on the platform continue with step 3a, or step 3b;
3a

MAM-iOSOn the Add a policy blade, select iOS as Platform and select No with Target to all app types. This enables the App types selection. In the App types selection choose between Apps on unmanaged devices and Apps on Intune managed devices;

Note: This enables the administrator to differentiate between MAM only devices and MDM managed devices.

3b MAM-Android

On the Add a policy blade, select Android as Platform and select No with Target to all app types. This enables the App types selection. In the App types selection choose between Apps on unmanaged devices, Apps on Intune managed devices and Apps in Android Work Profile;

Note: This enables the administrator to differentiate between MAM only devices, MDM managed devices and MDM managed devices with Android Enterprise.

4 On the Add a policy blade, select Apps to open the Apps blade. On the Apps blade, select one or more apps from the list to associate them with the policy and click Select;
5 On the Add a policy blade, select Settings to open the Settings blade. On the Settings blade, configure the policy settings related to data relocation (data movement in and out apps) and access (access apps in work context) and click OK;
6 On the Add a policy blade, click Create;

Note: This post is focused on iOS and Android devices, but for Windows 10 it’s also possible to differentiate between devices with enrollment and devices without enrollment.

Result

Now let’s end this post by looking at the results of the configuration. There are many things to look at, but it will be hard to show the difference in behavior via screenshots. That’s why an overview of my policies is the easiest way to show the difference in policies. Below is an overview of the different platforms and the different management types.

MAM-Policy-Overview

More information

For more information about app protection polices in combination with device management state, please refer to this article How to create and assign app protection policies – Target app protection policies based on device management state.

Conditional access and guest users

This week back in conditional access. More specifically, the recently introduced feature to assign a conditional access policy to All guest users, which is currently still in preview. At the same time also the ability to assign to Directory roles was introduced. The idea for both is the same. The first is to specifically assign to guest users and the second is to assign to specific roles in the directory. This post will focus on the first scenario. I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

Microsoft Teams is getting really hot for collaboration. This also creates a very low bar for inviting external parties (B2B) to collaborate with. Working together. Of course this should be facilitated to enable the productivity of the end-user. However, that doesn’t mean that there shouldn’t be additional security in-place. Even if it’s just to ensure the identity of the guest user. For example, enable multi-factor authentication for guest users. The following steps walk through the simple configuration to enable multi-factor authentication for guest users on Microsoft Teams.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroupOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select Select users and groups > All guest users (preview) and click Done;
4 AAD_CA_CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps > Microsoft Teams and click Done;
5

AAD_CA_GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access > Require multi-factor authentication and click Select.

6 Open the New blade, select On with Enable policy and click Create;

Note: Guest user matches any user account with the userType attribute set to guest.

End-user experience

Now let’s end this post by looking at the end-user experience. Once the (external) user is invited for using Microsoft Teams, it will first have to configure MFA (see screenshot on the left). After that the user will be able to access Microsoft Teams by using its favorite MFA option. In my example I picked the Microsoft Authenticator app, as it will clearly show that an external account was used (see screenshot on the right). It clearly shows #EXT and onmicrosoft.com.

Screenshot_MFA Screenshot_Authenticator

More information

For more information about conditional access and assignments, please refer to this article about Conditions in Azure Active Directory conditional access | Users and groups.

Rename a device via Windows 10 MDM

This blog post uses the Accounts configuration service provider (CSP), to create a local user account on Windows 10 devices. This area was added in Windows 10, version 1803.

This weeks blog post is a follow up on last weeks post about creating a local user account via Windows 10 MDM. This week is also about the Accounts CSP, but this this time I’ll use the Accounts CSP for renaming a Windows 10 device. This can be useful with maintaining a specific naming convention. I’ll show the available nodes, I’ll show how to configure them and I’ll end this post by showing the end-user experience. Also, I’m pretty sure this will be possible via Windows AutoPilot at some point in time, but, even then, this can be useful for existing devices.

Overview

Like last week, let’s start by having a look at the tree of the Accounts CSP. That enables everybody to use this post without switching between this post and my previous post.

Available nodes

The Accounts CSP contains nodes for renaming a computer account and for the creation of a user account. To get a better understanding of the different nodes, it’s good to walk through the available nodes. Specifically those related to the device name, as those are the subject of this post. Let’s go through those related nodes.

  • .Device/Vendor/MSFT/Account – Defines the root node for the Accounts CSP;
  • Domain – Defines the interior node for the domain account information;
  • ComputerName – Defines the name of the device.

Configurable nodes

There is basically only one configurable node related to the naming of the device. The ComputerName node. The ComputerName node can be any string within the standard requirements for a device name. Besides that, it also allows a couple of macros. The table below provides an overview of them.

Macro Description
%RAND: <# of digits>%

This macro can be used to generate a random number with the specified number of digits, as part of the device name.

Example: CLDCLN%RAND:6%

%SERIAL%

This macro can be used to set the serial number of the device, as part of the device name.

Example: CLDCLN%SERIAL%

Note: The random number macro can create pretty bizarre behavior when targeted at devices (or users). It will keep on renaming the device. In that case make sure to use a Dynamic Device group filtered on disaplayName (for example filtered on Starts With DESKTOP). That will prevent constant renaming of the devices, as the devices will eventually loose the membership of the group.

Configure

Now let’s continue by having a look at the configuration to rename a device. In other words, create a device configuration profile with the previously mentioned custom OMA-URI setting. The following three steps walk through the creation of that device configuration profile. After that simply assign the created profile to a device group.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MSI-CN-SerialOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: ./Device/Vendor/MSFT/Accounts/Domain/ComputerName;
  • Data type: Select String;
  • Value: CLDCLN%SERIAL% (or use the other example of CLDCLN%RAND:6%).

Note: At some point in time this configuration will probably become available in the Azure portal without the requirement of creating a custom OMA-URI.

End-user experience

Let’s end this post by having a quick look at the end-user experience. There is not that much to be shown, besides the actual device name. However, it’s good to see that it automatically generates a name within the restrictions of a device name. Below on the right is a screenshot of the serial number of the device and below on the left is a screenshot of the generated device name. It contains the specified prefix with the added serial number. When the serial number is too long, it will use the maximum number of characters that are allowed for a device name. It uses the characters starting from the back.

CN-Serial-Properties CN-Serial-CMD

Note: The reporting in the Azure portal still provides me with a remediation failed error message, while the actual rename of the device was a success.

More information

For more information about the Accounts CSP, refer to this article named Accounts CSP.

Create a local user account via Windows 10 MDM

This blog post uses the Accounts configuration service provider (CSP), to create a local user account on Windows 10 devices. This area was added in Windows 10, version 1803, which is currently available as Insider Preview build.

This week is all about creating local user accounts via Windows 10 MDM. That can for example make life a bit easier with troubleshooting an offline device. A fallback account. In this post I’ll show how this can be achieved by using the Accounts CSP. I’ll show the available nodes and I’ll show how to configure them. I’ll end this post by showing the end-user experience. Also, spoiler alert, it’s good to note that this is not a pretty administrator experience at this moment, but I’m pretty sure that will be fixed when it’s a built-in configuration in Microsoft Intune.

Overview

Let’s start by having a look at the tree of the Accounts CSP.

Available nodes

The Accounts CSP contains nodes for renaming a computer account and for the creation of a user account. To get a better understanding of the different nodes, it’s good to walk through the available nodes. Specifically those related to user accounts, as those are the subject of this post. Let’s go through those related nodes.

  • .Device/Vendor/MSFT/Account – Defines the root node for the Accounts CSP;
  • Users – Defines the interior node for the user account information;
  • [UserName] – Defines the username of the new local user account;
  • Password – Defines the password for the new local user account;
  • LocalUserGroup – Defines the local user group for the new local user account.

Configurable nodes

There are basically two configurable nodes related to the creation of a local user account. The Password node and the LocalUserGroup node. The [UserName] node should contain the username and can be anything. The table below provides an overview of the configurable nodes.

Node Value Description
Password

String

This required setting allows the administrator to set the password for the new local administrator account.
LocalUserGroup Integer
1 – (Default) Users
2 – Administrators
This optional setting allows the administrator to control the local user group of the new local administrator account.

Note: The password value can be any valid string and is visible as plaintext in the Azure portal.

Configure

Now let’s continue by having a look at the required and optional configuration to create a local user account on the device. In other words, create a device configuration profile with the previously mentioned custom OMA-URI settings. The following three steps walk through the creation of that device configuration profile. After that simply assign the created profile to a user or device group.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b and 3c.
3b

LU_PasswordOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: ./Device/Vendor/MSFT/Accounts/Users/TestUser/Password;
  • Data type: Select String;
  • Value: P@ssw0rd!.
3c

LU_GroupOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: ./Device/Vendor/MSFT/Accounts/Users/TestUser/LocalUserGroup;
  • Data type: Select Integer;
  • Value: 2.

Note: At some point in time this configuration will probably become available in the Azure portal without the requirement of creating a custom OMA-URI.

End-user experience

Let’s end this post by having a quick look at the end-user experience. There’s actually not that much to be shown. Only the created account. Below on the left is a screenshot of the default configuration of the created user account, including the full name, and below on the right is a screenshot of the group memberships of the created user account.

TestUser01 TestUser02

Note: The reporting in the Azure portal still provides me with a remediation failed error message, while the actual account creation was a success.

More information

For more information about the Accounts CSP, refer to this article named Accounts CSP.

Great overview about the current state of the environment with Management Insights

This week I’m back in Configuration Manager again. More specifically, I’m going to look at Management Insights that is introduced with the release of Configuration Manager, version 1802.  Management Insights provides information about the current state of the environment. The information is based on analysis of data from the site database and will better understanding the state of the environment and. It also provides additional information to take action based on the insight. In this post I’ll show the different insights and were to find the information that is used for the insight.

Management Insights

Let’s go through the different insights. I’ll do that by first providing the step to get to the available insights, followed by more information per Management Insight Group Name. As the insights are all based on analyses of data from the database, the information that I provide includes the stored procedure that does the analyses. That should give an additional insight of why the information is as it is displayed. To get to the Management Insights simply follow the next step.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Management Insights > All Insights;
MI_Overview

Management Insight: Applications

The first management insight group is Applications. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Applications without deployments
Description: Lists the applications in your environment that do not have active deployments. This helps you find and delete unused applications to simplify the list of applications displayed in the console.
Stored procedure: MI_ApplicationsNotDeployed
MI_Applications

Management Insight: Cloud Services

The second management insight group is Cloud Servers. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Access co-management readiness
Description: Co-management is a solution that provides a bridge from traditional to modern management. Co-management gives you a path to make the transition using a phased approach. This rule helps you understand what steps are necessary to enable co-management.
Stored procedure: MI_EnableCoMgmt
Rule: Configure Azure services for user with Configuration Manager
Description: This rule helps you onboard Configuration Manager to Azure AD. Onboarding to cloud services creates the server web app and the native client app in Azure AD for Configuration Manager. This enables clients to authenticate with Configuration Manager site using Azure AD. When Azure services configuration is complete, the rule will turn green.
Stored procedure: MI_EnableAAD
Rule: Enable devices to be hybrid Azure Active Directory joined
Description: Modernize identity on your devices by extending your domain-joined devices to Azure Active Directory (Azure AD). Hybrid Azure AD-joined devices allow users to sign in with their domain credentials while ensuring devices meet the organization’s security and compliance standards. This rule helps identify if there are any hybrid Azure AD-joined devices in your environment. If the rule detects any such devices, it turns green.
Stored procedure: MI_DJPlus
Rule: Update clients to the latest Windows 10 version
Description: Update Windows 10 devices to the latest version to improve and modernize the computing experience for users. This rule detects if there are any Windows 10 version 1709 or later devices in your environment. If the rule detects any such devices, it turns green.
Stored procedure: MI_UpgradeToRS3
MI_CloudServices

Management Insight: Collections

The third management insight group is Collections. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Empty Collections
Description: List the collections in your environment that have no members. You can delete these collections to simplify the list of collections displayed when deploying objects, for example.
Stored procedure: MI_EmptyCollections
MI_Collections

Management Insight: Simplified Management

The fourth management insight group is Simplified Management. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Non-CB Client Versions
Description: This lists all clients running client versions from ConfigMgr builds before Current Branch.
Stored procedure: MI_OutdatedClientVersion
MI_SimplifiedManagement

Management Insight: Software Center

The fifth management insight group is Software Center. Below is an overview of the rules that are part of this group. That overview includes a description about the rules and the stored procedure that is used to gather the information from the database.

Rule: Direct your users to Software Center instead of Application Catalog
Description: This rule checks if any users installed or requested applications from the Application Catalog in the last 14 days. The primary functionality of the Application Catalog is now included in Software Center. Support for the Application Catalog web site ends with the first update released after June 1, 2018. Update any end-user documentation and shortcuts to use Software Center.
Stored procedure: MI_App_AppCatalogUsage
Rule: Use the new version of Software Center
Description: Software Center has a new, modern look. The previous version of Software Center is no longer supported. Set up clients to use the new Software Center by enabling the client setting. Computer Agent > Use new Software Center.
Stored procedure: MI_App_NewSoftwareCenter
MI_SoftwareCenter

Management Insight: Windows 10

The documentation also shows a sixth management insight group, named Windows 10, that contains two rules (Configure Windows telemetry and commercial ID key and Connect Configuration Manager to Upgrade Readiness). This group and rules are not available in my environment, yet, but the stored procedures are already available (MI_TelAndCommercialId and MI_AnalyticsOnboarded).

More information

For more information about Management Insights, refer to this article named Management Insights in System Center Configuration Manager.

Default device compliance status

This week I’m going to look at the recent introduction of the feature to configure the default compliance state for devices when no compliance policies are targeted. This enables additional security for all devices, as it enables administrators to mark devices as non compliant when no compliance policies are targeted to the device. In this post I’ll start with a short introduction about this security feature, followed by a walk through the configuration. I’ll end this post by looking at the end-user experience.

Introduction

As should be known by now, compliance policies are basically rules, such as requiring a device PIN, or requiring encryption. These device compliance policies define rules and settings that a device must follow to be considered compliant. The recently introduced security feature enables administrators to determine the default compliance state of devices when no compliance policies are targeted. The default state (for new tenants) is that devices are marked as compliant. From a security perspective it can be required to switch this to non complaint, as this will make sure that all devices that have access are actually compliant with the company requirements.

Configuration

Let’s have a look at the required configuration. This configuration is actually quite simple. To make sure that the default compliance status is switched to non compliant, simply follow the next 3 steps.

1 Open the Azure portal and navigate to Intune > Device compliance to open the Device compliance blade;
2 On the Device compliance blade, click Compliance policy settings to open the Device compliance – Compliance policy settings blade;
3 DC_SettingsOn the Device compliance – Compliance policy settings blade, click Non Compliant with Mark devices with no compliance policy assigned as;

Note: Compliant means the security feature is off and Non Compliant means that the security feature on.

End-user experience

Now let’s end this post by having a look at the end-user experience on the different platforms. The first platform is Windows 10. In a co-management configuration the compliance state can be seen in the Company Portal app and Software Center. So I’ll show them both. Below on the left is an example of Software Center and below on the right is an example of the Company Portal app.

NoCompliancePolicy01 NoCompliancePolicy02

The next platforms are iOS and Android. Nothing too fancy for these platforms. Below on the left is an example of the Company Portal app (latest update) on iOS and below on the right is an example of the Company Portal app on Android.

20180411_182037518_iOS Screenshot_20180411-205045_Company Portal

More information

For more information about compliance policies and Microsoft Intune, refer to this article named Get started with device compliance policies in Intune.