Enable password-less sign-in with security keys

This week is all about enabling password-less sign-in with security keys on Windows 10. I know that a lot has been written about that subject already, but it’s that big that it still deserves a spot on my blog. Especially the Microsoft Intune configuration belongs on my blog. In this post I’ll show the required configurations that should be performed, by an administrator and the the user, to enable the user to use a security key as a sign-in method. My user will use a Yubikey 5 NFC security key. I’ll start this post with the authentication method policy that should be configured in Azure AD, followed by the steps for a user to register a security key. I’ll end this post by showing the different methods to configure security keys a sign-in method on Windows 10, by using Microsoft Intune, and the end-user experience.

Keep in mind that the best experience, for password-less sign-in with security keys, is on Windows 10 version 1903 or higher. This is caused by the fact that the PassportForWork CSP setting is introduced in Windows 10 version 1903.

Configure the authentication method

The first step in enabling password-less sign-in with security keys, is configuring the authentication method. Within Azure AD there is the Authentication method policy available, which is currently still in preview, that can be used to enable password-less authentication for users. Either all users, or a specific group of users. Within that policy it’s currently possible to enable FIDO2 security keys and Microsoft Authentication as password-less authentication options. The following three steps walk through the process of enabling FIDO2 security keys as a password-less authentication option for all users.

  1. Open the Azure portal and navigate to Azure Active Directory Authentication methods > Authentication method policy (preview) to open the Authentication methods – Authentication method policy (preview) blade
  2. On the Authentication methods – Authentication method policy (preview) blade, select FIDO2 Security Key to open the FIDO2 Security Key settings blade
  3. On the FIDO2 Security Key settings blade, provide the following information and click Save
  • ENABLE: Select Yes
  • TARGET: Select All users (use Select users to only enable for specific users)
  • Allow self-service set-up: Select Yes
  • Enforce attestation: Select Yes
The key restriction policy settings are not working yet and should be left default for now.

Register security key as sign-in method

The second step is that the user must register a security key that can be used as sign-in method. That does require that the user already registered an Azure MFA method. If not, the user should first register an Azure MFA method. After registering an Azure MFA method, the following nine steps will walk the user through the process of adding an USB security key.

  1. Open the My Profile and navigate to Security info to open the Security info section
  2. On the Security info section, click Add method to open a dialog box
  3. On the Add method page, select Security key and click Add
  4. On the Security key page, select USB device and click Next
  5. A browser session will open to register the security key
  6. Insert the security key, touch it, provide a PIN and click Next
  7. Touch the security key another time and click Allow
  8. Provide a name for the security key and click Next
  9. On the Your all set page, click Done

After registering a security key as a sign-in method, the user can already use the security key as a sign-in method for browser sessions.

Configure security keys as a sign-in option

The third and last step is to configure security keys as a sign-in option on Windows devices. Within Microsoft Intune there are multiple methods for enabling security keys as a sign-in option on Windows 10 devices. It’s also good to keep in mind that, even though password-less sign-in is supported starting with Windows 10, version 1809, the following configuration options are all for Windows 10, version 1903 or later. The reason for that is actually quite simple, as the required setting (UseSecurityKeyForSignin) is introduced in the PassportForWork CSP with Windows 10, version 1903.

Using Windows enrollment (Windows Hello for Business) settings

The first configuration option is by using the Windows Hello for Business settings that are available within the Windows enrollment settings. Those settings actually enable the administrator to configure the use of security keys for sign-in independent of actually configuring Windows Hello for Business. The biggest challenge with this approach is that it can’t be slowly implemented, as it’s all or nothing. The following two steps walk through this configuration.

  1. Open the Azure portal and navigate to Microsoft Intune Device enrollmentWindows enrollment > Windows Hello for Business to open the Windows Hello for Business blade
  2. On the Windows Hello for Business blade, select Enabled with Use security keys for sign-in and click Save

This setting requires Windows 10, version 1903, or later, and is not dependent on configuring Windows Hello for Business.

Using Device configuration (Identity protection) settings

The second configuration option is by using the Identity protection device configuration profile. The Identity protection device configuration profile, provides the same configuration options as the Windows Hello for Business settings. The biggest difference is that the Identity protection device configuration profile can be implemented by using groups, which allows a phased implementation (and differentiation). The following four steps walk through this configuration.

  1. Open the Azure portal and navigate to Microsoft Intune Device configuration Profiles to open the Devices configuration – Profiles blade
  2. On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade
  3. On the Create profile blade, provide the following information and click Create
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Windows 10 and later
  • Profile type: Identity protection
  • Settings: See step 4
  1. On the Windows Hello for Business blade, select Enable with Use security keys for sign-in and click OK;

This setting requires Windows 10, version 1903, or later, and is not dependent on configuring Windows Hello for Business

Use Device configuration (Custom) settings

The third and last option is by using a Custom device configuration profile. That Custom device configuration profile, is actually identical to the Identity protection device configuration profile. The only difference is that it’s a OMA-URI configuration, so no simple UI switch. Even though it’s good to mention this option, to remember what the actual configuration is that’s done on the background. The following four steps walk through this configuration.

  1. Open the Azure portal and navigate to Microsoft Intune Device configuration Profiles to open the Devices configuration – Profiles blade
  2. On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
  3. On the Create profile blade, provide the following information and click Create;
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Windows 10 and later
  • Profile type: Identity protection
  • Settings: See step 4
  1. On 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 valid description
  • OMA-URI: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
  • Data type: Select Integer;
  • Value: 1

