Android Enterprise Dedicated device – matching a physical device to a device record in Intune

I work with organizations who have 100’s to 1000’s of managed devices in Intune.  When it comes to Android there may be various Android OEMs and OS versions organizations are managing and a variety of use cases for those devices.  With more organizations migrating to Android Enterprise they must choose an enrollment method based on the scenario.  With Android Enterprise there are several methods of enrollment, Dedicated, Work Only, and Personally-Enabled.  For more details on Android enrollment options please visit: https://www.android.com/enterprise/management/

For digital signage, kiosks, barcode scanners, etc. those devices are typically enrolled as a “Dedicated” device where a single or multiple apps are the only apps accessible by the end user. In addition, dedicated devices do not have user affinity, meaning the device isn’t linked in an MDM to a specific user unless there some sort of tagging associated which identifies the user or location of the device.

Because there’s no user affinity assiated with dedicated devices, I’m often asked, “what’s the best method to identify an Android device enrolled as a dedicated device (e.g. kiosk) in the Intune admin portal with a physical device in hand?”

There’s a simple method of doing this and it’s identifying the device by serial number. Here’s how to do it without removing the battery:

1.  With the device turned on tap on the arrow key on the bottom left about 15 times to launch the options (btw, the screen with the app(s) you’re accessing is called the Microsoft Managed Home Screen). Depending on the app configuration for the managed home screen you may see “Logs” and/or “Exit Kiosk”.

2.  Select “Logs” and slide up on the Logs banner to expand

3.  Find the “deviceInfo” and tap the + until it expands

4.  Locate “serialNumber” and match it to the device serial number under “All devices” in the Intune admin portal. If you don’t see the “Serial Number” column select “Columns” at the top of the page and add “Serial Number” to the list.

Here’s a video showing the process in action:

7068B017-43B0-4070-BA94-3F8AD24A918F

In summary whether your organization manages 10 or even 1000’s of devices, having a simple method of identifying a physical device will save a lot of time during the process of troubleshooting.

To learn more about Android device enrollment with Intune please visit: https://docs.microsoft.com/en-us/intune/android-enroll

Use a QR code to point users to the Intune Company Portal app for enrollment

Use a QR code to point users to the Intune Company Portal app for enrollment

Quick post here, ever wonder how you can create a QR code that points to the Intune Company Portal in the iOS app store (or any app store), and paste it in an email and send it to your end users? Well it’s super easy to do. Simply search online for a QR code generator. Example: https://www.bing.com/search?q=qr%20code%20generator

When I searched for a QR code generator, a result came up inline of my search results and I pasted the URL that points to the Intune Company Portal in the Apple app store and it generated the QR code below.

If you’re interested, here’s the raw data behind the QR code:

Even better, the Intune Company Portal has 4.5 stars, hey that’s awesome!  Ok shameless plug, however it’s really cool to have such a high rating.

Anyway, theoretically you can do this for any app in an app store, whether they’re Microsoft Office apps, 3rd party apps, one of your published apps, etc.

To save you time, I generated QR codes that point to the Intune Company Portal (or enrollment URL in MacOS case) for all the platforms supported by Microsoft Intune:

iOS                                 Android

        

Windows Store            MacOS

        

Note: MacOS points to https://portal.manage.microsoft.com

Here’s an example email I manually created. Create your own by copying a QR code and generating your own custom emails using your corporate email application such as Outlook.  Your users will love it!  Plus it streamlines their enrollment process.

Here an example of using the built-in camera in iOS to scan the QR code.  As you can see it took me directly to the Intune Company Portal app in the Apple app store.

Intune_iOS_QRCode

 

If you’re intersted, for coporate owned devices Intune supports NFC, QR, and Zero Touch for Android Enterprise already, for more information please visit: https://docs.microsoft.com/en-us/intune/android-enroll

That’s it, I hope you find this valuable when directing your end users to enroll their devices with Microsoft Intune.

Intune, Azure AD, and Zscaler Private Access

Securing the perimeter has become increasingly difficult with more and more services moving to the cloud and users needing, no, expecting, access from their personal devices. The days of relying on the walls of a network to “trust” access are fading fast, and some would say they’re long gone. This is why organizations are using Microsoft technologies to build out zero trust networks where they rely on device and user claims to evaluate access to resource both on and off network. As I’ve written about in the past, security comes in layers, and zero trust encompasses many layers of security behind the scenes.

Over the past few years, Microsoft has worked with many security and management vendors to integrate with Microsoft Intune and other solutions in EMS such as Azure Active Directory.

The following list is just an example of the many technology partnerships Microsoft has in place today.

