Zebra, OEMConfig, Ivanti Velocity, and Microsoft Intune

I work with a lot of organizations who manage a wide range of devices including organizations who manage rugged devices.

Rugged devices are utilized in a variety of scenarios, including warehouses, big box stores, field engineering, logistics, emergency services, government, and so on.  Typically, these devices are locked down in modes where it’s dedicated to a specific use case, such as inventory scanning. Some organizations deploy multiple apps to a locked down screen where those apps are used in specific scenarios such as inventory look up and/or data entry.

For this month’s post I’m focusing on a specific scenario I run into quite a bit with rugged devices and an app called Velocity (powered by Wavelink) by Ivanti.

According to the Ivanti Velocity user guide:

Ivanti Velocity is an Android client that can connect to Telnet hosts (including IBM 5250/3270 and VT100/220), web apps, and Oracle SIM hosts. For Telnet and Oracle SIM hosts, it can present applications to your users in a modern touch interface, either with automatic, predictive reformatting or with a customized experience.

Source: https://help.ivanti.com/wl/help/en_US/Velocity/2.0.0/admin/velocityConsoleHelp.htm

The Velocity app may downloaded directly from Ivanti and is found on Google Play: https://play.google.com/store/apps/details?id=com.wavelink.velocity

So naturally I was curious about managing the Ivanti Velocity app on an Android device managed with Microsoft Intune. For the device, I chose to utilize a Zebra TC-57 rugged device.

Requirements for this scenario

  • Microsoft Intune
  • Zebra device
  • Zebra OEMConfig powered by MX app from Google Play
  • Ivanti Velocity app from Google Play
  • Ivanti Velocity deployment bundle (.wldep file)

Special thanks to Alex Evans from Ivanti who supplied me with a demo deployment bundle, thanks Alex!

Let’s get started

Device enrollment
I chose to enroll my Zebra device as a dedicated device under Android Enterprise Device Owner enrollment. Fortunately, I posted on this already, so I don’t have to re-create the steps. To learn more about enrolling a device as a Dedicated (kiosk) device please visit: https://uem4all.com/2018/08/06/android-kiosk-enrollment-and-microsoft-intune/

Ivanti Velocity app deployment
Let’s add the Velocity app to Intune.

  1. Navigate to the Intune admin portal via https://devicemanagement.microsoft.com and select Client apps from the left hand navigation.
  2. Select Apps > Add > App type > Managed Google Play and search for “Ivanti Velocity” and should look something like the image below. Go ahead and approve the app and chose your approval settings when prompted, then save.
  3. After the app info has synchronized to Intune, assign the app to the device group you created you went through the device enrollment steps above. This will ensure the app is deployed to the device.

 

Intune Managed Home Screen config
After the Ivanti Velocity app is assigned, if it is a dedicated device, you’ll most likely be utilizing the Intune Managed Home Screen. Whether it’s a single- or multi-app add the app to the list so it’s available on the Managed Home Screen. Note: I covered this in the post I referenced above…

Once the apps are deployed to the Managed Home Screen you’ll see them populate. Again, assign the apps to device for installation purposes under “Client apps” and in addition, add the apps to the Managed Home Screen under device configuration, as shown above, so they’re available for users to launch and interact with.


Ivanti Velocity app configuration deployment
Next, we need to create an Intune profile to push the Ivanti Velocity deployment bundle to the device. For this I utilize Zebra OEMConfig, Zebra StageNow, and an FTP server to push the Ivanti Velocity deployment bundle to the device.