This setting requires Windows 10, version 1903, or later, and is not dependent on configuring Windows Hello for Business

End-user experience

Let’s end this post by having a look at the end-user experience. Below on the first row it starts with a static example of the sign-in experience on Windows 10 and in a browser. The second row is an example of the password-less sign-in experience of an user on Windows 10, version 1903, using a Yubikey 5 NFC security key. I’m specifically showing the experience when using the Other user sign-in option, as it will show that the user doesn’t need to provide a username nor a password. The user only needs to have the security key and the related PIN.

More information

For more information about password-less sign-in on Windows 10, see this doc named Enable passwordless security key sign in for Azure AD (preview).

Windows 10 MDM policy refresh

This week is all about the Windows 10 MDM policy refresh. More specifically, the policy refresh behavior starting with Windows 10, version 1903. Starting with Windows 10, version 1903, the policy refresh got a lot more interesting. Before Windows 10, version 1903, the policy refresh would simply tattoo the settings once during the device checking. Starting with Windows 10, version 1903, the settings that are implemented by the Policy CSP are actually refreshed during the device check-in. Not just tattooed once, but actually re-applied when for example adjusted by the user. Also, similar to that, those settings are also removed when no longer assigned. In this post I’ll have a look at the triggers for a device check-in, the different device check-in actions and the difference in behavior of the device check-ins (focused on the Policy CSP).

Triggers for device check-ins

Let’s start by looking at the multiple triggers for the device check-in. I would like to differentiate between the following three different type of device check-in triggers:

  • A notification – The check-in can be triggered by a notification from Microsoft Intune.
  • A scheduled check-in – The check-in can be triggered by a scheduled task.
  • A manual check-in – The check-in can be triggered manually by the user.

Notifications that trigger device check-ins

The challenge with notifications that trigger a device check-in is that it’s not an exact science and that we’re mainly bound to the docs about the process. When looking at the notifications that trigger device check-ins there are basically different actions, performed by the administrator, that can trigger a notification. The triggered notification will notify the device to check-in with Microsoft Intune. Actions that trigger a notification are for example when a policy, a profile, or an app is assigned (or unassigned), updated, or deleted.

The device will check-in with Microsoft Intune when the device receives a notification to check-in. The challenge is that it’s up to the device to actually check-in. A different priority, so to say, is for targeting a device or user with an action, like a lock, a passcode reset, an app, a profile or a policy assignment. With those actions Microsoft Intune immediately notifies the device to check in to receive these updates.

There are also changes that don’t cause a notification to the devices. For example revising the contact information in the Company Portal app don’t cause an immediate notification to be send to the device.

This device check-in will refresh the already applied Policy CSP settings and will also remove unassigned Policy CSP settings.

Scheduled device check-ins

The scheduled device check-ins are more clear. In that case we’re not mainly stuck to the docs, as the configuration is available in the Task Manager. After the device is enrolled in Microsoft Intune, three scheduled tasks will be enabled and run on different schedules. Let’s have a close look at those scheduled tasks.

Frequency of scheduled device check-ins

Once a Windows 10 device is enrolled in Microsoft Intune, three different scheduled tasks will be used to trigger the compliance and configuration check-ins. Those scheduled tasks can be found in the Task Scheduler at Microsoft > Windows > EnterpriseMgmt > {tenantId}.

Table 1 provides an overview of the different check-in schedules that belong to the different scheduled tasks. The first scheduled task repeats every 3 minutes for the first 15 minutes after the enrollment. The second scheduled task starts 15 minutes after the enrollment and repeats every 15 minutes for 2 hours and the third scheduled task starts 2 hours and 15 minutes after the enrollment and repeats every 8 hours indefinitely.

Table 1: Check-in frequency
Schedule Frequency
Schedule #1 created by the enrollment clientAfter triggered, repeat every 3 minutes for a duration of 15 minutes
Schedule #2 created by the enrollment clientAfter triggered, repeat every 15 minutes for a duration of 2 hours
Schedule #3 created by the enrollment clientAfter triggered, repeat every 8 hours indefinitely

Note: The behavior for devices without user affinity is different, as it’s up to the device to check-in.

Action during scheduled device check-ins

During the device check-in the deviceenroller.exe will be started as a program. The different scheduled tasks, used for triggering the compliance and configuration check-ins, use slightly different parameters.

Table 2 provides an overview of the different check-in actions. The deviceenroller.exe program itself is still a little bit of a mystery, as it’s being user for enrolling devices en also for check-ins. Both by using different parameter. Sadly not all parameters speak for itself, which makes it a little guesswork to fully understand.

This device check-in action will also refresh the already applied Policy CSP settings.

Table 2: Check-in action
Schedule Action
Schedule #1 created by the enrollment client%windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c
Schedule #2 created by the enrollment client%windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c
Schedule #3 created by the enrollment client%windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c /b

Note: The documented actions can also be used to “manually” trigger a device check-in.

Manual device check-ins

The manual device check-ins are also in the gray area. It’s clear that the manual device check-in can be triggered by using the Settings panel. Navigate to Accounts > Access work or school and click Sync. Another option is by using the Company Portal app. Navigate to Settings and click Sync.

During the device check-in the omadmclient.exe will perform actions to sync the policies.

This device check-in will not refresh the already applied Policy CSP settings.

Recognize different device check-ins

I noticed that the easiest method to fully recognize the difference in device check-ins, is by using the Event Viewer. When opening the Event Viewer, simply navigate to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider and look at for Event ID 208. The difference will be in the origin of the started session, as shown in the following list:

  • A notification – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x7), Initiator: (0x0), Mode: (0x2), SessionID: (0x7C), Authentication Type: (0x3).
  • A scheduled check-in – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x3), Initiator: (0x0), Mode: (0x2), SessionID: (0x75), Authentication Type: (0x3).
  • A manual check-in (by using Settings panel) – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x5), Initiator: (0x0), Mode: (0x2), SessionID: (0x76), Authentication Type: (0x3).
  • A manual check-in (by using Company Portal app) – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0xD), Initiator: (0x0), Mode: (0x2), SessionID: (0x77), Authentication Type: (0x3).

Example Windows 10 MDM policy refresh

Now let’s end this post by having a look at an example of the Windows 10 MDM policy refresh. Below on the right I’ve adjusted the telemetry setting of the device and below on the left I’m manually running the device check-in action of the scheduled task (yes, I’ve tested it multiple times). It end’s by refreshing the telemetry value immediately after the check-in.

More information

For more information about installing applications for devices, please refer to the doc about Common questions, issues, and resolutions with device policies and profiles in Microsoft Intune.

Configure time zones via Windows 10 MDM

This week a blog post about a nice newly introduced policy setting in Windows 10, version 1903. That setting is available in the TimeLanguageSettings area, and can be used to set the time zone of the device. The TimeLanguageSettings area already existed before Windows 10, version 1903, but previously only contained a single setting for Windows 10 Mobile. Now it also contains a very useful setting related to non-Mobile versions of Windows 10. That setting will give some more control on the default time zone configuration of a device. In this post I’ll briefly go through the setting, followed by the configuration and the end-user experience.

Settings

Let’s start by having a look at the setting. The TimeLanguageSettings area is not a new node within the Policy CSP, but starting with Windows 10, version 1903, it does contain a nice new policy setting.  Below is an overview of that policy setting. Keep in mind that the complete node of this policy setting starts with ./Device/Vendor/MSFT/Policy/Config/TimeLanguageSettings/.

Policy Description

ConfigureTimeZone

Value: <time zone ID>

This policy can be used to specify the time zone that should be applied to the device.

Note: The time zone ID can be retrieved by using tzutil.exe. Simply use tzutil.exe /g on a device that already has the correct time zone configured.

Configuration

Now let’s continue by having a look at the configuration steps for the time zone. In other words, create a device configuration profile with the previously mentioned custom policy setting. I will use my own time zone as an example. 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 Microsoft Intune > Device configuration > Profiles to open the Devices configuration – Profiles blade;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

TZC-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Time zone configuration
  • Description: (Optional)  
  • Platform: Select Windows 10 and later
  • Profile type: Select Custom
  • Settings: See step 3b
3b

On 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: Set time zone
  • Description: (Optional)
  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/TimeLanguageSettings/ConfigureTimeZone
  • Data type: Select String;
  • Value: W. Europe Standard Time

TZC-AddRow

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 looking at the end-user experience. Below is an example of a Windows 10 device running version 1903. In that example it shows the configuration of the time zone that should be configured. In my testing the end-user would still be able to adjust the time zone afterwards.

TZC-EndUserExperience01

As the end-user was still able to adjust the configuration afterwards, I wanted to be sure that the configuration was actually applied. To do that I also looked at the MDM Diagnostics Report. That report, which is shown below, clearly shows that the policy setting is configured,

TZC-EndUserExperience02

Besides that report, the Event Viewer will also provide the information about the time zone change.

  • The Admin log in Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Proivder shows event id 814 with the message MDM PolicyManager: Set policy string, Policy: (ConfigureTimeZone), Area: (TimeLanguageSettings), EnrollmentID requesting merge: (A77EC83D-AFD9-4949-AE0C-69CD6784C83F), Current User: (Device), String: (W. Europe Standard Time), Enrollment Type: (0x6), Scope: (0x0).
  • The System log shows event id 22 with the message The time zone bias has changed to -120 from 420 followed by event id 1 with the message The system time has changed to ‎2019‎-‎07‎-‎11T06:26:15.574273500Z from ‎2019‎-‎07‎-‎11T06:26:15.574273500Z. Change Reason: System time adjusted to the new time zone.

More information

For more information about the available time zone settings in the Policy CSP, please refer to the documentation about Policy CSP – TimeLanguageSettings.

Quick tip: Configure primary device via Software Center

This week a relatively short blog post about a recently introduced feature in Configuration Manager, version 1902. That feature is the option for the user to select a device as a primary device, by using Software Center. Previously the Application Catalog was still required to provide users with that specific option. That was also practically the only reason to still use the Application Catalog. From that perspective, this also provides a clear path for further simplifying the Configuration Manager hierarchy. In this post I’ll show how to enable the option for the user to configure a primary device via Software Center, followed by the end-user experience.

Configuration

Now let’s have a look at the configuration that enables the option for the user to configure a device as a primary device, by using Software Center. That configuration can be achieved by using Client Settings. The 3 steps below show how to enable this option for the users.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Client Settings;
2 Now either open/create a new Custom Client User Settings and select the Software Center section, or open open the Default Client Settings and select the User Device Affinity section;
3

SCPU-UserSettingsIn the User Device Affinity section, select Yes with Allow user to define their primary devices and click OK;

Note: When using the Default Client Settings this setting is available in the separate section of User Settings. When using Custom Client User Settings this setting is the only available setting. Also, when using Custom Client User Settings, make sure to deploy the Client Settings to a user collection.

Note: Theoretically, when Automatically configure user device affinity from usage data is set to No, the administrator must still approve the affinity request. However, my experience is that the primary user configuration is immediately processed.

End-user experience

Let’s end this post by having a quick look at the end-user experience. When the user now opens Software Center and navigates to the Options section, the user will find a new checkbox named I regularly use this computer to do my work. When that checkbox is selected, the user will be marked as the primary user of that specific device.

SCPU-UserExperience

More information

For more information about lettings users create their own device affinity, refer to this article about User device affinity (section Let users create their own device affinities).

Windows Autopilot white glove service

This week is about Windows Autopilot. More specifically, the Windows Autopilot white glove service. The Windows Autopilot white glove service will enable organizations to pre-provision Windows 10 devices to make sure that end-users get their device faster to a fully provisioned state. In this post I’ll start with a short introduction about the Windows Autopilot white glove service, followed by the steps to enable the white glove service in Windows Autopilot. I’ll end this post by showing the end-user experience.

Introduction

Now let’s start with a short introduction about the Windows Autopilot white glove service (also known as Windows Autopilot for white glove deployment). This process is designed to get the user faster up-and-running. That is achieved by splitting the provisioning process (as shown below). The starting point of the Windows Autopilot for white glove deployment is the same as any other Windows Autopilot deployment, it starts with a device that is provided by the OEM (imaged and accommodated with drivers). The second step is what makes this the Windows Autopilot for white glove deployment, it enables an organization to pre-provision device apps, device settings, device policies and user apps (of the assigned user) on the device. This can be achieved by an OEM, partner or the IT organization itself. That also enables the faster user experience, as, once the user logs on, only user settings and user policies are still required.

WhiteGlove-Process

Before looking at the configuration, let’s go through a few important requirements and limitations of the Windows Autopilot for white glove deployment:

  • The device must run Windows 10, version 1903 or later;
  • Only user-driven scenarios, supporting both, Azure AD join and hybrid Azure AD join;
  • Must be a physical devices that support TPM 2.0 and device attestation (virtual machines are not supported);
  • The device must have a ethernet connectivity (Wi-Fi connectivity is not supported).

Configuration

Let’s continue by looking at the actual configuration. As the configuration of a Windows Autopilot deployment profile now contains a new look-and-feel, I thought it would be good to show screenshots of that new experience. The following 4 steps walk through the creation of a Windows Autopilot deployment profile that allows white glove.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Deployment Profiles in the Windows Autopilot Deployment Program section to open the Windows Autopilot deployment profiles blade;
3 On Windows Autopilot deployment profiles blade, select Create profile to open the Create profile blade;
4a

On the Create profile blade, on the Basics section, provide the following information and click Next;

  • Name: Provide a unique name for the Windows Autopilot deployment profile;
  • Description: (Optional) Provide a description for the Windows Autopilot deployment profile;
  • Convert all targeted devices to Autopilot: Select Yes to automatically convert Intune managed devices to Autopilot;

WA-WG-CreateProfile-Basics

4b

On the Create profile blade, on the Out-of-box experience (OOBE) section, provide the following information and click Next.

  • Deployment mode: Select User-Driven, as that deployment mode provides the functionality that is
    needed for this post;

  • Join to Azure AD as: Select Azure AD joined to join the device to Azure AD during the Windows Autopilot user-driven experience;
  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot user-driven experience;
  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot user-driven experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot user-driven experience;
  • User account type: Select Administrator to only make any user on the device an administrative user;
  • Allow White Glove OOBE: Select Yes, as that enables the functionality that is needed for this post;
  • Apply computer name template: Create a computer name, according to the configured template, for devices at initial startup;
WA-WG-CreateProfile-OOBE
4c On the Create profile blade, on the Scope tags section, click Next;
WA-WG-CreateProfile-Scope
4d On the Create profile blade, on the Assignments section, add an assignment and click Next;
WA-WG-CreateProfile-Assignment
4e On the Create profile blade, on the Review + create section, click Create;
WA-WG-CreateProfile-Review

Administrator experience

Now let’s end this post by having a look at the administrator experience. More specifically the experience of the IT person performing the Windows Autopilot white glove deployment. Below on the first row is are the screens that the administrator has to go through, after pressing the Windows key 5 times on the initial OOBE screen. First the administrator has to select the Windows Autopilot provisioning option and click Continue, followed by confirming the device information and clicking Provision. The QR-code contains the identifier of the device and can be used to make some configuration changes.

After starting the process, it will either fail or succeed. Like with everything else. The reason I specifically mention it, is because the result is clearly shown by the background color. Below on the second row, are screenshots of a failed and succeeded Windows Autopilot white glove deployment. To make creating screenshots easy, I simulated both scenarios on a VM (see the error on the red screenshot and the no found messages in the green screenshot). Simulated, because a VM is not supported and will not work. On a physical device those screenshots will also provide a QR-code. As shown below, after a failure the administrator can choose to Retry, Reset and View diagnostics and after a success the administrator can Reseal the device. Resealing the device will make sure that the end-user will receive the expected OOBE.

WA-WG-01 WA-WG-02
WA-WG-Error WA-WG-Success

More information

For more information about enrolling Windows devices by using the Windows Autopilot white glove service, please refer to the documentation named Windows Autopilot for white glove deployment.

Working with Win32 app dependencies

After a couple of weeks with distractions, this week I’m stepping away from conditional access. This week is all about Win32 app management capabilities. More specifically, about Win32 app dependencies. About half a year ago, when Win32 app management capabilities were introduced, I did my first post about those capabilities. That post is still being read really good, so I thought this would be a good time for a nice addition to that post. In this post I’ll start with a shorting introduction about Win32 app dependencies, followed by the configuration steps for Win32 apps and specifically for Win32 app dependencies. I’ll end this post by showing the experience for the end-user and the administrator.

Introduction

Let’s start with a short introduction about reason for using Win32 apps and more specifically about using the Win32 app dependencies. Slowly there are coming more and more reason to look at Win32 apps as a serious alternative to using single-file MSI via MDM. An important reason for that is that Windows 10, version 1709 and later, will download Win32 app content by using delivery optimization. Other reasons are the Win32 app configuration options for requirements and detection rules. That will make the Win32 app really flexible. To make the Win32 app even more flexible, and even more comparable to the ConfigMgr app model, it’s now also possible to configure dependencies between Win32 apps.

Scenario

Before looking at the actual configuration steps, let’s first describe the example scenario that I’ll use to show the Win32 app dependencies feature. As an example scenario, I’m using PolicyPak. I won’t go into details about the functionalities of PolicyPak, that information can be found here. The reason that I’m using it as an example scenario, is simply because the installation contains three steps: install the license file, install the client-side extension and install any setting file. All of these are available as MSI and the mentioned order (see also the picture below) provides the best result. In other words, ideal for showing the Win32 app dependencies feature.

PolicyPak-dependency-overview

Note: In my testing, PolicyPak will work just perfectly fine if you don’t take into account dependencies, but this is an ideal scenario to ensure that all policies delivered from PolicyPak always get applied the first time

Configuration

Now let’s start with the configuration steps. I’ll do that by first quickly showing the steps to wrap a Win32 app and the steps to configure a Win32 app. For more details about that, please refer to my previous post about Win32 apps. After that, I’ll show the detailed steps for configuring Win32 app dependencies.

Prepare Win32 app

The first step is to quickly go through the steps to prepare the Win32 apps by using the Microsoft Intune Win32 App Packaging Tool. Wrap the Win32 apps. The packaging tool wraps the application installation files into the .intunewin format. Also, the packaging tool detects the parameters required by Intune to determine the application installation state.  The following five steps walk through wrapping the different PolicyPak MSIs.

1 Download the Microsoft Intune Win32 App Packaging Tool. In my example to C:\Temp;
2 Create a folder per PolicyPak MSI. In my example C:\Temp\[PolicyPakMSI];
3 Open a Command Prompt as Administrator and navigate to the location of IntuneWinAppUtil.exe. In my example that means cd \Temp;
4 Run IntuneWinAppUtil.exe and provide the following information, when requested

  • Please specify the source folder: C:\Temp\[PolicyPakMSI];
  • Please specify the setup file: [PolicyPakMSI].msi;
  • Please specify the output folder: C:\Temp
5 Once the wrapping is done. The message Done!!! will be shown. In my example a file named [PolicyPakMSI].intunewin will be created in C:\Temp.

Note: The mentioned steps should be performed per PolicyPak MSI.

Configure Win32 app

The next step is to quickly look at the configuration steps, within Microsoft Intune, to configure the Win32 apps. The following 17 steps walk through all the steps to configure the Win32 apps, by using the .intunewin files.

1 Open the Azure portal and navigate to Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, click Add to open the Add app blade;
3 On the Add app blade, select Windows app (Win32) – preview to show the configuration options and select App package file to open the App package file blade.
4 On the App package file blade, select the created [PolicyPakMSI].intunewin as App package file and click OK to return to the Add app blade;
5 Back on the Add app blade, select App information to open the App information blade;
6 On the App information blade, provide at least the following information and click OK to return to the Add app blade;

  • Name: [PolicyPakMSI] is pre-provisioned as name of the app;
  • Description: Provide a description of the app;
  • Publisher: Provide the publisher of the app;

Note: The remaining information regarding the Information URL, the Privacy URL, the Developer, the Owner, the Notes and the Logo is optional.

7 Back on the Add app blade, select Program to open the Program blade;
8 On the Program blade, verify the Install command and the Uninstall command and click OK to return to the Add app blade;
9 Back on the Add app blade, select Requirements to open the Requirements blade;
10 On the Requirements blade, provide at least the following information and click OK to return to the Add app blade;

  • Operating system architecture: Select the applicable platforms;
  • Minimum operating system: Select a minimum operating system version;
11 Back on the Add app blade, select Detection rules to open the Detection rules blade;
12 On the Detection rules blade, select Manually configure detection rules and click Add to open the Detection rule blade.
13 On the Detection rule blade, select MSI as Rule type, verify the pre-provisioned MSI product code and click OK to return to the Detection rules blade;
14 Back on the Detection rules blade, click OK to return to the Add app blade;
15 Back on the Add app blade, select Return codes to open the Return codes blade;
16 On the Return codes blade, verify the preconfigured return codes and click OK to return to the Add app blade;
17 Back on the Add app blade, click Add to actually add app.

Note: The mentioned steps should be performed per PolicyPak .intunewin file.

Configure Win32 app dependency

Now the main configuration of this post, the configuration of the dependency between Win32 apps. The created Win32 apps need to be installed in the order as described (and shown) during the explanation of the scenario. The following six steps walk through the Win32 app dependency configuration. In my scenario, these steps need to be performed for he PolicyPak settings MSI, to create a dependency between the PolicyPak settings MSI and the PolicyPak client-side extensions MSI, and for the PolicyPak client-side extensions MSI, to create a dependency between the PolicyPak client-side extensions MSI and the PolicyPak license MSI. After configuring the Win32 app dependencues, make sure to assign the PolicyPak settings MSI to a user group.

1 Open the Azure portal and navigate to Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, select the just created [PolicyPakMSI] app to open the [PolicyPakMSI] app blade;
3 On the [PolicyPakMSI] app blade, select Dependencies to open the [PolicyPakMSI] app – Dependencies blade;
4 On the [PolicyPakMSI] app – Dependencies blade, click Add to open the Add dependency blade;
5 On the Add dependency blade, select the [PolicyPakMSI] app and click Select to return to the [PolicyPakMSI] app – Dependencies blade;
Win32App-AddDependency
6 Back on the [PolicyPakMSI] app – Dependencies blade, select Yes with AUTOMATICALLY INSTALL and click Save.
Win32App-AddDependency-Save

Note: Keep in mind that these steps need to be performed for both dependencies.

Experience

Now let’s end this post by looking at the end-user experience and the administrator experience.

End-user experience

The first experience to look at is the end-user experience. Below, from left to right, is the end-user experience. As I configured the dependencies to automatically install, the dependencies will install before the actual assigned PolicyPak settings MSI. First the end-user will receive the message that PolicyPak license MSI will install as a part of the PolicyPak settings MSI installation. After a successful installation, the end-user will receive the message that the PolicyPak client-side extensions MSI will install as part of the PolicyPak settings MSI installation. And once that installation is successful, the PolicyPak settings MSI will install.

PP-Example01 PP-Example02 PP-Example03

Administrator experience

Win32App-AdministratorExperienceThe second experience to look at is the administrator experience. That is not always the most exiting experience to look at, but in this case it does add something good and new to look at. For the administrator, Microsoft Intune provides the Dependency viewer. The Dependency viewer can be found by selecting an app and navigating to Monitor > Dependency viewer. The Dependency viewer shows the the dependencies of the selected app and the dependencies of the dependencies (all the way down). The Dependency viewer does not show the apps that depend on the app. So, to explain that with the example of this post, it would be like this:

  • PolicyPak settings MSI: The PolicyPak settings MSI would show that it has a dependency on the PolicyPak client-side extensions MSI and that the PolicyPak client-side extensions MSI has a dependency on the PolicyPak MDM license MSI (as shown on the right);
  • PolicyPak client-side extensions MSI: The PolicyPak client-side extensions MSI would show that it has a dependency on the PolicyPak MDM license MSI;
  • PolicyPak MDM license MSI: The PolicyPak MDM license MSI would show no dependencies.

More information

For more information regarding Win32 apps and Win32 app dependencies, please refer to the following article:

Join us at Experts Live Netherlands in Den Bosch

EXPERTSLIVE.6015_email-signature_spreker_ENG_200x200A bit less than a week from now, June 6, Experts Live Netherlands will be in Den Bosch. Experts Live Netherlands is one of the biggest Microsoft community events, with over 1200 visitors. I’m proud to be part of the speaker lineup again. Together with my finest colleague, Arjan Vroege, I will deliver a session about moving to a modern managed workplace at your own pace! And we hope to see you there!

About our session

During our session we will discus (and show) how to migrate to a modern managed workplace at your own pace. As many organizations want to make the switch to a modern managed workplace, but are currently unable to make the complete switch. Often this is related to missing specific management features, like limited control over updates and missing rich app deployment features. The good news is that it’s not required to directly make the complete switch. This can be achieved in steps, by using Configuration Manager and Microsoft Intune. In this session we will present and show you how to use these tools in combination with Windows 10 to make a smooth transition.

Simple method for adding notifications to scripted installations

This week is focused on the end-user experience. More specifically, the end-user experience for scripted actions. Especially when deploying apps, or performing other scripted actions, by using the PowerShell functionality, there could be actions of interest for the end-user.In that case I would like to notify the end-user. The app deployment functionality already provides the option to display notifications to the end-user and in this post I’ll show a simple, but effective method, to also display notifications to scripted installations. That can be a nice addition to this post about combining the powers of the Intune Management Extension and Chocolatey. In this post I’ll provide an updated script, followed by the required configuration steps. I’ll end this post with the end-user experience.

Script

The first step is to create a PowerShell script that can be used to install Chocolaty packages and to show notifications to the end-user after a successful installation. The following script provides the exact mentioned functionality, nothing more, nothing less, and the script is documented to provide some more details about the exact actions. The script uses the BurntToast module, which is available in the PowerShell Gallery, to display notifications.

Note: The BurntToast module, which is used, will only work for the logged-on user. For functionality in SYSTEM context, additional adjustments are required.

Configuration

The next step is to configure the PowerShell script in Microsoft Intune. The script must run in SYSTEM context to easily install new Windows Features. To upload the script, follow the five steps below. After uploading the script, simply assign the script to the required devices. I deliberately mentioned devices, as I’m using a security group that filters on the version of Windows 10. The good thing is that nowadays these scripts can be assigned to devices and that users are not required to be logged on first.

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

  • Name: Provide a valid name for the PowerShell script;
  • Description: (Optional) Provide a description for the PowerShell script;
  • Script location: Browse to the created PowerShell script;
  • Settings: See step 3b;

Note: The script must be less than 200 KB.

3b Notification-ScriptSettingsOn the Script Settings blade, provide the following configuration and click OK;

  • Run the script using the logged on credentials: Yes;
  • Enforce script signature check: No;
  • Run script in 64 bit PowerShell: Yes;

Explanation: This configuration will make sure that the script will run by using the user credentials on 32-bit and 64-bit devices.

Note: Keep in mind that the script will be running by using the user credentials, which will require the user to be local administrator for installing the different apps.

End-user experience

Let’s end this post by having a look at the end-user experience. This time I choose to go for an animated gif, as that will provide the best example of the end-user experience. Below is an example of the script installing 7-Zip and Notepad++.

Notification-Experience

More information

For more information about the BurtToast module, please refer to the PowerShell Gallery.

Always apply baseline to co-managed devices

Like the last couple of weeks, this week is also about co-management. This week is all about another nice detail that can be really useful, in specific use cases. That detail is the ability to always apply a configuration baseline to co-managed devices. Even when the Device configuration workload is switched from Configuration Manager to Microsoft Intune. That can be useful for configurations that are not available yet via Microsoft Intune, or for compliance checks that need to be performed and consolidated in one location. In this post I’ll provide a short introduction about the different configuration options, followed by the steps to configure a configuration baseline to co-managed devices when the workload is switched to Microsoft Intune. I’ll end this post with the end-results.

Introduction

When looking at the evaluation of baselines, co-management provides the administrator with 3 different configuration options (of which the third options is the main subject of this post):

  1. Apply Configuration Baselines via Configuration Manager when the Device configuration workload is set to Configuration Manager:
  2. Apply Device configuration profiles via Microsoft Intune when the Device configuration workload is set to Microsoft Intune:
  3. Apply Configuration Baselines via Configuration Manager as an exception to Device configuration profiles via Microsoft Intune when the Device configuration workload is set to Microsoft Intune

Configuration

Let’s start by having a look at the configuration. I’ll do that by going through an example that will create a baseline to verify the update compliance of co-managed devices. That will provide an easy method to verify compliance and consolidate the results. Below are 4 steps that walk through the process.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Baselines;
2 On the Home tab, click Create Configuration Baseline to open the Create Configuration Baseline dialog box;
3a

AlwaysApply-Step01On the Create Configuration Baseline dialog box, provide the following information and click OK to create the configuration baseline.

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description; 
  • Configuration data: See step 3b;
  • Select Always apply this baseline even for co-managed clients;

Explanation: The check Always apply this baseline even for co-managed clients in the baseline will make sure that the baseline is always applicable to co-managed devices. Even when the Device configuration workload is set to Microsoft Intune.

3b

AlwaysApply-Step02On the Create Configuration Baseline dialog box, click Add > Software Update to open the Add Software Updates dialog box. On the Add Software Updates dialog box, find the required software update and click OK.

Explanation: This configuration will make sure that this baseline will verify the compliance of all co-managed devices for the latest cumulative update.

4

AlwaysApply-Step03Right-click the just created baseline and click Deploy to open the Deploy Configuration Baselines dialog box. Leave everything default, select the collection for this baseline deployment and click OK.

Explanation: This configuration will make sure that this baseline is deployed to the required collection and will make sure that this baseline is only used for compliance and not for remediation.

Note: The setting Always apply this baseline even for co-managed clients in the baseline, as mentioned in step 3a, can be used to make sure that the baseline is always applied on co-managed devices.

End-results

Now let’s continue by having a look at the results on a co-managed device. Below are two examples of one of a co-managed device. First an overview of the Configuration Manager Properties, followed by a look in the DCMAgent.log file. Both are client-side details, as the server-side will provide status information similar like for any other device.

