Monthly Archives: September 2014

Clean Up SMA Database After a Module Deletion

Written by Tao Yang

Background

I noticed an issue while I was writing a SMA integration module. I once made an mistake in the .json file and I noticed I couldn’t import the updated module back to SMA even after I firstly deleted the old version. I’ll explain this issue using a sample dummy module.

Reproducing The Issue

To reproduce the issue, I firstly created a dummy module with 3 files:

image

The module .psm1 and the connection file .json (notice there’s a connection field named “ComputerName” in the .json file):

image

I zipped and imported this module into SMA, everything looks good so far. and the connection fields are correctly displayed (as expected):

image

I then update the .json file (Changed the connection field name from ComputerName to ComputerFQDN):

image

I zipped the updated module, tried to import the module into SMA, but got an error:

image

I then tried to delete the existing module and imported again, but I got the same error.
I also noticed that even after the module has been deleted, the connection is still available to be selected:

SNAGHTML1a885165

My Resolution

Since I couldn’t find any documentation on how to completely remove an Integration Module, I went ahead and developed a SQL script to completely remove the module and module connection from the various tables in the SMA database. Here’s the SQL script:

To use this script, you will need to change the @ModuleName and @ConnectionName variable to suit your module:

SNAGHTML1a938e65

After I ran this script, I was able to import the updated module:

image

Disclaimer

Although I’ve used this for multiple modules in multiple SMA environments and so far have not found any problems, I did not consult this workaround with SMA experts, please use this at your own risk. Please don’t blame me if it breaks your environment.

SMA Management Pack Could Not Connect To Database Alerts – My Troubleshooting Experience

Written by Tao Yang

I’ve setup 2 servers for the SMA environment in my lab a while back. Yesterday, I loaded the SMA MP (version 7.2.89.0) into my OpsMgr management group. Needless to say, I followed the MP guide and configured the Database RunAs profile. However, soon after the MP is loaded, I started getting these 2 alerts:

  • The Service Management Automation web service could not connect to the database.
  • The Service Management Automation worker server could not connect to the database.

SNAGHTMLc49f04a

To troubleshoot these alerts, I firstly unsealed the management pack Microsoft.SystemCenter.ServiceManagementAutomation.2012R2.mp, as this is where the monitors are coming from. The Data Source module of the monitor type uses System.OleDbProbe probe action module to make the connection to the database.

SNAGHTMLc5582d0

To simulate the problem, I used a small free utility called Database Browser Portable to test the DB connection. I launched Database Browser using the same service account as what I configured in the RunAs profile in OpsMgr, and selected OleDB as the connection type:

SNAGHTMLc61bf04

I populated the Connection String based on the parameters (monitoring object properties) passed into the data source module: Provider=SQLOLEDB;Server=SQLDB01.corp.tyang.org\;Database=SMA;Integrated Security=SSPI

image

Note the Database Instance property is empty. this is OK in my lab because I’m using the default SQL instance. I’ll explain this later.

The test connection result is positive:

SNAGHTMLc687aa6

However, after connected, when I clicked the connection, nothing happened, the list of tables did not get populated. I then tried using my own account (which has god rights on everything in the lab), and I got the same result.

Long story short, after trying different configuration changes on the SQL server, I finally found the issue:

On the SQL server, the Name Pipes protocol was disabled

SNAGHTMLc705360

After I enabled it, I was able to populate the tables in Database Browser:

SNAGHTMLc7245ca

And within few minutes, the alerts were auto closed.

While I was troubleshooting this issue, I came across a blog post from Stanislav Zhelyazkov. In the blog post, Stan mentioned adding the DB instance name in the registry (where the discoveries are looking for). However, when I added “MSSQLSERVER” in the registry and forced re-discovery, the monitors became critical again and I received several 11852 event in Operations Manager event log:

SNAGHTMLc7e3526

I email Stan and he got back to me and told me he’s using a named instance in his lab and these monitors are working fine in his lab after he added the SQL instance name in the registry. He also told me he didn’t recall specifying the SQL Instance name during the SMA setup but the setup went successful. My guess is that the SQL Browser service must be running on his SQL server, so the setup had no problem identifying the named instance.

Conclusion

Based on my experience and Stan’s experience, we’d like to make the following recommendations:

  • Enable the Name Pipes protocol
  • If using the default SQL instance, please do not manually populate the registry key
  • If using a named instance, please add the SQL instance name in the registry if it’s not populated after setup.

 

Thanks Stan for his input on this one!

ConfigMgr 2012 (R2) Client Management Pack Updated to Version 1.1.0.0

Written by Tao Yang

4th October, 2014: This MP has been updated to Version 1.2.0.0. Please download the latest version from this page: http://blog.tyang.org/2014/10/04/updated-configmgr-2012-r2-client-management-pack-version-1-2-0-0/.

OK, after few weeks of hard work, the updated version of the ConfigMgr 2012 (R2) Client MP is finally here.

The big focus in this release is to reduce the noise this MP generates. In the end, besides the new and updated components I have introduced in this MP, I also had to update every single script used by the monitors and rule.

The changes since previous version (v1.0.1.0) are listed below:

Bug Fixes:

  • Software Update agent health not rolled up (dependency monitors was missed in the previous release).
  • SyncTime in some data source modules were not correctly implemented
  • Typo in Pending Software update monitor alert description
  • The “All ConfigMgr 2012 Client computer group” population is incorrect. It includes all windows computers, not just the ones with ConfigMgr 2012 client installed.
  • Many warning alerts “Operations Manager failed to start a process” generated against various scripts used in this MP. It has been identified the issue is caused by the OpsMgr agent executing the workflows when the SMS Agent Host service is not running. This typically happened right after computer startup or reboot because SMS Agent Host service is set to Automatic (Delayed). All the scripts that query root\ccm WMI namespace have been re-written to wait up to 3 minutes for the SMS Agent Host to start (if it’s not already started). Hopefully this will reduce the number of these warning alerts. The updated scripts will also try to catch such condition so the alert indicates the actual issue:

clip_image002

 

Additional Items:

  • A diagnostic task and a recovery task for the CcmExec service monitor. The diagnostic task detects if the system uptime is longer than 5 minutes (overrideable), if the system uptime is longer than 5 minutes, the recovery task will start the SMS Agent Host service. Both the service monitor and the recovery task are disabled by default. –If you decide to use this service monitor and the recovery task (both disabled by default), it would help to reduce the number of failed start a process warning alerts caused by stopped SMS Agent Host service.
  • Monitor if the SCCM client has been placed into the Provisioning mode for a long period of time (Consecutive Sample monitor) (http://thoughtsonopsmgr.blogspot.com.au/2014/06/sccm-w7-osd-task-sequence-with-install.html)
  • The Missing CCMEval Consecutive Sample unit monitor has been disabled and replaced by a new monitor. The new monitor is no longer a consecutive sample monitor, it will simply detect if the CCMEval job has missed 5 consecutive cycles (number of missing cycles is overrideable). This new monitor is designed to simplify the detection process and to address the false alerts the previous consecutive monitor generates.
  • Monitor CCMCache size. Alert when the available free space for the CCMCache is lower than 20%. Some ConfigMgr client computers may be hosted on expensive storage devices (i.e. 90% of my lab machines are now running on SSD). Therefore I think it is necessary to monitor the ccmcache usage.  This monitor provides an indication on how much space has been consumed by ccmcache folder.
  • Agent Task: Delete CCMCache content

 

Updated Items:

  • Pending Reboot monitor updated to allow users to disable any of the 4 areas that the monitor checks for reboot (Pending File Rename operation is disabled by default because it generates too many alerts):
    • Component Based Serving
    • Windows Software Update Agent
    • SCCM Client
    • Pending File Rename operation
  • The Missing CCMEval monitor is disabled and superseded.
  • All consecutive samples monitors have been updated. The System.ConsolidatorCondition condition detection module has been replaced by the <MatchCount> configuration in the System.ExpressionFilter module (New in OpsMgr 2012) to consolidate consecutive samples. It simplifies the configuration and tuning process of these consecutive sample monitors.
  • Additional events logged in the Operations manager event log by various scripts. – help with troubleshooting. Please refer to Appendix A of the MP documentation for the details of these events.

 

Upgrade Tip

This version is in-place upgradable from the previous version. However, since there are additional input parameters introduced to the scripts used by monitors and rule, you may experience a large number of “Operations Manager failed to start a process” warning alert right after the updated MPs have been imported and distributed to the OpsMgr agents. To workaround this issue, I strongly recommend to place the “All ConfigMgr 2012 Clients” group into maintenance mode for 1 hour before importing the updated MPs. To do so, simply go the the “Discovered Inventory” view, and change the target type to “All ConfigMgr 2012 Clients”, and place the selected group into maintenance mode.

SNAGHTML30b0e7ee

Special Thanks

I’d like to thank all the people who has provided the feedback since the last release and spent time helped with testing this version. I’d like to specially thank Stanislav Zhelyazkov for this valuable feedbacks and the testing effort. I’d also like to Thank Marnix Wolf for his blog post which has helped me built the Provisioning Mode Consecutive Sample monitor in this MP.

 

Download

Download ConfigMgr 2012 (R2) Client Management Pack 1.1.0.0

What Have I Been Up To

Written by Tao Yang

This blog has been a bit quiet lately. This is because I have been very busy, and it’s just all the things I’ve been working on have not been eventuated yet. I just want to quickly post a short update here to share some information with everyone.

ConfigMgr 2012 Client Management Pack Update

I have spent the last couple of weeks updating the ConfigMgr 2012 Client Management Pack. I thought it would only take me few days but it turned out it has taken a lot longer than what I expected (2 solid weeks with over 10 hours each day including weekends). Having said that, there has been a lot of changes and bug fixes in the new release. I have completed the beta version last night and I’m currently testing it with my fellow SCCDM MVP Stanislav Zhelyazkov. I’ll let the beta version running in the test environments for few more days, so hopefully if nothing goes wrong, it will be released in the coming days.

A Custom OpsMgr PowerShell Module for SMA

I started writing a number of OpsMgr PowerShell functions that directly interact with OpsMgr SDK. These functions can be used to create management packs, various rules and monitors. I then transformed these functions into a standalone PowerShell module which can be imported into SMA as Integration Modules. Unlike the built-in OpsMgr module in SMA, this is not a portable module, it does not require SMA runbook workers to install the native OpsMgr 2012 module.

I will be presenting this module in the Melbourne System Center, Security & Infrastructure group next Thursday night (25th September 2014) at Microsoft’s Melbourne office in Southbank with Dan Kregor. We will demonstrate how to automate OpsMgr management packs creation using this module, alone with SMA, Orchestrator and Sharepoint 2013.

To date, I have spent over 2 months working on this project and have already written around 2000 lines of code. I’m really excited with what this solution does and I think it’s pretty cool. If you live in Melbourne and interested in attending, the RSVP detail can be found on the user group website: http://mscsig.azurewebsites.net/

After the user group meeting, I will also document this solution and make it available to the community.