The key questions and considerations of enterprise mobility reporting

Enterprise reporting for mobility services involves considerably more than knowing the number of devices in use. In fact, a view into a range of details is critical to enterprise security and workplace effectiveness.

The ultimate goal of mobile device management (MDM) is safe, secure handling of corporate data by device users, and enterprise reporting for mobility should reflect that goal. We don’t want to know that Joe Blog’s iPhone was used yesterday in Walmart, but we do want to know if it is compliant, secure and functional.

In an enterprise report, we are not looking at details of a specific device – those details support the day-to-day management and operations of the service — but we are looking for service health and service consumption indicators. Ideally, we want to get data from all devices that “touch” our infrastructure. The management service is a means to protect corporate data, and we want to know about any device that connects, not just the managed ones.

In a small rollout we may know all of the mobile users and can anticipate their problems or risks. But when the number of managed devices grows, we lose visibility into the devices and the users. With a global rollout of thousands of devices, the small percentage of devices that are not compliant or have problems becomes a sizeable number. You may need to know how many of these problem devices have been retired and how many have the latest patched operating system.

The report in Figure 1 shows 232 non-compliant devices out of a total of 40k devices. When we only had 400 devices under management, there were only two non-compliant devices. We could easily catch the two culprits when they walked into the office. But with 232 culprits, we need a different process. The process starts with defining what we need to know.

Sample report for mobility service consumption

Figure 1: Sample report for mobility service consumption

What we need to know

To effectively manage a large number of devices, we need reports on the number of available and assigned licenses for Microsoft Enterprise Mobility & Security (EMS) and other mobility-related tools. We need proof that the assigned licenses are really used – because that’s what we are paying for. Some enterprise customers may even want to break these reports down by business unit or location.

Here’s what we need to ask to start with:

  • How many devices are under management and how many are not managed?
  • How many devices are compliant with corporate requirements and how many are not, and therefore pose a data risk?
  • What is the breakdown by owner type (BYO, corporate personal enabled, corporate shared, corporate kiosk)?
  • How old are the corporate devices in use? When do they require replacement?
  • How much change was there over the last month (new devices, new enrollments, removed devices, lost/stolen devices)?
  • How many incidents were logged with the service desk regarding the mobile devices? What is the cost of repairs and device downtime?

With all this data you need some guidance as to what is acceptable: Is the number of non-compliant devices improving? What did the service look like last month compared to today? Figure 1 gives a sample report with some key service parameters and compares the latest numbers (February 2018) with previous months.

How to use the data

For the reporting service, we do not want to add a data collection agent to the devices, but rather reuse data collected by existing services. When a device is used, it talks with the back office, with Active Directory, with the device management service EMS and, most importantly, with the Microsoft Exchange server. (See Figure 2.) Every interaction leaves fingerprints in log files, and we can use these log files for reports. This way, happily, the reporting service has zero impact on the user.

Data flow from collection from a managed device in EMS till reporting

Figure 2: Data flow from collection from a managed device in EMS until reporting

At the same time, we want to use all available data to define the service health. For instance, if we want to know if a device is still in use, the back-office logs may be more reliable than the EMS logs. We also have security matters to consider — at a minimum we want all data encrypted both in situ and in transit. Do we need to obfuscate personally identifiable information (PII) data? Does the process scale to more than 25,000 devices, for instance?  Do we have access to historic data so we can compare today’s service with last month’s? Can we easily remove PII historic data so that we can be GDPR compliant?

If we look at the process of creating the report, we have even more questions:

  • Can we set (and forget) the report creation, so that when the admin is on extended leave or sick leave, the report is still created?
  • Can we have the report both scheduled (for the first Monday of the month, for example) and ad hoc?
  • Can the report run fully automated, without user interaction?
  • Do we need to have admin privileges to run the report, or can a normal (or reporting service account) suffice?
  • Is the password for these accounts exposed?

And finally, we want the report to be repeatable. If two people create a report, the results should be the same. Ideally, we also want to give management the right to go in and have a look at the service performance whenever they want. They should not be able to see data related to the day-to day-service operations, but instead should receive a report with the appropriate management summary — a clear snapshot of the service health.

Ideal or real?

Does a reporting tool like this really exist? How does your service compare? Even the example for reporting I gave in Figure 1 still has scope for improvement!


Ben Santing headshotBen Santing is a DXC Technologist for Workplace and Mobility. He focuses on transforming cutting-edge technology into services for enterprise customers that provide business critical functions. His interest in the bigger picture is matched by technical skills that include Windows NT MCSE, ITIL V3 expert, IT Strategy and Architecture certificate, Azure EMS MCP, and are demonstrated in knowledge briefs and white papers. He held a variety of architecture and engineering positions within DXC Workplace and Mobility before becoming a lead architect for DXC Device as a Service and DXC Business Insight for Mobility. Ben lives in the Republic of Ireland, but originates from the Netherlands.

Trackbacks

  1. […] a previous blog we looked at several key considerations about how enterprise mobility reporting can ensure that devices are compliant, secure and […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: