Microsoft Endpoint Manager Management Pack Sneak Preview

Introduction: Current SCCM Management Pack Limitations

For those who are very familiar with the current System Centre Configuration Management pack are aware of its limitations.

Not only does it not take into account the versions we are quickly escalating to on the current branch but the base of its limitations really is based down to how the management pack is structured where it primarily works as a forwarder.

So basically where we see messages in various areas such as;

• Site Status
• Component Status
• Status Messages

Once these are flagged as a warning or error within our SCCM infrastructure you’ll see the statuses of a specific component or role change. And with the administrative effort to go through and search for the messages as well as investigating the corresponding service or logs, it can definitely mount up the amount of effort to troubleshoot.

So with the current management pack that’s available its more based on the detection of the status of these component statuses, whilst this is helpful we know that sometimes the component statuses may either be out of sync, stuck and not always true on a real-time basis.

With SCCM being a beast of a technology we still require a more efficient way of understanding its health, not just based on its component/health statuses but also to incorporate the best practices and also to spot the potential bottlenecks which cannot be seen by the naked eye.

This is where ProtectOrg Comes In

We, at ProtectOrg are designing a new management pack which will accommodate SCCM as well as Microsoft Endpoint Manager, with already great progress so far and its entirely built using our M-Pack creator tool which is available to purchase right here

It’s still early in the game right now and with Microsoft Endpoint Manager being a huge technology we want to be able to tend to all of its need as much as possible.

As an example, one thing we want to do is to also tackle those best practices which can also cause catastrophic issues for your environment if not sorted out as well as the overall health which we are also looking into as well. Lets visit a few things in which we can show off to you just to get the ball rolling 🙂

Everything is very early stage but you can truly see the power that the M-Pack Creator product can bring

All Systems Limiting Collection Alerting

This one is quite an important best practice especially when you start to ramp up scalability, and also I’m slightly guilty of doing this myself 🙂 And this is exactly the reason why things like this are to be notified and highlighted a lot more so it’s no longer overlooked.

Now this isn’t something that’s even monitored in general not even in a management pack or the SCCM console itself….until now

In Figure 1.1 you can see an open alert here and also listing out the collections which have been found using an All Systems collection as its limiting collection. It’s also worth noting that it does exclude the default collections within SCCM that use this by default.

Now you might think that listing it as critical is perhaps harsh…but the reality of that anything can be added to that collection as well as the wrong deployment of…..anything going to it can have grave consequences. So it’s perhaps best that it’s sorted now than later.

Duplicate Devices

Quite another frequent one which does pop up in our environment from time to time. Whilst we do have the options to automatically resolve conflicting records, this isn’t always the case and can still see some which may linger around.

Now normal practice for us would be to either create a query either based on WQL or SQL which we can check at leisure. Sometimes even imported into a collection as an incremental rule to catch them. But what if we can catch them sooner, especially within the framework of our monitoring. Which is why I decided to build a monitor which can indeed do so by a certain interval we can do an automated check to find these objects. Below is a screenshot of its configuration on alerting. Unfortunately I was unable to create a test or dummy duplicate record my environment is a bit too healthy at the moment 🙂

Orphaned/Offline Devices

One of the most requested bits of information which can come from stakeholders as well as regular clean-up type of statistics is always around offline devices. This topic is interesting because it really falls down to what do we perceive to be an “offline device”.

Most typically 30 days or longer we would consider to be offline. Circumstances can differ where those objects are still around but sometimes they are not addressed in a timely manner. Also not to mention when these devices are within our estate, not only does it show an un-true look to our statistics but especially impacts SLAs if we are trying to achieve targets of certain percentages which then have a knock on effect when these devices are there.

We want a way to be able to know what devices have been captured as offline so that we can effectively group them and deal with them. And below is an example of another useful monitor here.

ADR (Automatic Deployment Rules) Have Failed

Patch Tuesdays, Windows Defender updates, all here and mostly configured within our ADRs (Automatic Deployment Rules). These are pretty crucial especially when we are talking about regular schedules and may be in a situation where others in an organisation might notice issues of patches not going out before we do. We want to be ahead of the game with this and know when this is happening.

Below is an example of an ADR Rule flagged up as containing an error the last time it was run.

Management Pack Cosmetics

The layout of the management pack will of course easily outline Site System roles and various other attributes which are very important to Microsoft Endpoint Manager. So below are just some very early stage examples as to how it’s progressing.

And one thing you might be thinking about in not just the monitoring but especially the MP design layout is how will the management pack effectively be able to target and discover the correct sites, site codes and different types of environments.

What do YOU want to see in this Management Pack?

We are a big community within the Microsoft Endpoint Manager and Enterprise Mobility space. The possibilities are endless, and so are the administrative tasks to ensure we have a healthy System Centre environment. We want to bridge the gap between the effort to troubleshoot and knowing where to find the issue together, which is ProtectOrg’s main goal.

We provided an M-Pack Creator tool to address the complicated processes of how to construct a management pack, and now using that to even further spread our message by building a management pack which does the same for SCCM.

There are so many different areas and levels to what can be achieved here, and could beneficial to understand what you may want to see in an ideal “Perfect” management pack for SCCM & Microsoft Endpoint Manager.

The next update on this is going to have way more so stay on the lookout for the next update coming soon from ProtectOrg!