Don’t forget to License your SCOM 2016 deployments




Just like previous versions of Operations Manager, all SCOM deployments are installed as “Evaluation Version” which is a 180 trial.  You DON’T want to forget about this and have your production and lab deployments time-bomb on you down the road.

To see your current license, in PowerShell on a SCOM server:

Get-SCOMManagementGroup | ft skuforlicense, timeofexpiration -a



In order to set your license – you just need to run the Set-SCOMLicense cmdlet.  This is documented here:


Two things:

1.  You need to get your license key, from whomever keeps that information for your company.

2.  You MUST run this cmdlet in a PowerShell sessions launched “As an administrator” as this will need access to write to the registry.


Run this command ONE time on ANY management server…..

Set-SCOMLicense -ProductId '99999-99999-99999-99999-99999'

…… where you change the example key above to your key.

You should restart the PowerShell session, then run the command to get the license again.


(Note:  You might have to restart you management server services or reboot the management server before you see this take effect)

Comments (3)

  1. Hi Kevin. My prod environment is good, thanks! 🙂

    Sorry for the off-topic, but after I upgraded my SQL MPs to the recent updates (, I got a slew of these alerts:

    Event ID: 18456. Login failed for user ‘removedremoved\removed’. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: an IP address]

    Any ideas? Thanks!

    Michael R.

    1. Kevin Holman says:

      I am VERY concerned about this when I saw the new MP’s.

      MANY customer environments have TONS of 18456 errors where something is trying to access a DB and gets denied. Having this NEWLY ADDED rule enabled by default seems like a concern to me initially, I read this in the “what’s new” section and that immediately stood out to me. I figured we’d get a lot of customer noise on this one. The good news it – it is a new rule, so simply disable it, if you don’t care about this situation. It technically should be “fixed” but I see this all the time and most DBA’s just don’t care. The best reason to “fix” it – is because it floods your application event logs in many cases. The bad news is now we are flooding SCOM. 🙁

      1. Ah, thank you Kevin for the lightning response. Disabled the rule across our SQL engines…

        Love this kind of feedback, right from the horse! 😉


Skip to main content