1 AlwaysApply-ConfigMgrPropertiesThe first example that I would like to show, is the Configurations tab in the Configuration Manager Properties. The Configurations tab shows the deployed baseline, including the last evaluation time and the compliance state. Similar to the evaluation of a baseline when the Device configuration workload is still set to Configuration Manager;
2 The second example that I would like to show, is the DCMAgent.log file. That log file records high-level information about the evaluation, conflict reporting, and remediation of configuration items and applications. Specifically to this post, this log file provides information about the status of the Device configuration workload (first arrow below) and provides information about specifically enabled baselines (second arrow below);
AlwaysApply-DCMAgent

More information

For more information about co-managed devices and configuration baselines, please refer to this article about creating configuration baselines in System Center Configuration Manager.

Switching the Office Click-to-Run apps workload

This week is all about the Office Click-to-Run apps workload. More specifically, this week is all about what’s happening, from a Configuration Manager perspective, when switching the Office Click-to-Run apps workload to Microsoft Intune. Switching the Office Click-to-Run apps workload to Microsoft Intune will make sure that the Office Click-to-Run app will be installed via Microsoft Intune and no longer via Configuration Manager. In this post I’ll show how to switch the Office Click-to-Run apps workload to Microsoft Intune, followed by what is actually making sure that Configuration Manager will no longer install Office Click-to-Run apps. I’ll end this post with a summary.

Configuration

Let’s start with the easy part, in this case, the configuration. Assuming that co-management is already configured, the following 3 steps will walk through the process of switching the Office Click-to-Run apps workload to Microsoft Intune.

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, to open the Properties dialog box;
3

O365W-ComanangementPropertiesOn the Properties dialog box, navigate to the Workloads tab. On the Workloads tab, move the slider with Office Click-to-Run apps to Intune.

Note: When there is a need to first test this configuration with a pilot group, simply move the slider with Office Click-to-Run apps to Pilot Intune. In that case make sure to configure a Pilot collection on the Staging tab of the Properties dialog box. 

Note: This configuration change will update the configuration baseline that is used to apply the co-management configuration to Configuration Manager clients. That baseline is shown on Configuration Manager clients as CoMgmtSettingsProd (and for pilot devices also CoMgmtSettingsPilot).

Effect of the configuration

Now let’s continue by looking at the effect of this configuration, from a Configuration Manager perspective. I’ll do that by showing the Global Condition that is used, I’ll do that by showing how that Global Condition is used and I’ll do that by showing what happens on the client device.

1 The first thing that I want to look at is the Global Condition that is used. Starting with Configuration Manager, version 1806, the Intune O365 ProPlus management condition is created as a Global Condition in Configuration Manager. That condition is used to make sure that the Configuration Manager client can no longer install the Office Click-to-Run app on co-managed devices, as the condition will be added as a requirement to the app. That is achieved by a VBScript, in the condition, that queries SELECT * FROM DeviceProperty WHERE DeviceIsO365IntuneManaged=TRUE in the root\ccm\cimodels namespace. Based on the results of the query, the VBScript will either return true or false. That return value will be used to evaluate the requirement of the app.
O365W-ConfigMgrConsole
2 O365W-AppRequirementThe second thing that I want to look at is the default configuration of the Office Click-to-Run app that is created when walking through the Microsoft Office 365 Client Installation Wizard. More specifically, the Requirements tab of the created Deployment Type. After a new Office Click-to-Run app is created, the Intune O365 ProPlus management condition is added as requirement to the Deployment Type. The value is configured to False, to make sure that the Office Click-to-Run app is not installed when the Office Click-to-Run apps workload is switched to Intune (or to Pilot Intune).
3 O365W-WbemTestThe third thing that I want to look at is the change on a co-managed device after the Office Click-to-Run apps workload is switched to Intune. Starting with Configuration Manager, version 1806, the Configuration Manager client has a new DeviceProperty named DeviceIsO365IntuneManaged in the root\ccm\cimodels namespace.Based on the configuration of the Office Click-to-Run apps workload, this property is configured to either TRUE or FALSE. That is done during the evaluation of the CoMgmtSettingsProd (and for pilot devices also CoMgmtSettingsPilot) baseline on Configuration Manager clients.

Note: Together these 3 things will make sure that the Configuration Manager client will no longer install any deployed Office Click-to-Run apps when the Office Click-to-Run apps workload is switched.

Summary

Let’s end this post with a summary of what is happening from a Configuration Manager perspective.

  • A relatively new Global Condition, named Intune O365 ProPlus management, is available in Configuration Manager;
  • The Intune O365 ProPlus management condition is used to verify if the co-managed device should use Configuration Manager or Intune for installing the Office Click-to-Run app;
  • The Intune O365 ProPlus management condition is added by default to to Office Click-to-Run apps created through the Microsoft Office 365 Client Installation Wizard;
  • A relatively new DeviceProperty, named DeviceIsO365IntuneManaged, is available in the Configuration Manager client configuration in WMI;
  • The DeviceIsO365IntuneManaged property is used to contain the status of the co-managed device, regarding whether Configuration Manager or Intune should be used to install the Office Click-to-Run app;
  • The DeviceIsO365IntuneManaged property is configured based on the status of the Office Click-to-Run apps workload in the co-management configuration;
  • The Office Click-to-Run app is deployed via Configuration Manager and the Configuration Manager client verifies the status of the DeviceIsO365IntuneManaged property by using the Intune O365 ProPlus management condition.

More information

For more information regarding the Office Click-to-Run apps workload, please refer to this article about Co-management workloads.