Troubleshooting

Troubleshooting: Product Evaluation is expiring in 60 days (SCOM 2012)

Posted on May 15, 2013October 24, 2014by OpsConfig

With some System Center 2012 products like Service Manager the install GUI requires you to enter a license key. While this is annoying during the install process this is nice in that it makes sure that you don’t forget to enter a license key. With Operations Manager 2012 the installer does not prompt for a license key and by default all installs are technically 180 day evaluation copies. This is fine except eventually you will log into the OpsMgr console and see the following:

This can be a little scary especially when you are seeing this in a production environment.

The official Microsoft instructions for adding a license key can be found here.

You will need to run the following powershell commands on each of your SCOM Management servers:

Launch Powershell Run as an Administrator

Type the following:

Import-Module operationsmanager

New-SCOMManagementGroupConnection

Set-SCOMLicense -ProductID “Enter your license key here”

Hit Enter

The Microsoft instructions then tell you to run:

Get-SCOMManagementGroup | ft skuforlicense, version, timeofexpiration -a

For me this would consistently return the following result with the Management server still appearing to be running a Eval copy:

However if you reboot the management server and rerun the commands you should see something like this:

So the reboot seems to be key after running through all the steps above.

Troubleshooting

Troubleshooting: MsDtsServer100 IS Package Failed (SQL Management Pack)

Posted on May 15, 2013May 15, 2013by OpsConfig

Every once in awhile an engineer will have this error pop up for one of their systems:

If the engineer is a SQL DBA than there is no problem as they will understand both the source and ultimately how to fix the problem.

Sadly not everyone who has or manages a SQL server is a DBA. There are plenty of cases where a sysadmin acquires a few SQL servers which they know the basics of managing or at least how to point an app server at to use it, but they may never have had the time to dig deeper into SQL, thus MsDtsServer100 IS Package Failed is not always particularly useful.

The Alert Description offers a useful clue “Maintenance Plan” Failed (Though this title will vary based on if the default plan name is used)

So how do you troubleshoot this error?

If you remote the SQL server referenced in the error you can launch SQL Management Studio and connect to the instance in question. If you expand the Management folder you will find a folder called Maintenance Plans

In this case the Maintenance Plan has been renamed to “Nightly Backups”

If you right click and select view history for the Maintenance Plan you will be presented with the following:

This is where things get confusing, everything looks like it ran perfectly as per the little green check marks of success. You see a Rebuild Indexes, a History Cleanup, some generic Maintenance task, and a DB Backup. All successful.

So where is the error coming from?

If you navigate to the Application Event Log on the SQL server for the time the alert was generated you will find the answer:

Subplan II actually had two components: one was a rebuild indexes which you can see from the SQL Management Studio history occurred successfully. The other item in this particular case was a reorganize indexes which was failing. Reorganizing indexes immediately after rebuilding them doesn’t sound like a very good order of operations. For this specific issue I recommended that the engineer remove the reorganize indexes from subplan II and the error has never happened since. So if you see MsDtsServer 100 IS Package Failed you are going to want to go to the Application Event Log of the SQL Server to figure out the source of the problem.

Troubleshooting

Critical Alert: WMI is unhealthy

Posted on March 3, 2013March 3, 2013by OpsConfig

Over the past few months I have had a few alerts related to a failure of WMI on servers. The Product Knowledge within SCOM recommends the following:

Unfortunately, I haven’t had much luck with the recommended fixes. In the past with other systems I used to just reboot the server in question. but I hate having to rely on a reboot to fix a problem as it’s not a particularly good long term solution.

When I try running winmgmt /verifyrepository I get a failure message:

If I try searching for anything that might be hogging all the threads, nothing obvious stands out.

If I run the handy WMI diagnosis tool I get more or less the same thing, along with some useful information that other than the threads being created issue all seems to be well.

I am 99% certain if I were to reboot the system it would resolve the issue, but my guess is this would be only a temporary fix. The particular system I am having the problem on now happens to be of the mission critical cannot reboot under any circumstances without change management and a team of skilled surgeons on hand to bring it back to life should it decide to crash post reboot.

In the interest of a long term solution, I am going to try running the recommended hotfixes to make WMI more robust as recommended by Marnix Wolf on his excellent Blog on OpsMgr.

Direct Link to Microsoft Recommended WMI Hotfixes

I will continue to update this post with any further info related to WMI troubleshooting that I come across in the future.