Ivanti Neurons for MDM: Best Practices for Supply Chain

There are a few different types of user accounts in Ivanti Neurons for MDM.

• An admin account. This is an account for someone to log in to the Ivanti Neurons Console and manage devices and configurations. It should always be a real person and a real email address.

• A default account (or device user account). This is an account that is tracked and associated with a device, but the user cannot log in to the Ivanti Neurons Console or manage other devices, apps, or configurations. This is the generally the type of account you want to use for enrolling devices. This does not need to be a monitored or real email address.

• An API user account. This allows another program to access the information in Ivanti Neurons for MDM using APIs. You should not associate devices with an API user account.

When you add devices to Ivanti Neurons for MDM, each device is associated with a user account. Depending on how you want to target devices, you can choose to have all the devices associated with just one account, or you can have different groups of devices each associated with their own account. We’ll talk about it more when we get to device targeting.

For now, let’s go through how to create an account manually:

1. Navigate to Users > Users.

2. Click Add > Single user.

3. Provide the email address and username for the account. The email addresses do not need to be associated with a real, monitored account if you’re just going to use them for device targeting.

Those are the only required fields, but you can provide additional information if the account is for a real person, or if you want to go ahead and add the user to a user group now.

In addition to creating an account manually, you can import user records from an LDAP server or a CSV file. See the Ivanti Neurons for MDM help for additional information.

Creating custom attributes (or properties) for devices allows you to use those attributes to assign devices to device groups or determine which policies or configurations get applied to which devices. Custom attributes could include things like location, warehouse ID, business unit, asset number, or whatever else you want to use to sort or identify devices.

You’ll use the custom attributes to determine things like which WiFi connection the device should use, or which devices receive a specific OEM config app.

You’ll want to create the custom attributes in the Ivanti Neurons for MDM Console before you import or provision the devices. Although you can assign the attributes to devices after they are added, it’s much easier to assign them during the bulk enrollment process, so we recommend creating custom attributes first.

To create global custom attributes:

1. Navigate to Admin > System > Attributes.

2. Click Add.

3. Provide a name for the attribute. And of course we’re creating a device attribute, so we’re going to leave that option set to device. The Usage field is not customizable, but it shows you how to refer to the attribute.

4. Click Add to add the attribute to the system list.

Once you’ve got the custom attributes created, let’s talk about how you can use attributes to target specific devices.

Device targeting is how you decide which devices get which settings. There are two ways you can target devices in Ivanti Neurons for MDM: device groups and user groups.

We've already briefly mentioned using custom attributes to create device groups. Device groups are based on the device attributes – either the system-defined attributes or the custom attributes that you made. For example, you may want all the truck-mounted devices to receive software that you don’t want on any other device. Use the custom property TruckMount, and then create a device group that only includes devices where TruckMount=yes. 

In addition to targeting device groups, you can also target a user or user group. For user targeting, each device is associated with a user account. You can use a single account for all the devices, or associate different lists of devices with different email accounts. Each device is associated with exactly one account, though. To send configurations to the device, target the user that the device is associated with. 

Let’s talk about a few ways you may structure things to make device targeting easier.

In our first scenario, I have a limited number of devices, say less than 100. When I do a bulk enrollment, I use the same account for all of the devices and then I use device attributes to create device groups to do all the targeting. In this scenario, I don't even have user groups.

If you’ve got more devices, this second scenario might work better for you. Here I have 3 different accounts, one for each of the 3 different locations I’m planning to manage. The devices at each location are associated with the account for that location when I create the device records. Then I can do user targeting for everything specific to location, and I use device groups for targeting specific types of hardware.

A third scenario might be to use even more specific email addresses. For example, each email address could be for a location AND a role. Create a user group for each location, and a user group for each role. Then use device groups for specialized device targeting.    

The degree of complexity you choose depends on what you need to do, but shifting some of the targeting to users rather than doing it all in device groups is an option you should consider before you start importing devices.

We’ve already talked about creating users, but let’s walk through creating a device group:

1. Navigate to Devices > Device groups.

2. Click Add.

3. Provide a Name for the group, and a description if desired.

   Ivanti Neurons for MDM has 2 types of device groups: dynamic and manual. In a manual device group, an administrator adds devices one by one and the devices are always in that group regardless of the device attributes. In a dynamic device group, devices are added based on the device attributes. If a device attribute changes, the groups that the device belongs to may also change. We’re going to focus on dynamic device groups.  

4. In this first dropdown, select the attribute. It can be a system-defined attribute, or one of the custom attributes that you created. Then decide what value of the attribute is going to define the group. This line is called a rule.

   If you want to use more than one rule to define a group, click the Add button to add another rule.

   When you have multiple rules, you can also decide if ALL of the rules must match for a device to be included, or if a device only needs to match one of the rules to be included.

   As you create the rules that define the group, the devices that currently match the rules are shown in the list at the bottom of the dialog box.

5. When you’re done, click Save. You can see on the Device Group page that the number of devices currently in the group are shown for each group.

After you have device groups created, they automatically update based on the devices’ current attributes. You can use the device groups to target specific devices for software, policies, or specific configurations.

There are a few things to be aware of before you start setting up apps. First off, if you are going to use kiosk mode on your devices, you’ll need to make sure the apps are added before you do the Lockdown and Kiosk configuration.

One of the things to decide is whether you want to use Velocity or other apps as an in-house app or directly from the Google Play Store. Generally, we recommend customers set up Velocity as an in-house app, but let’s go through some of the reasons why:

• If you have AOSP devices in your environment, then you need to set apps up as in-house.

• If you want control over the version of the app that is distributed to devices, set it up as in-house. There is some convenience to having apps auto-update from the Play Store, but most Supply Chain people prefer the change control that an in-house app setup provides.

• If you have the appropriate licenses and you want apps to auto-update each time the app releases, then the Play Store is a good fit for you.

For system apps like WebView, it's often not worth the effort to try and set it up as an in-house app. You can use a Managed Google Play configuration to limit when an app from the Play Store can be updated, though. For more information, see the Configurations and policies section.

In addition to deciding where the apps are hosted, you may also need to make decisions about how to distribute app configuration information. For example, in addition to installing Velocity, you need to configure it with the host profiles and settings you want to use.

There are also different methods for distributing configurations to devices using Ivanti Neurons for MDM:

• Use a server to host the config files and provide the client with a link to the files

• Use a File Transfer Payload to send the configuration files to the devices

The app developer can tell you which methods they support. For Velocity, we recommend using a File Transfer configuration to send the configuration files as long as the devices are fully managed. If the devices have work profiles or are COPE (corporate owned, personally enabled) devices, you'll need to host the config files on a server, instead.

The process you'll use to distribute apps to devices will be very similar for all applications, but we'll walk you through Velocity to give you an idea of how it works. In addition to distributing the Velocity app, we're also going to distribute the configuration profiles for Velocity. And that actually leads us to our first step. Before we even upload the app, we need to create an attribute to associate the configuration with the app.

Create an attribute

1. Inside Ivanti Neurons for MDM, navigate to Admin > System > Attributes.

2. Click Add.

3. Provide a name for the attribute and make sure the Attribute type is set to Device.

4. Set the Data Type to Text.

5. Highlight the attribute created in the Usage field and copy it to your clipboard.

6. Click Add.

Again, we’ll use this attribute to associate the File Transfer payload we create with the Velocity app.

Now that we have the attribute created, we can add Velocity to the App Catalog as an in-house app.

Add the Velocity app to the App Catalog

1. Download the .apk file from the Wavelink Downloads (www.wavelink.com/downloads) page.

2. Inside Ivanti Neurons for MDM, click Apps > App Catalog and click Add.

3. From the drop down menu in the top left, click In-House.

4. 4. Drag and drop the .apk file, or click Choose file and navigate to the file. Then click Next.

5. Specify the category for the app and click Next.

6. If you want, add screenshots of the app for your internal app store and click Next.

7. Click Next.

8. Determine which devices will receive the app. This is where the device and user targeting comes in handy. Since you already have that set up, this should be a nice easy step. When you’re done, click Next.

9. Now we’ll create the configurations for the app. For Managed Configurations on Android, click Add.

10. Provide a name for the configuration.

11. Expand the Fetch Configurations section and paste the attribute you created in the Manifest Info field.

12. For the Velocity License ID, select MAC address. Newer versions of Android restrict which apps can access the MAC address. When you use this option, it allows the Ivanti Neurons for MDM client to pass the MAC address to the Velocity client. Then the Velocity Client can use the MAC address as the device ID. This makes it easier to identify licensed devices when you’re looking at the License Server records.

13. Click Manage permissions and give Velocity permissions so that the user doesn’t need to, then click Select.

14. Click Next.

15. For Install on Device, click Add.

16. Provide a name for the configuration and select Device Installation configurations. Make sure Require installation on device is selected. If you have Zebra or Samsung KNOX devices in your environment, use the silently install option to get Velocity installed without any user interaction.

17. Use the options to control when the app can be installed if you have Android Enterprise. Otherwise, click Next to save the configuration.
    

After Velocity has been added to the app catalog and is ready to be distributed, we'll create a File Transfer payload to configure Velocity. To do that, we need the configuration files.

Create a File Transfer Configuration

1. From the Velocity Console, create the profiles you want available in the Velocity client. I've already got some created and deployed locally, so I'll create a zip file with all of the deployment files. You can have other file types, including text files, scripts, or images in here, but do not use folders inside the zip file. It needs to be a flat file structure.

2. Inside Ivanti Neurons for MDM, click Configurations.

3. Click Add and then select File Transfer.

4. Give the new configuration a name.

5. Browse to the zip file you created with the deployment files.

6. Make sure Transfer using Android managed app config is selected and paste the same attribute into the field. If you have a different set of deployment files in different File Transfer configurations, you can re-use the same attribute for all the configurations. Just remember that each device should only get one File Transfer payload.

7. In the App Names field, start typing Velocity and select it from the list that appears.

8. Click Next.

9. Determine which devices will receive the configuration. You'll probably use the same device targeting that you used for setting up the Velocity app.

10. Click Done.

After we have everything set up, the MDM client on the device downloads the app and File Transfer Payload, and sends the zipped configuration files to Velocity after it is installed. When Velocity is launched, it will have all the profiles you included in the File Transfer payload, and any profiles previously on the device (such as the demo profile) are removed.

OEM config apps are specific to the hardware manufacturer (such as Zebra or Honeywell) and give you options for configuring a device in addition to what an MDM can provide. The options and the option names vary by device manufacturer, though. Let's go through a few that you may find most useful.

Let's start with Zebra OEMConfig powered by MX.

After the app has been added to the App Catalog, click on the name of it. Then click App Configurations > Managed configurations for Android > Add. The configurations are inside the Transaction steps expander. If you want the settings applied in a specific order, create them in subsequent transaction steps by clicking Add to create a new step.

A few of the options in the Zebra OEMConfig app: 

•Power Configuration > Doze mode. Doze mode is a power-saving option where the device enters a mode with low power consumption. Only apps that are whitelisted can prevent the device from entering doze mode, so if you don't want to manage that list of devices, just turn Doze Mode off.

•Wireless LAN Configuration > Advanced options > Option pair > MAC address randomization. Use the custom name MACRandomization and a value of 0 to turn MAC randomization off. When you disable Mac address randomization, the device does not create random MAC addresses for the Wi-Fi adapter. This keeps the MAC address from changing and is especially useful if you are using the MAC address as the Velocity License ID.

•Service Binding Configuration. This allows you to configure TeamViewer. For additional information on TeamViewer, see the Additional Resources page.

In the Honeywell UEMConnect app, the options are in the Managed Configurations section.

•System Settings > Doze Mode. Doze mode for Honeywell is a similar power-saving option (including turning off the Wi-Fi) after a few minutes of idle time. The whitelist for this means that even after the device enters Doze mode, the apps continue to function and consume regular power. Again, we recommend just disabling this.

The Datalogic OEMConfig app does not have a Doze mode setting, but you may want to take a look at all of the scanner settings.

As you can see, the options available are different for each hardware manufacturer. You'll need to do some exploration to find the settings you need specific to the hardware in your environment.

Configurations and policies are ways to configure a device. A configuration is generally a collection of settings for a device, and a policy creates requirements for how the device can behave. You’ll have specific needs for the policies in your environment, so we’re not going to cover policies as part of this best practices series. We can make a few recommendations for configurations, though.

Some of the configurations are fairly simple, and others are more complex. Let's start with some of the simple ones.

Open the configurations by navigating to Configurations, click Add, and then select the type of configuration you want to create.

Managed Google Play

While we generally recommend setting apps up as in-house, there may be some apps that you want to distribute through the Google Play store instead. For those apps, or for apps that are installed on the device by default (such as Android WebView), you can still control when the app updates to a new version using a Managed Google Play configuration. You can set apps to update only during a specific window of time, only over Wi-Fi, never, or always.

For example, some of the ways you could use this are: 

•If you set this configuration to None, then by default, no apps would update from the Google Play store. Then on an app-by-app basis, configure the apps that you want to update regularly separately.

•For apps that are mission-critical, you may want to have a test group update regularly, while most devices are set to not update. Then after the test group verifies that the update is successful, you can change the configuration for the other devices and allow them to update.

If you configure the settings in a general configuration and for a specific app, the app configuration is used.

Default app runtime permissions

The Default app runtime permissions are useful to grant apps permissions without prompting the user. This particular configuration would grant permissions to all apps that requested them. If you’d prefer to grant the permissions on a per-app basis (like we did when we configured Velocity), you can do that during the app configuration step.

Wi-Fi

A Wi-Fi configuration provides the device with the Wi-Fi SSID and security information. I’m sure you can see how useful that is, so we're not going to spend much time on it – just point it out so you can use it.

System Update

A System Update configuration gives you control over the OS update process. This is especially useful if you have Zebra devices with LifeGuard for Android – you can update to specific versions of the OS over the air. It also gives you control over when the OS update downloads and installs. Prompt the user and allow them to postpone the update, restrict it to only happen when the device is idle or charging, or create a schedule for when it is allowed to install. 

(As a quick note, in order to use the Zebra OS updates, you’ll need to navigate to Admin > Firmware management > Zebra OTA and provide your Zebra credentials.)

Lockdown and Kiosk: Android Enterprise

A Lockdown and Kiosk configuration applies restrictions to the ways that the device can be used. Restrict the device to specific apps and use your own branding, even. (To create a branding style, navigate to Admin > Branding > Android Kiosk. After you’ve created the branding, it shows up in the Kiosk Branding dropdown back in the configuration.) You need to set up apps before you can select the apps you want the user to have access to. If an app needs to be able to run but you don’t want the icon in the kiosk launcher, add it to the list and then click this eye to hide it.

Adding an app to the kiosk list doesn’t actually install it – you’ll still need to deploy the app.

AOSP

If you have devices that do not have Google managed services (like the Play Store), you may want to configure AOSP settings.

Configurations to disable

And finally, there are a few default configurations that you probably want to turn off or set to No Devices. If you are using corporate BYOD, you may want these on still, but for many Supply Chain customers, they are not a good fit. Search for "work profile" in the existing configurations and you'll see the Android enterprise: Work Profile (Android for Work) and the Android enterprise: Managed Device with Work Profile/Work Profile on Company Owned device configurations. Set those so that they are not distributed to devices.

Bulk enrollment is going to be the simplest way for Supply Chain users to enroll devices in Ivanti Neurons for MDM. For bulk enrollment, you upload a CSV with a list of devices. The bulk enrollment profile generates a token, and then each device in the CSV uses the token to enroll.

Remember, each device must be associated with an account. Since the bulk enrollment process associates a device with an account, you must create the accounts before you begin the bulk enrollment process.

Each CSV is associated with one account, so if you are planning to use multiple accounts for user targeting, create one CSV file for each account.

It will be easiest to create the csv file if you download a template first. Navigate to Devices > Bulk Enrollment and click Add. Click Download CSV template to download a file that has a header row and an example row. When you create your CSV file, put each device on one line, and include at least 2 of these 3 properties for each device:

IMEI, Manufacturer, Serial number

For each line, you can also include custom attributes for the device. The attributes should already be created in the system before you upload the CSV. If you provide multiple custom attributes for a device, separate them with semicolons. When the device record is created, the attributes are applied to the device. You can always apply the attributes later on a device-by-device basis, but bulk enrollment is the best way to apply those custom attributes to a bunch of devices all at the same time.

After you’ve got all the device records in the CSV file, upload it to create the bulk enrollment record.

1. Navigate to Devices > Bulk enrollment.

2. Click Add.

3. Provide a name for the bulk enrollment profile and upload the CSV. Then click Next.

4. Provide the account that you want the devices associated with and click Save.

If you want to add devices after the CSV has been uploaded, click Actions > Add more devices and add the devices one by one. Again, you must have at least 2 of the 3 properties required for the device record to be created.

The token at the top of the screen is an identifier associated with the devices. It's built into a QR code that you can scan with your devices to enroll them.

For information on provisioning, see Device Registration or the links on the Additional resources page.