Operations Shell–Using different credentials

Some companies setup their user accounts and then provide an administrator account, and maybe only the administrator account is a member of the Operations Manager Administrator user role. The Operations Console provides a login screen, so it’s not a problem authenticating to the management group. But the Operations Shell does not provide a login option – it will automatically attempt to login using the context of the current user.

This results in an access denied message:

New-SCOMManagementGroupConnection : The user does not have sufficient permission to perform the operation.


One way to get around this is to use the Powershell Get-Credential cmdlet. Add this to the beginning of administrative scripts or start your console sessions with:


$Credentials = Get-Credential –UserName [domain\username] -Message "Enter password"

$MS = [your management server name]

New-SCOMManagementGroupConnection -ComputerName $MS -Credential $Credentials



Report Server – The underlying connection was closed

I ran into an issue while helping a customer install reporting services. I haven’t seen this problem before, so thought it might be helpful to share with the community.

After installing SQL Reporting Services 2012, and choosing to automatically configure the default instance during the setup process, the main SRS page displayed an error:

“The underlying connection was closed. Could not establish trust relationship for the ssl/tls secure channel.”


Choosing to have the SQL installation wizard to configure SRS automatically has always resulted in success for me until now, so this was a bit disconcerting. Long story short, the issue was fixed by updating the rsreportserver.xml config file SecureConnectionLevel value from 2 to 0. I don’t know why the wizard set this value to 2, assuming SSL would be used, but explicitly disabling this solved the problem in this case.

Additionally, when installing the SCOM Report Server role, the wizard failed after selecting the SRS instance. Removing the SSL bindings completely in the Reporting Services Configuration Management tool solved that problem as well.



7 years of blogging about Operations Manager – wow!

I was looking at referrer statistics for this blog, and noticed that many people still arrive here by clicking on a link in the very last blog post from my previous Microsoft Technet blog. It’s been a while since I’ve visited the old blog, but I do actually still refer to it from time to time – and looking at the archive list I noticed that I am coming up on a 7 year anniversary.

That’s right – I cannot believe I’ve been blogging about Operations Manager since December, 2007!

My very first blog post was about a bug in the UI that didn’t add a reference to the management pack. LOL – it can be fun looking back on history sometimes! I get a sense of satisfaction that I have contributed so much to the Operations Manager community – through my blogs, the Technet forums, the Unleashed book, my projects site, etc…

I encourage you all to share your knowledge in your own way, because this body of work is quite literally the first knowledge base anyone will check before pioneering there own solution.



Create a class – visual studio authoring extensions (vsae)

In this post, I want to demonstrate how easy it is to create a class using Visual Studio Authoring Extensions. This is in response to some blog posts out there (like this one and this one) that describe this task as “difficult” outside of a 3rd party tool. It’s actually extremely easy!

Let’s take a look at how easy it is to create a class using VSAE.

<ClassType ID="ToolAndDie.Class.Computer" Abstract="false" Accessibility="Public" Base="Windows!Microsoft.Windows.ComputerRole" Hosted="true" Singleton="false" />

Yep – it’s really that easy to create a class. Now all you need to do is discover it, and it’s actually just as easy to do that, especially if you’re using the registry.

My suggestion is, if you are new to authoring management packs, just take the leap into VSAE. There is no benefit in using 3rd party tools, like MP Author by Silect. I say that because, you’re not really picking up a new skillset by using these types of UI tools – however, you do pickup a new skillset that can be useful in other areas of your job by learning the language (XML).

There is a learning curve to everything – make the wise choice for your career.

Best Practices – Alert Priority

It’s been a while since I’ve written a best practices article. I thought about an interesting one the other day I wanted to share. Alert priority is one of those configuration elements that seems to stay tucked under the covers in the vast majority of environments that I’ve worked in, but it can be an integral piece of operations – it’s also something to consider when developing management packs.

Because of this, I think it’s a good idea to take a look at alert priority from two perspectives; development and operations.

Development Perspective

This is a well known practice for management pack development, but I’ve actually seen vendors not adhere to this practice in their management packs (including Microsoft). That is – alert priority should ALMOST ALWAYS be set to medium in a management pack. A developer should not presume the priority of an alert for a couple reasons:

1. Developers do not know what a customer considers high priority, and;

2. Customers should have the ability to freely use alert priority in processing alerts without having adverse effects.

The only case a developer should set alert priority as anything but medium, is to set is as low priority. In no case should a management pack be sealed with any alert priority being set to high.

Operations Perspective

Alert priority can be an integral part of processing alerts. Whether a command channel is implemented, another System Center product is used (Orchestrator or Service Manager), or perhaps a 3rd party product connects to your environment; Alert priority should be one of the top 3 criteria in determining whether an alert should be processed.

Fortunately, most vendor management packs do set default alert priority to medium (or low). Hopefully the days are gone when some developers set default alert priority to high.

This means that you, as a SCOM administrator, can easily add alert priority as a criteria for alert processing. This can be accomplished by setting overrides for select alert-generating unit monitors and rules. In my opinion, the best way to go about this is to use MPViewer, because you can export the management pack to an Excel spreadsheet and hand that to the group that monitors the application for review.

Once the application group has reviewed the spreadsheet and selected the alerts in which they want to be notified on, they send it back and the SCOM team can set overrides on those workflows by updating alert priority to high. If your company employs the Advanced Operators role, then there is really nothing you need to do but provide them with the spreadsheet, because then you can assign a member of the application team the privilege to update alert priority based on their requirements and when they want. The latter will dramatically reduce administrative overhead, and overall this would reduce complexity of subscriptions.

Finally, the benefit of using alert priority as a processing criteria is enormous. For example: if you just select all classes of the SQL management pack to send email notifications to the database administration team, the potential for them to ignore all email notifications is high; however, if alert priority is implemented correctly, you enhance the user experience by only sending notifications that the application team actually want to receive. This is a win-win situation.


If you have any best practices suggestions you’d like me to write about, let me know in the comments section or send me an email. Thanks for your readership 🙂