Finally the long awaited (multi) Device query (MDQ) arrived by the end of February. Time to have a look at it again, as we already have tested it during the private preview.

The PG already did a lot of work based on the feedback of the participants, but one thing I directly notice and miss is the ability to export data or to be able to use it outside the query area in some other form.

And thing of course, is the 50000 limit of the query, which for bigger companies will be an issue. 

Since I use our Log Analytics data on a daily basis, I am curious about MDQ.  

So, let’s look at some testing I did over the last 3 weeks. 

Device entity

A good thing to know, were I ran it to, is  the fact the Device entity is a linked object and implicitly part of all other entities. So, there is no need to join, and when you do, you will get a syntax error.

So, this query, which looks to be a valid query, will give a syntax error!

But, the funny enough you can do the join the other way around!

Of course the join is not needed, as the Device info is already part of the Memory entity.

Also the Device entity is based on EntraID devices, but it also complies to the Intune RBAC setup and only shows the devices with the scope tag of the role the admin is in. Funny thing is, also devices not enrolled into Intune yet, but only registered in Autopilot, are displayed in this way.

Functionality

Like, as mention before, the option to export and/or use the data outside the query area is a big must have. Next to the options to sort and filter in the result instead of doing that in the query.

Extending the limit of 50000 would also be needed. Or, just as in Log Analytics where the limit is 30000, provide options to the query in Excel or PowerBi to get more results.

Other options that would make sense:

  • Use the query in other area's in Intune, like for instance in filters. How great would it be to assign lets say specific power settings on to devices where battery is below a specified threshold.
  • An option to save the queries, so they can be re-used by other admins.
  • Use the data together with data in our Log Analytics workspace, which we heavily use (Intune logs, Event logs, Custom Inventories, etc.)

Data

Looking at the Device entity, it would be great if the enrolment status and RBAC info (OrderId /Group Tag or Scope Tags) could be added to the dataset. Should not be to hard as the OrderId is part of the EntraID device object.

The NetworkAdapter entity or actually the inventory should change, so it would have useful data like adapter vendor and model, driver version, MAC address, etc. Same goes for the VideoController entity, which already has some useful data but can be enriched with driver info.

Looking at addition data, it would very helpful when we would be able to have an option to configure and collect specific registry keys.

Query 

One of the operators I use a lot is let, to create a temporary table, in combination with either join or has-any(). This is helpful in cases where you have a issue on a number of devices and you want to get data to compare the properties of the devices (OSVersion, Model, Location, etc.).

Like this example from Log Analytics, which gives me back the data on the 7 devices I have asked for.

Also the option to render, so you could have a chart of the result, will be very helpful. 

Like this example from Log Analytics, showing a piechart of the count of Bios Version of a specific model.


Conclusion

In my opinion MDQ has a lot of potential to become a great and powerfull feature you can use in you day-to-day work, but more functionality, query options and data needs to be added to be useful.

For large organisations the feature currently doesn’t add value. So, we still need the inventories we have setup in Log Analytics based on great community examples.

 

Comments

Post a Comment

Popular posts from this blog

Why pre-provision Windows devices?

Image
Recently I was asked again; “Why do you pre-provision devices?” I, or actually we, got that question several times last year. Also, in conversations with Microsoft this question pops up regularly. So, why do we pre-provision (aka. White Glove) devices? There are two main reasons to do this: Security Employee Experience And in addition, of course, the costs. Security Looking at security, by pre-provisioning devices we make sure we block things like Shift-F10, the Recovery Command prompt, etc. and to have the security policies applied before we hand the device over to the employee. Employee Experience Pre-provisioning devices will limit the time the employee needs to enroll the device to around 15 mins, with all applications installed on the device when the employee gets the desktop. As part of the pre-provisioning process, we make sure: The drivers and firmware are updated to the latest version before pre-provisioning. All core applications are installed as part of pre-provisioning....
Read more

How to do phased deployments in a cloud native world?

Image
   Back in the days when we had SCCM, we could easily setup phased deployments. In a cloud native world these controls are missing, but  we can create phased deployments based (dynamic) groups.  In this blog post I will show you how to set it up and use it. Groups First of we need to create groups that contains the devices for each phase. You can of course fill those groups manually, but in larger environments Dynamic Groups will be a better option. We will use the first character of the DeviceId in our dynamic query to select the devices per group.  Keep in mind that the DeviceId is containing hexadecimal characters, so that means 16 options (0 till F) per character. How big you want to make the groups is up to you, but I have chosen for a group for each first character, so 16 groups. With 16 group you have around 6.25% of your devices per group. Of course this is a bit depending on the size of the environment, for 60K+ clients environment the distribution look...
Read more

Why are we using Autopilot group tags?

Image
  Why are we using Autopilot group tag? Do we need group tags?  Two valid questions which I will discuss in this blog post. So, why do we use group tags? The short answer, to add the device to the correct group! The long answer As we are in over 40 countries and might even have multiple entities in those countries, we have around 90 legal entities with their own local support teams, and so we need to be able to distinguish the devices per entity. Next, we have different device types for different use cases, we call them worker types. We currently have the standard device, engineering device, shared device, virtual device and kiosk device. User can have multiple devices which have different worker types. So, that is the second requirement. Other requirements are to separate laptops, desktops and virtual devices. And yes, we could use filters instead, but they were not available 4 years ago. And finally, the need to mark devices as pre-production and to be able to see which glob...
Read more