For many customers, getting more value from their SCOM investment means going beyond the basics and authoring custom management packs. As SCOM proliferates in more IT shops, organizations continue to invest in the platform which usually equates to one Administrator and a number of MP developers. Balancing day-to-day activities along with the special needs of management pack development has shaped these roles. For the already busy SCOM Administrator, there is relief through simple automation.
An example is how mature IT organizations follow some form of release process. When a new version of their code is deployed, a new management pack can be revisioned and shipped alongside. As the SCOM Administrator, you have to work with the developers to deploy the management pack and often, facilitate the iterations. Offloading this particular task is not trivial because non-Administrators would then have the ability to make system changes and other potentially harmful actions.
Ask yourself these questions:
- Do you manage multiple SCOM environments such as sandbox, test and production?
- Do you support MP Developers who don’t have import permissions in the management groups?
- Do you spend more time than you wish scheduling releases for management pack updates?
- Would you like to enable MP developers or deployment staff to securely import their management packs?
If you answered yes to any of these questions, chances are, you can benefit by implementing this simple process. Without importuning the Administrator each time, MP Developers can import their management packs by copying them to a drop share and having a scheduled task to run the install-managementpack PowerShell cmdlet. After they have been imported, the management packs are then moved to a processed folder.
Here’s what you need to make it work:
– A (domain) account with administrative permissions
– A scheduled task on the RMS
– A share on the RMS
– Operations Manager Shell component on RMS
– Downloaded sample scripts
1) Let’s start by downloading and unzipping the file. Inside is a directory structure, test MP, batch file and PowerShell script.
2) Copy the MyShareRoot folder to a location on the RMS. The RMS should already have PowerShell installed as a SCOM prerequisite however you may need to install the Operations Manager Shell component if it does not already exist.
3) Create a share for the MPDrop folder and assign permissions so users have the necessary access rights. For demonstration purposes, we chose to share with Everyone.
4) In the MyShareRoot folder, you need to edit three variables in ImportMPsSchedTask.cmd to match your environment. The BaseImportManagementPacks.ps1 PowerShell script does not need to be changed.
- ROOTMS should be the fully qualified name of your RMS
- IMPORTPATH should be the directory of the MPDrop folder (not the share but the shared folder)
- PROCESSPATH should be the folder where the imported MPs are copied after they are imported
5) Let’s the script to make sure everything works before creating the scheduled task. Login to the RMS as a user with the domain account listed above so we can validate the permissions. From a CMD prompt, change directory to the MyShareRoot directory. Run the ImportMPsSchedTask.cmd batch file. If this worked, the TestManagementPack.xml in the MPDrop directory will be imported to your management group and moved to the Processed subdirectory. If necessary, troubleshoot any issues with permissions or variables in the batch file before continuing.
6) Create a scheduled task to run ImportMPsSchedTask.cmd at a reasonable interval such as every 5 or 10 minutes. We won’t describe how to create the task but ensure it runs as a domain user with permissions to import management packs. In our sample, we used the Default Action Account which had the necessary permissions. Use the appropriate method which meets the security requirements of your environment.
You may want to set some ground rules as to what MPs can be imported as you wouldn’t want someone to import unwanted packs. If you encounter issues with importing management packs on a schedule, make sure users are not trying to import an .xml management pack on top of a sealed pack because this won’t work (i.e. when multiple MPs are placed in the drop folder). When this happens, the MPs will be stuck in the MPDrop folder until the offending one(s) are removed. You can run the ImportMPsSchedTask.cmd batch file to see any SCOM errors.
WME offers an upgraded version of this process which adds Windows error logging, import history logging, alerting, MP exclusions, log file cleanup and feature to remove blocking MPs so others can continue.
