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.

Get Windows AutoPilot device information of Microsoft Intune managed devices

This week I’m going to show an example of how to collect the Windows AutoPilot device information of existing Microsoft Intune managed (Windows 10) devices. That could be useful, for example, when an organization wants one similar deployment experience for all devices. For now and in the future. In that case it can be very useful to gather the device information and upload that information. That will provide future deployments of those existing devices with the same company branded deployment experience as new devices. Also, another reason for this post is the simple fact that I’ve received this request multiple times now.

This example will use an Azure storage account that will be used to store the Windows AutoPilot device information and it will use the Get-WindowsAutoPilotInfo script to collect the information. In this post I’ll show high over the steps to create the Azure storage account, followed by an overview of the PowerShell script to collect the information and write the information to the storage account. I’ll end this post with the Microsoft Intune configuration and a quick peak at the results. After that simply collect the information and upload it via Microsoft Intune or the Microsoft Store for Business (or the Partner portal).

Create storage account

The first step is to create a storage account in Azure. The following four steps walk through the high over steps to create a storage account including a file share. That file share will be used to store the Windows AutoPilot device information.

1 Open the Azure portal and navigate to Storage accounts;
2 Add a storage account of the Storage (general purpose v1) kind and make sure that Secure transfer required is enabled (remember the storage account name);
3 Navigate to Files and add a file share (remember the file share name);
4 Navigate to Access keys and view the available keys (remember the key) ;

