SCOM Management Pack Creator 2.0 Officially Released
Dujon Walsham • 5 December 2018
Available on Microsoft Gallery
The long waited SCOM Management Pack Creator V2.0 script is now officially released and available on the Microsoft Gallery
Link can be found here
https://irp-cdn.multiscreensite.com/c1f89e50/files/uploaded/SCOM%20Management%20Pack%20Creator%20V2.0.zip
The ZIP file includes the full guide on how to use the script aswell.
The first version is also available on here on my older post being the SCOM Management Pack Creator V1.0 which contains more the proof of concept code which focuses on the idealistic of a PowerShell Script which can build out the entire SCOM Management Pack
It does work well, but limited in comparison to the newer release which i have here
Please share and provide feedback and perhaps ideas of new things i can to it or improve
Release Notes
Version 1.0 Release Notes
- XML Output - Creates an XML output file for each individual part of the SCOM Management pack being the Class, Discovery, Folders, Views, Monitors & Rules
- Classes Creation - Can create a new class, properties for classes and also run as accounts
- Discoveries Creation - Create a discovery using either PowerShell, VBScript, Registry or WMI
- Create Monitor - Create the Windows Event Two State Monitor
- Create Rule - Create the Windows Event Rule
- Create Views - Create the following views; State View, Alerts View, Overrides and Events View
- Create Folders - Create folders for where you can place other folders and views for your SCOM Management Pack
Version 2.0 Release Notes
- Dynamic Class Detection - Can now dynamically detect all of the classes which you had created within the wizard and provides a numerical list option to select from when creating discoveries, monitors, rules or any additions to your SCOM Management Pack
- Create All Views in SCOM - This now includes comments which give a breakdown on how to perform criteria filtering on views so that you can customize even further. So now you can create URL Views, Task Status Views, Performance and Dashboard views
- Create Relationships - Now when you create multiple classes you can now create relationships between them to link them together
- Create More Monitors/Rules - The first release was only the Windows Event Monitor but now you can create Event Monitors, Service Monitors, Service Performance Monitors (CPU & Memory), PowerShell Script Rule, Performance Rules and Event Rules
- List Selections - The questionnaire wizard has been simplified more so you dont have to worry about typing in manual entries or formatting which can cause Visual Studio build issues
- Create Monitors Based on PowerShell - You can now create a Monitor which runs on a PowerShell script using the Custom Probes, Data Sources and Unit Monitor Types
- Reload Management Pack Function - You can now use this function which can load your entire SCOM Management Pack you created with the script and gives you a list of options where you can add addtional classes, discoveries, views, folders, monitors and rules to your SCOM Management Pack
- Alert Parameters and Suppressions - You can now utilise Alert Parameters to customize your alert messages and also suppression parameters for rules
Looking through the current SQL Server topology and how it affects our decision
Impact of Current Branch Upgrades
All the parts of the series we went into great detail about how we analyse an end to end solution and how we would design a solution in which would allow us to build endpoints without SCCM being a dependency. Whilst we did this, there is another scenario which we have not touched on yet, which is the hybrid scenarios. In a perfect world ideally you would have your Azure Active Directory within the cloud, every machine meets the recommended requirements for Windows 10, everything is imported into Intune/Autopilot and everyone is happy. But we know this isn't realistic in all cases. Many organisations cannot just simply up and go from on-premise into the cloud therefore the checkpoint here is of course getting into hybrid solutions such as; Co-Management Between Intune and SCCM Hybrid AD with Azure AD and On-Premise AD syncing together These things can play a very interesting part in how you would tackle this if you envisage the next step in the blueprint is to be in a position in which you can build and manage endpoints soley within Intune. With this final part of the series we will go in-depth in how the common hybrid setups look like and how we go about moving into the next step of being able to manage and build devices without SCCM.
In continuation from the previous part where we had discussed how we create the "on site" piece of the solution, this was the part which would allow us to get our endpoints into a state in which they would essentially be ready to go through the Autopilot process. Which leaves our next piece of the puzzle, to begin the configuration of the actual backend side that resides within our Endpoint Management console. And you will see how everything ties up together to satisfy the full end to end process of getting an unknown (or known) device to proceed thorough the whole workflow to be finally managed by Intune without the aid of SCCM taking part in any of the prerequisites or preparation at hand.
In this part we are now going to look into the technical step by step points on how we put everything together. In the previous part we spoke about the structure of how we would asses whether a machine was actually ready to be built with Autopilot or not with a build checklist process which would step through all areas which would cover an endpoints eligibility. Now with everything planned out we finally want to step into making things reality by putting everything together.
When it comes to managing your endpoints in endpoint manager, one of the things you may be looking to do is to get all of your Intune registered machines to also be enrolled as Autopilot devices. Now we can of course just have the deployment profile deployed to all machines and then hit the "Convert targeted machines to autopilot" but this might not necessarily be feasible for every client. We may want to perform some due diligence first so we can at least understand what devices in Intune are not in Autopilot.
