Browsed by
Category: System Center

Manage Report Operator User Role in SCOM and SSRS 2016

Manage Report Operator User Role in SCOM and SSRS 2016

During the installation of SCOM 2016, you can choose to deploy the Reporting Server feature. This feature will provide the possibility to generate SQL Server Reporting Services (SSRS) reports based on SCOM data. During the installation, it will automatically configure the Operations Manager Report Operator default SCOM user role as System User of your SSRS site.

You can check it by getting the Identity Id in SCOM console and cross checking it with the security configuration of your SSRS site.

And by default, this SSRS user is only granted to Browser, My Reports and Report Builder roles. However, if you want to provide members of this SCOM User role to create a scheduled report, you will need to add Content Manager role to the SSRS user as shown below.

You should create another SCOM Report Operator user role instead of using the default one. But you will need to create a new user in your SSRS site by using the Identity Id of your new user role.
Enable Proxy as a default setting in SCOM 2016

Enable Proxy as a default setting in SCOM 2016

As you may know, the default setting for new SCOM agents is that proxy is disabled. You can enable this agent by agent in the console, or even use script automation. But as more and more management packs require this capability to be enabled (e.g. Active Directory, SharePoint, Clustering, etc.), it makes really more sense to just enable this by default.

In order to achieve this, just connect to a SCOM Management Server and run these PowerShell commands.

If you want to check the actual configuration of your SCOM environment settings, you can also run these commands.


Install SCOM 2016 PowerShell Modules without SCOM Console

Install SCOM 2016 PowerShell Modules without SCOM Console

If you work with SCOM and custom management packs, you are most likely using SCOM PowerShell modules. By default, these modules are installed with the console using SCOM setup. But one of my customers needed to install these modules on a Gateway Server installed on a Windows Server 2016 Core running custom PowerShell rules.

In order to install SCOM 2016 PowerShell Modules on a Windows Server or even on a Windows Client without having to install SCOM console and its prerequisites, follow the following steps.

First, you need to copy the PowerShell Modules source folder from a computer with the SCOM console installed to your target computer.

Additionally, to avoid any future error with the import of the OperationsManager, you have to create two additional empty folders (Console and Server) as below.

Then, you have to copy these 3 DLLs from the same source computer to a temporary folder on your target computer:

  • Microsoft.EnterpriseManagement.Core.dll
  • Microsoft.EnterpriseManagement.OperationsManager.dll
  • Microsoft.EnterpriseManagement.Runtime.dll

Once you copied these DLLs, you need to register them to your local GAC (Global Assembly Cache). The easiest way to accomplish this is to open a PowerShell session as Administrator and run these commands (replacing your temporary folder path if needed).

Finally, you need to set the module path to the local environment variables (as always modify path accordingly to your environment). It will simplify the import of these modules in your future PowerShell sessions.

And it’s done… As you can see above you can now import Operations Manager PowerShell modules easily.

You will obviously need to open a Management Group Connection to one of your Management Server with proper credentials, in order to use cmdlets.
You can delete DLLs in temporary folder on your target computer once you finished the import to your GAC.
Deploying VMware Veeam MP for SCOM

Deploying VMware Veeam MP for SCOM

This article covers the installation of the SCOM Veeam MP for VMware (version 8). If you are not aware, the Veeam Management Pack for System Center provides integration, monitoring, advanced reporting, and detailed topology features for virtualized systems and their hosts, and the associated network and storage fabric. This allows the virtual environment to be integrated into multiple System Center components, including System Center Operations Manager, Orchestrator, Virtual Machine Manager and Service Manager.

At this time, the Veeam MP for VMware solution utilizes the following components but I guess that these prerequisites will handle the new version of SCOM or VMware solutions.

  • SCOM 2012 SP1/SCOM 2012 R2
  • ESXi 4.x, 5.x, 6.0
  • vCenter Server 4.x, 5.x, 6.0

Additionally, the Veeam MP for VMware includes the following components.

  • Veeam VMware Collector (Collector) — gathers topology, event and performance data from VMware systems.
  • Veeam Virtualization Extensions Service (VE Service) — is used for centralized configuration of Veeam VMware Collectors, failover and load balancing control, and license distribution.
  • Veeam Virtualization Extensions UI (Veeam UI) — web-based (IIS) UI for configuration of the VE Service and the managed Collectors.
  • Veeam Management Pack (Veeam MP) — provide rich and flexible capabilities for VMware management, natively integrated with System Center. Advanced monitors, dashboards, and reports are included out-of-box.

For this deployment, we will install the solution based on this architecture.

We will deploy both Extensions UI and Extensions Service on a dedicated Management Server which is also used for SCOM Web Console. Note that Extensions Service component can only be installed on a Management Server.
Then we will deploy multiple collectors to handle the load of connections and workflows. These collectors will either be Management Server or Gateways depending on the existing SCOM infrastructure. To help us on the sizing of the architecture based on our VMware infrastructure, Veeam is providing a calculator through an Excel file.EXCEL CALCULATOR Before deploying the solution, I suggest you dedicate two GWs or MSs for VMware monitoring jobs. If you are using Management Servers, you should remove them from the All Management Servers Resource Pool (cf. previous article). In order to deploy Veeam MP solution in our environment, we will first install the Extensions UI and Extensions Service component by choosing this option on the installer screen.

You would need to provide a license during the installation. You can ask for a trial license directly on Veeam website.

Then, we will be asked to provide a specific user account to run Veeam Virtualization Extension service. And you need that this account is a member of local Administrators group on the server.

Note that this part of the setup will also import Veeam Management Packs in your SCOM environment.

Once setup is finished, it will ask to log off from the server. It will permit to apply Logon as server right to specified service account during installation.

You can then relog to the server and open UI Web console. Note that if you are installing the solution on Windows Server 2012 or above it will create a Metro IE shortcut. I never had any issues with this, so you can use it or choose your own browser as this console can be opened from other location such as your computer.

Besides, you can check that all Veeam Management Packs were successfully imported.

Then, we need to install the collectors. In this article, we will only deploy one collector on a SCOM Management Server. Note that you will need to add the collector’s computer account to the local group Veeam Virtualization Extensions Users (on VE server).

As for Virtualization Extensions service, we need to provide a service account to handle Veeam collector service. Note that this account must be a local administrator.

Finally, you need to fulfill the name and the port of the Veeam Virtualization Extensions Server (depending on what you configured previously).

Once the installation is done, you should see your collector in your web console.

Then, in order to enable monitoring of our VMware infrastructure, we will configure a connection to a VMware vCenter server. Note that the account used for this connection must have the following rights on VMware solution.

When the connection is successful, the console will display some recommendation to handle the load associated with the monitoring of this VMware infrastructure (Hosts, Datastores, VMs, etc.).

Once you finished to install all your collectors and configured your connections, you will need to wait some time (depending on your infrastructure) to retrieve all discovered objects and their health in SCOM console. For example, it took around 8 hours to discover 20 clusters, 100 hosts, 300 datastores and 2500 VMs.

Automatic and Manual Resource Pool Membership in SCOM

Automatic and Manual Resource Pool Membership in SCOM

One of the new features in System Center 2012 – Operations Manager was the Resource Pool. A resource pool is a collection of management servers and/or gateway servers used to distribute work amongst themselves and take over work from a failed member. And by default, there are three resource pools.

  • AD Assignment Resource Pool
  • All Management Servers Resource Pool
  • Notifications Resource Pool

But from experience, Gateways and Management Servers should not be mixed in pools. Besides, in some situations, you will need to modify the membership of SCOM Resource pools and especially the All Management Servers Resource Pool. Most of these situations are listed below.

  • Network Monitoring:
  • UNIX/Linux Monitoring: Management Servers in charge of UNIX/Linux monitoring should be removed from the default pools and added to a custom one.
  • Web Application Availability
  • Veeam MP
  • Custom Workflow

For all of these situations, Management Servers in charge of this monitoring should be removed from the default pools and added to a custom one. But by default, these default pools are in automatic membership and cannot be changed directly from the console as it is in read-only. To accomplish this, you will need to use this PowerShell command.

Then you will be able to add/remove Management Servers and Gateways from your Resource Pool. But if you remove some Management Servers from the All Management Servers Resource Pool, you will need to adjust distribution configuration of the Data Warehouse Account and Data Warehouse Report Deployment Account. Otherwise, these Management Servers will become grayed out and won’t function properly.

Modify PowerShell Version of Orchestrator “Run .Net Script” Activity

Modify PowerShell Version of Orchestrator “Run .Net Script” Activity

By default System Center Orchestrator 2012 (event R2 latest CU), Run .Net Script activity will launch PowerShell in v2 and x86 mode. But nowadays, the Orchestrator runbook service is installed on Windows Server 2012/Windows Server 2012 R2 or even Windows Server 2016 who used natively at least Powershell v3 and above. Besides a lot of useful modules and cmdlets are implemented in PowerShell v3 and above.
In fact, you can already get around the problem by running the script remotely on another server or an instance of PowerShell shell using: PowerShell {Your Script}, but in both cases, we loose the possibility to publish all variables to the data bus.

In order to change this, if the server executing the Orchestrator runbook service use PowerShell v3 or above, you can change a registry value to use the same version in your activity.

The registry value OnlyUseLatestCLR, that needs to be equal to as above (0 by default) is located:

To apply the changes you don’t even need to restart Orchestrator services. In fact, you can verify that change has occurred by running this activity in a runbook.

Remove List of SCOM Orphaned Agents in PowerShell

Remove List of SCOM Orphaned Agents in PowerShell

I faced this need for a customer need, so I wanted to share with you this little article. In order to remove a list of SCOM orphaned agents (e.g. computer doesn’t exist anymore) you can use this script. Obviously, it will only remove agents from SCOM console, but it will not uninstall agent from the computer (we will see how to manage this in another article).

You can actually use either a plain list of gray agents or .csv file as input of the array.

Restart Windows Computer Remotely Through a SCOM Agent Task

Restart Windows Computer Remotely Through a SCOM Agent Task

One of the needs of my customer was to be able to reboot any Windows computer (with SCOM agent) remotely without having local administrator rights. I figured out that the best way to accomplish this would be to create a SCOM agent task (not a console task), that you can call from anywhere (script, runbook, etc.). The main advantage is that tasks run under the credential of the Default Action Account on the agent computer. This account typically has sufficient privileges for accessing most application components and running actions, even if the user running the tanks does not have these user rights.

To create this agent task you can use your favorite tools, in my case I will create this task in a new Management Pack fragment on my visual studio solution. You can find below the XML source code for this agent task.

Once you have imported your management pack containing this agent task, you can launch the task from one of your MS for example, through these PowerShell lines.

You will have an associate output in your Powershell windows with the status of the task. You can also retrieve the information directly in the Task Status view on your SCOM console.

SCOM Maintenance Mode for Windows Cluster

SCOM Maintenance Mode for Windows Cluster

You may already use some scripts to put Windows servers in maintenance mode, but sometimes you need to handle the fact that targeted Windows computers are part of a Windows cluster. In this case, you will need put all of the cluster objects in maintenance mode otherwise, SCOM will generate an alert (by default) for network, disks, etc.

So, I wrote a little PowerShell script to check if a Windows computer is part of a Windows cluster in SCOM, and put all related objects in maintenance mode.


The script accepts five parameters: objectName, maintenanceType, description, duration and managementServer.

The FQDN of the SCOM Windows Computer in the SCOM Management Group that you want to put in maintenance mode.

The type of maintenance based on what you can find in the console.

The description that explains the reason for maintenance mode.

The duration time in minutes of maintenance mode.

The FQDN of the SCOM Management Server that you want to launch maintenance mode.


You can retrieve and download this script directly on TechNet gallery here.

How to Add Overridable Parameters to a SCOM Monitor Type

How to Add Overridable Parameters to a SCOM Monitor Type

When you create a monitor unit in SCOM you need to specify a monitor type that defines the schema, operation, parameters of the monitor. But sometimes you need more parameters or functionalities than default monitor types provided by Microsoft for example.

In this case, a client needed the possibility to override thresholds values of a custom management pack monitor directly from the console. At first, it was not possible because the monitor was based on standard Microsoft monitor type: Microsoft.Windows.TimedScript.ThreeStateMonitorType. This monitor type as indicated by his name is a three state monitor used to run a script against a specific target to retrieve specific values. Additionally, this monitor type is based on the standard data source module type Microsoft.Windows.TimedScript.PropertyBagProvider.

In order to add the possibility to override threshold values of this monitor, the only solution was to rewrite the data source module type and the monitor type. In this example, we will see how to add a warning and critical overridable parameters.

So first, you’ll need to write your own data source module type. In this case, the easiest way to handle that is to copy/paste source code of the original data source and add parameters that you want to override. As you can see below, I added my two parameters (Warning Threshold, Critical Threshold) to the configuration schema and overridable parameters blocks.

Then, you need to create your monitor type that will use this data source module type. As this monitor type is also based on an existing monitor type, just copy/paste source code. And as for the data source module type, you will need to add your parameters to the configuration schema and overridable parameters blocks.

Then, you’ll need to call the data source module type that we created and build your conditions detection depending your needs. In this case, it is a three state monitor based on a script, so you need to create 3 condition detection based on your parameters. For this monitor type, the configuration of conditions is:

  • Healthy, when the value of the property named Value in the script will be greater than the value of the Warning Threshold parameter.
  • Warning, when the value of the property named Value in the script will be less or equal than the value of the Warning Threshold parameter AND when the value of the property named Value in the script will greater than the value of the Critical Threshold parameter.
  • Critical, when the value of the property named Value in the script will be less or equal than the value of the Critical Threshold parameter.

You can see a part of the configuration in the picture below. Just for information, you can also define these expressions directly in the monitor rather than in the monitor type. It depends on your needs.

Finally, you can create your monitor based on your previously created monitor type id and define your overridable parameters.

You can then verify in SCOM that you can override your parameters directly from the console.

You can retrieve MP source code of this example here. Enjoy.