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: Assign scope tags to devices by using security groups

This week is also a relatively short blog post. However, this week is about a recently introduced feature in Microsoft Intune. That feature is the ability assign a scope tag to all devices in a specific security group. Like last week it’s a relatively simple feature, but also like last week that simple feature makes life a lot easier. A few months ago I did a post about adding scope tags to devices. In that time it was still a manual action per device, which could be automated via PowerShell. In this post I’ll show how that this configuration can now be achieved by using a security group and what the result of that configuration is.

Configuration

Now let’s start by having a look at the steps to configure the automatic assignment of scope tags to all devices in a specific security group. The following 5 simple steps walk through the configuration of that assignment.

1 Open the Azure portal and navigate to Microsoft Intune > Roles > Scope (Tags) to open the Intune roles – Scope (Tags) blade;
2

On the Intune roles – Scope (Tags) blade, select Create to open the Create Scope Tag blade;

Note: When existing Scope tags are available, simply select the existing Scope tag to open the Edit <ScopeTagName> blade. The step next step will be pretty similar.

3 On the Create Scope Tag blade, provide a valid Name for the scope tag and select Assign scope tag to all devices in selected groups to open the Select groups blade;
MSI-CreateScopeTag01
4 On the Select groups blade, select the required security group and click Select to return to the Create Scope Tag blade;
MSI-CreateScopeTag02
5 Back on the Create Scope Tag blade, click Create to create the Scope tag;

Result

Let’s end this post by having a quick look at the result of the mentioned configuration. Let’s do that by having a look at the Properties of a device. Initially the scope tag configuration had to be done manually in the Properties of a device (or by using a script). Now the scope tag configuration will automatically be populated based on the devices in the selected security groups in the scope tag configuration (see below). When the device will be removed from the security group, the scope will also be automatically removed.

MSI-ScopeTagResult

Note: At this moment the scope tags in the Properties of a device are not read-only. The administrator is still able to manually remove a scope tag. Even when that scope tag was added via a security group. It is strongly recommended not to do this, as, in my experience, it will break the automatic behavior for that scope tag. In the future this configuration will become read-only.

More information

For more information about using scope tags, refer to this article about using role-based access control (RBAC) and scope tags for distributed IT.

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).

Microsoft MVP 2019-2020

Yeah! A few hours ago I received that great email that I’m awarded with the 2019-2020 Microsoft MVP Award for my contributions in the Enterprise Mobility technical communities! That’s number 5!

MVP2019-2020

To me this is always worth a small post on my blog. Not just because I’m very honored, very proud and very exited of receiving my fifth award in a row, but maybe even more because I just need to let everyone know that it’s made possible by my great family. Without their support, my blog wouldn’t exist! Without their support I wouldn’t be able to contribute the way I am! Like every year, a really big thank you to my awesome wife and our super kids for giving met time to do my “thing”.

Me and my family are ready for another community driven year!

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.

Android Enterprise fully managed devices and conditional access

This week is all about Android Enterprise fully managed devices. More specifically, the recently introduced functionality to use Android Enterprise fully managed devices in combination with conditional access. To support this functionality Microsoft introduced a new app, named Microsoft Intune app, and a new profile type for device compliancy policies for the Android Enterprise platform. Together these 2 features enable Android Enterprise fully managed devices to be registered as compliant device and to successfully work with conditional access. In this post I’ll provide some information about the Microsoft Intune app and I’ll show how to configure that app, followed by some information about the compliance policy for device owner scenarios and how to configure that policy. I’ll end this post by showing the end-user experience.

Keep in mind that Android Enterprise fully managed devices is still preview functionality. There are still scenarios that will not fully work at this moment. One of those scenarios is related to app protection policies. I specifically mention that scenario, as it can conflict with the scenario in this post. Apps with app protection policies assigned, will still prompt for the Company Portal app.

Microsoft Intune app

The first part in using Android Enterprise fully managed devices in combination with conditional access is the Microsoft Intune app. The Microsoft Intune app is a new modern and light-weight app that will enable the Company Portal app experiences for end-users on fully managed devices. That includes managing compliance for their device. Keep in mind that the Microsoft Intune app is only for the fully managed device scenario. As Android Enterprise fully managed devices require the Managed Google Play Store, the following 4 steps walk through the process of adding the Microsoft Intune app by using the Managed Google Play Store. After that the Microsoft Intune app can be assigned as any other app.

Keep in mind that after the May 2019 service roll out of Microsoft Intune, the Microsoft Intune app will automatically be added to the Intune admin console after connecting the tenant to managed Google Play.

1 Open the Azure portal and navigate to Microsoft 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;
3a MIapp-AddAppOn the Add app blade, provide the following information and click Sync;

  • App type: Managed Google Play;
  • Managed Google Play: See step 3b – 3f;
3b On the Search managed Google Play blade, search for the Microsoft Intune app;
MIapp-SearchApp
3c On the Search managed Google Play blade, select the required app and click Approve to open a dialog box with app permissions;
MIapp-ApproveApp
3d

MIapp-ApproveAppDB01On the dialog box with app permissions, click Approve to continue to the selection about handling new app permissions;

Important: Keep in mind that this will accept these permissions on behalf of the organization.

3e

MIapp-ApproveAppDB02On the dialog box about handling new app permissions, select Keep approved when app requests new permissions and click Save to return to the Search managed Google Play blade;

Important: Keep in mind that this decision might impact the future app permissions and/or the future user experience.

3f On the Search managed Google Play blade, click OK;
MIapp-ApproveAppOK
4 Back on the Add app blade, click Sync;

Note: These steps will approve the app in the Managed Google Play store and sync the approved app in to Microsoft Intune..

Compliance policy for device owner

The second part in using Android Enterprise fully managed devices in combination with conditional access is the compliance policies. Since recently it’s possible to create compliance policies for fully managed devices. The list of available compliance settings is smaller than other platforms. The main reason for that is because those settings are only applicable to fully managed devices. And fully managed devices are, as the name already implies, fully managed. In other words, fully managed devices already follow strict configuration policies. The following 5 steps walk through the process of creating a device compliance policy for Android Enterprise fully managed devices. After configuring the device compliance policy assign it to a user group like any other device compliance policy.

1 Open the Azure portal and navigate to Microsoft Intune > Device compliance > Policies to open the Device compliance – Policies blade;
2 On the Device compliance – Policies blade, click Create Policy to open the Create Policy blade;
3a

AEfmd-CreatePolicyOn the Create Policy blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Android Enterprise;
  • Profile type: Device owner
  • Settings: See step 3b and 3c;
  • Actions for noncompliance: Leave default (for this post);
  • Scope (Tags): Leave default (for this post);

Note: Configuring non-standard values for Actions for noncompliance and Scope (Tags), is out of scope for this post;

3b

AEfmd-DevicePropertiesOn the Device owner blade, select Device Properties to open the Device Properties blade. On the Device Properties blade, configure the required device properties and click OK to return to the Device owner blade;

3c AEfmd-SystemSecurityBack on the Device owner blade, select System Security to open the System Security blade. On the System Security blade, configure the required system security settings and click OK to return to the Device owner blade;
4 Back on the Device owner blade, click OK to return to the Create Policy;
5 Back on the Create Policy blade, click Create to create the policy.

Note: To take full advantage of this device compliance policy configuration, it must be used in combination with a conditional access policy that requires the device to be marked as compliant.

End-user experience

Now let’s end this post by looking at the end-user experience. Below, from left to right, is an overview of the different steps in the Microsoft Intune app to get a device from a noncompliant state to a compliant state. When the user has a noncompliant device state, the user can start the process by clicking on “You need to update settings on this device”. That will bring the user to the screen to setup access to resources. On that screen the user can simply continue. The next screen will show the user the settings that need to be updated and by clicking on a setting the user will receive information to resolve the issue. Once all the issues are resolved, the device state will switch to compliant.