Oct 2019 UPDATE
Zebra OEMConfig now supports File Management.  Simply add the path to the source to the Source URI (ftp-p://username:password@0.0.0.0:21/Velocity_Demo.wldep) and the Destination Path and File Name will be /sdcard/com.wavelink.velocity/Your_Velocity_Bundle.wldep

2019-10-23_14-07-32

If you’re not familiar with OEMConfig please review my earlier post on the topic: https://uem4all.com/2019/07/09/intune-oemconfig/


With the Zebra OEMConfig now supporting File Management, the step below using StageNow is now optional and you would either use the step above or the one below, not both.

<Begin optional steps>
Let’s start with Zebra StageNow…

  1. Zebra StageNow is a Windows application and may be downloaded by visiting: https://www.zebra.com/us/en/products/software/mobile-computers/mobile-app-utilities/stagenow.html
  2. Open StageNow and create a new profile, select the proper MX version (e.g. MX 8.2) for your Zebra device, then select Xpert Mode and then Create.
  3. Give the profile a name and select Start
  4. From the Settings tab select FileMgr and select the + sign to add it under the CONFIG tab and select Add as shown in the example screenshot below.

  1. In the StageNow Config under File Action select Transfer/Copy File.
  2. Under Target Path and File Name add the following: /sdcard/com.wavelink.velocity/Your_Velocity_Bundle.wldep, this will add the .wldep file in a folder named com.wafelink.velocity on the device. The Velocity app knows to automatically look in that folder and apply the profile info in the bundle.

Note: you can rename the .wldep bundle to .zip to peek at the files if needed.

  1. Select File on a remote server if not already selected and select the … to open the dialog.
  2. Under Staging Server select “External” and for the Source Path and File Name add the ftp server info, Zebra has documented this well and can be viewed by visiting: http://techdocs.zebra.com/mx/filemgr/

The source path to my FTP server looks like the following: ftp-p://username:password@0.0.0.0:21/Velocity_Demo.wldep

  1. Once we’re finished with entering all the parameters select “Continue” until you see “Complete Profiles”.
  2. Select “Complete Profiles” and then select “Export for MDM” and save the .xml file.

Locate where you saved the .xml file and open it and it will look similar to xml output below. Copy the data beginning with <characteristic… to the last </characteristic> as outlined in red in the image below.

<End of Optional Steps>


Intune OEMConfig Configuration
Frist we need to add the Zebra OEMConfig app from Managed Google Play; to do that, from the Intune admin portal, select Client Apps > Apps > Add > App type > Managed Google Play and search for “Zebra oemconfig”.  It will look something like the images below.

Go ahead and approve the app and chose your approval settings when prompted, then save.

Note: Intune also supports Datalogic, Honeywell, and Samsung OEMCOnfig. If you’d like to test settings for OEMConfig with other OEMS, search Managed Google Play from Intune and add their specific OEMConfig apps. Stay tuned for Intune expanding support of additional vendors who offer OEMConfig.

Create OEMConfig profile in Intune
We now need to create an OEMConfig profile in Intune. Do this by selecting “Device configuration” in the Intune portal > Profiles > Create profile.

Give the profile a name, from Platform select Android Enterprise, from Profile Type select OEMConfig. From here select “Zebra OEMConfig powered by MX” app.

Intune_OEMConfig

Select Configure > select the three dots next to Transaction Steps > and then select Add setting.

From the list of settings select, Device Administration Configuration.


  1. Under Device Administration Configuration only two settings are required.
  2. Action = SubmitXML
  3. Submit XML = the .xml data we copied above. Paste it into this field.

     

    Note: If needed, switch to the JSON view to see what the full JSON looks like. JSON view is really helpful when troubleshooting as well.

     

  4. Select OK and Save.

When the device syncs with Intune the apps and the OEMConfig settings will deploy to the file and push the Velocity app config file to the directory we specified.


 

The following video displays the profile I deployed using Zebra OEMConfig from Microsoft Intune in the Velocity app.

 The Velocity profile was populated on the device in a folder called com.wavelink.velocity.  

Finally, the Velocity app automatically knows to look there so it’s added when the app is launched.  

Next I scan some bar codes using the app to show inventory and other data.  You can’t see it, however I’m actualy scanning those barcodes in the video.

2019-09-09_14-57-23

 

Couple if items to be aware of:

  • In the Intune admin console, device sync status for app deployment, policies, etc. will show as “pending”, this is known.
  • At this time, only one OEMConfig profile may be assigned to a device.

That’s it!  This is incredible… the Intune team has made monumental investments across device platforms supporting a variety of different scenarios, from rugged devices, information workers, and bring your own.

Stay tuned for future updates and posts about Intune right here on UEM4all.com!

 

Intune, Samsung Knox, and OEMConfig

I work with many organizations who are beginning to migrate from Android device admin enrollments to device owner (i.e. Android Enterprise). While migration to device owner requires a factory reset on the device, once enrolled with device owner, devices have a more standardized approach to management and consistency vs. the fragmented management experience device admin enrollments exhibit when multiple OEMs are being managed.

Realizing there was a need to standardize and secure devices beyond the device admin APIs, years back Samsung introduced Knox. Samsung Knox provides an additional set of security and management APIs built on top of Android and is included with many Samsung devices. EMMs, including Microsoft Intune, also took steps to integrate with Samsung Knox to provide a rich set of management capabilities where the device admin APIs didn’t cover (e.g. email profiles).

Google requires device OEMs wanting their devices to be Android Enterprise Recommended (AER) to meet certain requirements thus standardizing and provide consistency across the Android Enterprise device ecosystem.  However, Samsung Knox remains available and continues to provide security and management features, in some cases, beyond what Android Enterprise offers with their current set of APIs.  Although Android continues to update/add security and management features with every API version.

With Android device owner enrollments, Samsung and other OEMs support OEMConfig.  OEMConfig provides a set of OEM specific features EMMs can configure along with standard device settings.

What is OEMConfig?

“OEMConfig policies are a special type of device configuration policy very similar to app configuration policy. OEMConfig is a standard defined by the AppConfig community (opens another web site) that allows OEMs (original equipment manufacturers) and EMMs (enterprise mobility management) to build and support OEM-specific features in a standardized way. Historically, EMMs, such as Intune, manually build support for OEM-specific features after they’re introduced by the OEM. This approach leads to duplicated efforts and slow adoption.

With OEMConfig, an OEM creates a schema that defines OEM-specific management features. The OEM embeds the schema into an app, and then puts this app on Google Play. The EMM reads the schema from the app, and exposes the schema in the EMM administrator console. The console allows Intune administrators to configure the settings in the schema.

When the OEMConfig app is installed on a device, it can use the settings configured in the EMM administrator console to manage the device. Settings on the device are executed by the OEMConfig app, instead of an MDM agent built by the EMM.

When the OEM adds and improves management features, the OEM also updates the app in Google Play. As an administrator, you get these new features and updates (including fixes) without waiting for EMMs to include these updates.”

Source: https://docs.microsoft.com/en-us/intune/android-oem-configuration-overview

Although Samsung offers OEMConfig settings, some Samsung features/settings require a Samsung license, for more details please visit: https://www.samsungknox.com/en/blog/knox-platform-and-android-enterprise

Intune documention on OEMConfig may be found here: https://docs.microsoft.com/en-us/intune/android-oem-configuration-overview

Let’s get started with OEMConfig with Intune and a Samsung device

Samsung Knox Service Plugin

First, let’s add the Knox Service Plugin from the Managed Google Play store which is required to deploy OEMConfig policies to Samsung devices.

Assumptions: Intune is already connected to Managed Google Play, if it’s not you can find details on how to do this by visiting: https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

We’ll do this by navigating to https://devicemanagement.microsoft.com -> Client apps -> Apps -> Add -> App type = “Managed Google Play” -> select Managed Google Play Approve

To learn more about Samsung OEMConfig settings, browse through the Knox Service Plugin (KSP) admin guide: https://docs.samsungknox.com/knox-service-plugin/admin-guide/welcome.htm

Creating an OEMConfig profile for Samsung in Intune

Navigate to Device configuration -> Profiles -> Create profile -> add a name -> Platform = Android Enterprise -> Profile type = OEMConfig

Associated app = Knox Service Plugin – this is the app added in the previous step.

Select OK after selecting Knox Service Plugin.

After selecting OK we’re taken to Settings where we’ll see a full page of JSON. Don’t be intimidated it’s straight forward once you understand the structure which are just key/value pairs.

Update: as of the Intune 1907 release there is now a configuration designer with a UI, so no need to edit JSON.

2019-07-30_10-28-52

Continue reading for additional details about these settings and details about JSON if you prefer to edit manually:

Either select all and copy or select Download JSON template and open in your favorite text editor.

There are a couple values I want to point out in the JSON:

I mentioned at the beginning some Knox features/settings may require an additional Samsung license, this is where the license key would be set:

We want to turn on the policies, do this by setting doPoliciesIsControlled to “true

Troubleshooting – everyone likes an easy method to troubleshoot a device and by setting verboseMode to “true” will enable you to view the policies deployed to the device via the Knox Service Plugin app. More on this later in the post.

There many settings that are controlled with OEMConfig, however for the purposes of this post I’m going to turn off face recognition and only allow fingerprint. Disable face recognition by setting doPasswordBioFace to “false“.

Note: blocking the ability to use Face unlock to unlock the phone doesn’t prevent the device user from adding their face recognition. They just won’t be able to log in with face recognition as password and fingerprint are allowed in the OEMConfig.

Once you’ve completed filling out the JSON, copy and paste into Intune where you originally copied the JSON from and select OK then Save.

Note: you don’t have to have every key/value in the profile present, feel free to delete key/values from the JSON, just make sure the formatting is correct.

Device view

Once the policy is targeted to device it should only be a few seconds or so before the policy gets pushed to the device through Google services.

We can check if the policy deployed by opening the Knox Service Plugin app and selecting “Configuration on yyyy/mm/dd” (e.g. “Configuration on 2019/07/08”)

Select the “Configuration results” dropdown and select “Policies received” and from here we see the same JSON that was deployed from Intune.

Look for the password policy in the JSON as shown below:

On the same Samsung device navigate to Settings -> Biometrics and security -> Face recognition -> enter your password if prompted and we see “Face unlock” is disabled.  Again, we can add face recognition, however we can’t use it to unlock the device, so it’s essentially benign.

Here’s a video of the process above:

C02937BC-C8ED-4E0A-A3B2-3915A014D37A

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!