Automatically renew Android enrollment tokens using Power Automate

This month’s post is a continuation of automation with Intune data using Power Automate and Graph. When managing Android devices utilizing Device Owner enrollment (i.e. Android Enterprise) there are options for enrollment, NFC, QR Code, and Zero Touch. Each enrollment option requires an enrollment token as well and those are displayed in the Microsoft Endpoint Manager (MEM) admin center. With Android Device Owner dedicated (i.e. kiosk) enrollments, MEM Intune provides the option to create enrollment profiles where each has their own enrollment token. Organizations may choose to create multiple profiles for various reasons, however enrollment profiles may be utilized to automatically to add devices to Azure AD dynamic groups. This makes management of devices and targeting policy/apps seamless.

One point of feedback I’ve received is about the token lifetime of 90 days for Device Owner dedicated enrollment profiles. When an enrollment token expires no new devices may be enrolled until the token lifetime is extended (existing enrolled devices are not impacted). Token extensions may be completed in the MEM admin center or through PowerShell. However, why not automate the process? This is exactly what I do in this month’s post.

Let’s get started

Requirements

  • Microsoft Endpoint Manager Intune
  • Microsoft Power Automate (aka Microsoft Flow)
  • Azure Active Directory

Description of the process

The process of renewing token when they near their expiration is as follows:

  1. Introduce a recurrence trigger where the Flow processes every day.
  2. Set a timeframe to look for when tokens are about to expire.
  3. Make a graph call through HTTP.
  4. Parse the JSON that comes from the output of the Graph call.
  5. Look for any tokens that expire within 10 days.
  6. If successful, extend the token for another 90 days.
  7. Make another Graph call and parse JSON to get the tokens that were extended.
  8. Send a notification of which tokens were extended to Teams.

Here is the entire Flow we’ll walk through:

Power Automate

Log into Power Automate, i.e. flow.microsoft.com and create a new Flow.

Scheduled run

Insert a Recurrence trigger and modify to run every day at a specific time.

Add to time

We need to set a timeframe for when the token is set to expire. I chose 10 days, and later on we’ll use this value to look and see if tokens are set to expire within 10 days.

Register an app with Azure AD

To make Graph calls we need to register an app in Azure AD and grant it the following delegated permissions: DeviceManagementConfiguration.ReadWrite.All

We can pull all the information to build the query from: https://docs.microsoft.com/en-us/graph/api/intune-androidforwork-androiddeviceownerenrollmentprofile-createtoken?view=graph-rest-beta

POST https://graph.microsoft.com/beta/deviceManagement/androidDeviceOwnerEnrollmentProfiles/{androidDeviceOwnerEnrollmentProfileId}/createToken

Content-type: application/json

Content-length: 35

{

“tokenValidityInSeconds”: 7776000

}

This API is under /beta and may change, please make note of this.

Add a Redirect URI, I pull this from the connector I created in a previous post:


Create a client secret to utilize in authentication:

Grant proper API permissions:


Use Graph to query for all Android enrollment tokens

Add an HTTP action and configure as shown in the image below. This is a GET method.

Refer to the Azure AD app registration completed in the previous step to fill in Client ID and Secret.

Add a Parse JSON action so we can utilize the values that come back in the GET method.

Choose the “Body” of the HTML action and for the Schema, make a Graph call using Graph Explorer by doing the following:

Add a Condition action (this will turn into a Apply to each automatically)

In the first field add tokenExpirationDateTime (this will trigger the Apply to each action) > is less than or equal to > in the second field add “Add to time” output from the action created in the beginning of this post:

Add an “And” in the condition and in the first field add tokenExpirationDateTime > is greater than or equal to > and in the second field choose utcNow() from Expression.

What the condition is doing is checking to see if the date of the token expiration falls within 10 days, if not do nothing, if yes, we extend the token with actions under “If yes” which I cover next.

Extending the Android enrollment token

The fist step if the condition is true is to update the tokens that expire within 10 days. I created a custom connector as this is a POST method and I found the best method is to create a connector with variables that are exposed in the connector I can add in.

To create a connector, in Power Automate expand Data and select Custom connectors and select new create from blank. I import from Postman and if you’re interested in how to do that, please refer my previous post on the topic.

Security tab

Use the same Client ID and secret from the Azure AD app registration step completed earlier. For the Resource URL, type in https://graph.microsoft.com (the redirect URL will auto generate once Update connector is selected, the URL should match what’s in the Azure AD app registration):

Definition tab

Add a “New action” and add some details as shown in the image below, the Operation ID is something you’ll make up:

For the Request, select import from sample, select POST, add in the URL below, and add in the JSON in the body and select Import:

https://graph.microsoft.com/beta/deviceManagement/androidDeviceOwnerEnrollmentProfiles/{ID}/createToken

We now have the parameters needed for the POST method (which will extend the token for x number of day, e.g. 90 days):

Select Update connector and test the connector by creating a new connection and filling in the blank fields with static data. ID will be the ID of a token.

Back in the Flow, add an action and select custom and choose the new connector. ID will be the ID from the JSON output and tokenValidityInSeconds is self-explanatory, 7776000 which translates to 90 days.

Next we want to validate the tokens that were extended by calling Graph. We do this by adding two actions, an HTTP action and a Parse JSON action.

The HTTP action is identical to the one we created earlier, however append it by adding the ID of the token from the dynamic content list. Use the same process for Parse JSON as we did in the previous step as well. This step will only pull the tokens that were extended.

Lastly I’d like to know when enrollment tokens were extended so I send messages to Teams.

The reason why we query for the tokens that were extended in the step above is because we need to utilize that output to populate the Teams messages.

I have a couple tokens I set to expire in 5 days (in fact you can set any expiration date within 90 days directly from the MEM admin center if needed. It’s good for testing as well.):

I ran the Flow and here are the results posted to Teams, however you can send to email, SMS, SharePoint, etc. if you prefer, just look for the diffrent templates in Power Automate:

And in the Intune console:

One last item

If you’d rather view and extend Tokens by hand in the UI, you can do so by selecting Filter then Inactive which shows all expired and active tokens.

That’s it, utilizing Power Automate and Microsoft Graph we have automated extending Android enrollment token expiration dates and posted the results to Teams.

Microsoft Endpoint Manager Intune, Power Automate, and Microsoft Graph

One of my passions is working with customers and I’m fortunate to be able to speak with customers every day. Another passion of mine is automating tasks. A piece of customer feedback I receive is how to automate certain processes using the data within Intune, Microsoft 365, and 3rd party services.  Currently organizations may automate programatically by using the Microsoft Graph, however if you’re not familiar with using PowerShell or a developer it may be difficult to create a solution in the timeframe you need it by. Fortunately, there are Intune Graph samples available and if you’re intersted in viewing and utilizing the samples please visit: https://github.com/microsoftgraph/powershell-intune-samples.

Additionally, and the goal of this post, Microsoft Power Automate provides a robust set of templates and connectors to automate processes across Microsoft 365 and many other solutions.

For this post, using Microsoft Graph and Power Automate, I have automated end user email notifications after an end user has enrolled a device. The Power Automate (aka Flow) runs every hour and will send a mail to the end user who enrolled the device within the hour (or timeframe of your choice) of the last time the Power Automate process ran. From a security and user awareness perspective, an organization may want to notify users after a device enrollment completes, and if it wasn’t the user who actually enrolled the device, they could report it to their security and MDM teams.

Let’s get started

Requirements

  • Azure Active directory
  • Intune
  • Power Automate
  • SharePoint Online
  • Postman

Azure Active Directory

Register an application in Azure and creating a Power Automate connector for Microsoft Graph

We need to do several things to register an app in Azure AD and create a Power Automate connector, however registering an app in Azure AD and granting it permissions is several steps as is creating a Power Automate connector (because I use Postman to create the auth flow and query to Graph then save it out and import it to Power Automate as a custom connector). So to keep this focused on the automation piece, I found an individual online who published the following video who has a great walk through of how to do this in the first 30 minutes: https://www.bing.com/videos/search?q=graph+api+microsoft+flow&docid=608006419082446884&mid=DDFFFEB586D6DA665B5DDDFFFEB586D6DA665B5D&view=detail&FORM=VIRE

I recommend going through the steps in the video above and supplementing the perms and Graph call with the following:

To access Graph in Power Automate we to register a new application in Azure Active Directory so we can use it to make Graph calls to Intune. Once the application is registered we need to provide it the following application permissions to access Intune device objects:

Note: I have more perms granted than needed for this particular process, however the three above should be enough:

We also need to create a client secret and save it for later use in Postman:

Postman and Graph Explorer

If you don’t have Postman you can download it from: https://www.postman.com/downloads/

Use Graph explorer to come up with the query you’d like to use by visiting: https://developer.microsoft.com/en-us/graph/graph-explorer For this post I’m pulling all the managed devices from Intune: https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/

For reference, here is the authorization for the Flow connector collection I created in Postman.

You’ll save the collection out and import as a custom connector in Power Automate. Refer to the video above and it walks you through all this minus the uniqness of my query and app.


SharePoint Online

We need a method to look up when the last time the Flow ran and to do this I store one list item in a SharePoint list. The item I store is just the date, however what I really care about is the created time the list item was created because I call that in the Flow and compare it to when the devices were last enrolled. For example, if the Flow ran on 2020-04-03T20:22:15Z, the date is stored in SharePoint and for any device registered after that time, an email will be sent to the end user. It’s a simple process, however it works well.

The following is my SharePoint Online list where I store a formatted date in the Title fiel, however it really doesn’t matter what is stored in the Title field as the Flow looks for the “created” date for the single item. After the flow completes, I have a process in Flow that deletes the record and adds a new one so the next time it runs it has new date to reference.


Power Automate

At this point you should have an app registered with Azure AD, a connector created in Power Automate, and a SharePoint list to reference.  Now we can move on to the next step.

Let’s create the Power Automate process now:

In Power Automate select Create, name it, and as the trigger select “Manually trigger a flow”. We need a trigger, and for testing I recommend creating the Power Automate process with a manual trigger. When you’re ready to go live, delete the trigger and replace it with the Recurrence trigger, more on this later.

Here’s the Flow in it’s entirety, however I break it down in the next few steps:

First step in the Flow, beyond the manual trigger, is pulling the item from the SharePoint list.  Do to this, add a new action and search for SharePoint the select “Get items”. I’m not doing anything special in Get items as I’m just looking for that one item in the list so there is no need to limit or filter items:

Next add another action, select “Custom” and select the connector you created earlier:

Now we need to parse the JSON that was returned from the custom action above. Do this by adding an action and search for Parse JSON, then add it. As you can see in the image below I have a perfectly formatted JSON output, however this needs to be generated. To do this select “Generate from sample” and go to either Graph explorer or Postman and copy all the JSON query output and paste into the sample payload.  Once you select done in the sample payload prompt, it will format properly and show something identical to what I have in the image below (provided you’re making the same Graph call).  You can also remove attributes from the JSON if you don’t want to show them in the dynamic content.

Next I want to select only devices that have a UPN because we can’t send email if there is no UPN to sent it to.  If the device record has a UPN and was created after the timestamp we stored in SharePoint, the user will receive a mail (sample mail shown later on in this post). To do this add an action and search for “Select” and add it. In the “From” field add the value from the Parse JSON step above, and in the Map section, select the txt icon on the far right then choose userPrincipleName from the dynamic list:

This next step is a cascade of actions so pay close attention please:

  • Add an “Apply to each” action and select the Parse JSON value (just like you did in the Select step above).
  • Now add an embeded “Apply to each” action and add the value from the SharePoint step above.

  • Add an embedded “Condition” action (this is where we compare dates), and in the first box find and select “created” from the SharePoint items and select “is less than” and in the far right box select “enrolledDateTime”:

What I’m doing is comparing the single item created date pulled from SharePoint to the enrollment dates pulled from Intune:

SharePoint item created date

Device enrollment dates

  • In the “If Yes” box, add an action, then search and add “Send an email (V2)”. Then select from the dynamic items to craft a mail. We don’t need anything for “If no”.

The next three steps in the Flow are fairly self-explanatory so I expanded them for reference:

What’s occurring  in the “Apply to each 2” is a SharePoint value is selected from the SharePoint Get items step, then I delete the item. Next step is up to you, all I’m doing is converting the current date/time then adding it to the Title field of a new SharePoint list item, however you can do what you want in the middle step, just make sure the last step creates a single SharePoint list item as the created date needs to be referenced in a previous step in this Flow.

Testing the Flow

Once the steps above are complete, run a test to create an item in SharePoint, then register a device and make sure it shows up in Intune under device, then run another test.  So you’ll run two tests, one to generate the SharePoint item, and other after the device is registered with Intune.

The following is the email Power Automate sends to the end user who enrolled the device:

When you’re ready to move this process into production, delete the manual trigger in the first step and replace it with the Recurrence trigger and run it on the interval that is best for your organization:

That’s it, we fully automated a process by using Power Automate to pull all enrolled device objects from Microsoft Intune, selecting only devices that have a UPN associated, and sending an email to end users who have enrolled their devices since the last time the Flow ran.

Microsoft Endpoint Manager, Debugging Android Devices

When managing devices at some point there will be some sort of issue that requires a deeper level of troubleshooting. Additionally, learning how to debug a device is not a bad thing, in fact anyone can do this. In this months post I dig into logging and debugging Android devices enrolled with Microsoft Endpoint Manager. There are several tools that can be utilized to troubleshoot Android devices and as with most troubleshooting, it’s a process of peeling back the layers until the issue is found and remediated.

Let’s get started!

Debugging Tools

For devices enrolled with Microsoft Endpoint Manager (MEM) I recommend starting with the Troubleshooting section within the MEM Intune console. It provides a consolidated view of policies, apps, compliance, and much more. Start with the troubleshooting console and work forward. If the troubleshooting information doesn’t reveal what you’re looking for we can head over to the device for direct troubleshooting.

Device Policy Controller (DPC)

There are various enrollment methods Goole offers for Android devices, such as Device Admin, Work Profile, and Device Owner. For the purposes of this post, I’m going to focus on Device Owner (Android Enterprise), however these methods may be applied to other enrollments as well.

When devices are enrolled with MEM they utilized what is called a Device Policy Controller (DPC). The DPC is automatically installed on the device during enrollment. Once enrolled, locate the DPC app by navigating to Google Play and selecting and opening the Android Device Policy app. From there you can sync the device and view which apps were installed and policy settings.

If you’re using the Managed Home Screen (as shown below), tap on the back arrow several times (ok 15 times) and on the menu select “Launch Android Device Policy app” which takes you to the DPC app where we can view and sync policy.

Note: the process above may not work (and probably doesn’t) for other EMMs who create their own DPCs.  The process is specifically for the CloudDPC Google provides for EMMs utilizing the Android Management API (which MEM does).  As such, contact Google to provide feedback about other debug features you may need in the CloudDPC.

Enable debugging in the DPC

I was poking around settings and I discovered a really helpful option for devices enrolled with MEM. Open the Android Device Policy app and select the three dots in the upper right hand corner > select device details > scroll down and look for “Model” and tap until debug items is enabled. Back arrow to the Device Policy screen and select the three dots in the upper right hand corner again, then check the box next to “All policies“.

You’ll now see all the policies deployed to the device from MEM including policy version, apps, settings, etc. This may be enough to work through issues, however if deeper investigation required read through the sections below.


Device debugging

We will need to do a few things to set up debugging, first we’ll need to enable debugging on the device and then install some tools provided by Google.

Enable developer options and USB debugging

  1. Under Settings search for “About phone” and tap > now find and tap “Build number” until is says “You are now a developer!”
  2. Next under Settings search for Developer and select developer options (System > Developer options) and is should show as On.
  3. Find and enable “USB debugging”
  4. Enable/disable settings you need to under the settings then connect to USB.


Android Debug Bridge (adb)

On a Windows, Mac, or Linux device navigate to https://developer.android.com/studio/command-line/adb and install the Android SDK Platform-Tools package.

Direct download link: https://developer.android.com/studio/releases/platform-tools.html


Log collection and debugging devices

Connect your device via USB (you can also connect via WiFi as well), open a cmd.exe window (I’m using Windows btw), navigate to the directory where the SDK was installed and type in adb.exe devices -l

If you receive an error, run the following commands:

adb kill-server

adb start-server

This should kick things off, assuming the device is enabled for debugging.

Another issue is debugging authorizations, if you run into issue here, do the following: Revoke USB debugging authorizations – when you attach this will prompt for authorization again otherwise you may receive “unathorized” in the command line

Run adb.exe devices -l again and you will see the following (in my case I have a Zebra attached):

List of devices attached

18359522505742 device product:TC57 model:TC57 device:TC57 transport_id:1

 

Collecting logs

Run the following commands to collect logs to be utilized in troubleshooting:

Logcat https://developer.android.com/studio/command-line/logcat

According to Google developer docs: “Logcat is a command-line tool that dumps a log of system messages, including stack traces when the device throws an error and messages that you have written from your app with the Log class.” Google also has a tool that developers may build to read app logs: https://developer.android.com/studio/debug/am-logcat

  • From the command line run: adb.exe logcat -v threadtime [device ID] > C:\temp\android.log

Bugreport https://developer.android.com/studio/debug/bug-report

According to Google developer docs: “A bug report contains device logs, stack traces, and other diagnostic information to help you find and fix bugs in your app.”

  • From the command line run: adb.exe bugreport c:\temp\bugreport.zip – open the file named “bugreport…….txt”   

    e.g. bugreport-TC57-01-12-01.00-OG-U16-STD-2020-02-18-07-39-37.txt

    I find the bugreport really useful, including when looking for device management settings.

     

Running queries using adb.exe

When devices are enrolled via Device Owner (Android Enterprise) most system and preinstalled apps will be hidden, however there are occasions where systems apps are critical to business functions, e.g. Zebra datawedge, so bringing those back is necessary.

Fortunately, you can whitelist system apps with MEM Intune by following the instructions listed here: https://docs.microsoft.com/en-us/intune/apps/apps-ae-system, however you may not know the app package name so having a way to look those up is necessary.

To list all apps installed on the device (hidden or not) run: adb shell pm list packages -s

Truncated example output:

package:com.android.calculator2

package:com.android.chrome

package:com.android.contacts

package:com.android.deskclock

package:com.android.dialer

package:com.android.providers.calendar

package:com.android.providers.contacts

package:com.symbol.batterymanager

package:com.symbol.rxlogger

package:com.symbol.rxloggerutility

package:com.symbol.scannerfirmwareupdate

package:com.symbol.ScreenShot

package:com.symbol.service

package:com.symbol.simulscan.res

package:com.symbol.tool.stagenow

package:com.symbol.zebrafolders

package:com.symbol.zebravolumecontrol

package:com.zebra.licensemgrservice

package:com.zebra.locationprerun

package:com.zebra.oemconfig

package:com.zebra.oeminfo

package:com.zebra.server

package:com.zebra.smartmu.service

package:com.zebra.zebracontentprovider

 

Use adb shell to interactively query

There may be situation where you will need to do some real-time queries and Google documents these here: https://developer.android.com/studio/command-line/dumpsys

For example, I can investigate the battery details by running: adb shell dumpsys battery – with the output I can see the date the battery was manufactured, which is useful in determining if a battery needs to be replaced.

According to Zebra docs, “A battery is considered to be decommissioned if the Health percentage of the battery is less than or equal to Percent Decommission Threshold.” Looking at the highlighted values below, looks like my battery is still good to go.

Current Battery Service state:

AC powered: false

USB powered: true

Wireless powered: false

Max charging current: 500000

Max charging voltage: 5000000

Charge counter: 6396244

status: 5

health: 2

present: true

level: 100

scale: 100

voltage: 4042

temperature: 210

technology: Li-ion

low temp shutdown level: -140

high temp shutdown level: 600

low battery level: 18

critical level: 10

shutdown level: 4

adjust shutdown level: 100

battery Type: 201

battery part number: BT-000314-01 R.E

battery serial number: T0738

battery Manufacture Date: 2018-11-17

rate capacity in mAh: 4050

decommission status of the battery: 0

base cumulative charge: 34079

battery error status: 0

battery charge cycle: 8

battery total cumulative charge in mAh: 35212

battery seconds since first use in secs: 31269629

battery present capacity: 3824

battery health percentage: 100

battery time to empty in secs: 65535

battery time to full in secs: 65535

battery present charge in mAh: 3821

battery percent decommission threshold: 80

SOC from external: 100

SOC from internal: 100

Temperature from external: 21

Temperature from internal: 210


Troubleshooting OEMConfig settings

If you’re interested in going deeper we can utilize the debug output (adb.exe bugreport c:\temp\bugreport.zip) to look at memory usage, apps status, settings, etc. For example, I set the time on my Zebra device using OEMConfig settings, however if there was an issue, I (or support) could use these logs to troubleshoot settings.

The following is the setting I pulled from a very long list of settings in the debug file where my policy successfully applied. Again, if there was an issue, I would simply find the setting and verify if it is set or not.

DUMP OF SERVICE settings:

_id:55 name:time_12_24 pkg:com.symbol.mxmf.csp.clock value:24 default:24 defaultSystemSet:true

Note: some Device OEM OEMConfig apps have policy/debug info builtin so you may not need to look at the logs, e.g. Samsung Knox Service Plugin.

Application troubleshooting

If you have an app that you’d like to test via Device Owner and Work Profile enrollments, using the Test DPC is helpful.

According to Google:
We provide the Test DPC app to help Android developers test their apps in an enterprise environment. Using Test DPC, you can set EMM policies or managed configuration values on a device—as if an organization managed the device using an EMM. Source https://developer.android.com/work/guide#testing

  • Connect the debugger and sideload the apps then install Test DPC to test app functionality.
  • Sideload app and see if it installs successfully
  • For app updates, the version code must be sequential and the signing cert must match

Google walks through how to provision devices using Test DPC here: https://developer.android.com/work/guide

Wrapping up

Debugging devices isn’t something you may do every day, however it’s useful to know and if needed the option is available.  Additionally, the MEM Intune app with Android Enterprise Device Owner enrollments has a button to send logs to Microsoft support so you may not need to do any debugging.  However if there is systemic issue occurring across multiple devices, debugging is a good in-house path to go down.

Managing Teams devices with MEM and Teams admin center

We’re now in 2020 and lots of has changed since Microsoft Ignite in November including a rebranding of endpoint management with Intune and Configuration Manager to Microsoft Endpoint Manager (MEM). Unifying the solutions under one brand is a major step to further unifying Microsoft endpoint management solutions.

You may be thinking, what happened to Intune and Configuration Manager? The good news is investments are continuing and even better news is where ever you’re at today with your Microsoft endpoint management solutions, Microsoft Endpoint Manager will meet you there. For example if you’re heavily invested in Configuration Manager, continue to utilize and and take advantage of the benefits of the cloud by cloud attaching Configuration Manger to the cloud (MEM Intune). Benefits include data sent from ConfigMgr to Intune for a single view of device information, Azure AD conditional access, and the ability to take action from Intune for ConfigMgr managed Windows client endpoints. Much more is on the way including user experience analytics, Autopilot updates, etc.

To learn about all the innovation and announcements for MEM, M365, and other Microsoft solutions please visit Microsoft Ignite and view sessions there: https://myignite.techcommunity.microsoft.com/sessions

I’ve been so busy the last couple months with travel, events, holidays, I have a backlog of blog posts I need to publish. As we start the new year I’ll start with managing Teams devices running Android with MEM and Teams admin center. As organizations move to Teams for communication and collaboration, Teams devices are also being deployed. As Teams devices are deployed, they naturally will need to be managed, that’s where Microsoft Endpoint Manager and the Teams admin center come in. To learn more about Teams devices please navigate to: https://products.office.com/en-us/microsoft-teams/across-devices

Let’s get started

For this post I utilize a Yealink T58A Teams device and enroll it with Microsoft Endpoint Manager. The setup process was extremely simple, however I’ll step through the process below.

Note: when these devices enroll they enroll under Device Admin not Android Enterprise (which isn’t supported at this time for Teams devices).

When the Yealink Teams device is powered on I’m presented with the sign in screen below.

Once I select Sign in I’m presented with the forms based sign-on from my IDP, in this case it’s Azure Active directory.

After I enter my password and sign in the MEM Company Portal processes joining the device to Azure AD and enrollment into MEM Intune as shown in the screenshots below:

Now that the registration and enrollment process is completed, I’m asked to select what type of account I’m utilizing, in this case I’m using a individual user account so I select “Personal”. If this were a shared device with a generic account I would have selected “Shared”.

With enrollment completed I’m now able to view settings, search the address book, and make calls.

Viewing Teams settings on the device

To access settings, tap settings then Company Portal. Here you can look at Teams version, report an issue, sign out, and access the Company Portal to view device compliance should there be compliance settings configured in MEM Intune.

Looks like my device is out of compliance and asking me to disable debugging, so I disabled debugging as suggested and am confirmed settings again.

Once the device is evaluated again against the MEM Intune compliance settings, my Teams device is now showing it’s compliant.

Microsoft Endpoint Manager admin console and Azure AD

Navigate to Azure AD and search for the device, my is shown below:

In Azure AD, selecting properties under the device show the following information:

In MEM admin center

Search for the device in MEM Intune, below you can see device info, including Android version, user name, as well as if the device is compliant or not.

Drilling down into the device settings we can see more details about the device.

Although we can see the Company Portal version on the device, as shown below, we can see the version in the console.

Microsoft Teams admin center

Next we need to navigate to the Teams admin center to manage the device settings, updates, etc. Do this by going to: https://admin.teams.microsoft.com/ then select Devices > Phones. Drilling down into the phone we see the following information about the Teams device.

It appears I need to update the Firmware and the Teams App and I can do this by selecting Update all and selecting items to be updated and either updating immediately or schedule the update to run at a later date and time.

Conclusion

That’s it for now, as you can see Teams devices provide a streamlined enrollment process by merely signing in. The processes reduces time to setup and rapid productivity for individuals who need communicate quickly.

Intune, Android Enterprise Device Owner enrollments & system apps

With Android Enterprise Device Owner enrollments, have you ever wondered where all the system apps go when enrolling with Android Enterprise Device Owner? Well they’re there, however they’re not whitelisted and only apps whitelisted by your admin are available (depending on the device OEM, there may be some system apps that are automatically whitelisted, e.g. phone dialer app).

The good news is with the Intune 1909 release, system apps may be whitelisted as well! An example of a system app is the dialer or some OEM specific app such as a battery monitoring app or barcode scanner app.

To bring back System Apps individually, you’ll need to know the package ID. For example, on my Zebra device I’d like to whitelist the battery manager app and the desktop clock. The package IDs for those are: com.symbol.batterymanager and com.android.deskclock

System apps may be whitelisted and assigned by navigating to the Intune admin portal, selecting Client apps > Add > App type = Android Enterprise system app

Provide a Name, publisher and package name and save.

Under Assignments, assign the app to the device group where the device lives. In my case I use a dynamic Azure AD group to assign Zebra devices that are enrolled as Device Owner Dedicated (aka kiosk).

If you’re utilizing the Managed Home Screen, for the app populate so user can launch it you’ll also need to publish the app to the Managed Home Screen profile under device configuration as shown below.

Search for the app name, e.g. battery, and add it.

Policy sync should only take a few seconds and on the device the battery manager is whitelisted and is available for users to access from the Managed Home Screen.

That’s it, it’s that simple. Again, system apps can be whitelisted now using Intune.

Additionally, Line of Business (LOB) apps and Web app links may also be published right from the console.

To learn more about managing Android devices with Intune by visiting: https://docs.microsoft.com/en-us/intune/

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!

 

Send Intune security task notifications to Microsoft Teams, email, etc. using Microsoft Flow

There’s a feature within Microsoft Defender Advanced Threat Protection (MDATP) and Microsoft Intune where MDATP security recommendations can be sent to Intune as a security task. This is helpful if security admins and MDM admins are separate and need to pass information for endpoint management teams to work on. Even if you work on a small team or are a one-person shop, sending security tasks to Intune provides a work item, so if you’re forgetful or get pulled in many directions, you’ll have a task sitting for you. For more details on this feature please visit: https://techcommunity.microsoft.com/t5/Enterprise-Mobility-Security/Microsoft-Intune-security-tasks-extend-Microsoft-Defender-ATP-s/ba-p/369857

The purpose of this post is to create a method to signal and/or alert that there is a new pending security task in Intune. Currently admins need to access the Intune console and check for tasks which is a manual process. I prefer automation and I created a Flow to post a message in a Teams channel and send an email about new, pending Intune tasks sent from WDATP. If you’re thinking, “I’m not a developer…” well the good news is, neither am I! I love Microsoft Flow because it makes creating workflows and automation easy (and I create a lot of Flows to automate tasks).

Let’s get started

Requirements

  • Microsoft Defender ATP
  • Microsoft Intune
  • Microsoft Flow
  • Microsoft Teams
  • A Windows 10 device enrolled with Intune and managed by Microsoft Defender ATP

Viewing a security recommendation and sending a task to remediate to Intune

Navigate to https://securitycenter.windows.com/tvm_dashboard (note if you don’t have a subscription or haven’t set up MDATP, you’ll need to do this first). Look at the Top security recommendation on the right and select one.

Here I see a list of security recommendations.

When “Update Chrome” is selected we can see the number of devices exposed and CVEs (Common Vulnerabilities and Exposures) the update will address.

Select “Remediation options”

Check the box next to “Open a ticket in Intune (for AAD joined devices)”, select a due date, and add notes if necessary.

When finished, select “Submit request”

Head over the devicemanagement.microsoft.com > Security baselines > Security tasks and there should be a pending task. In this case I have two that have a status = Pending.

Select a task and Assign or Reject it, however, don’t do this yet, because we want to get a notification of pending security task in Intune.

Notifications of new pending tasks

Now we know how to send a task from MDATP to Intune, however what would be better is to be informed a task is waiting for us to address, and to set up notifications I use Microsoft Flow.

Creating a new Flow

Navigate to https://flow.microsoft.com, select My flows from the left hand navigation and select New -> Instant-from blank. Give the Flow a name and select create.

Schedule the Flow to run

Search for the “Recurrence” trigger and add it to the beginning of the Flow. Populate the fields to meet your requirements. I set my schedule to kick off everyday at 8 AM mountain time.

Azure AD Authorization to call Graph

This process requires multiple steps so I’ll refer you to a couple sources that may be utilized to configure the authorization steps:

Query Graph

Search for and add the HTTP Flow action. Method = GET, URI = https://graph.microsoft.com/beta/deviceAppManagement/deviceAppManagementTasks

In the header I utilize the authorization info compiled in previous steps.

The next three Flow actions take the information from the graph call and parse it out based on the JSON schema

  1. Search for and add a Compose action and as the “Input” add the Body from the Http action above.
  2. Search for an add a Initialize variable action, Name = JSONObject, Type = Object, Value is the Value from the Compose 2 output in the previous action.
  1. Next we need to parse the JSON so we can select JSON fields to be added to an email and Teams posts. Search for an add a Parse JSON action, Content = JSONObject from the variable above the Parse action. The Schema is generated easily by going to Graph Explorer and querying Graph as shown below. Copy the JSON returned from the response preview pane and in the Parse JSON action, select “Use sample payload to generate schema” and past the JSON output and select done. This will construct your schema.
Use the JSON output from graph explorer (as shown below) to populate the sample payload to generate the schema.

Send to Teams and/or email

Here I walkthrough sending to Microsoft Teams; however, an email trigger is roughly the same process.

  1. Search for and add a “Apply to each” trigger, Select an output from previous steps = the value from the Parse JSON action above.
  2. I only want task with a status of “Pending” so I added a Condition trigger where search for a status equal to “pending”. The Status object comes from the JSON we parsed above.
    • If status of pending = yes, I send an email and post to Teams, if status is anything other than pending, the Flow terminates.
  3. Search for and add “Post a message” action. Search for the Team site, Channel, and then craft your message. More on this below.

The reason we need to add a schema and parse the JSON returned from the Graph call is so we can select the variables returned individually. Below is an example of the fields I selected for my messages sent to Teams.

Viewing Teams posts

The following is an example of an Intune Task sent to teams with the Flow constructed above. If there is more than one pending task, the Flow will post individual messages for each pending task (same goes for emails). As shown below, I happen to have two tasks that are pending, one to Update Chrome and the other to Update Windows 10, lucky me!

That’s it! If you’re utilizing Microsoft Defender ATP and Intune, integrate the two and start sending tasks to Intune today. Use Flow to schedule notifications and send to Microsoft Teams, email, or whatever method Microsoft Flow supports.

Additional References

Logic apps docs: https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-perform-data-operations#join-action

Use data operations with Microsoft Flow: https://docs.microsoft.com/en-us/flow/data-operations

Follow me on Twitter @mscloudinfa

Entire Flow