AEfmd-Experience01 AEfmd-Experience02 AEfmd-Experience03
AEfmd-Experience04 AEfmd-Experience05

Note: Keep in mind that this is still preview functionality. When using app protection policies, the protected apps will still prompt for the installation of the Intune Company Portal app.

More information

For more information regarding the Microsoft Intune app and Android Enterprise fully managed devices, please refer to the following articles:

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.

Conditional access and registering security information

Similar like last week, this week is also still about conditional access. This week is about the recently introduced user action of Register security information (Preview).  A lot has been posted about that recently and I had my post ready, but I wanted to wait for an official blog post before publishing my version. Just to make sure that I’m using the right reasons for using this feature. Also, it simply fits the line of my recent post. This user action can be used to add conditional action to Azure AD security services that require information of the end-user. In this post I’ll start with a short introduction about this new user action and the behavior that the user action controls. After that I’ll show the configuration steps, followed by the end-user experience.

Introduction

Let’s start with a short introduction about the Register security information (Preview) user action. This user action can be used to add conditional access to Azure AD security service that require information of the end-user. That enables the administrator to require the end-user to be in a trusted location to register for multi-factor authentication (MFA) or self-service password reset (SSPR). At this moment this user action responds to the following:

  • https://aka.ms/setupsecurityinfo – The new, still in preview, combined security information registration page for MFA and SSRP;
  • https://aka.ms/mfasetup – The MFA security information registration page. With preview features enables for end-user, this will redirect to the new combined page;
  • https://aka.ms/ssprsetup – The SSRP security information registration page. With preview features enables for end-user, this will redirect to the new combined page;

Configuration

Let’s continue by having a look at the configuration options. Let’s do that by looking at a simple scenario that is focused on the Register security information user action. That scenario is to only allow users to register their security information, when connecting from a trusted location. The following seven steps walk through that scenario.

1 Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or navigate to Azure Active Directory > Conditional access > Policies to open the Conditional Access – Policies blade;
2 On the Conditional Access – Policies blade, click New policy to open the New blade;
3a

RSI-UserGroups-IncludeOn the New blade, provide a unique name and select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, on the Include tab, select All users and click Exclude to open the Exclude tab;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users.

3b

RSI-UserGroups-ExcludeOn the Exclude tab, select Directory roles (preview) > Global administrator and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude global administrators. As global administrators should not be treated as normal users (to prevent a potential lock out) and usually have a separate conditional access policy applied.

4

RSI-CloudAppsOrActionsOn the New blade, select the Cloud apps or actions assignment to open the Cloud apps or actions blade. On the Cloud apps or actions blade, select User actions, select Register security information (preview) and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is only applicable to user actions to register security information.

5a

RSI-Locations-IncludeOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Locations to open the Locations blade. On the Locations blade, click Yes with Configure, on the Include tab, select Any locations and click Exclude to open the Exclude blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to any location.

.

5b

RSI-Locations-ExcludeOn the Exclude tab, select All trusted locations and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude trusted locations. As this conditional access policy should only be applied to untrusted locations.

6

RSI-GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will block access for any location that is not trusted by the IT organization.

.

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

Note: Keep in mind that the Register security information user action is still in preview.

End-user experience

Now let’s end this post by having a look at the end-user experience. When the end-user is connecting from a non-trusted location, the end-user will be blocked from accessing any of the earlier mentioned URLs. In that case the end-user will receive the message “You cannot access this right now” as shown below.

RSI-EndUserExperience

I did notice a few hick-ups when using this feature in it’s early preview state:

  • When using the new combined security information registration page for MFA and SSRP, the URL will re-direct via the Microsoft App Access Panel. That can trigger other conditional access rules that are configured for cloud apps;
  • Often I could initially sign-in shortly before getting tossed out by conditional access;

More information

For more information regarding conditional access and sign-in frequency, please refer to the following article: