Predeclaring corporate-owned devices

This week something related to last week. This week will be about predeclaring corporate-owned devices. In other words, making sure that the Device Owner of the specified devices is set to Company after enrollment. It’s also a much easier solution, for a scripted solution that I created more than year ago, for automagically setting the mobile Device Owner to Company. In this blog post I’ll provide some information about this feature, I’ll show the configuration of this feature and I’ll show the administrator experience of this feature. Please note that this functionality is only available for Microsoft Intune hybrid.

Information

Predeclaring corporate-owned devices allows organizations to identify corporate-owned devices by importing the International Mobile Equipment Identity (IMEI) numbers, or, for iOS devices, by importing the serial numbers. It’s possible to upload a comma-separated values (.csv) file containing device IMEI numbers, or to manually enter device information. Imported information will make sure that the Device Owner will be set to Company for the devices that are in lists of devices. Keep in mind that this is only applicable to devices that still need to enroll. Already enrolled devices that are on the list will not change the Device Owner.

Configuration

Before I’m going through the required configuration steps, it’s good to mention the format of the csv files that can be used. The lines in the csv file can contain a maximum of 4 columns with the following items in the following order: IMEI number, iOS serial number, Platform (iOS, Windows, Android), Details. Each row must contain an IMEI number, or iOS serial number, and a Platform. The Details are optional. An example would look like the following.

,F9FFFFFFFFK9,iOS,Company-owned iOS device
357777777777748,,Android,Company-owned Android device

With this information, I can go through the required configuration steps. During these steps I’ll use the example csv information. It’s good to keep in mind that it’s also possible to manually add a single IMEI number or iOS serial number. In that case the wizard will simply skip the import page, mentioned below.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > All Corporate-owned Device > Predeclared Devices;
2 On the Home tab ,click Create Predeclared Devices to open the Create Predeclared Devices wizard;
3 CPD_GeneralOn the General page, select Upload a CSV file containing IMEI or serial numbers and details, select the csv file and click Next;
4 On the Import page, click Next;
5

CDP_EntryOn the Entry page, verify the information and click Next:

Note: This page is similar to when a single IMEI number or iOS serial number, is added, using this wizard. It’s even possible, at this point, to still manually add an additional IMEI number, or iOS serial number.

6

CDP_ProfileOn the Profile page, select an iOS enrollment profile and click Next:

Note: This is an optional page that will only show when an iOS device is imported. The refresh button can be used to update the selection box for newly created iOS enrollment profiles.

7 On the Summary page, review the summary and click Next:
8 On the Completion page, review the results and click Close.

Note: After completing the wizard, the Configuration Manager administration console will not automatically refresh. This requires a manually activity.

Administrator experience

Now it’s time to look at a few interesting places in the Configuration Manager administration console. When I now navigate to Assets and Compliance > Overview > All Corporate-owned Devices > Predeclared Devices, I can see the predeclared devices, including the enrollment status of those devices. Once a device is enrolled the status will reflect in the Configuration Manager administration console, as shown below.

PD_Overview

When the predeclared devices also contained iOS devices, the iOS devices are assigned to the selected iOS enrollment profile. When I now navigate to Assets and Compliance > Overview > All Corporate-owned Devices > iOS > Enrollment Profiles, I can select the iOS enrollment profile and see the related device count, as shown below. If I want to see even more information, I can select the iOS enrollment profile and click Show Assigned Devices.

EP_Overview

When I enroll the predeclared devices, the devices will show in the Configuration Manager administration console with the Device Owner set to Company. I can easily see this information when I navigate to Assets and Compliance > Overview > Devices, as shown below.

DS_Overview

Keep in mind that the Device Owner will only be set to Company when the predeclared devices are imported before the devices are enrolled. The Device Owner will not change for already enrolled devices.

More information

For more information about predeclaring company-owned devices, please refer to this article about Predeclare devices with IMEI or iOS serial numbers.

Share

Categorizing devices

This week something completely different as the last couple of weeks. This week no conditional access and nothing specifically related to Windows 10 devices. This week it’s all about categorizing devices. Within Microsoft Intune hybrid this functionality is named Device Categories and within Microsoft Intune standalone this functionality is named Device Group Mapping. Both of these functionalities can be used to achieve the same goal. In this post I’ll provide some more information, I’ll describe the configuration in Microsoft Intune hybrid and Microsoft Intune standalone and I’ll show the end-user experience.

Information

Categorizing devices can be useful to differentiate between device categories. For example, to differentiate between devices used by users of the sales department and the users of the human resources department. When categorizing devices, the following workflow is applicable.

  1. Create collections, or device groups, for each required category;
  2. Configure collection membership rules, or device group mapping rules, that map the categories to the collections, or device groups;
  3. When end-users enroll their device, they must choose a category from the configured categories. After they choose, their device will be automatically added to the corresponding collection, or device group;.
  4. Use the collections, or device groups, when deploying policies and apps.

Configuration

Now it’s time to start with the configuration of device categories. I’ll walk through the configuration steps for Microsoft Intune hybrid and standalone and I’ll provide the configuration options.

Microsoft Intune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to create custom device categories and I’ll show how to use a device category.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Device Collections;
2 On the Home tab ,click Manage Device Categories to open the Manage Device Categories dialog box;
3 ManageDC_MIHIn the Manage Device Categories dialog box, click Create to open the Create Device Categories dialog box;
4 CreateDC_MIHIn the Create Device Categories dialog box, provide an unique name and click OK to return to the Manage Device Categories dialog box;
5 Back in the Manage Device Categories dialog box, click OK.

Now that I’ve created device categories, I can use them as a collection membership rule. Assuming a collection is already available, the device category can be added by performing the following steps.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Device Collections;
2 Select the required collection and on the Home tab ,click Properties to open the Properties of the collection;
3 Within the Properties of the collection, click Add Rule > Device Category Rule to open the Select Device Categories dialog box;
4

SelectDC_MIHIn the Select Device Categories dialog box, select a device category and click OK to return to the Properties of the collection;

Note: This will actually create a query collection membership rule that simply queries on the MDMDeviceCategoryID property of a device.

5 Back in the Properties of the collection, click OK.

Note: An administrator can add an additional column, named Device Category, to the devices overview (and any device collection), to get a quick overview of the used device categories for the devices.

Microsoft Intune standalone

Let’s continue with similar configuration within Microsoft Intune standalone. I’ll walk through the required steps to create a device group mapping. Assuming the required device groups are already available, the device group mapping rule can be add by performing the following steps.

1 In the Microsoft Intune administration console, navigate to ADMIN > Mobile Device Management > Device Group Mapping;
2 On the Device Group Mapping page, enable Device Group Mapping;
3 DGM_MISOn the Device Group Mapping page, with Step 2: Mapping device group mapping rules click Add to open the Add device group mapping rule dialog box;
4 AddDGM_MISIn the Add device group mapping dialog box, provide an unique name, select a device group and click Add to return to the Device Group Mapping page;
5 Back on the Device Group Mapping page, click Save.

End-user experience

After the configurations of the device categories are completed, it’s time to have a look at the end-user experience. During the enrollment of an iOS or Android device, the end-user will receive an additional message to choose a device category. Once completed that category will display in the Company Portal app and the Company Portal web app. On Windows devices the configuration can be completed after the enrollment, via the Company Portal web app.

Company Portal app Company Portal web app
IMG_0086 IMG_0087

More information

Fore more information about categorizing devices, please refer to:

Share

Conditional access for Exchange Online to the max

This week I want to show another look at conditional for Exchange Online. I want to do that by providing a scenario. That scenario will cover more than just conditional access. Mainly because conditional access simply blocks access to non-compliant devices, but what if I want to take it one step further? What if I also want to prevent potential data leakage? In that case I can’t just look at conditional access. In that case I also need to add mobile app management to the playing field. This post will address those subjects for Exchange Online.

Scenario

Now lets start with the scenario that I want to cover. Even though I know that I will use Microsoft Intune and related technologies to do the configuration, I want the scenario to describe functional requirements. The configuration should address the following requirements:

  • Email access is only allowed on managed and compliant devices;
  • Email data leakage must be prevented on managed and compliant devices;
  • Email access is available via the browser;
  • Email access is supported on iOS, Android and Windows 10.

Configuration

Now lets have a look at what I need to configure to address that scenario. The good news is that I can support this scenario with Microsoft Intune. However, the default configuration is not sufficient. I need to get creative. To address this scenario I need to make sure that email access is only available through browsers and apps that can be managed by mobile app management (MAM) policies or by Enterprise Data Protection (EDP)/ Windows Information Protection (WIP). No back doors allowed. That means that to address this scenario I need to add the following technical configurations on top of the standard conditional access and MAM (and WIP):

  • The OWA app for iOS and Android must be blocked;
  • ActiveSync apps that use basic authentication must be blocked;
  • The default browsers on iOS and Android must be blocked.

Block the OWA app

ADFS_DenyOWAThe first thing that I want to configure is a deny for the Microsoft OWA app. That specific app bypasses every form of conditional access. Luckily that doesn’t mean that there is nothing that I can do to block the app. I can use AD FS to deny specific client user agent claims for the Microsoft OWA app. 

The following example claim will deny every active claim that arrives via the AD FS proxy with a client user agent that contains MOWAHost. That should be distinctive enough to only deny the Microsoft OWA app. However, keep in mind that the Microsoft OWA app will only be blocked once it tries to verify the credentials.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/services/trust/2005/usernamemixed”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “MOWAHost”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Block Exchange ActiveSync apps with basic authentication

The second thing I want to configure is a deny on every Exchange ActiveSync app with basic authentication, like the default mail app on iOS and Android. Those apps are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those apps can still leak data. The combination of the following three components allows me to only allow the Microsoft Outlook app, which is capable of working with MAM policies, on mobile devices.

1

ExchangeOnlinePolicy_EASThe first component that I need to address is the Exchange Online Policy for conditional access. I don’t want Microsoft Intune to control the access for the Exchange ActiveSync apps with basic authentication, I want Exchange Online to take care of those apps. Within Exchange Online I’ve got the ability to easily block or allow access to specific device families and models. Microsoft Outlook is available as a device family.

To achieve that Microsoft Intune doesn’t control those apps, I need to make sure that the setting Block non-compliant devices on platforms supported by Microsoft Intune and the setting Block all other devices on platforms not supported by Microsoft Intune are disabled in the conditional access policy for Exchange Online.

2

EA_AccessSettingsThe second component that I need to address are the Exchange ActiveSync access settings. Within these settings I can define the default behavior of Exchange Online when a device isn’t managed by a rule or personal exemption. In this case I want to block access to all mobile devices that are not part of the rule that I will define.

To achieve that every device is blocked when it’s not managed by a rule, I need to configure the Exchange ActiveSync Access settings to Block access.

3

EA_DeviceAccessThe third component that I need to address is the Device Access Rule. With a rule like this I can define which device families and models are allowed, blocked or quarantined. In this case I want to allow access to all mobile devices that use Outlook to connect.

To achieve that all mobile devices that use Outlook are allowed, I need to create a Device Access Rule with the Outlook device family and for All models.

Note: It’s even possible to specifically select Outlook for iOS and Android as model, but at this moment that cannot be enforced.

Block default browsers on iOS and Android

The third thing that I want to configure is a deny on the default browsers on iOS (Safari) and Android (Chrome). Those browsers are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those browsers can still leak data. Luckily that doesn’t mean that there is nothing that I can do to block those browsers.

ADFS_DenySafariDefault browser iOS (Safari)
I can use AD FS to deny specific client user agent claims for the Safari browser. However, the Safari browser is tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Safari. That isn’t only applicable to iOS, but also to Android and Windows.

The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Safari, but doesn’t contain Windows or Android. That should be distinctive enough to deny the Safari browser on iOS devices.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Safari/”])
  && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Windows|Android”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

ADFS_DenyChrome

Default browser Android (Chrome)
I can also use AD FS to deny specific client user agent claims for the Chrome browser. However, the Chrome browser is also tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Chrome. That isn’t only applicable to Android, but also to iOS and Windows.

The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Chrome and Android, but doesn’t contain PKeyAuth or ManagedBrowser. That should be distinctive enough to deny the Chrome browser on Android devices.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Chrome/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Android”])
  && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “PKeyAuth|ManagedBrowser|Windows”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Result

The result is awesome, in my personal opinion. I’ve successfully tested this configurations on iOS, Android and Windows 10 devices with multiple browsers and apps. This configuration, in combination with conditional access and MAM (and WIP), provides the following results:

  • Email access is only available on managed and compliant iOS and Android devices via the Managed Browser and on managed and compliant Windows 10 devices via Internet Explorer and Microsoft Edge. These browsers can be managed via MAM and WIP to prevent data leakage. Other browsers will be blocked by conditional access, or AD FS;
  • Email access is only available on managed and compliant iOS and Android devices via the Microsoft Outlook app on managed and compliant Windows 10 devices via Outlook. These apps can be managed via MAM and WIP to prevent data leakage. Other apps will be blocked by Exchange Online;
  • Known back doors are closed. The OWA app will be blocked by AD FS.

More information

Fore more information about conditional access for Exchange Online and mobile app management, please refer to:

Share

Conditional access for browsers

This week I’ll provide an overview about the latest addition to conditional access, which is conditional access for browsers. It’s a feature that many have been waiting for and a feature that is indeed a pretty welcome addition to conditional access. This post will provide the basics about conditional for browses, the configuration of conditional access for browsers and the end-user experience with conditional access for browsers. It will also be the introduction for something much better next week.

Introduction

Conditional access allows IT organizations to manage access to corporate email, files and other resources based on customizable conditions that ensure security and compliance. The addition of conditional access for browsers addresses the backdoor that still existed for end-users connecting to the Outlook Web App (OWA) and end-users using browser access to SharePoint and OneDrive for Business. It’s now possible to restrict Outlook Web App (OWA) and browser access to SharePoint and OneDrive for Business when accessed from a browser on iOS and Android devices. Access is only allowed from the following supported browsers, on compliant devices, while unsupported browsers are simply blocked:

  • Safari (iOS);
  • Chrome (Android);
  • Managed Browser (iOS and Android).

Note: Keep in mind that this does not block access via the OWA app. More about that in my post next week.

Configuration

Now let’s have a look at the configuration of conditional access for browsers. The configuration is the same for Microsoft Intune standalone and Microsoft Intune hybrid, as the configuration is part of the conditional access policies. It’s actually nothing more than one simple checkbox that belongs to one specific setting. That specific setting is Block non-compliant devices on the same platform as Outlook in the Exchange Online Policy and Block non-compliant devices on the same platforms as OneDrive for Business in the SharePoint Online Policy. That specific setting can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online SharePoint Online
OWAExchangeOnline OFBSharePointOnline

End-user experience

Now it’s time to look at the end-user experience, which is the most important part of this feature. Below I’ve got examples for compliant and non-compliant devices and supported and unsupported browsers. In all examples I’m trying to access https://outlook.office.com.

Android

Here is an example on an Android device using the supported Chrome browser and using the unsupported Firefox browser. The left column shows the non-compliant examples and the right column shows the compliant examples. Notice the clear message in the unsupported browser about using supported browsers for access.

Non-compliant Compliant
Screenshot_20160708-203644 Screenshot_20160710-181822
Screenshot_20160708-203757 Screenshot_20160708-204830

iOS

Here is an example on an iOS device using the supported Safari browser and using the unsupported Firefox browser. The left column shows the non-compliant examples and the right column shows the compliant examples. I haven’t been able to receive the same clear messages yet, as shown on my Android device, but the access is definitely blocked.

Non-compliant Compliant
IMG_0058 IMG_0056
IMG_0059 IMG_0057

Windows 10

I’ve also managed to successfully test conditional access for browsers on Windows 10, with Internet Explorer and Microsoft Edge, in combination with Microsoft Intune standalone and Microsoft Intune hybrid. Even in combination with Windows 10, fully managed by ConfigMgr. More about those awesome scenario’s once it’s listed as a supported platform with supported browsers.

More information

Fore more information about conditional access for browsers with Exchange Online and SharePoint Online, please refer to:

Share

Quick tip: Available token types for app configuration policies

This is a quick and short blog post to create awareness about the existence of token types. Token types are basically just variables that can be used within a property list of an app configuration policy in Microsoft Intune hybrid and Microsoft Intune standalone. This blog post will provide a quick overview about the available token types with example values.

Overview

The following table contains the currently available token types for Microsoft Intune hybrid and Microsoft Intune standalone. Before going through this table, it’s good to know that the {{ and }} characters are used by token types only and should not be used for other purposes.

Token type Example value
{{userprincipalname}} pvanderwoude@petervanderwoude.nl
{{mail}} pvanderwoude@petervanderwoude.nl
{{partialupn}} pvanderwoude
{{accountid}} fcc00012-123e-f479-aabe-abe2a1123b45
{{deviceid}} c7d01dd3-136f-40c5-b843-711e958c4eef
{{userid}} 2dda638e-28b7-4bdc-a4fd-70faaa811010
{{username}} Peter van der Woude
{{serialnumber}} F9FPVD86FCM5
{{serialnumberlast4digits}} FCM5

More information

For more information about iOS apps with mobile app configuration policies, in Microsoft Intune standalone and Microsoft Intune hybrid, please refer to:

Share

Microsoft Intune and the AppConfig Community

This week I would like to write about Microsoft Intune and the AppConfig Community. I want to create some awareness about what the AppConfig Community is and I want to show how even Microsoft Intune can, and will, benefit of that great alliance.

What is the AppConfig Community?

Let’s start with what the AppConfig Community actually is. I could do that by providing my own explanation about the AppConfig Community, but to prevent any possible misinterpretation from my side, I will provide the good and clear explanation as provided on the AppConfig Community website.

The AppConfig Community is a collection of industry leading Enterprise Mobility Management (EMM) solution providers and app developers that have come together to make it easier for developers and customers to drive mobility in business. The community’s mission is to streamline the adoption and deployment of mobile enterprise applications by providing a standard approach to app configuration and management, building upon the extensive app security and configuration frameworks available in the OS. Working together, the members of the AppConfig Community are making it simpler for developers to implement a consistent set of controls so that enterprise IT administrators can easily configure and manage apps according to their business policies and requirements.

Historically, developers used proprietary software development kits (SDKs) to enable configuration and management features of their apps through EMM. This required app developers to build different versions of their apps for each EMM vendor. Now, with the AppConfig Community tools and best practices, developers do not require EMM-specific integrations for many enterprise use cases. End users also benefit from automated features such as an out-of-the-box experience to give the users instant app access without requiring cumbersome setup flows or user credentials.

Microsoft Intune and the AppConfig Community

Let’s continue with how Microsoft Intune works with the AppConfig Community. Well, it’s good to know that, at this moment, Microsoft Intune is not part of the collection of industry leading EMM solution providers that started the AppConfig Community. However, that doesn’t mean that the apps, created with the AppConfig Community standards, won’t work with Microsoft Intune. The XML format used by the AppConfig Community is similar to the XML format used by Microsoft and the Microsoft Intune app partners. In other words, the apps created by the partners, of the AppConfig Community, should also work with Microsoft Intune.

Microsoft Intune example

Now I want to show how Microsoft Intune works with an app, of a partner, of the AppConfig Community, to proof my previous statement. As an example app I use the amazing Nacho Mail app. Not only is it a great email app, it also has a great support team and some awesome configuration options. The support team is more than willing to help with providing the required information to apply app configurations to the Nacho Mail app.

Configuration

As I’m currently looking at multiple mail apps, with one of my customers, I’m also looking at the Nacho Mail app. One of the big pros, of the Nacho Mail app, is the fact that it allows the configuration of the app. It has the ability to configure a mail profile and it even has the ability to apply custom branding to the app. After contacting the support team, of the Nacho Mail app, they provided me with the following configuration key-value-pairs.

Type Key Description
String AppServiceHost Name of server
Integer AppServicePort Port number
String UserName User name
String UserDomain Domain name
String UserEmail User email address
String BrandingName Name of app to be displayed
String BrandingLogo Link to image to be displayed with app

I could use those key-value-pairs to create a mail profile for Office365, including custom branding. It’s not required to specify AppServiceHost with outlook.office365.com, as the Nacho Mail app is intelligent enough to figure it out based on the provided mail address. However, I noticed that it would save me a certificate warning. Below is the configuration that I’ve created and to use this configuration, please refer to my post about App Configuration Policies for iOS.

<dict>
   <key>AppServiceHost</key>
   <string>outlook.office365.com</string>
   <key>BrandingName</key>
   <string>petervanderwoude.nl</string>
   <key>BrandingLogo</key>
   <string>[Specify URL to logo]</string>
   <key>UserEmail</key>
   <string>{{userprincipalname}}</string>
</dict>

Note: I used the {{userprincipalname}} token type that is supported by Microsoft Intune to provide the user principal name of the end-user. However, at this moment Microsoft Intune hybrid seems to be having problems with the supported token types. Microsoft Intune standalone works like a charm.

End-user experience

After creating the app configuration, it’s time to look at the end-user experience. This time I will show the first two screens of the Nacho Mail app, after installation. That will provide a clear picture about how app configuration policies can be helpful for an end-user. The screenshots on the left show the default start of the Nacho Mail app and the screenshots on the right show the start of the Nacho Mail app after deploying the app together with the app configuration policy.

On the second screenshot, on the right, it clearly shows the complete configuration of the mail profile and my custom branding. I love it!

Before After
IMG_0034 IMG_0030
IMG_0035 IMG_0033

More information

For more information about the AppConfig Community and mobile app configuration policies, in Microsoft Intune standalone and Microsoft Intune hybrid, please refer to:

Share

App Configuration Policies for iOS apps

This week another blog post that is triggered by a feature that is introduced in ConfigMgr 1602. And again, it’s about a feature that already did exist in Microsoft Intune standalone. This post will be about the App Configuration Policies for iOS apps. These policies can make the life of an end-user a lot easier and are a very welcome addition to Microsoft Intune standalone and Microsoft Intune hybrid.

For now the biggest challenge might be finding the apps that support App Configuration Policies and, maybe even more important, apps that have the settings documented. During the deployment of an app via ConfigMgr, or Microsoft Intune, it’s already visible if  an app could support App Configuration Policies. However, a lot of apps have the potential, but not yet the complete implementation.

Introduction

App Configuration Policies in Microsoft Intune hybrid and Microsoft Intune standalone, can be used to supply settings that might be required when the end-user runs an app. Settings that the end-user would have to specify manually. Think about settings like, a server name, a custom port number, a user name, a password, specific language settings and specific security settings.

If these settings are incorrectly entered by the end-user, this can increase the burden on the service desk, and can also slow the adoption of new apps. App Configuration Policies can help with eliminating these problems by letting the organization deploy these settings to the end-users in a policy before they run the app. The settings are then supplied automatically, and the end-user doesn’t have to perform an action.

These App Configuration Policies are not deployed directly to users and devices. Instead, they are associated with a deployment type during the deployment of the application. The policy settings will be used whenever the app checks for them (typically, the first time it is run).

Configuration

App Configuration Policies are configured per app, because every app supports different settings. In the following configuration examples I’m using the Acronis Access app as an example. During the configuration I will use one specific configuration setting, named enrollmentServerName. For all other supported Acronis Access app configuration settings, please refer to: https://www.acronis.com/en-us/support/documentation/AcronisAccessAdvanced_7.0/index.html#28935.html

Microsoft Intune standalone

The configuration of App Configuration Policies in Microsoft Intune standalone can be achieved by performing the following steps. After the configuration of the App Configuration Policy, it can be used during the deployment of the Acronis Access app.

1 In the Microsoft Intune administration console, navigate to POLICY and click Add..;
2 In the Create a New Policy dialog box, select iOS > Mobile App Configuration Policy and click Create Policy  to open the Create Policy page;
3

On the General section of the Create Policy page, specify the following information.

  • MI_AppConfig_GenName: [Specify a unique name for the app configuration policy];
  • Description: [Specify details that help identifying the app configuration policy].
4

In the Mobile App Configuration Policy section of the Create Policy page, specify the following information and click Verify;

MI_AppConfig_Rule<dict>
   <key>enrollmentServerName</key>
   <string>[Specify an enrollment server name]</string>
</dict>

5 After verifying the created configuration, click Save Policy.

Microsoft Intune hybrid

The configuration of App Configuration Policies in Microsoft Intune standalone can be achieved by performing the following steps. After the configuration of the App Configuration Policy, it can be used during the deployment of the Acronis Access app.

1 In the Configuration Manager administration console, navigate to Software Library > Overview > Application Management > App Configuration Policies;
2 On the Home tab, click Create new Application Configuration Policy to open the Create App Configuration Policy Wizard;
3

CM_AppConfig_GenOn the General page, provide the following information and click Next.

  • Name: [Specify a unique name for the app configuration policy];
  • Description: [Specify details that help identifying the app configuration policy].
4

CM_AppConfig_PolOn the iOS Policy page, select Specify name and value pairs (for simple property list files without nesting) and click New to open the Edit Name/Value Pair dialog box.

Note: Select Browse to a property list file (for more complex property list files with nesting) for adding more advanced configurations, or for adding the configuration in an XML format (like with the Microsoft Intune standalone configuration).

5

CM_AppConfig_RuleIn the Edit Name/Value Pair dialog box, provide the following information and click Ok to return to the iOS Policy page.

  • Type: String;
  • Name: enrollmentServerName;
  • Value: [Specify an enrollment server name].
6 CM_AppConfig_ConfBack on the iOS Policy page, verify the created configuration and click Next.
7 On the Summary page, click Next.
8 On the Completion page, click Close.

End-user experience

Now it’s time to look at the end-user experience. This time I will show the first start of the Acronis Access app after installation. The first screenshots shows the default start of the Acronis Access app and the second screenshot shows the start of the Acronis Access app after deploying the app together with the App Configuration Policy. As I don’t really have a server to connect to, it stops at the connection screen in which it did configure my custom server URL.

Before After
IMG_0018 IMG_0017

More information

For more information about iOS with mobile app configuration policies, in Microsoft Intune standalone and Microsoft Intune hybrid, please refer to:

Share

The new ability on iOS devices to send diagnostic information

This week a short blog post about the new ability in the updated Microsoft Intune Company Portal app, for iOS, to send diagnostic information. Before it was always fun to explain somebody the method to get the Company Portal Diagnostic Information, as it would require the end-user to open the Microsoft Intune Company Portal app and simply start shaking the device. Actually, this is still a possibility to get the Company Portal Diagnostic Information.

New in the latest update of the Microsoft Intune Company Portal app, for iOS, is the ability to send the Company Portal Diagnostic Information via the menu of the Microsoft Intune Company Portal app. This is a new Microsoft Intune Company Portal app ability and is not related to the iOS version.

End-user experience

Now let’s have a look at what the new end-user experience looks like. The end-user has to open the Microsoft Intune Company Portal app and simply walkthrough the following two steps.

Step 1 Step 2
IMG_0017 IMG_0018
The first step is to click on the username and to select About. The second step is to click on Send Diagnostic Report.

Note: After selecting Send Diagnostic Report an email will open, like with shaking the device, that includes the Company Portal-Log.log.

More information

For more information about the new features released in November, please refer to the following article: http://blogs.technet.com/b/microsoftintune/archive/2015/10/28/coming-soon-new-intune-features-including-windows-10-edp-policies.aspx

Share

The new managed app installation experience on iOS 9 devices

This week a short blog post about the new managed apps installation experience for end-users on iOS 9 devices, as it was a huge pain. One of the most heard complaints with managed apps, on iOS, was about the fact that the end-user would have to manually uninstall their personally-installed apps. After that the managed app could be installed and it would really work and act like a managed app.

New in iOS 9 is the ability to convert a personally-installed app to a managed app. This allows Microsoft Intune (standalone and hybrid) to take the management of a personally-installed app and turn it into a managed app. Of course, only after the users’ permission. This is really an iOS 9 ability and does not affect devices with iOS 8 and earlier.

End-user experience

Now let’s have a look at what the new end-user experience looks like. This experience is the same for required and available deployed managed apps. At the moment of the installation of the managed app, the end-user will get the following behavior depending on their situation. When the app is not yet installed the Install managed app behavior is applicable and when the app is already personally-installed the Manage managed app behavior is applicable.

Install managed app Manage managed app
InstallWord ManageWord
“i.manage.microsoft.com” is about to install and manage the app “Word” from the App Store. Your iTunes account will not be charged for this app. Would you like to let “i.manage.microsoft.com” take management of the app “Microsoft Word”? Your app data will become managed.

Note: Keep in mind that after allowing the management of the personally-installed app, the app will be a fully managed app. That also means that the app and its data will be removed after the removal of the management profile.

More information

For more information about the new iOS 9 features, please refer to the following article about the Day Zero Support for iOS 9 with Intune.

Share

Store accounts and the Microsoft Intune Company Portal app

CompanyPortalAppLogo_thumb9In this blog post I will answer a question that I get, with a lot of customers, and that’s if it’s required for end-users to have an account for the app store, of their platform, to download the Microsoft Intune Company Portal app. The app store that I mean here is can be the Google Play app store, the Apple app store,  the Windows Phone app store or the Windows app store. All these stores match with their platform and require their own store account to download apps.

Before I can answer the initial question, I first have to answer another question. That question is if it’s required to use the Microsoft Intune Company Portal app, simply because a store account is not required if the Microsoft Intune Company Portal app is not required. In this post I’ll try to answer both of these questions by providing tables for a nice overview of the requirements per platform. In general this is applicable for both Microsoft Intune standalone and Microsoft Intune integrated with ConfigMgr 2012.

Microsoft Intune Company Portal app

Now let’s start with the first question, is the Microsoft Intune Company Portal app required? In almost all the scenario’s the answer to this question will be, yes. Also, keep in mind that the advised scenario for every platform is to install the Microsoft Intune Company Portal app  and to enroll the mobile device. To be complete the following table lists the functional requirements for the Microsoft Intune Company Portal app  for every platform.

 Platform Enrollment and policies Application deployment
Android Yes Yes
iOS Yes1 Yes
Windows Phone 8.0 No Yes
Windows Phone 8.1 No Yes
Windows No Yes

1 It is possible to enroll iOS devices without using the Microsoft Intune Company Portal app. That can be achieved by either using portal.manage.microsoft.com on an iOS device, or by using the corporate device enrollment feature with Microsoft Intune standalone.

Store account

That brings me to the second question, is the store account required to get the Microsoft Intune Company Portal app? Well, this also differs per platform. To make it easy I can say that it’s required for the non-Microsoft platforms. The following table provides a quick overview per platform, including the alternatives for the Microsoft platforms.

Platform Store account required Alternative
Android Yes N/A
iOS Yes N/A
Windows Phone 8.0 No Microsoft Intune Company Portal app for Windows Phone
Windows Phone 8.1 No Microsoft Intune Company Portal app for Windows Phone 8.1
Windows No Microsoft Intune Company Portal app for Windows 8.1

Conclusion

At this moment the best method for end-users to enroll their device is to use the Microsoft Intune Company Portal app, if possible. In case the Microsoft Intune Company Portal app is not required for the enrollment, like with Microsoft platforms, it’s still advised to install the Microsoft Intune Company Portal app to better manage devices and applications.

Back to the original question, this would mean that, at this moment, a store account is always required for non-Microsoft platforms. For Microsoft platforms it depends on how the Microsoft Intune Company Portal app is deployed. Like I mentioned in my previous post, I like to use the Microsoft Intune Company Portal app for the Microsoft App store, if possible, and in that case a store account is required.

Share