To keep up to date with Microsoft security partners please visit: https://www.microsoft.com/en-us/enterprise-mobility-security/microsoft-intune?rtc=1

For this month’s post I’ll focus on Intune, Azure Active Directory, as well as a Microsoft security partner, Zscaler, particularly Zscaler Private Access and its integration with Azure AD and Intune.

What is Zscaler Private Access?

According to Christopher Hines, Head of Product Marketing at Zscaler:

“The Zscaler Private Access (ZPA) service provides users with seamless and secure access to private applications without placing them on the network and without exposing apps to the internet. Allowing enterprises to embrace a software-defined perimeter that supports all private apps and environments.”

More details about Zscaler may be found by visiting: : https://help.zscaler.com/zpa/getting-started/what-zscaler-private-access

Before we get started, I want to give special thanks to the following individuals I collaborated with for this post:

    • Tyler Castaldo – Microsoft Program Manager – Intune
    • David Creedy – Senior Product Manager – Web Security
    • Christopher Hines – Head of Product Marketing – ZPA and Zscaler App

Let’s get started

Zscaler SSO Setup

First, we need to set up Zscaler with Azure so we can provide SSO as users access the app. Once the user accesses the the Zscaler App on their device, they’ll be passed through to Azure AD for sign-on.

Setting up Zscaler Private Access (ZPA) requires a few steps so I won’t go through them, however the steps are well documented here: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/zscalerprivateaccess-tutorial

In addition, Zscaler has also created their own documentation that may be referenced as well:

Adding Zscaler App to Intune for deployment

For this post I focus on iOS and Android. However, Zscaler is also supported on macOS and Windows 10 (more details at the bottom of this post).

After SSO is set up with Zscaler and Azure AD, we now need to add the Zscaler App to Intune for deployment.

Navigate to portal.azure.com or devicemanagement.microsoft.com and select “Client apps -> Apps”

Select “Add” then App Type and from the dropdown select iOS. Search for Zscaler and select “Zscaler App” as shown below. Add the app and assign it to a group for deployment.

For Android, repeat the steps above, however for the “App type” select “Android“. Use Managed Google Play in the console to search for Zscaler, then add and assign the app to a group for deployment.

Note: if you haven’t set up Managed Google Play with Intune yet, you will find details steps on how to do so by visiting: https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

When performing a search for “Zscaler” under apps in Intune you should see both assigned apps.

Configuring the Zscaler App using a VPN policy for iOS and app config for Android

Configuring Zscaler Private Access for iOS in Intune is straightforward as Intune has the settings available directly in the Intune adming portal UI as shown below.

Note: the “Organization’s cloud name” is case sensitive and FQDN and key/value pairs are optional, for more details please visit: https://docs.microsoft.com/en-us/intune/vpn-settings-ios#base-vpn-settings.

Select how the VPN will be launched:

Configure additional settings your organization requires to provide access to applications bridged by Zscaler:

For Android, we need to create an app configuration policy and assign it to the Zscaler App we added earlier.

https://docs.microsoft.com/en-us/intune/app-configuration-policies-use-android

Create an app configuration policy by navigating to “Client apps -> App configuration policies”

Select “Add”, provide the policy a name and from the “Device enrollment type” drop-down select “Android”.

Under “Associated app” select the Zscaler App added earlier.

Under “Configuration settings” select “Use configuration designer” from the drop-down and select all the options provided. Select ok to begin configuring the values.

Configure the values based on how your Zscaler environment is configured. In my case, my Zscaler environment is set up in Azure so I utilized the cloud name for the service in Azure as well as the domain my users log into. For username, I selected variable and chose “Partial UPN”.

Once all the settings are configured select “Ok” to complete the setup.

Note: you’ll notice the “deviceToken” value is set to “DummyValue”. This value isn’t needed when Azure AD is used as the identity provider (IdP), however it is needed in the profile, so just add it and type in whatever you like for the value. Also, please note the “Organization’s cloud name” is case sensitive.

After you’re finished with the app config policy, be sure to assign it to the same group you assigned the Zscaler App to.

Client experience

On first launch, the Zscaler App on iOS and/or Android it will redirect to sign-on using Azure AD, however subsequent launches of the Zscaler App will sign-in automatically.

Azure AD Conditional Access

To prevent access to an application Zscaler Private Access is securing access for, we need to create an Azure AD conditional access policy. The Azure AD Conditional Access policy will ensure the device and/or user meets compliance policies (e.g. Intune) before allowing access.

Navigate the Azure Active Directory in the Azure portal and select “Conditional Access”

Provide a name for the policy and under Cloud app add “Zscaler Private Access” and add the Zscaler cloud app used to access resources, i.e. the organization cloud name that points to the app we added earlier. The cloud app I utilize is called Zscaler ZSCloud as shown below.

Select the device platforms to target the Azure AD CA policy, since I’m focusing on iOS and Android in this post, I select iOS and Android from the devices platforms list.

Now grant access if the device is marked as compliant by Intune, enable the policy and save.

Note: additional conditions and access controls may be checked if needed.

If the device is compliant with Intune compliance policies, Zscaler will connect the user to the application. If the device isn’t compliant, Azure AD Conditional Access will block access to the application Zscaler provides access until the compliance issue is remediated.

Note: currently there is an issue with Conditional Access and Android Enterprise where the device is treated as not enrolled.  Zscaler is working through this and we’ll provide an update as soon as the issue is resolved.

Let’s see this in action

I’m testing with my Android device enrolled with Intune under Android Enterprise Device Owner as a fully managed device. The Zscaler Private Access (ZPA) App and ZPA App configuration is automatically deployed.

Intune_Zscaler.gif

Conclusion

In summary we learned how to set up Zscaler with Azure and provide SSO using Azure Active Directory. We also learned how to set up Zscaler Private Access App configuration and app deployment with Microsoft Intune. Finally, we learned how to set up an Azure Active Directory Conditional Access policy to further secure application access with Zscaler based on Intune device compliance.

I hope this post helps you and your organization further secure corporate applications, devices, users, and resources using Microsoft Intune, Azure Active Directory, and Zscaler Private Access. If you’re a Zscaler customer today, go out and give these steps a try.

Appendix

Information on setting up Zscaler for Windows and MacOS

Intune MacOS management capabilities

Back in 2015 I wrote a blog about Mac management with Intune, however it’s been a few years and I feel it’s time we re-visit Mac management with Intune to learn more about what’s changed. You’ll soon learn there’s been a significant amount of progress and since my first post Intune now has a lot of native Mac management capabilities built in.

First let’s look at MacOS enrollment options with Intune.

MacOS enrollment options

There are two methods to enroll MacOS with Intune, user driven or using Device Enrollment Program.

User driven enrollment

For user driven enrollment the end user will need to sign into the web based version of the company portal via https://portal.manage.microsoft.com

If the user already had a device registered it will show on the screen, if the Mac is the first device being enrolled, they will see the following:

Once the user selects “Add this one by tapping here” they’ll be prompted to download the Intune Company Portal app.

After the Company Portal is downloaded and installed, open it up and you’ll be asked to sign-in using your corporate credentials. These are the same credentials used to sign into Office 365 (derived from Azure AD).

After sign-in is complete the device will begin the enrollment process.

For more details on user driven Mac enrollment please visit: https://docs.microsoft.com/en-us/intune-user-help/enroll-your-device-in-intune-macos-cp

Apple Device Enrollment Program

The concept of the Apple DEP is to associate devices with an organization and to streamline the enrollment process, similar to enrolling Apple iOS devices. However, enrollment requires a different process by associating an Apple enrollment token with Intune. After the enrollment token is added and enrollment profile is created in Intune and associated with the enrollment token.

During the enrollment profile creation process you’ll be asked to select user affinity (i.e. userless or user associated). Once user affinity is selected, you’ll also select whether or not you’ll allow users to remove the enrollment profile via the “Locked enrollment” setting.  Finally, you’ll customize the setup assistance which allows for hiding setup screen, e.g. Apple Pay, Siri, Registration, etc.

For more details on the Apple enrollment token process with Intune please visit: https://docs.microsoft.com/en-us/intune/device-enrollment-program-enroll-macos

Conditional access

An exciting feature of Azure AD is the ability to target certain device platforms (e.g. MacOS) and set a series of conditions for access by creating conditional access policies in Azure AD.

Compliance

Azure AD and Intune compliance policies also play a role in access. Step through the compliance policies below to view the restrictions that may be enabled for the device to be compliant.

Device Health

System integrity protection prevents malicious apps from modifying protected files and folders.

Device Properties

Specify which OS version and builds you’ll allow before accessing corporate resources.

System Security

Configured password and password integrity, storage encryption, firewall, and gatekeeper to project against malware.

Actions to take for non-compliance

Take action when devices are not compliant with the compliance policy by sending the user a mail and/or locking the device.

Associating an Intune compliance policy with Azure AD conditional access policy

Create an Azure AD conditional access policy to require the device be compliant to access corporate resources.

Looking at device configuration for MacOS there are a number of settings, and in my opinion, those settings address a lot of organizations requirements for Apple Mac management.

Device features

Device restrictions








Endpoint protection

Looking to protect the device further by configuring the firewall and controlling where apps are installed from? Gatekeep will help with those requirements.


Further configure firewall settings to device what you’ll allow in and which apps are allowed and/or blocked.


Certificates

Intune supports PKCS certificates for general and S/MIME purposes.



Device and user-based certificates are both supported via SCEP


VPN

Many VPN settings are available including 3rd party VPN support.


Make note of On-demand and per-app VPN


Use a proxy server? No problem!


Wi-Fi

Both Basic and Enterprise Wi-Fi profiles are supported with various auth types.


Customize with Apple Configurator

Don’t see a setting in the UI, not to worry as you can create a custom profile using Apple Profile Manager and/or Apple Configurator and upload the payload for delivery through Intune.


App deployment

Both line of business and Office apps are supported right from the UI.


When selecting “Line-of-business app” the MacOS app must be wrapped using the app wrapping tool for Mac which will wrap the app and give it an extension of .intuneMac.

The tool is available on GitHub: https://github.com/msintuneappsdk/intune-app-wrapping-tool-mac

To learn more about Mac app deployment with Intune please visit: https://docs.microsoft.com/en-us/intune/lob-apps-macos

One of my peers Scott Duffey @Scottduf has a great post on this topic: https://blogs.technet.microsoft.com/microscott/deploying-apps-to-macs-using-microsoft-intune/

Note: as of this post only .pkg files are supported nor are conversions from .dmg to .pkg

Microsoft + Jamf partnership

Microsoft has also has a partnership with Jamf. Jamf also provides MacOS management and if your organization currently utilizes Jamf and would like to receive the benefits of integrating Jamf with Intune you can do this today with Jamf Pro. So, what does this mean?

MacOS devices managed by Jamf remain managed by Jamf when Intune comes into the picture (thus are only registered with Intune not enrolled) and integrating Jamf Pro with Intune provides a path for Jamf to send signals in the form of inventory to Intune. Intune will use compliance policies to evaluate the Jamf signals and in turn send signals over to Azure AD stating whether the device is compliant or not. The Azure AD conditional access policy will kick in and based on your configuration of the conditional access policy, will either block or further challenge the user to remediate before access company resources.

For more details about Intune and Jamf integration please visit: https://docs.microsoft.com/en-us/intune/conditional-access-integrate-jamf

Jamf also has a whitepaper about Intune integration: https://www.jamf.com/resources/technical-papers/integrating-with-microsoft-intune-to-enforce-compliance-on-macs/

That’s it for now, however Microsoft is always releasing updates for Intune.  Check back monthly with What’s new in Microsoft Intune and be sure to check which Intune features are under development by visiting: https://docs.microsoft.com/en-us/intune/in-development

Configuration Manager, Intune, and the Cloud – What’s your plan?

As I meet with organizations, I learn what their business goals are, what their end user goals are, and what their budgetary guidelines are. I also learn a lot about their endpoint management goals. What I’ve discovered is endpoint management has different meanings for each customer with a few common themes, user experience, simplification, and cost reduction.

The pace of change with technology is extremely rapid and organizations often struggle to keep up with all the updates across deployed technologies. When IT teams deploy technologies to help secure and simplify administration, they must provide evidence to the organization about the short- and long-term benefits of shifting to newer technologies, especially if they are duplicative of existing technologies. The evidence to rip and release a working solution is typically prioritized and is provided in the forms of cost reduction, end user benefits, and administrative simplification. Looking back in history, many would argue managing Windows in the enterprise has been a priority for most organizations. Many of these organizations today continue to manage Windows with a variety of technologies with one, (based on my interaction with hundreds of organizations) standing out the most, System Center Configuration Manager (ConfigMgr).

Configuration Manager has been around for a couple decades and for good reason, in my opinion it manages Windows best. For those familiar with ConfigMgr, you’re probably familiar with its history and the changes to the product over time. What I’ve seen is a blend of enhancing the client, infrastructure, and administrative experiences, including enhancements to reporting, management techniques, bandwidth controls, scale, performance, and more recently attaching Configuration Manager to the cloud. These advancements are critical to an ever-changing landscape of Windows computing and resource access.

Why write about this now?

There are a couple reasons:

  • Organizations are going through digital transformation and taking a hard look at existing endpoint management solutions.
  • Configuration Manager remains one of the most widely utilized endpoint management technologies across organizations today and I articulate the ongoing value of ConfigMgr in the content below.

Recently organizations have asked me the question if ConfigMgr is “dead” and my consistent answer is “no” is it not, ConfigMgr as of this post manages over 150 million endpoints, in fact there’s been continued investment in ConfigMgr year-over-year. Take a look at “What’s New in Configuration Manager” over the past several releases and you’ll see a growing list of exciting enhancements over each release.

You’ll also notice ConfigMgr has a release roughly every four months which provides a predicable release schedule for organizations needing to plan updates. Speaking of ConfigMgr updates, in console notifications of new releases provides an easy and informative method to update ConfigMgr to the next release by a click of a button. In addition, ConfigMgr technical previews allow organizations to test new features ahead of upgrading to the next service release of ConfigMgr. The servicing of ConfigMgr and technical previews are a win/win in my opinion.

I also receive questions such as “why stay with Configuration Manager, when I see Microsoft doubling down on efforts to enhance Intune toward feature parity?“. While partially true, there are clear advantages to continue utilizing ConfigMgr and leverage the cloud by cloud attaching ConfigMgr.

For example:

  • Preparing your infrastructure for cloud attach by extending ConfigMgr to Azure enables organizations to manage devices off the corporate network by utilizing Cloud Management Gateway .  By attaching ConfigMgr to the cloud, it allows organizations to simplify management of Windows devices and administrators will have the advantage of leveraging current processes built around endpoint management with ConfigMgr.
  • Organizations needing high availability in ConfigMgr can take advantage of site server high availability and SQL Always On.
  • Cloud attach Windows 10 clients to Intune by enabling co-management in ConfigMgr allows organizations to utilize ConfigMgr and Intune to manage Windows devices.  By enabling co-management, the organization benefits from the currently unparalleled strength of Configuration Manager as well as additional benefits cloud services such as Microsoft Intune and Azure Active Directory provide.
    For example, ConfigMgr client health will be reported directly to the device stats in Intune (shown below), remote actions may be initiated directly from the Intune admin console, as well as utilizing conditional access policies with Azure Active Directory to control access to company resources.

So why not move from ConfigMgr and manage all Windows devices with Intune?

Although managing devices may be viable for many modern management scenarios, there are scenarios where ConfigMgr remains as the preferred solution including:

  • Network controls for locations with low bandwidth
  • Down-level Windows 7/8 client management
  • Windows Server management
  • Devices that are network Air Gapped (isolated) and have no Internet access
  • OS deployment through network boot options
  • Complex application deployment scenarios
  • Third-party software updates
  • Etc.

Co-management provides methods for organizations running ConfigMgr to decide where they manage certain workloads. Currently, there are a number of workloads that may be managed by Intune when devices are co-managed, including:

  • Compliance policies
  • Device configuration
  • Endpoint Protection
  • Resource access policies
  • Client apps
  • Office Click-to-Run apps
  • Windows Update Policies

When utilizing co-management there are several advantages to utilizing Intune, for example in a co-managed scenario when moving “compliance policies” workload over to Intune, organizations can take advantage of Azure Active Directory Conditional Access. There are also immediate benefits of co-management such as executing remote actions directly from Intune including: Factory Reset, Selective Wipe, Device Restart, Fresh Start, etc. Intune compliance policies also play a significate role in controlling device health and access via Azure AD conditional access, for example Windows 10 compliance policies may require one or more of the following before accessing corporate resources:

  • Use a password to access devices
  • Encryption (e.g. BitLocker)
  • Firewall enabled
  • Installed Antivirus
  • Installed AntiSpyWare
  • Windows Defender version and signature is up-to-date
  • Minimum OS version required
  • Maximum OS version allowed
  • Valid operating system builds
  • Require the device to be at or under the Mobile Threat Defense level integrated with Windows Defender Advanced Threat Protection

Traditionally, setting up device health posture for an on-premises requires additional services and hardware such as a Network Access Control (NAC) solution. Whereas selecting workloads by enabling co-management for Intune to manage, organizations can take advantage of access controls delivered from Azure AD and Intune, including for on-premises web applications published through Azure AD Application Proxy. Not only is device health posture evaluated, additional access controls may be enabled including multi-factor authentication.

Below is an example of a device managed with ConfigMgr and Intune where compliance is reported back and shows in the ConfigMgr Software Center.

Intune Portal – shows compliant

Software Center – shows compliant (reported back from Intune)

Windows Deployment

Now let’s talk about Windows deployment options. Traditional deployment techniques for Windows typically involves an image that requires updating and then a system to publish those images so when a bare-metal boot takes place an image can be accessed, downloaded, and installed. OS image management can be a time-consuming process as it requires a human resource to manage and update the OS, drivers, apps, agents, etc. Some organizations offload OS image management to an OEM where the OEM preloads the image on the device, however the images still need to be maintained, and offloading to the OEM comes at a cost.

By leveraging Microsoft Intune and Azure Active Directory, organizations can take advantage of Windows Autopilot. Autopilot is very exciting as it eliminates the OS image management process which in turn can reduce IT costs. By pre-registering devices with Microsoft Intune when a user receives a device from the OEM, upon boot and connecting to the internet, the device will see that it’s registered with Microsoft Intune and go through the Autopilot process.

When organizations continue to utilize ConfigMgr, the CM agent can be pushed from Intune and the device now connects directly to ConfigMgr (when on corporate network) or through the Cloud Management Gateway giving your organization the confidence of maintaining current processes. Additionally, utilizing task sequences in ConfigMgr, Windows 7/8 devices may be upgraded to Windows 10 and automatically enabled for AutoPilot thereafter. The Windows 7/8 to 10 upgrade process may be pushed automatically or manually executed by end users (see screenshot below).

What about running scripts and installing software?

Both ConfigMgr and Intune support running PowerShell scripts and deploying Win32 applications, however for complex scripting scenarios such as running in task sequences and complex application deployments (i.e. deep app dependencies, etc.), ConfigMgr is unparalleled in this space.

My colleague Danny Guillory (who is also a PM on the Intune team) provided the following comments about Win32 applications and Intune:

Win32 App Deployment in Intune is a great way to get those .exe applications deployed and installed on those Windows Devices. The Win32 Wrapping Tool wraps all the files within that folder (think of a zipped folder), then distributes and deploys those files to the endpoints. The addition of detection method and delivery optimization makes Win32 app deployment more robust, simplifies distribution of content, and makes Win32 apps a must to explore with Intune Application Deployment.”

Additionally, MSIX is a new app packaging format that can take existing Win32 applications such as APP-V, MSI, .exe, etc. and package them in the new MSIX format. Many partners already support MSIX as well and for more details on MSIX packaging please visit: https://docs.microsoft.com/en-us/windows/msix/

If you’re looking to simplify application deployment both ConfigMgr and Intune provide the tools needed to deploy applications.

Monitoring and Reporting

Finally let’s talk about monitoring and reporting. ConfigMgr comes with hundreds of built-in reports, in addition there are newer monitoring and reporting capabilities with co-managed devices and a new reporting feature called CMPivot that provides real-time state of devices (see screenshot below). If you’re looking to creating dashboards based on ConfigMgr data, look into the Power BI template for ConfigMgr.

Next Steps

There are many Ignite sessions covering the topics in this post as well, to watch videos and learn more about the services and features discussed in this post please visit: https://www.microsoft.com/en-us/ignite search for “configuration manager”, “MSIX”, “Intune”

In conclusion, as organizations plan for the future of modernizing Windows management processes, my message to those organizations is to continue to leverage your current investments in ConfigMgr and keep current with releases. In parallel, begin to look at the benefits of cloud attaching ConfigMgr and/or managing workloads with Intune.

Outlook app configuration – contact field export control

Organizations utilizing the Outlook app on iOS and Android may desire granular control of app behavior such as only allowing certain contact fields to be sync’d with the native contacts app on iOS. Fortunately, Outlook settings are available to further control the Outlook app on iOS and Android.

I’ve worked with organizations who have strict data protection and GDPR requirements and utilizing Intune we were able to protect data from leaking from users’ corporate email to unmanaged apps and storage while allowing limited contact attributes sync’d to the local contacts app so caller ID will show for callers residing in contacts. Some of the restrictions are enforced by the platform (i.e. iOS/Android) while other restrictions are controlled at the app and device layer by Intune.

To learn more about app config with Outlook please visit: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/outlook-for-ios-and-android-configuration-with-microsoft-intune#configure-contact-field-sync-to-native-contacts-for-outlook-for-ios-and-android

As you walk through the settings make note of the “Device Enrollment Type” for each configuration setting, e.g. “Managed devices”, “Managed apps”. The device enrollment type corresponds to the Intune “Device enrollment type” setting when adding a configuration policy (see screenshot below). It’s important to understand the differences as there are different settings for different types of profiles and if settings are used for an unsupported profile type, they simply will not deploy to the app. In addition to the contacts settings, there are also account configuration, wearable, and iOS notification settings that can be configured as well.

Let get started

The following example demonstrates syncing only certain contact fields to the local contacts app so the end user will see the caller ID for a contacts for phone numbers when calls are received.

Navigate to the Intune admin portal and select “Client Apps > App configuration policies > Add”

Give the configuration policy a name and select “Managed apps” as the Device enrollment type as I’m pushing this policy via an App Protection Policy.

Select “Associated app” and select Outlook for the platform(s) you’re interested in configuring Outlook for. For “Managed Apps” I recommend using a single policy for iOS and Android to maintain consistency across platforms.

Add configuration settings to configure the app configuration settings for contacts in Outlook as shown below. These are key/value pairs and are documented here: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/outlook-for-ios-and-android-configuration-with-microsoft-intune#configure-contact-field-sync-to-native-contacts-for-outlook-for-ios-and-android

I’m only allowing first name, last name, and mobile phone number. If other phone fields are required such as home, office, other, you may want to allow those as well. Note: these fields match up to the existing fields in Outlook contacts and the native contacts app.

Assign the policy to a group of users:

Syncing contacts to the native contacts app

For contacts to show up in the native contacts app, users need to manually select “Save Contacts” in Outlook settings to sync contacts to their device.

Note: if you don’t see “Save Contacts” an Intune App Protection Policy may be blocking contacts sync. To check APP settings install and open the Edge browser and type in: about:intunehelp in the search box and view Intune app status for Outlook. If block contact sync is enabled, it will be set to “1” disabled will be set to “0”. Also, the “Save Contacts” setting cannot be set by policy at this time.

As shown below, only the fields specified in the Outlook configuration policy show up when the contact is accessed from the native contacts app. All other fields are blanked out. Even if I add the additional data to the fields, such as a phone number, the field will show up populated in the native contacts app then disappear when the policy refreshes (the update to the field will retain in Outlook though).

If you continue to see the fields that are blocked, try waiting a few minutes and disabling and re-enabling contact sync in Outlook.

Finally, when the email profile is removed from Outlook so are the sync’d contacts from the native contacts app.

Additional info

For MDM enrolled iOS devices, if contacts do not sync with the native contacts app after going through the steps above, because of certain Apple restrictions, you may need to toggle these settings to “Not configured”. There is a support post on this topic that is worth reading with additional tips: https://blogs.technet.microsoft.com/intunesupport/2018/04/17/support-tip-ios-11-3-and-native-contacts-app/

NFC-based Android Enterprise device enrollment with Microsoft Intune

I am pleased to have Chris Baldwin from Microsoft as a guest blogger this month. Chris is a Principal PM for Android on the Intune Engineering team. Chris has been working in Android space for the past couple years and leads delivery of Android Enterprise features.

NFC-based Android Enterprise device enrollment with Microsoft Intune – By Chris Baldwin, Principal PM, Microsoft Corporation

For corp-owned Android Enterprise devices (technically referred to as devices in “device owner” mode) there are a number of streamlined enrollment methods available. Depending on your Android version it’s possible to enroll devices with a QR code, by manually entering a short enrollment string, through Google’s Android zero-touch enrollment service (basically, Android’s answer to Apple’s Device Enrollment Program). It’s also possible to use NFC to perform enrollment, which makes provisioning devices as easy as tapping them on a specially formatted NFC tag. This blog will explain how you can use a couple inexpensive and readily available tools to program your own NFC tags to use for Intune device enrollment.

Android Enterprise for BYOD and corp-owned devices
There are two core ways to manage Android Enterprise devices depending on whether the device belongs personally to the end user of the device (BYOD) or if the device is corp-liable, an asset owned by your organization. Those modes are:

    • Work profile – in this mode of management the end user self-initiates enrollment with a device they own. The enrollment process creates a new, MDM-managed work profile on the device that sits alongside the user’s personal profile. The work profile is managed by the IT admin and the personal profile is not. This provides both privacy assurances to end users because their personal profile remains unmanaged, and data protection assurances to the IT admin because the work content is containerized and manageable.

 

  • Device owner – in this mode the device is fully managed (it is analogous to supervised mode on an iOS device). Device owner mode is unique in that there are two main deployment scenarios that can be configured when devices are in this mode: Dedicated devices, which are userless, heavily-locked down kiosk-style devices ideal for task worker usage, and Fully Managed devices which are associated with and user’s AAD account and are intended for core productivity usage (calling, messaging, Outlook, Office apps, and so on). Enrollment of device owner devices is also unique in that the device must be fully factory reset to be enrolled.

As of the writing of this blog, Intune supports work profile mode and the Dedicated (kiosk) device owner deployment scenario. Fully Managed support is currently being built and we expect it to be in public preview by the end of 2018, with general production support available in Q2 of 2019.

Why use NFC?
There are a couple reasons why using NFC-based enrollment might be useful for your scenario. First, it’s the only device owner enrollment mechanism that is supported on Android version 5.1. If you are using 6.0 and up there are additional options. Second, it’s very easy to use. You can program your NFC enrollment tag with Wi-Fi connection information, so you don’t need to perform any steps to enroll the device beyond tapping it. As a reminder, NFC enrollment is available on device owner devices only, and won’t work for work profiles.

What you’ll need
For NFC-based enrollment, you’ll need two items:

    1. Blank NFC tags. I used NTAG216 NFC tags, however you may use any tags that you’d like. One thing to remember is NFC cards come with varying amounts of capacity in bytes. You’ll want to be sure that you buy ones with enough byte capacity to store all the NFC data necessary for enrollment. The amount of capacity you’ll need varies depending on how many options you put into your NFC data, but at minimum you’ll need 561 bytes. More will be required if you add Wi-Fi connection options. The NTAG216 tags I used have a usable capacity of 888 bytes.

 

  1. Once you have the blank tags, you’ll need something to imprint/write the correct data onto the tags. You may use any NFC tool that you choose as long as it’s capable of writing NFC tags with an arbitrary mimetype. I demonstrate the process later in this post using the NFC Tools PRO app from the Play Store.

Steps to follow
Guidelines

  • The NFC data that will be written to the NFC tags needs to be of a very specific format and will contain a lot of boilerplate data.
  • There is a portion of the tag data that you can copy and paste directly from this post because it will be identical for every Intune enrollment.
  • There is also part of the tag data that must be changed to match the enrollment token generated in your Intune tenant.
  • Finally, there are optional NFC data parts that you can choose to use if you want to use the tag to automatically turn on Wi-Fi during the NFC provisioning process.

Step 1: Format your NFC data
Tag data that must be copy-pasted as-is
The following NFC data lines must be entered precisely as they appear here. These lines tell the device where to download the MDM agent from and ensure that it is installed properly:

android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION=https://play.google.com/managed/downloadManagingApp?identifier=setup
android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM=I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg
android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME=com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver

Tag data you must change for your tenant
The line below must be copied precisely as it appears, except you must change the highlighted text to match the enrollment token you want to use for the device enrollment. This should match the token text that is displayed in the Intune admin console. This is what will associate your NFC enrollment with your Intune tenant.

android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE=com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN=NMEFNXHOVYMEMSSLBRSR

Optional tags you can use for Wi-Fi connections
Optionally, you can use these lines to tell the device to automatically connect to a W-Fi network that it’ll use to perform enrollment. For example, these are the lines I used to connect to an open authentication network in my office called “MSFTGUEST”:

android.app.extra.PROVISIONING_WIFI_SSID=”MSFTGUEST”
android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE=NONE
android.app.extra.PROVISIONING_WIFI_PASSWORD=

Note: I have observed that the PROVISIONING_WIFI_PASSWORD line must be included even if there is no password required for the network. It seems like a quirk that shouldn’t be necessary, however I have seen devices fail provisioning without it. The valid options for security type are NONE, WPA, and WEP.

Step 2: Configure the app with the tag data
As a reminder, I’m using the NFC Tools PRO app to demonstrate the enrollment process, however you may use your tool of choice for writing NFC data.

  1. Under the Write tab, select Add a record
  2. Scroll to the bottom and select Data: Add custom record
  3. In the content-type field enter “application” in the first text box and then “com.android.managedprovisioning” in the second (without the quotes)

Take the all the tags above and put together to look like the following and past it into the data section of the app:

android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION=https://play.google.com/managed/downloadManagingApp?identifier=setup
android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM=I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg
android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME=com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver
android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE=com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN=LSKDINVIGHNCTXNZQDIS
android.app.extra.PROVISIONING_WIFI_SSID=”MSFTGUEST”
android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE=NONE
android.app.extra.PROVISIONING_WIFI_PASSWORD=
  1. In the Data: field enter the big NFC data blob that you formatted in the step above. It should look close to this:
  2. Tap OK

Step 3: Write your NFC data to the tags

  1. Tap Write
  2. Bump your device against your blank NFC tag

Step 4: Enroll devices!
Now that you have your properly formatted and programmed NFC tag from Step 3, the only thing left to do is to enroll devices. You can do this on any Android 5.1 or above device:

  1. Factory reset the device (this is a necessary step for any device owner provisioning)
  2. Once the device is reset and is on the initial welcome screen, bump the device against your NFC tag
  3. Tap OK

From this point on, the device will enroll into Intune using the enrollment token your specified in your NFC data. You can use the same NFC tag again and again to quickly bulk provision a large number of devices. If needed, you may reprogram the tags with different enrollment tokens as well.

Conclusion
NFC is one of the lesser known enrollment techniques for Android Enterprise, however it can also be one of the most powerful because of how easy it is to kick off device enrollment once you get the tags properly programmed. I hope you found this useful!