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

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:

eval expiring

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


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: MsDtsServer100 IS Package Failed (SQL Management Pack)

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:

view history

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:

event log

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.

Critical Alert: WMI is unhealthy

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.

The contents of this site are provided “AS IS” with no warranties, or rights conferred. Example code could harm your environment, and is not intended for production use. Content represents point in time snapshots of information and may no longer be accurate. (I work @ MSFT. Thoughts and opinions are my own.)