Note: Be aware that not every ISP allows access from port 445 to Azure (for an overview see: https://social.technet.microsoft.com/wiki/contents/articles/32346.azure-summary-of-isps-that-allow-disallow-access-from-port-445.aspx).

Create PowerShell script

The second step is to create a PowerShell script to upload the Windows AutoPilot device information to the file share in the just created storage account.

Script variables

This PowerShell script is created for usage within Microsoft Intune. Currently the PowerShell script functionality within Microsoft Intune can’t work with input variables, which means that the values of the different variables have to be available in the script. That means that in the variables block on top of the script (see script snippet section) the following values should be adjusted.

  1. <StorageAccountKey>: This should be the access key of the created storage account (step 4);
  2. <StorageAccountName>: This should be the name of the created storage account (step 2);
  3. <ShareName>: This should be the name of the share of the created storage account (step 3).

Script actions

The PowerShell script contains a few actions that it should perform to complete the required activities. It contains the following actions that can be found in the different try-catch blocks (see script snippet section).

  1. Create a drive with the created Azure storage account;
  2. Download the available script from PowerShell Gallery;
  3. Set the location to the location of the downloaded script;
  4. Install the downloaded script;
  5. Run the installed script and use the created drive for the output;
  6. Remove the downloaded script and the created drive.

Script snippet

The PowerShell script is shown below.

Note: Be aware that downloading PowerShell Gallery items requires PowerShellGet and that PowerShellGet requires the NuGet provider to work with the PowerShell Gallery (for more information see: https://docs.microsoft.com/en-us/powershell/gallery/psgallery/psgallery_gettingstarted).

Configure PowerShell script

The third step is to configure the PowerShell script in Microsoft Intune. To upload the script, follow the next five steps. After uploading the script, simply assign the script to the required users and/or devices.

1 Open the Azure portal and navigate to Intune > Device configuration > PowerShell scripts;
2 On the Device configuration – PowerShell scripts blade, click Add script to open the Script Settings blade;
3 GWAI_AddPowerShellScriptOn the Add PowerShell script blade, provide the following information and click Settings to open the Script Settings blade;

  • Name: Provide a valid name for the PowerShell script policy;
  • Description: (Optional) Provide a description for the PowerShell script policy;
  • Script location: Browse to the PowerShell script.

Note: The script must be less than 10 KB (ASCII) or 5 KB (Unicode).

4 GWAI_ScriptSettingsOn the Script Settings blade, provide the following configuration and click OK to return to the PowerShell script blade;

  • Run the script using the logged on credentials: No;
  • Enforce script signature check: No;

Note: Configure Run the script using the logged on credentials to No means that the PowerShell script will run in SYSTEM context;

5 Back on the Add PowerShell script blade, click Create.

End result

Now let’s end this post by looking at the results. The share in the created storage accounts will start filling with CSV-files of the different Windows 10 devices that are managed by Microsoft Intune. That means that it will start to look like something as shown below.

GWAI_AzureStorage

As the required device information is available now, within the file share of the storage account, it can be downloaded and imported via for example Microsoft Intune. Of course it’s possible to use PowerShell to merge these CSV-files into one big CSV-file. This is relatively easy by simply using something like Get-Content and always grab the second line of the CSV-files.

Import Windows AutoPilot devices in Microsoft Intune

This week I’m going to show the import experience of Windows AutoPilot devices in Microsoft Intune. About three months ago, this wasn’t possible yet and it was still required to use the Windows Store for Business (see this blog post). Even up until a few weeks ago it was still required to perform additional steps with the formatting. Now the experience is really straight forward.

I was planning on showing that experience during my session last week, at the Microsoft Tech Summit, but after speaking to many people onsite I noticed that it would be better to spent more time on explaining what Windows AutoPilot is and what Windows AutoPilot is not. Setting the expectations. An easy comparison with car and aircraft functionality helped a lot (together with some statements about what Windows AutoPilot does and what Windows AutoPilot does not do).

Now, back to the subject of this post, let’s have a look at the latest import experience by getting the device information and than importing that information in Microsoft Intune.

Get device information

To get the required device information, I’m using the latest version of the Get-WindowsAutoPilotInfo PowerShell script. That script is the easiest method to get the required information, especially for testing purposes. An alternative could be the Windows AutoPilot Device Information report in Configuration Manager, version 1802 or later. The script can create a CSV with a column for the Device Serial Number, the Windows Product ID and the Hardware Hash of the device. With the latest version of the script the value for the Windows Product ID will be skipped. Simply follow the next four steps.

1 Open Windows PowerShell as an Administrator;
2 Run Save-Script -Name Get-WindowsAutoPilotInfo -Path C:\Windows\Temp to inspect the PowerShell script;
3 Run Install-Script -Name Get-WindowsAutoPilotInfo to install the PowerShell script;
4 Run Get-WindowsAutoPilotInfo.ps1 -OutputFile C:\Windows\Temp\MyComputer.csv to get the required device information;
WA_MyComputer

Note: Keep in mind that the script can also run with a Partner switch, which will make sure that also the Manufacturer name and Device model are collected and reported.

Import device information

Now import the Windows AutoPilot device information into Microsoft Intune. The import process in Microsoft Intune can now also handle a header row in the CSV and an empty column for the Windows Product ID. This wasn’t possible until a couple of weeks ago. To import the device information, simply follow the next five steps.

1 Open the Azure portal and navigate to Intune > Device enrollment > Windows Enrollment;
2 On the Devices enrollment – Windows enrollment blade, click Devices below Windows AutoPilot devices (Preview) to open the Windows AutoPilot devices (Preview) blade;
3 On the Windows AutoPilot devices (Preview) blade, click Import to open the Add Windows AutoPilot devices blade;
4 WA_AddWAdevicesOn the Add Windows AutoPilot devices blade, select the just created CSV (MyComputer.csv) and click Import to trigger the import process;

Note: Selecting the CSV will immediately trigger a check on the formatting of the CSV.

5* Back on the Windows AutoPilot devices (Preview) blade, click Sync followed by Refresh to speed up the process to show the devices in Microsoft Intune;
WA_WAdevices

*At this moment the Microsoft Intune experience might still be a bit out of sync (it’s still preview) with the Windows AutoPilot deployment service, which is why I’ve added this step to manually trigger the sync.

Join me at the Tech Summit in Amsterdam

Next week, March 28-29, the Microsoft Tech Summit will be in Amsterdam and I will be there. On Wednesday (March 28) I will be available at the Ask the Experts Reception and on Thursday (March 29) I will be speaking about Manage Windows AutoPilot via Microsoft Intune. I hope I will see you there!

pvanderwoude

About my session

In this session, I will pull you into the world of Windows AutoPilot. Learn what Windows AutoPilot is and also, learn what Windows AutoPilot is not. In this demo-rich session I will show you how to use Windows AutoPilot, together with Microsoft Intune, to simplify device provisioning.

Co-management and the ConfigMgr client

This blog post is a follow-up on this earlier post about deploying the ConfigMgr client via Microsoft Intune. In this post I want to look more at the behavior of the ConfigMgr client in a co-management scenario. I want to show the available configurations and, more importantly, I want to show the behavior of the ConfigMgr client. I want to show the corresponding configuration and the messages in the different log files.

Co-management configuration

Now let’s start by looking at the different configuration options of co-management and the configuration values. To look at the available configuration options, simply follow the next three steps (assuming the initial co-management configuration is already created).

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Co-management;
2 Select CoMgmtSettingsProd and click Properties in the Home tab;
3

ComanagementPropertiesNavigate to the Workloads tab, which provides the option to switch the following workloads from Configuration Manager to Intune:

  • Compliance policies;
  • Resource access policies (this contains VPN, Wi-Fi, email and certificate profiles);
  • Windows Update policies.

Note: Looking at the current Technical Preview version, the number of available workloads will quickly increase.

ConfigMgr client behavior

Now let’s make it a bit more interesting and look at the behavior of the ConfigMgr client. By that I mean the configuration changes of the ConfigMgr client that can be noticed in the log files. The co-management configuration related log file is the CoManagementHandler.log (as shown below). That log file shows the processing of the configuration and the MDM information related to the device.

Log_ComanagementHandler

The values in the CoManagementHandler.log are shown, after a configuration change, in both hex and decimal. These values relate to the following workload distribution.

Value Configuration Manager Microsoft Intune
1 (0x1) Compliance policies, Resource access policies, Windows update policies
3 (0x3) Resource access policies, Windows Update policies Compliance policies
5 (0x5) Compliance policies, Windows Update policies Resource access policies
7 (0x7) Windows Update policies Compliance policies, Resource access policies
17 (0x11) Compliance policies, Resource access policies Windows Update policies
19 (0x13) Resource access policies Compliance policies, Windows Update policies
21 (0x15) Compliance policies Resource access policies, Windows Update policies
23 (0x17) Compliance policies, Resource access policies, Windows Update policies

Compliance policies

When co-management is enabled, the ConfigMgr client will verify if it should apply compliance policies. Before applying them. That information is shown in the ComplRelayAgent.log (as shown below). It shows the current configuration (for a translation of the workload flags see the table above) and what it means for the status of the compliance policies. After that it will perform an action on the policy. In this case it won’t report a compliance state.

Log_ComplRelayAgent

Resource access policies

When co-management is enabled, the ConfigMgr client will also verify if it should apply resource acces policies. Before applying them. That information is shown in the CIAgent.log (as shown below). As that log file is used for a lot more operations, it might be a bit challenging to find the information. It shows the current configuration (for a translation of the workload flags see the table above) and what it means for the status of the resource access policies. After that it will perform an action on the policy. In this case it will skip the related CI.

Log_CIAgent

Windows Update policies

When co-management is enabled, the ConfigMgr client will also verify if it should apply Windows Update for Business policies. Before applying them. That information is shown in the WUAHandler.log (as shown below). It shows the current configuration (for a translation of the workload flags see the table above) and what it means for the status of the Windows Update for Business policies. After that it will perform an action on the policy. In this case it will look for assigned policies.

Log_WuaHandler

Start with helping users by using the awesome troubleshooting portal

This week I’m back with a new blog post, after not posting anything last week due to visiting the yearly Global MVP Summit. This week is all about creating awareness. Awareness for the troubleshooting portal (the Troubleshoot blade). The troubleshooting portal is THE best place to start with troubleshooting to help the end-users. In this post I’ll provide a complete overview of the current status of the troubleshooting portal.

Troubleshooting portal

The troubleshooting portal can be used by Intune administrators, and other delegated users like help desk operators, to view user information. The troubleshooting portal provides information about the user, the assignments for the user and the devices of the user. To get to the troubleshooting portal, simply follow the next steps.

1 Open the Azure portal and navigate to Intune > Troubleshoot (or use the short link: https://aka.ms/intunetroubleshooting);
2 On the Microsoft Intune – Troubleshoot blade, select Select user and get the information to start with troubleshooting. This will provide the overview as shown below. I will go through the different numbered items in more detail;
IntuneTroubleshooting_Overview

Item 1 – Account status

IntuneTroubleshooting_AccountStatusThis shows the status of the current Intune tenant. The logged on user does need permissions to view this information.

Item 2 – User selection

IntuneTroubleshooting_UserSelectionThis shows the name of the selected user. Simply click Change user to select a different user. All the shown information is related to the selected user.

Item 3 – User status

IntuneTroubleshooting_UserStatusThis shows the Intune license of the selected user, the number of non-compliant devices and the number of non-compliant apps.

Item 4 – User group memberships

IntuneTroubleshooting_UserInformationThis shows the group memberships of the selected user.

Item 5 – User information

This shows the detailed information of the selected user, about the assignments, the devices, the app protection status and the enrollment failures. More details below.

Item 5.1 – Assignments

This shows the details about the assignments for the selected user. At this moment it’s possible to view the details about Mobile apps, Compliance policies, Configuration policies, App protection policies, Windows 10 update rings and Enrollment restrictions (see screenshot below). To view more details, about a specific assignment, simply select the assignment, which will bring the administrator to the policy overview. This information is really useful for getting a quick overview of the assignments that are applicable to the selected user.

IntuneTroubleshooting_Assignments

Item 5.2 – Devices

This shows the details about the devices of the selected user. The shown devices are all the devices joined or registered to Azure AD. The shown information is the Device name, Managed by, Azure AD join type, Ownership, Intune compliant, Azure AD compliant, OS, OS version and Last check-in (see screenshot below). To view more details, about a specific device, simply select the row, which will bring the administrator to the device properties as shown in Azure AD. This information is really useful for getting a quick overview of the devices of the selected user.

IntuneTroubleshooting_Devices

Item 5.3 – App protection status

This shows the details about the app protection policies that are assigned to the selected user. The shown information is Status, App name, Device name, Device type, Policies and Last sync (see screenshot below). This information is really useful for quickly determining the status of the app protection policies that are applicable to the selected user.

IntuneTroubleshooting_AppProtection

Item 5.4 – Enrollment failures

This shows the details about the enrollment failures for the selected user. The shown information is Enrollment attempt, Issue ID, OS and Failure (see screenshot below). Each row represents a unique attempt. To view more details, about an enrollment failure, and the suggested remediation, simply select the row. This information is really useful for quickly determining enrollment failures for the selected user.

IntuneTroubleshooting_EnrollmentFailures

More information

For more information about the troubleshooting portal, please refer to this article about using the troubleshooting portal to help users.