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.

Azure Information Protection… a log journey

 

Azure Information Protection (AIP) provides the ability to protect and classify information. For example, AIP policies can be created and used to classify, label, and protect data from leaking such as credit card numbers, social security numbers, or classify, label, and protect based off key words and so on.

For this post, I will not dive into details about how data protection, classification and labeling work, because there is already plenty of great documentation the teams at Microsoft provide out there on the web.  Rather I will focus on logging and reporting.  I’ll assume you’re already familiar with AIP or are using it today in some fashion.

If you’re interested in learning more about Azure Information Protection and what it can do for your organization, please visit: https://www.microsoft.com/en-us/cloud-platform/azure-information-protection

Within the Azure Information Protection umbrella we have a service called Azure Rights Management Services (Azure RMS). You’ll hear Azure Information Protection and Azure RMS terms interchanged, however I’ll stick with the term Azure RMS for the next section of the post.

 

Azure RMS

Azure RMS provides the ability to protect content, whether it’s an email or file.  Azure RMS templates which contain content permissions such as blocking printing, forwarding, editing, and much more.

To learn more about Azure RMS please visit: https://docs.microsoft.com/en-us/information-protection/understand-explore/what-is-azure-rms

I encourage everyone to read through the Azure RMS FAQ as well because it will answer most questions: https://docs.microsoft.com/en-us/information-protection/get-started/faqs-rms

 

Assuming you have Azure RMS set up and your users are protecting content, the next stage is to learn about how to access the Azure RMS logs.  Log entries are generated as users apply Azure RMS templates files, share protected content with users, and when users attempt to open Azure RMS protected content.

The following link does a very good job at walking through accessing Azure RMS log files: https://docs.microsoft.com/en-us/information-protection/deploy-use/log-analyze-usage

Once the logs are downloaded using the instructions provided in the previous link, use logparser (described within the link above) to consolidate the logs into a .CSV.

 

With a .CSV file full of Azure RMS log history we can create reports from it.  We can create tables within Excel or use a cloud service such as Microsoft Power BI to import the logs into to create reports and dashboards or utilize Microsoft Log Analytics to upload the logs to create dashboards as well (more on Log Analytics in the next section).

For example, I imported the .CSV file to Power BI and created a report that shows Azure RMS protected documents and who accessed them:

image

 

I also created a Power BI report showing who shares the most Azure RMS protected files:

image

 

Lastly, I created a report to view when and what files were protected and shared:

image

The options are endless using services such as Microsoft Power BI and you can get as creative as you’d like with reporting and dashboards.

 

Classification and Labeling

Classification and Labeling provides users the ability to classify and label content. To learn more about classification and labeling and how to install the client please visit: https://docs.microsoft.com/en-us/information-protection/understand-explore/what-is-information-protection

I encourage everyone to read through the Azure Information Protection FAQ as well because it will answer most questions: https://docs.microsoft.com/en-us/information-protection/get-started/faqs-infoprotect

 

With classification and labeling, logging is localized to the Windows device via event viewer. Logging events occur when a user changes the classification label, for example changing a document labeled as confidential to personal. The classification profile I have configured requires a justification for changing the classification label and that justification is also logged in event viewer. However, having logs localized to a device makes it difficult to create a centralized report typically used for auditing or monitoring purposes. So, we must get creative with centralizing logging and reports for classification.

 

Microsoft offers a service called Log Analytics (part of the Operations Management Suite or OMS) that will ingest logs from a variety of formats. Log Analytics is similar to a SIEM (Security Information and Event Management) system, some may even call it a SIEM.

To view more details on Log Analytics please visit: https://azure.microsoft.com/en-us/documentation/articles/log-analytics-overview/

 

Working with Log Analytics 

I have a Windows client where I downloaded the Log Analytics agent to (as well as has the Information Protection client installed). To download the Log Analytics agent, sign into https://www.microsoft.com/en-us/cloud-platform/operations-management-suite (create a trial if you don’t already have a subscription) and select the “Settings” cog on the left, then “Connected Sources” and download the version of the agent that aligns to your device (e.g. 32 or 64 bit).

image

 

Once the Log Analytics agent is downloaded to the Windows device with the classification client installed, install it and run through the wizard to register the device with the Log Analytics subscription.

 

After client installation and registration is complete, within Log Analytics select the “Settings” cog and then select “Data” and “Windows Event Logs”. Add the Windows event logs you wish to monitor using the “+” sign. The “Azure Information Protection” log will contain the Azure Information Protection (classification) events. 

Note: past events from Event Viewer will not be sent to Log Analytics, only new events that are created after the Log Analytics agent will.  This is important because if there were classification label changes that took place before the Log Analytics agent was installed they will not be sent to Log Analytics, only new events post Log Analytics client install will.

 

image

 

Once the Log Analytics logging configuration is completed, start creating events by changing the classification label in a document. Watch the video below for an example:

December 2016 Update – with the release of the new AIP Client, new event IDs are now logged in Event Viewer as well as other features (updated images below).  More details here: https://blogs.technet.microsoft.com/enterprisemobility/2016/12/07/azure-information-protection-december-preview-now-available/ 

AIP_EventLogging

 

Now that we have logs in event viewer (and the device is connected to Log Analytics), navigate to Log Analytics and query for all Azure Information Protection events as shown below:

image

image

image

 

Save the query, give it a name, and add the query to your dashboard for a more real-time view as shown below:

image

 

That’s all for now, I hope you find this useful when you’re looking to manage logs that Azure Information Protection creates as well as creating reports and dashboards for visibility and compliance.