Are Your Microsoft Entra Extensions Actually Being Used?
Today I'll take a deeper dive into what Entra Extensions Manager can help with and be used for.
As I went over in my last two blog posts, custom extensions have a habit of sticking around.
An application gets built, an extension gets created, values get written to users or other directory objects and, a few years later, nobody is really sure whether any of it is still being used.
The application might be gone, the extension might even be deprecated, but what about the data?
Especially when working in an inherited environment, or across multiple environments, simply finding the extension definitions is only the first part, actually knowing whether those extensions contain any actual values is often the missing part.
That's one of the reasons I built the Usage Monitor in Entra Extensions Manager.
Helping understanding the data, values and objects using them before removing or deprecating extensions, applications or the values kept in them.
Table of Contents
Defining "Unused" Microsoft Entra Extensions
Before we jump in, it'll be worth defining what I actually mean by an unused extension.
Finding an extension with no values is a useful signal, but it doesn't automatically prove that nothing depends on the definition.
Let's say we got an app that queries the extension and have different responses whether values are added or not - data might not have been added yet, but removing the extension could result in future issues with the app.
Likewise, finding values doesn't necessarily prove that an extension is actively being used. The data itself might simply be leftovers from an old application.
So the goal here isn't to press a button and have Entra Extensions Manager tell us:
"Delete these five extensions."
That would be nice, but potentially very dangerous as well. Instead, the usage monitor feature is designed to provide the information required to investigate further, to allow us a path to clean up our environments.
Beginning by Beginning - Extensions Overview
As with any run of the Entra Extension Manager, it loads on the inventory, making taking a look at what extensions actually exists across the environment, a piece of cake.
Entra Extensions Manager lists Schema and Directory extension definitions in the their own inventory overviews where they can be searched, filtered, and expanded.
Open extensions are a bit more annoying to work with as they cannot be caught in a singular overview but has to be queried on a by object basis.
At the overview we'll be able to see owner apps, FQDN, ids, source, target and type of the extensions, for Schema extensions we're also able to see the status of the extension.
At this point we might already fall over an extension we knew nothing about, an application that noone recognizes, extensions with very similar names that could be combined or extensions sitting in deprecation for a while.
Any of those might be worth investigating, but the existence of the definition itself doesn't tell us whether there's still data attached to it.
Which, very smoothly, leads into the Usage monitor which can help us expanding on that exact point
Running the Usage Monitor
The Usage Monitor automatically probes supported Microsoft Entra directory object types to estimate where extensions are present, both with and without values.
This probe can be manually refreshed by clicking the refresh button in the top right corner
Once the probe run is complete, we get an overview of which extensions appear across our environment.
When it comes to Schema extensions it'll show any with status InDevelopment regardless of whether any value is stored within it. Directory extensions are also shown regardless of whether it's in use or not, providing better insights for both types of extensions to help evaluate their worth.
Note: Open extensions do isn't supported for tenant wide probing, and is only possible to view on a by-object basis
This gives us a much better starting point for a potential cleanup.
Instead of investigating every extension definition equally, we can begin separating them into different categories.
Extensions with no discovered values
These might be worth investigating as a potential cleanup candidate.
Extensions with hundreds or thousands of values
These probably deserves considerably more attention before anybody thinks about touching the Delete button.
Extensions that are deprecated
This type of extension is part of a somewhat more interesting category, as we'll go over in the next section
Deprecated Does Not Mean Empty
As I previously went over, Schema extensions have a lifecycle, which includes the Deprecated state.
Though deprecating a definition doesn't mean that all of the values previously written using that extension suddenly disappear.
Luckily, utilizing the Usage monitor tool it's a cinch to check deprecated Schema extensions in our environment, and check whether they still hold data.
This is exactly the kind of thing I want to know when coming into a new environment, reviewing environments, or when I'm asked to help out a client with cleaning up their identity masterdata.
Deprecating an extension is a manual thing and means someone has intentionally chosen that it shouldn't be used going forward.
This means we have a range of questions we need to think about and answer for deprecated extensions that still contains associated data, and these questions might not always be straightforward as Schema extensions are global and might not have it's roots within our known environment.
Still, these are the questions I try to answer before a potential cleanup:
Is the extension associated to the tenant, or a global one?
Was there a migration, planned or executed?
Did every object move to the replacement?
Are these simply old values that were never cleaned up?
Is something still actively depending on them?
The tool can't answer these questions for us, but it can provide insights and a better foundation for investigating them.
Working With The Monitor Output
One of the strongest parts of the Usage Monitor is the capability to drill into each object assigned a value pr. extension, and even what the value is.
By default, values are masked if we only want to see which object holds value, but without a need to know what said value is.
This provides a great way to both monitor whether an extenion is used, by who, holding what, while keeping track of expected extensions. For example in a JML flow that utilizes different values and/or extensions where values are expected on all users, simply throwing a quick glance at the extension in the usage monitor will show if the flow is working correctly.
If the values are present on a particular set of users, groups, devices, or other supported objects, that might give us a clue as to which process or application created them.
At this point, we've gone from:
"What on earth is extension_abc123_SomethingOld?"
To having actual objects and values we can investigate, giving us a considerably better position to be in.
Audit Trail, Documentation and Audits
As with any and everything we do in IT, we have to keep up with the most loved thing, documentation and audits.
To help with this, a snapshot of the live data might not always be the best match, therefore it's also possible to export the values of each extension to either CSV or JSON
From there, the data can be compared with application inventories, migration records, CMDB data, scripts, or whatever else is available in the environment.
This also gives a great route for sharing the data with application owners which might not have access or knowledge of how to see this data.
Great, so all of this means we can start deleting extensions left and right, right?
Well not so fast
Investigation Candidates vs. Deletion Proof
With the Usage Monitor tool, we have a much clearer picture of how our environment is doing in terms of extension usage, but an extension showing no values in the Usage Monitor should only ever be treated as a candidate for investigation, and not as proof that deleting it is safe.
For this, there are a few different reasons:
First off, Microsoft Graph doesn't provide equal query capabilities across every directory object type, so the Usage Monitor can only probe combinations that are supported by Graph.
Secondly, and arguably more important, is that usage of extension attributes can be both statically stored values and ephemeral with applications, automation, provisioning processes etc. which may reference an extension definition even when there aren't currently values stored against it, or add values and remove them again during the run of a flow.
That is why we need to use the insights from the Usage Monitor on top of investigating owner applications and references before coming to an actionable result.
The investigation usually includes questions like:
Who owns the owner application?
Is the application still in use?
Does any code, automation, or provisioning configuration reference it?
If values exist on a deprecated extension, do they need to be migrated or preserved?
What happens to dependent applications if the extension disappears?
While Entra Extensions Manager can make a lot of the discovery and investigation easier, it's not able to replace the knowledge of our environment and the manual investigation steps.
Okay Cool, but What about Open extensions?
So one thing I've gracefully skipped talking too much about so far are Open extensions.
There is a very simple reason for that; It's simply not possible to query them via graph as they aren't stored or registered tenant-wide, but directly on each object. There isn't a Microsoft Graph endpoint for enumerating every Open extension, and querying each and every object to get an overview is simply not feasible for most environments.
Because of that it's not a part of the Usage Monitor tool, instead the Open extensions page allows per-object query with an autocomplete searchbar to help it run a bit smoother.
It's an unfortunate Graph limitation, which I've tried to work with in the best way possible.
It is, however, still an important part to understand when assessing extension usage across a tenant.
Wrapping up: Use the Monitor for Usage Monitoring!
Understanding, and potentially cleaning up a new or inherited Entra environment often a rather broad task, with the Usage Monitor tool helping bridge at least some of the required tasks, that in it self is of great value.
Particular for custom extensions, understanding both sides of the equation is of utmost importance: What definitions exists, and Where does their data exist?
The Extension Inventories and Usage Monitor in Entra Extensions Manager are designed to make answering those questions just a little easier.
It can't, and frankly I don't really think any tool should pretend they can, tell you whether deleting an extension is safe or not, but what it CAN do, is turn an unknown extension into something you can actually investigate.
And when you're staring at an Entra environment you've never seen before, that's usually a pretty good place to start.
Go check it out directly, look through the GitHub or the announcement post for more info on the complete tool
And I won't forget to send you off with the mandatory bad joke ofcourse:
I always eat exactly 1024 pieces of candy before going to a concert.
Otherwise it won't really be a gig 😎
Next time I'll go into how to self-host the portal, so stick around if that's something up your alley.
Comments