Customizing the Microsoft Intune Company Portal app and website

This week is all about customizing the Microsoft Intune Company Portal app and website. The main trigger for this subject are the recently introduced additional customization options. Besides configuring default branding and support information, the list of actual specific customization configurations is growing and providing more and more options for an organization specific look-and-feel. That includes the option for creating multiple different customization policies. In this post I’ll go through the different customization options and policies. I’ll end this post by having a quick look at the end-user experience.

Company Portal app and website customization options

Now let’s have a look at the Company Portal app and website customization options. To do that, I want to walk through the different customization options and explain the usage. Let’s start with the following steps for editting or creating a customization policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Tenant administration > Customization to open the Tenant admin | Customization page
  2. On the Tenant admin | Customization page, click Edit to edit the Default Policy or click Create to create a new custom policy

Editting the Default Policy will provide the administrator with all the available settings as I’m going through below, while creating a new customization policy will provide the administrator with the Create customization policy wizard that doesn’t contain the Hide features section mentioned below. Either way, the customization options are divided into three categories: 1) Branding customization, 2) Support information customization and 3) Configuration customization.

Branding customization

The first category contains the Branding customization, which enables the administrator to configure customizations related to the branding that is shown to the user via the Company Portal app and website. Below, in Figure 1, is an overview of the Branding customization options and a short explanation of those customization options is described below that figure.

  • Organization name: The organization name field is used for configuring the name of the organization and is limited to 40 characters. The organization name can be displayed in the Company Portal app and website.
  • Color: The color selection is used for configuring a Standard color, which provides the selection of five standard colors, or a Custom color, which provides the option to configure a custom color code.
  • Theme color: The the color field changes based on the initial color selection. The configured theme color is shown in the Company Portal app and website. This can be any color and the text color is automatically adjusted to the selected color.
  • Show in header: The show in header selection is used for configuring the header of the Company Portal app and webiste. The options are self-explaining: the Organization logo and name, the Organization logo only, or the Organization name only.
  • Upload logo: The upload logo field comes in different variations (not shown in Figure 1) and is used to upload a custom logo. That logo can be displayed displayed in the Company Portal app and website.

Support information customization

The second category contains the Support information customization, which enables the administrator to configure customizations related to the support information that is shown to the user via the Company Portal app and website. The information will be displayed on the contact pages in the end-user experience. Below, in Figure 2, is an overview of the Support information customization options and a short explanation of those customization options is described below that figure.

  • Contact name: The contact name field is used for configuring the name of the support contact for users in the Company Portal app and website. The name is limited to 40 characters.
  • Phone number: The phone number field is used for configuring the number of the support contact for users in the Company Portal app and website. The number is limited to 20 characters.
  • Email address: The email address field is used for configuring the email of the support contact for users in the Company Portal app and website. The address is limited to 40 characters.
  • Website name: The website name field is used for configuring the friendly name of the support website in the Company Portal app and website. The name is limited to 40 characters.
  • Website URL: The website URL field is used for configuring the URL of the support website in the Company Portal app and website. The URL is limited to 150 characters.
  • Additional information: The additional information field is used for providing additional support-related information for the users in the Company Portal app and website. The information is limited to 120 characters.

Configuration customization

The third category contains the Configuration customization, which enables the administrator to configure multiple customizations related to the available configuration options via the Company Portal app and website. The Configuration customization options actually change the options and the behavior provided to the user and are divided into five sections: 1) the Enrollment section, 2) the Privacy section, 3) the Device ownership notification section, 4) the App Sources section and 5) the Hide features section.

Enrollment section

The first section contains the Enrollment customization options, which enables the administrator to configure customizations related to the enrollment experience that will be provided to the user via the Company Portal app. Below, in Figure 3, is an overview of the Enrollment customization options and a short explanation of those customization options is described below that figure.

  • Device enrollment: The device enrollment selection is used for specifying if and how users should be prompted in the Company Portal app to enroll their iOS/iPadOS and Android devices. The options are: Available, with prompts, which will prompt the user to enroll the device; Available, no prompts, which will provide the option to enroll the device but will not prompt the user and Unavailable, which will not enable the user to enroll the device.

Privacy section

The second section contains the Privacy customization options, which enables the administrator to configure customizations related to the privacy statement and messages that will be shown to the user via the Company Portal app. Below, in Figure 4, is an overview of the Privacy customization options and a short explanation of those customization options is described below that figure.

  • Privacy statement URL: The privacy statement URL field is used for configuring the URL that links to the privacy statement of the organization in the Company Portal app and website. This URL is limited to 79 characters.
  • Privacy message in Company Portal for iOS/iPadOS: The privacy message selection is used for configuring the privacy message that is shown in the Company Portal app on iOS/iPadOS devices. That can be used to inform the user about what the organization can and cannot see on the device of the user. The options are to use the Default or a Custom message and when using a custom message that message is limited to 520 characters.

Device ownership notification section

The third section contains the Device ownership notification customization options, which enables the administrator to configure customizations related to the push notifications about the device ownership changes that will be automatically sent to the user via the Company Portal app. Below, in Figure 5, is an overview of the Device ownership notification customization options and a short explanation of those customization options is described below that figure.

  • Send a push notification to users when their device ownership type changes from personal to corporate (Android and iOS/iPadOS only): The send push notification selection is used to select whether a push notification should be send to the Company Portal app on Android and iOS/iPadOS devices after changing the device ownership from personal to corporate. The options are Yes or No.

App Sources section

The fourth section contains the App Sources customization options, which enables the administrator to configure customizations related to the additional app sources that will be shown in the Company Portal app and website (currently website only). Below, in Figure 6, is an overview of the App Sources customization options and a short explanation of those customization options is described below that figure.

  • Azure AD Enterprise Applications: The Azure AD enterprise applications selection is used to select whether Azure AD enterprise applications should be shown in the Company Portal app and website (currently website only). The options are Hide and Show.
  • Office Online Applications: The Office online applications selection is used to select whether Office online applications should be shown in the Company Portal app and website (currently website online). The options are Hide and Show.

Hide features section

The fifith section contains the Hide features customization options, which enables the administrator to configure customizations related to the available self-service actions on devices that users can perform via the Company Portal app and website. Below, in Figure 7, is an overview of the Hide features customization options and a short explanation of those customization options is described below that figure.

  • Hide remove button on corporate Windows devices: The hide remove button checkbox is used to select whether the remove button is hidden in the Company Portal app and website for corporate Windows devices.
  • Hide reset button on corporate Windows devices: The hide reset button checkbox is used to select whether the reset button is hidden in the Company Portal app and website for corporate Windows devices.
  • Hide remove button on corporate iOS/iPadOS devices: The hide remove button checkbox is used to select whether the remove button is hidden in the Company Portal app and website for corporate iOS/iPadOS devices.
  • Hide reset button on corporate iOS/iPadOS devices: The hide reset button checkbox is used to select whether the reset button is hidden in the Company Portal app and website for corporate iOS/iPadOS devices.

Company Portal app and website experience

Now let’s end this post by having a look at the end-user experience. I’m not going to show all the branding, support information and configuration customizations, but just a few that really standout. Below, in Figure 8, is a side-by-side of the Company Portal website on the left and the Company Portal app on the right. Both show the same look-and-feel. A few detail that can be spotted are:

  • The branding theme color
  • The branding header of organization logo and name
  • The configuration app sources of Office online apps
  • The configuration hide features of Windows devices

More information

For more information about configuring the Microsoft Intune Company Portal app and website, refer to this article about customizing the Intune Company Portal apps, Company Portal website, and Intune app

Pushing notifications to users on iOS and Android devices

This week is all about the different options in Microsoft Intune to send push notifications to users on iOS (and iPadOS) and Android devices. The trigger of this post is the option to send push notifications as an action for noncompliance, which was introduced with the 2005 service release of Microsoft Intune. Besides that, it was already possible to send custom notifications to a single device, to the devices of a group of users, or as a bulk action to multiple devices. In this post I want to go through the different options for sending push notifications, followed by showing the end-user experience.

Send custom notifications

Custom notifications can be used to push a notification to the users of managed iOS (including iPadOS) and Android devices. These notifications appear as push notifications from the Company Portal app (or Microsoft Intune app) on the device of the user, just as notifications from other apps. A custom notification message includes a title of 50 characters or fewer and a message body of 500 characters or fewer. Besides those message limitations, the following configurations should be in place for a device to be able to receive push notifications.

  • The device must be MDM enrolled.
  • The device must have the Company Portal app (or Microsoft Intune app).
  • The Company Portal app (or Microsoft Intune app) must be allowed to send push notifications.
  • An Android device depends on the Google Play Services.

Send custom notification to a single device

The method for sending a custom notification to a single device is by using device actions. To use device actions for sending a custom notification to a single device, simply follow the three steps below.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > All devices {{select Android or iOS device} to open the Overview page of the specific device
  2. On the Overview page, select the Send Custom Notification device action (when the option is not available, select the  option first from the upper right side of the page) to open the Send Custom Notification pane
  3. On the Send Custom Notification page, specify the following message details and select Send to send the notification to the device
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to a single device can be achieved by using the sendCustomNotificationToCompanyPortal object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/managedDevices('{IntuneDeviceId}')/sendCustomNotificationToCompanyPortal

Send custom notification to a group of devices

There are actual two methods for sending a custom notification to a group of devices. The first method for sending a custom notification to a group of devices is by using the tenant administration. That can be achieved by using the four steps below. The twist is that those steps will enable the administrator to send a notification to a group, which will only target the users of that group. The notification will then only go to all the iOS (and iPadOS) and Android devices that are enrolled by that user.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Teant administration Custom notifications to open the Tenant admin | Custom notifications blade
  2. On the Basics page, specify the following message details and select Next
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation
  1. On the Assignments page, select the group that should be used to send this notification to and click Next
  2. On the Review + Create page, review the information and click Create to send the notification

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to the devices of a group of users can be achieved by using the sendCustomNotificationToCompanyPortal object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/sendCustomNotificationToCompanyPortal

The second method for sending a custom notification to a group of devices is by using bulk actions. That can be achieved by using the four steps below. Those steps will enable the administrator to send a notification to multiple selected iOS (and iPadOS) and Android devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices All devicesBulk Device Actions to open the Bulk device actions blade
  2. On the Basics page, specify the following details and select Next
  • OS – Select the platform of the devices that should receive this notification (Android (device administrator), Android (Work Profile), or iOS/iPadOS)
  • Action – Send custom notification
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation
  1. On the Assignments page, select the devices to send this custom notification to and click Next
  2. On the Review + Create tab, review the information and click Create to send the notification

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to multiple selected devices can be achieved by using the executeAction object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/managedDevices/executeAction

Send noncompliance notification

Noncompliance notifications can be used to push a notification to a device about the noncompliance state of the device. These notifications appear as push notifications from the Company Portal app on the device of the user, just as notifications from any other app. The notification is pushed to the device, the first time after the device is noncompliant and checks in with Microsoft Intune (depending on the configured schedule of the push notification). The message of the notification contains the details about the noncompliance and can’t be customized. Also, the notification is only pushed a single time. To push multiple notifications, simply add multiple actions. The four steps below show how to add a noncompliance action that will send a push notification to a compliance policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Endpoint security Device compliancePolicies to open the Compliance policies | Policies blade
  2. On the Compliance policies | Policies page, either create a new policy, or edit an existing policy (this example is of editing an existing policy)
  3. On the Actions for noncompliance page, select Send push notification as an additional action
  1. On the Review + save page, click Save

For automation purposes, automating updating a device compliance policy can be achieved by patching the specific deviceCompliancePolicies object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies/{policyId}

End-user experience

Let’s end this post by having a look at the end-user experience. The push notifications will show on the lock screen just as notifications from any other app. Below on the left (Figure 5) is showing an example of the lock screen that contains a custom notification and a noncompliance notification. Below in the middle (Figure 6) is showing an example of a custom notification when the Company Portal app was open. The user will go to the same page in the Company Portal app, when clicking on the custom notification on the lock screen. Below on the right (Figure 7) is showing an example of the page in the Company Portal app, when clicking the noncompliance notification. That will enable the user to immediately take action.

Note: The experience on Android devices is similar. However, keep in mind that on Android devices, other apps might have access to the data in push notifications.

More information

For more information about the different options to send push notifications to users on iOS and Android devices, refer to the following docs:

Conditional access and ipadOS

Update: Azure AD has taken a change in how they recognize the browsers so conditional access will now work as expected when creating an iPad conditional access policy and browsing to the modern desktop-class browsing experience on iPadOS. For more information see this article.

Maybe a little overdue, but this week is all about ipadOS in combination with conditional access. At the end of September, Apple released ipadOS. A new platform for iPad. One of the ideas behind ipadOS is to provide “desktop-class browsing with Safari”. That desktop-class browsing is achieved by making sure that the Safari browser on ipadOS will present itself as a Safari browser on macOS. That change introduces a few challenges in combination with conditional access. I know that a lot has been written about this subject already, but looking at the amount of information on my blog about conditional access, and the number of questions I still receive about this subject, I just had to write about this subject. In this post I’ll describe the behavior of ipadOS with conditional access and the challenges that the behavior brings.

The behavior

The first thing is to identify the behavior. The best and easiest place to look for the behavior is the Safari browser itself. Open the Safari browser and browse to a location that is blocked via conditional access. Click on More details and the Device platform will show macOS as the platform (as shown on the top right).

Another method, from an administrator perspective, is by using the Monitoring > Sign-ins section of Azure Active Directory. That section logs the sign-in status. That information also includes device information of the device that is used for the sign-in. On the bottom right is an example of the information that is shown for devices that are running ipadOS and using the Safari browser. It will be recognized as a device running macOS and using the Safari browser.

So far I’ve only mentioned this behavior for the Safari browser on ipadOS. However, there is more. More components that are behaving in a similar way to provide a desktop-class experience. The complete list of affected components on ipadOS is the following:

  • the Safari browser
  • the Native mail app
  • anything that uses Safari View Controllers

Besides that it’s also good to mention that everything else is not affected by this adjustment. So, all Microsoft apps still work as expected, all other browser still work as expected and basically all other apps (with the Intune SDK integrated, or wrapped) still work as expected.

The challenges

Now let’s have a look at the challenges that this behavior brings. Those challenges can be categorized in two main categories, 1) managed apps and 2) differentiating between platforms. This first category contains a flow that actually breaks and the second category contains a flow that needs some more attention. Let’s discuss those challenges in a bit more detail.

Category 1: Managed apps

When looking at the first category, we can simply state that we’re limited in options when we want to require a managed app by either using the Require approved client app or the Require app protection policy control. At this moment these controls only work for Android and iOS. That means that we cannot (easily) force a user to use a managed app on ipadOS. Before we could provide a clear message to a user that a managed app must be used, when trying to connect to a cloud app with the Native mail app or the Safari browser.

This is the point were we have to get creative. It’s possible to look at a technical solution by blocking the Native mail app and the Safari browser when accessing the different cloud apps. However, keep in mind that those technical solutions might also impact macOS (see the second category).

At this moment there is no pretty method to force users away from the Safari browser and into using managed apps on ipadOS. Any solution will also impact macOS. Besides the fact that those solutions will also impact macOS, the end-user experience will also be bad. In this case the only option would be to block access from the Safari browser to the different cloud apps. Not pretty. Also, keep in mind what that would mean for the macOS users, as there are no alternatives for macOS users.

The Native mail app is a different story. There are options when already blocking basic authentication and Exchange Active Sync. In that case you’re relying on modern authentication and when you’re relying on modern authentication, for i(pad)OS devices, you’re relying on the iOS Accounts app in Azure AD. Revoking the user grants will remove the access for the user via the Native mail app (for some detailed steps have a look here). Keep in mind that the behavior will not be as pretty as before.

Category 2: Differentiating between platforms

When looking at the second category, we can (and have) to say that we need to be careful when using the Device platforms condition. There are many scenarios available in which an organization might want to differentiating between ipadOS and macOS. In any of those scenarios don’t forget the potential impact.

Both platforms will impact ipadOS. Anything configured for macOS will impact iOS when using the Native mail app or the Safari browser. Anything configured for iOS will impact all other iOS app.

More information

For more information about the impact of ipadOS with conditional access, please refer to this article Action Required: Evaluate and update Conditional Access policies in preparation for iPadOS launch.