Does Intune’s new Azure Portal meet enterprise device management reporting needs?

mobile-business-users

In a previous blog we looked at several key considerations about how enterprise mobility reporting can ensure that devices are compliant, secure and functional. We posed many questions without really giving answers. In this blog we will look at the answers provided by the Azure Portal interfacing Microsoft EMS, aka Intune.

The bottom line is that Microsoft Azure Portal and its access software, Graph API, are primarily designed for operations management, where someone is looking at detailed information one device at a time and performing actions based on that information. It’s not surprising, then, that the tools have trouble scaling for enterprise device management reporting.

That said, Azure Portal is the second iteration of a management portal for Intune, and a huge improvement over the Silverlight-based portal. It is a solid tool for operations management, but some challenges remain for enterprise device reporting.

Great stuff with room to grow

The move to the new Azure Portal means that Graph API can access Intune data aided by a set of Microsoft-provided PowerShell sample scripts. As the tool under the “hood,” Graph API accesses the same live data as Azure Portal. The exported data provides a good base for an enterprise report, but because its purpose is operational management rather than enterprise reporting, it cannot be scheduled. However, it can be created ad hoc by someone with admin privileges in the Intune Azure Portal.

In addition, the Azure Portal contains “live” data, so if we create the same report five minutes apart, the details in the report will be different. Some devices, for instance, will have a new “last contact date” in the five minutes that lapsed since the initial report.

On the plus side, you can now export the “All Device” data view to Excel, as shown in the figure below. The option is labelled “Export all” and that’s exactly what it does. Azure Portal exports all data (36 fields, including serial number and email) from all devices. In the portal you can customize the fields displayed and filter the rows, and the report exports all of the fields – impressive, but a challenge if you have over 25,000 devices!

Intune reports in Azure Portal

Intune reports in Azure Portal

Reporting requirements vs. Intune

The improvements look promising, however, so let’s have a look at the following reporting requirements and how Intune stacks up:

  • Use only existing data — don’t collect anything new. As obvious as this requirement sounds, there are still areas where Enterprise clients will want Intune to provide data, and we use Azure Operations Management Suite (OMS) to accomplish that goal. Reporting on security compliance is one of those hot items that Microsoft promises to close soon. The gap is getting smaller. Intune is nearly there.
  • Use all available data collected about the service. Graph API can report on most data, as long as it is collected in Azure. If we need to provide some types of data, including license assignments, Intune falls short. It doesn’t answer the question, “Which user has a license assigned but isn’t using it?” In fact, Intune has no insight into data that sits in the customer’s back office. That’s not really an Intune problem though. If the data is important, it could be made available to a cloud-based reporting engine or combined with a cloud-based reporting engine using Power BI. I would give Intune a pass here . . . just about.
  • Data encrypted in situ and in transit and GDPR compliant. I have combined two requirements here. Microsoft Azure is compliant and provides us with means to create a compliant reporting engine. Of course, we can make a reporting tool that is not compliant, but why would we do that? Again, a definite pass.
  • Access to historic data. In operational reporting – for which Graph API and Intune Portal are designed — you are not really interested in historic data for comparison. So it is not surprising that Microsoft has another solution for that through the Intune Data Warehouse. We will discuss that in another blog. Possible with a workaround.
  • Supports automation (scheduled reporting). Report automation is a tricky requirement with Intune. Microsoft provides some examples of automation, and you need to run the report job from an online system using your credentials. With a small customization we were able to run the script “serverless” using Azure Automation. The modification enables us to say that Intune passes this requirement.
  • Scales to enterprise level (25k devices and above). Recently Microsoft asked its partners about usage of the old Silverlight portal. To our surprise some of our customers were still using the Silverlight portal because the new Azure portal runs out of steam more quickly. If you need reports for 25k devices, Azure might time out, but Silverlight might still give the answer – albeit after a long, patient wait.  If the portal doesn’t scale to meet your needs, what about Graph API? Graph API comes with warnings of bandwidth throttling and paging – it pages its answers by default to 100 records, but you can size it up to 999 records per request. Some information (advanced details) requires a “per device” request, which makes the process very slow and cumbersome. Challenging for scale to enterprise levels.

Our conclusion: Azure Portal has come a long way toward providing enterprise reporting, but still has some challenges if you have a very large enterprise-level operation.  Again, though, it’s not fair to look at these as limitations of the product itself, since we are using it here for something it is not intended.


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.

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 )

w

Connecting to %s

%d bloggers like this: