Update and Recommendation feature was introduced in SCOM 2016  for Microsoft owned Management Packs  . This feature was introduced to alleviate the challenges involved in discovering the appropriate Management Packs for various workloads running in the customer’s environment from different websites on the internet and staying up to date with the latest versions of the Management Packs.

With this feature, the customer is able to automatically discover various workloads(for which the Management Pack exists) running in their environment that is managed by the SCOM server and it would recommend appropriate Management Packs (including the latest version or missing Management Packs) that can be imported to monitor the workloads. This feature is enabled for 110+ Microsoft workloads, for which the customers can easily download and import the Management Packs without having to search those on the internet at all.

We are extending this feature to support Management Packs authored and offered by several external technologies and consulting partners of SCOM. Partners have extended their support by signing up with SCOM team to onboard their Management Packs to ease the Management Pack discovery problem solved by this feature. With the partner support, this feature is now able to recommend Management Packs for both Microsoft and non-Microsoft workloads.

In the Operations Manager 1801 release, we are starting with onboarding Management Packs  from the following external partners:

1. Calcomp – CHS Suite
2. Comtrade – Nutanix, F5 BIG-IP
3. Infront Consulting – RightFax, SC Orchestrator, McAfee, and Isilon
4. NiCE – IBM Domino, Oracle, and DB2
5. Opslogix – BlackBerry, IBM MQ, Oracle, Swift, and VMware
6. Savision – ActiveDirectory, Exchange 2013, Exchange_2010, DynamicsCRM, SharePoint 2013, SkypeForBusiness 2015, SystemCenterConfigurationManager 2012, DHCP, DNS, RemoteDesktopServices, and Lync Server 2013

The UI experience of the Update and Recommendation feature in the Operations Manager console is enhanced to indicate the company that owns the Management Pack as shown in the screenshot below. For non-Microsoft workloads, Get MP action will navigate the user to the Partner website with the MP details .

Please share your feedback on User Voice. If you are an Management Pack partner and want to onboard your Management Packs, please write to us at mpgfeed@microsoft.com.

About 

This series of blogs intends to introduce the new SCOM Web Console released in System Center Operations Manager 1801. For details on implementation and other parameters please refer to the detailed documentation. This blog is designed to be a bit more informal and describes the different features by associating them to use cases.
The series is divided into different parts and it is recommended to read them in order for better understanding. 

After going through this series of blogs a user would: 

• Get a fair idea about the new SCOM Web Console and the different features added to it 
• Understand the new dashboard capability 
• Understand the different widgets and their customizations 
• Learn about the different dashboard and widget actions 

• Learn about the drilldown feature and how it can be used to investigate issues 
• Get a walkthrough on how to create a custom web application on SCOM REST APIs 

This series consists of the following other blogs:

• New SCOM Web Console – Blog series (Post 2/5): The all new Dashboards
• New SCOM Web Console – Blog series (Post 3/5): The new HTML5 Widgets
• New SCOM Web Console – Blog series (Post 4/5): The all new Drilldown experience
• New SCOM Web Console – Blog series (Post 5/5): Sample Custom Dashboard walkthrough

What’s new in SCOM 1801 Web Console? 

The SCOM 1801 release marks the inception of a faster, modern, flexible and more reliable HTML based Web Console. The Web Console has been given a complete reboot to ensure that it fulfills modern day monitoring needs (and yes, it is now completely free from Silverlight!). 
This is another step towards our continuous commitment to the SCOM community and we would like to give a big thanks to all our customers who voted this as the top most requested feature in SCOM User Voice. We are really excited about this new Web Console and we strongly believe that you’d just fall in love with it!  

Still using Silverlight? Don’t worry, we’ve got that covered too! The Silverlight dashboards are available in a new URL:
http://<Your_Web_Server_Name>/Dashboard 

Authentication 

The new SCOM Web Console brings back the network authentication! This is what you’d see when you visit the Web Console for the first time:
 

Choose your preferred login option and you are in, welcome to the new SCOM Web Console! 

 Recommended Next: New SCOM Web Console – Blog series (Post 2/5): The all new Dashboards

About

This blog aims at introducing the all new HTML5 based dashboard functionality added to SCOM 1801 release. For details on implementation and other parameters please refer to the detailed documentation.
After going through this blog, a user would:

• Understand the new dashboard capability
• Learn about the different dashboard actions

The all new Dashboards

The SCOM 1801  Web Console introduces the all new, fully customizable, dashboards. These dashboards are built and fine-tuned keeping in mind the huge volume of IT monitoring data. This ensures that you get next to real-time monitoring information without compromising on performance.
The dashboards, being built in HTML5, support a wide range of modern browsers including Internet Explorer, Microsoft Edge, Google Chrome and Mozilla Firefox.

Below is a screenshot of a sample dashboard:

As portrayed in the above screenshot, a dashboard is comprised of multiple widgets. These widgets can be completely configured for data, display and positioning within the dashboard in a manner that best suits your needs.
Currently the dashboard supports the following widgets:

• Alert Widget
• State Widget
• Performance Widget
• Topology Widget
• Tile Widget
• Custom Widget

Dashboard Actions

The dashboard supports the following actions:

Creating a dashboard

You can create a new dashboard by selecting the “+ New Dashboard” option in the navigation tree as shown below:

This would popup a right pane as follows:

Wish to add this dashboard in a new MP? Don’t worry, you needn’t go back to the SCOM console. Just hit the “+” next to the MP list and you’d get a section allowing you to create a new MP and add this dashboard to it.

It really is that simple!

Deleting a dashboard

To delete a dashboard simply hit the “Delete Dashboard” button on top and when prompted hit “Yes”

Editing a dashboard

The edit operation allows the user to edit the name of the dashboard as well as the layout of the widgets added to it.
Once you hit the edit action, the dashboard name becomes an editable field.

Also, all the widgets can now be dragged and resized. This is really useful when you want to club together the widgets targeted to similar objects/groups.

Once you are done, hit “Save Changes” and your layout is saved!

Adding a Widget

When you create a new dashboard it is empty and has no widgets. You can click on the “+ Add Widget” action on top of the dashboard that would lead to the right pane popping up as shown below:

There are lots of widgets that are shipped in box. All of them are discussed in detail in the next part.

Viewing in Full Screen

Wish to only view the dashboard in a big screen like a projector? That’s now possible!
Hit the “View in Full Screen” link on top of the dashboard and you’d get a full screen view of the dashboard.

Exporting Dashboards

Dashboard once created can easily be exported. To export a dashboard, the user simply needs to export the management pack in which the dashboard is stored. If you drilldown into the exported management pack, you’d observe that the dashboard is defined as a view. So for ex. If a dashboard is created as shown below:

Then the generated MP would look like this (note below just a snippet from the MP is taken to avoid clutter):

Note the TypeID of the view. This is a new TypeID introduced for HTML dashboards. Rest of the structure of the MP is pretty similar to any other view.

Recommended Next: New SCOM Web Console – Blog series (Post 3/5): The new HTML5 Widgets

About

This blog aims at introducing the all new HTML5 based widgets added as part of the new dashboards with  . For details on implementation and other parameters please refer to the detailed documentation.
After going through this blog a user would:

• Understand what are all the new widgets
• Learn about the different widget actions

It is highly recommended to read the previous blog in this series for better understanding.

The new HTML5 Widgets

There are a total of 6 widgets that are shipped with SCOM 1801 :

• Alert Widget
• State Widget
• Performance Widget
• Topology Widget
• Tile Widget
• Custom Widget

These widgets are designed to be fast and robust. It’s quick to load, unlike Silverlight. The widgets support a high level of customization to ensure that they can be used effectively by one and all.
One important thing to note is that the data refresh for these widgets happens in the background at the defined interval (or you can do a force refresh). This way you always have some data to work on while the new chunk is being fetched in the background. Thus, the widgets and the dashboard in general feels a lot more responsive.

Widgets are stored in the management packs as views. Below is a snippet from a management pack containing a “Tile widget”

Note the TypeID. This is a new TypeID introduced for HTML widgets.

Types of Widgets

Alert Widget

This widget displays the list of alerts for a given criteria. Refer to the authoring parameters section below to learn more about the customizations that can be done.

Authoring Parameters

When you start off with the authoring for alert widgets you’d see something like this:

As clear from above there are 4 sections at high level:
Scope

In this section you can define the groups/objects to which this widget is to be targeted. For ex. If you enter “All Windows Computers” then this widget would show the alerts targeted to “All Windows Computers”.

Criteria

Here you can filter alerts based on their severity, priority, resolution state and age.
Take note of the age parameter. At times you might get better performance out of this widget if you select a suitable value for the age parameter.

Display

Here you can select what all columns you wish to see in the widget. Additionally you may select a column with which you wish to group the alerts.

Completion

Finally you give the widget a name and description and you’re done!

Optionally you may specify the refresh interval (minimum value 1 minute) in which the widget would refresh its data.

Actions

Alert widget supports the following actions:

Setting resolution state

You can select one or more alerts and select this action. Once selected it’d open the right pane where you set the state and give an optional comment.

Exporting to Excel

The data shown in the widget can be exported in excel format. This helps when you wish to do any custom analysis on the data by leveraging the power of Excel.

Personalization

Widgets can be personalized for each user. Each user can select the column they wish to see and the grouping they wish to apply. In other words “Personalization” is like the “Display” section shown in authoring.
Note: The selection made in “Personalization” would always overwrite the selection made in the “Display” section. Also note that personalization data is stored in the browser in the current system and thus if you switch browsers or machine
then you’d have to re-personalize the widgets.

Edit & Delete Widget
As the name suggests you can edit and delete this widget from a dashboard. Note: This action is permanent and all the users having access to these dashboards would be affected by it.

State Widget

The state widget displays the health state information about the targeted entities satisfying a particular criterion. Refer to the authoring parameters section below to learn more about the customizations that can be done on this widget.

Authoring Parameters

When you start off with the authoring for state widgets you’d see something like this:

As clear from above there are 4 sections at high level:
Scope

In this section you can define the groups/objects to which this widget is to be targeted. For ex. If you enter “All Windows Computers” then this widget would show the health state information targeted to “All Windows Computers”.
There is another required parameter, class.
You also have the option here to get the health state of the group or the entities contained in that group which are the individual objects.

Criteria

Here you can set the filter to see the entities only in particular health states.

Display & Completion

Display and completion section of the state widget is similar to that of Alert Widget except for one difference. The display columns for the state widget are defined as per the “class” selected in the Scope section whereas the alert widget has fixed display columns.

Actions

State widget supports the following actions:

All of these are exactly similar to what has been defined for alert widget above.

Performance Widget

The performance widget displays the information about the different counters associated with the entity. Refer to the authoring parameters section below to learn more about the customizations that can be done on this widget.

Authoring Parameters

When you start off with the authoring for performance widgets you’d see something like this:

As clear from above there are 5 sections at high level:
Scope

In this section you can define the groups/objects to which this widget is to be targeted. For ex. If you enter “All Windows Computers” then this widget would show the health state information targeted to “All Windows Computers”.

Metrics

Here you can select the object, counter and instance triplet whose data would be displayed in the widget.

Criteria

Here you can specify the age of data that you are interested in.

Display

This section is important. If you wish to visualize the widget with a graph then the above act as legend columns. If you wish to only see these columns then you can check “Visualize objects by performance”. Then you’d only see the table without the graph.

Completion

This section is similar to Alert widget.

Actions

Performance widget supports the following actions:

All of these are exactly similar to what has been defined for alert widget above except for “Set Vertical Axis”. With this action you can specify a range and the graph is scoped to that. This is useful when you are trying to drilldown on particular events. This is how it looks like:

Topology Widget

Have a Visio or other image of your IT topology? Wish there was a way to map the health states to these entities? Then topology widget is what you are looking for. Refer to the authoring parameters section below to learn more about the customizations that can be done on this widget.

Authoring Parameters

As clear from above there are 3 sections at high level:
Scope

This is exactly similar as State Widget.

Display

This is the section where you upload and select your IT topology image:

Completion

Similar to State Widget.

Actions

When a topology widget is created, you’d see all the health icons placed at the top left corner. Drag the icons and place them at relevant places on the image and hit save once you are done. Below image shows an example of how  it works.

Apart from this, the topology widget supports the standard edit and delete widget actions.

Tile Widget

Need a quick way to investigate the health of an entity and the current alerts generated on it? Tile widget is the answer for you. This is the smallest widget (size wise) in the dashboard. Below is a sample tile widget:

As can be seen clearly, the current health state of “All Windows Computers” group is Warning state. This is because the availability monitor is in warning state resulting in the health rollup.

Authoring Parameters

The authoring for tile widget is very straightforward and is like a subset of “Alert Widget” as can be seen in the image below:

Actions

Apart from edit and delete widget the user can launch the health explorer for the target entity from topology widget. Isn’t that cool?

Use the health explorer to dig down further on the health state of the entity and its monitors

Custom Widget

SCOM 1801 release marks the inception of REST based APIs to fetch SCOM data thus giving birth to custom widget. With custom widget, you could bring in any custom html code and it’d get rendered as a widget which could then reside with other widgets in the dashboard. This brings in a whole new strength to the dashboards since the power to manipulate and render the data is completely up to you. For sample scripts to talk to REST APIs, please visit the official documentation here.

Below is a diagram to show how custom widget works:

For details about SCOM REST APIs visit here <<Insert link to SCOM REST APIs>>. Below is a screenshot showing custom widget in action:

Authoring Parameters

The authoring of custom widget is straightforward and requires just an HTML source code. Note if you have any JavaScript (which you most probably would have) you’ll have to insert it inline with the HTML code. Below is a screenshot taken while authoring custom widget with a basic HTML code:

Below is an image taken from the detailed documentation:

Can you figure out which are the custom widgets above? If your answer is no, then that’s exactly how we intended it to be! The custom widget simply blends with other widgets in the dashboard and once created acts no differently from the other widgets. Well, if your answer was yes then we’ve got to give it to you, you are really insightful

Actions

Custom widget supports the basic edit and delete widget actions. But this in no way limits you to innovate! You can define and design custom actions for your custom widgets which could then reside in the widget container. The limit here is just your imagination!

Recommended Next: New SCOM Web Console – Blog series (Post 4/5): The all new Drilldown experience

About

This blog aims at introducing the all new drilldown experience added as part of the new dashboard with SCOM 1801 release.  For details on implementation and other parameters please refer to the
After going through this blog a user would:

• Understand what the new drilldown feature is.
• Get a brief understanding of how drilldown feature can be used for better monitoring.

The all new Drilldown experience

The new SCOM dashboards come with the drilldown feature which, as the name suggests, allows you to drilldown into a problem and get more insights about the situation. This is helpful in root causing the issue and in identifying what all components are affected by the problem. There are five type of drilldown pages:

1. Alert page
2. SCOM Group/Object page
3. SCOM Class page
4. Rule Page
5. Monitor Page

These pages are dashboards of their own comprising of different widgets. The widgets present in these dashboards take up the context at runtime and scope their data to the current target entity. For ex. take a look at the below URL for alert drilldown page:
http://<server_name>/OperationsManager/#/monitoring/drilldown/alert/023e5e00-e9e9-4d81-8135-052bf935062f/dashboard/d0d82ac8-215b-3b77-7a3b-8bef450796e3?mpId=da187e72-b9d7-9e16-d098-3b0a624dc38c&show_full_screen_link=false&hide_header=true

The highlighted section tells the Alert drilldown page to display data in all widgets targeted to this alert. This makes sharing the drilldown pages within the organization super easy. All you need to do is share the URL and people can start off from there.

How to drilldown?

Well, the next obvious question is how to use the drilldown feature? The answer to that is simple. Some of the widgets discussed in 2. The all new HTML5 widgets and their actions allow you to click a row/entity from the data. Once you make your selection the drilldown page is launched. For ex. consider the state widget below:

Now when you click on any of the row above the Group/Object drilldown page is launched. That page then has widgets displaying all sorts of relevant data targeted to the selected row from the state widget.

Which drilldown page leads to where?

The starting point of drilldown could be either a row from the alert widget, a row from the state widget or a health icon from the topology widget. The user can then navigate to the other drilldown pages by clicking on items present in the widgets of the current drilldown page. Below diagram shows the path a user can navigate during drilldown.

For ex: from a State widget the user can drilldown and land at the SCOM Group/Object drilldown page and from there they can click one of the unhealthy monitors and land up in the Monitor Drilldown page.

Drilldown pages deep dive

Alert drilldown page

The alert drilldown page contains detailed information about the alert. Below is a screenshot of how the alert drilldown page looks like:

As clear from the above screenshot the alert drilldown page has 6 widgets. These represent the following data from left to right and top to bottom:

1. Alert description: Here you will get detailed description for the alert like the workflow name, instance name etc.
2. Alert context: All the context information for this alert would be displayed here
3. Company knowledge: Any added company knowledge for the underlying rule or monitor for this alert would be displayed here. Read the text in the company knowledge widget above, you may discover a cool new feature . Yes, you read it right, now SCOM supports adding HTML based company knowledge right from the Web Console.
   Just hit the ellipses icon (…) and you shall see a “Edit Company Knowledge” action. Fill in the company knowledge in the editor that shows up, choose the MP and hit save!
   Below are just some screenshots showing the flow:
   • Select the action
     
   • Enter the company knowledge
     
   • Choose MP (or create new one) and save
     
4. Product knowledge: Here you will see the product knowledge added for the corresponding rule or monitor.
5. Rule Properties: Would display the properties of the rule that generated this alert. It is blank in the above screenshot since this alert came from a monitor.
6. History: Would show the history of changes to the resolution state of the alert.

Use cases

Scenario 1: Adding company knowledge without the burden of desktop console and Word

Many a times there are alerts which come up frequently in an environment. You might want to add information for your fellow operators to help them save time. But you don’t have access to Operations Console and an active Word deployment. This is where the Company knowledge widget in alert drilldown comes in handy. Just click the alert and once the “Alert drilldown page” opens up start editing the company knowledge without having to depend on Word or Operations Console.

SCOM Group/Object drilldown page

The SCOM Group/Object drilldown page shows detailed information about a SCOM Group/Object. Below is a screenshot of a sample SCOM Group/Object drilldown page:

As is evident from above the SCOM Object/Group page consists of 2 dashboards. The first one is the object information dashboard. This dashboard consists of 5 widgets:

1. Object relationship and properties widget: This widget shows all the related objects to the current object along with their properties to the right. You can select any of the items from this diagram and the properties on the right would get updated. Notice the small health state icons on top of each entity. This would help you figure out if there are any related entities which are at the crucial stage too!
2. Warning and critical alerts generated on this object
3. The unhealthy monitors targeted on the current object. This is a really useful widget and can effectively tell you about the root cause for the critical or warning health state of the entity.
4. Performance metrics: This widget is like a “Object By Performance Widget” and displays all the performance metrics related information for the current target object.
5. Classes widget: All the classes the current entity belongs to is displayed in this widget.

The second one is the Performance dashboard. This dashboard shows one performance widget each for every performance object of the current entity. Below is an example:

User cases

This section tries to narrate a few possible scenarios which you might face regularly and where drilldown can really come in handy.

Scenario 1: A server in the environment is reporting a critical health state

In this case the user can click that server in the state widget and can launch the SCOM Group/Object drilldown page. Here you will find lots of valuable information which’d help you root cause and figure out the issue.
What all can you do to investigate the issue?

• Check the related objects widget and see if some underlying entity is critical. For example, the hard drive might on the server may be critical (say because of less space) and thus the health of the server rolled up to be critical. Now you know you need to check the hard drive. This way you can keep drilling down and get to the root cause of the issue
• Check the currently active alerts generated on this server. There would most probably be an alert sitting there clearly calling out the problem.
• Check the unhealthy monitors widget if it contains any entries.
• Check the performance metrics and see if there is any unusual behavior or spikes.

You are highly likely to discover the root problem with the above-mentioned steps. If not, then keep drilling down wherever you find anything suspicious.

Scenario 2: A server is reporting delays and unexpected behavior

Now is a good time to check for the performance data collected from the server. Simply select the server from a state widget and then once the “SCOM Group/Object drilldown page” opens, select the 2^nd tab “Performance”. Here you’d see all the performance data collected from the server and you most probably should see a spike or abnormal behavior.

SCOM Class drilldown page

The SCOM Class drilldown page gives information about a SCOM class. Below is a sample screenshot of how the SCOM class page looks like:

This drilldown page has 3 widgets:

1. Class properties widget displaying all the properties of the class
2. Rule widget: Showing information about all the rules targeted to this class
3. Monitor widget: Showing information about all the monitors targeted to this class

Use Cases

Scenario 1: Figuring out all targeted rules and monitors of a class

Not only that you can then even go ahead and look up those rules/monitors and even modify their company knowledge.

Rule drilldown page

The Rule drilldown page shows detailed information about a SCOM Rule. Below is a sample screenshot:

The Rule drilldown page has 4 widgets.

1. The rule properties widget displaying all the properties of the rule.
2. A rule configuration widget displaying the configuration of the rule as present in the management pack
3. A company knowledge widget where the user can see the company knowledge for this rule. Users can also edit the company knowledge here if they have sufficient permission.
4. A product knowledge widget where the user can see the product knowledge for the rule.

Use Cases

Scenario 1: You want to check the rule properties and/or modify the company knowledge

Monitor drilldown page

The Monitor drilldown page shows detailed information about a SCOM Monitor. Below is a sample screenshot:

The Monitor drilldown page has 3 widgets.

1. The monitor properties widget displaying all the properties of the monitor.
2. A company knowledge widget where the user can see the company knowledge for this monitor. Users can also edit the company knowledge here if they have sufficient permission.
3. A product knowledge widget where the user can see the product knowledge for the monitor.

Use Cases

Scenario 1: You want to check the monitor properties and/or modify the company knowledge

Recommended Next: New SCOM Web Console – Blog series (Post 5/5): Sample Custom Dashboard walkthrough

About

SCOM 1801 marks the release of REST APIs for SCOM SDK. Using these APIs a user can create any custom client application of their own. This blog aims at walking the user through a scenario where a complete standalone application is developed and deployed using the SCOM REST APIs. This application can even be brought inside the Web Console using Custom Widget and can be made to reside next to any of the widgets shipped by SCOM.

It is highly recommended to go through the other previous blogs in the series to better understand the content provided here.

What does the sample comprise of?

The sample is a JavaScript based application that is communicating with SCOM SDK and displaying data to the user who can take further action on the same. We have also tried to stretch the limit of custom widget here by not only limiting it to be used as a widget but rather as a standalone application in itself. This application could then be rendered as a dashboard or a widget, we leave the choice to you. The sample comprises of two major sections:

• Overview Dashboard
• Search Dashboard

Overview Dashboard

This is a view designed to give a quick overview about the current monitoring state. It can act as a starting page using which you can proceed with further actions. Below is a screenshot of how the Overview Dashboard looks like:

As displayed in the image above the Overview Dashboard has two major sections:

• Active Alerts
• Health States

Active Alerts

This section shows the active alerts for the past 7 days in three categories namely critical, warning and informational alerts. If you are interested, you may dive into the individual alerts by clicking “View Details”. For example if you click on “View Details” under critical alerts, you’d see a view like:

Need more information? You got it!
Each of these rows are clickable and would take you to our very own drilldown pages  (refer to blog 4/5 for more details on drilldown).

Once an alert above is clicked, it launches the following drilldown page:

As you can see, there is a lot more detail about the alert here which would help you in further investigating the issue.

Health States

For a given target class and given target object group you’d see the health states in three buckets namely unhealthy, in maintenance mode and healthy. The target class and target group field can be modified and the health state information displayed below would modify as per the new input. By default this view shows health state information about the “Windows Computer” SCOM class.
Similar to alert you can see the details of the entity by clicking “View Details”:

And yes, you guessed it right. We have drilldown pages for these entities as well! Here’s how they look like:

There is a bunch of information about the entity here like related objects (their health states and properties), the alerts targeted to this entity, performance metrics and the classes this entity belongs to. Most of the entries shown above can be drilled down further giving a more detailed view. Again, going over all the details is out of scope for this blog and we’d strongly recommend going over through the detailed documentation.

Search Dashboard

Know what you are looking for but hate to go over multiple pages and views in the current desktop or web console? Then this search section is designed just for you!
Here you can search for any active alert (for the last 7 days), SCOM object, SCOM group, SCOM class, rule or any monitor. The search is asynchronous and quite fast. It’d help you choose the starting point using which you can further drilldown. Below is a screenshot of how search looks like (say you search for the term “health”):

And that’s not it! Remember drilldown? From all of these search results you can jump to their drilldown pages and proceed with any action you may wish!
Below are a couple of screenshots portraying what you can expect after clicking these results (you have already seen the alert and object drilldown pages above when we were at Overview Dashboard):

Clicking a rule:

Clicking a monitor:

Well this is just the beginning! The intention of walking you over this sample application was to show you the power custom widget and in turn, the SCOM REST APIs provide. With a few lines of code, one can achieve functionality which would otherwise have taken a lot more steps.
Feel free to go through the SCOM REST API documentation and create your own user stories and your own custom widgets!

Deployment

There are multiple ways you can deploy the sample dashboard discussed in this blog:

1. Importing the management pack
2. Adding it alongside SCOM Web Console as a JavaScript application (with this the application will have its own URL and may or may not be added as a custom widget)
3. Adding the two sections as individual widgets

Note: From now on we will refer to the content available in attached zip file: Custom-Widget

Importing the management pack

A management pack containing the two individual sections (overview and search) are available under “Custom Widget\Management Pack\”

Import this management pack and you should see two dashboards overview and search having the two sections respectively.

Adding it alongside SCOM Web Console as a JavaScript application

1. Go to the directory where SCOM 1801 Web Console is installed. Ex. C:\Program Files\Microsoft System Center\Operations Manager\WebConsole\Dashboard\
2. Create a folder named “custom”. Note that you may choose any folder name, this is just an example
3. Copy the contents placed under “Custom Widget\Source Code\“
4. Go to SCOM Web Console
5. Create a dashboard
6. Click Add Widget and select Custom Widget from the dropdown.
7. When asked for source code enter the following:
   <iframe src=”http://your_server_name/OperationsManager/custom ” style=”width: 100%; height: 100%”></iframe>
   Here replace your_server_name with your Web Server
8. Hit save and you are done!

Adding the two sections as individual widgets

1. Go to SCOM Web Console
2. Create a dashboard
3. Click Add Widget and select Custom Widget from the dropdown.
4. When asked for source code pick the contents of any one file from under “Custom Widget\Individual Sections\“
5. Hit save
6. Repeat 4 and 5 for the other one or repeat 2-5 if you wish to add these in separate dashboards

Documentation

Discussing the technical approach of how the sample widget presented here works is out of scope of this blog. The code has been documented thoroughly and documentation has been generated using JSDoc. The documentation can be found under “Custom Widget\Source Code\docs\”

Start with index.html and that would guide you through all the code.

How SCOM REST APIs can be used

Refer to “Custom Widget\Source Code\dist\js\helpers\data-helper.js” for an example of how SCOM REST APIs can be used.

For more details on SCOM REST APIs, please refer https://docs.microsoft.com/en-gb/rest/operationsmanager/

References

For the sample app discussed above, the following 3^rd part libraries were used:

1. jQuery: <script src=”https://cdnjs.cloudflare.com/ajax/libs/jquery/3.2.1/jquery.min.js”></script>
2. jQuery UI: <script src=”https://code.jquery.com/ui/1.12.1/jquery-ui.js”></script>
3. MetisMenu: <script src=”https://cdnjs.cloudflare.com/ajax/libs/metisMenu/2.7.1/metisMenu.min.js”></script>
4. Bootstrap: <script src=”https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.7/js/bootstrap.min.js”></script>
5. jQuery DataTables: <script src=”https://cdn.datatables.net/1.10.16/js/jquery.dataTables.min.js”></script>
6. Bootstrap DataTables: <script src=”https://cdn.datatables.net/1.10.16/js/dataTables.bootstrap.min.js”></script>
7. Responsive DataTables: <script src=”https://cdn.datatables.net/responsive/2.2.0/js/dataTables.responsive.min.js”></script>

System Center Operations Manager 1801 has enhanced log file monitoring capabilities for Linux Servers.

• Operations Manager now supports Fluentd, an Open source Data collector.
• Customers can also leverage Fluentd capabilities and plugins published by the Fluentd community to get enhanced customizable log file monitoring.
• The existing OMI based monitoring for currently supported Linux workloads will continue to work as it is today. 

With this release we have added support for the following log file monitoring capabilities

• Support for wildcard characters in log file name and path.
• Support for new match patterns for customizable log search like simple match, exclusive match, correlated match, repeated correlation and exclusive correlation. We have released 6 new filter plugins for customizable log search.
• Support for generic Fluentd plugins published by the fluentd community. System Center Operations Manager 1801 would include a convertor plugin which would convert the fluentd data from generic plugins to the format specific for SCOM log file monitoring.

Architecture

Below are few architectural changes in the SCOM Management server and the SCOM Linux agent to support Fluentd.

The new Linux SCOM agent would include a Fluentd agent (as shown in the above picture (1)).

Users would define the log file names, match pattern and the event to be generated on pattern match along with the event description in the Fluentd Configuration file.

On match of a log record, Fluentd would send the event to the System Center Operations Manager External Datasource service on the SCOM Management Server / Gateway (2).This is a Windows REST based service which would receive the event and send it to a dedicated custom Event log channel Microsoft.Linux.OMED.EventDataSource (3).

User would need to import a management pack (4) which would look for events in this custom event channel and generate alerts accordingly

User Workflow:

On Linux Server:

On SCOM Management Server:

User needs to follow the below steps on the Management Server 

Step 1:

User would need to import the latest Linux Management pack (shipped with the SCOM 1801 binaries) and install the new SCOM agent on the Linux Servers.

Users can install the agent either manually or through discovery wizard (recommended). For detailed steps, refer here.

Step 2:

Author Fluentd configuration file and place it on the Linux Servers

Customers need to author a Fluentd configuration file and can use any of the existing enterprise tools like Chef/Puppet to place the configuration file to the Linux server.

Recommended practice is to copy the configuration into /etc/opt/microsoft/omsagent/scom/conf/omsagent.d directory on all Linux servers and include the configuration file directory as @include directive in the master configuration file /etc/opt/microsoft/omsagent/scom/conf/omsagent.conf

The Fluentd configuration file is where the user should define the input, output and the behavior (match processing) of Fluentd. This is done by defining the following in the configuration file:

Source directive:

Fluentd’s input sources are defined in the source directive using desired input plugins. Users would need to define the log file names along with the file path here in this directive. Wild card characters are support both in file name and path.

Filter directive:

Filter directive is the chained processing pipeline. Users would need to define the match pattern and the events that are to be generated on a match here in this section. We have released the following filter plugins with this release

• filter_scom_simple_match,
• filter_scom_excl_match
• filter_scom_cor_match
• filter_scom_repeated_cor
• filter_scom_excl_correlation
• filter_scom_converter

Match directive:

Users define the output processing in Match directive. We have released “out_scom” match plugin which would send the events generated by Fluentd to the System Center Operations Manager External Datasource service on the SCOM Management Server/Gateway.

For more detailed instructions on how to author a Fluentd configuration file, refer here.

Step 3:

On SCOM Management server: Import Management pack and enable OMED Service

On Management Server User needs to do the following:

1)      Start OMED service (refer here).

2)      Import Management pack for log file monitoring.

User can import the sample Management pack (reference here ), save this as an xml file and import it in SCOM console. This Management pack has a rule that looks for all events from the new data source Microsoft.Linux.OMED.EventDataSource and generates alerts accordingly. The Alert severity and priority are set in the management pack. The Alert description is obtained from the event description which would be defined by the user in the Fluentd configuration file.

If users are interested to generate alerts only for specific events generated, they could author their own custom management pack using VSAE.

Example Scenario:

User would like to monitor the following scenarios

1)      Apache http server URL monitoring

Scenario: Monitor a web URL hosted on Apache http server and generate alerts on SCOM Management server if the URL has any issues.

Log to be monitored: User monitors Apache http server access.log for error code. If the log receives any code other than 200 (success code) an event will be sent to SCOM Management Server.

2)      Authentication failure

Scenario: If a user tries to access a server more than 5 times with an incorrect password, an alert would be sent to the SCOM server alerting an unauthorized user trying to intrude.

Log to be monitored: User monitors Linux Server auth.log for authentication failure error messages. If the messages exceeds 5 times in 10 seconds and event will be sent to SCOM Management server.

Sample Configuration File:

The OMEDService on SCOM Management server would receive an event on match of a log record along with the log record context. User would need to import a management pack on SCOM server which would generate alert when there is an event received from Linux Server.

Events on the SCOM Management Server:

 Generated Alert on the Management Server:

The Alert context will contain the log record which will have more details on the error code received while trying to access the URL.

Other Sample User Scenarios:

For more detailed steps look at the online documentation.

Feedback:

We’d love to hear your feedback on this new feature. Feel free to send your feedback to scxtech@microsoft.com.

In February we announced that System Center, version 1801 was now available.  It’s the first release in our new Semi-Annual Channel and delivers new features and enhancements based on customer feedback. It builds on the capabilities of System Center 2016 and has support for the latest version of Windows Server, version 1709 as well as Windows Server 2016. It includes enhanced Linux monitoring support, more efficient VMware backup, and improved user experience and performance. For more details, read the full announcement..

The following is a special guest blog from Silect

We are pleased to announce the General Availability of MP Author version 8.2. We’ve made lots of updates and improvements to our family of products for SCOM. Here’s a summary of the changes to MP Author:

• Support for SCOM 1801
• When sealing and deploying and MP, deploy the sealed MP, not the unsealed.
• Remember the last SCOM version used when creating an MP, as it should be the default next time. Improve display and logging of the versions of reference MP that are loaded.
• Groups can now be created without dynamic membership rules.
• Improved impersonation when browsing remote registries.
• When parsing scripts for class names, parameters, etc. allow both single and double quotes.
• When displaying lists of targets, ensure the list shows abstract and singletons if needed.
• Several dialogs and message boxes now allow you to not show them again (once you know what they are telling you, you can select a “Don’t Show This Again” check box.)
• Discoveries can now be enabled for a group from within the wizard.
• Alert, Event, Performance and State views can now be filtered by a group.
• Editing event, performance, service or process rules/monitors will work correctly even if the machine being browsed doesn’t have the items previously selected.
• Performance monitors now support two and three-state monitors using simple values, average values, delta values, or consecutive samples.
• Script monitors and rules allowed overrides on the parameter values but did not use the override value. This has been corrected.
• Setting a description for an element which does not have a display name failed. The new behaviour is to set the missing display name (to the actual name) at the same time.
• Do not require hosted classes with no key properties to be singletons because the hosting class may have key properties.
• Improve handling of reference MPs which don’t exist or are the wrong version.
• Allow registry and WMI queries to work if they contain characters which are significant in XML (like < or >).
• The script class wizard will no longer allow users to change the class name, if the class name was determined from the script (if they don’t match, the discovery will fail).
• Numerous bug fixes, UI and performance improvements

System Center Operations Manager 1807 overview

System Center 1807 announcement is available here.

What’s new in System Center Operations Manager 1807 is available here.

How to Upgrade to System Center Operations Manager 1807 is available here.

The content in this blog describes the features and scenarios enabled in System Center Operations Manager 1807

HTML5 dashboards

Users can create and manage PowerShell Widgets in their HTML5 dashboards. While authoring the PowerShell widget, user needs to provide the PowerShell script which would be executed and visualized in the widget. This widget enables users to leverage PowerShell scripting to retrieve and visualize custom data (more details on PowerShell widget is available here).

Users can visualize effective configuration for a server/object in the objects drill down page. This allows users to view the configuration of a rule/monitor with respect to a server or an object.

More details on viewing effective configuration of a monitored object is available here.

Operators can create/manage HTML5 dashboards in MyWorkspace. This feature allows operators to create and visualize dashboards (only with the data they have access to) in the form they like (more details on creating dashboards in My Workspace is available here).

User can Visualize Network Node dashboard and Network Interface dashboard for Network Node/interface from the Objects drill down page. This allows users to consume more relevant data while trouble shooting a network node or interface.

User can navigate to the objects drill down page of the alert and change the resolution of an alert from within the alert down page. This allows users to act on an alert while troubleshooting the same.

More details on the changes to alerts drill down page is available here.

User can select/change the size of the icon in topology widget, allowing flexibility to have bigger icons for NOC view scenarios.

More details on changes to topology widget is available here.

Schedule Maintenance Mode view in Web Console

This feature enables users to create and manage schedule maintenance mode from within the web console.

More details on creating/managing schedule maintenance from web console is available here.

User can choose to enable/disable APM component while installing agent

This feature allows more flexibility to the users by providing an option to enable/disable APM component in the agent.

User can enable/disable APM component while installing agent through Discovery wizard (more details are available here).

User can enable/disable APM component through the agent repair wizard (more details are available here).

User can enable/disable APM component through the new parameter added for the below cmdlets:

Install-ScomAgent

Example:

• Without APM: Install-SCOMAgent -DNSHostName “NEB-OM-1536628.smx.net” -PrimaryManagementServer $PrimaryMS -NoAPM
• With APM:       Install-SCOMAgent -DNSHostName “NEB-OM-1536628.smx.net” -PrimaryManagementServer $PrimaryMS)

Repair-ScomAgent

Example:

• Without APM: Get-SCOMAgent -DNSHostName “NEB-OM-1536628.smx.net” | Repair-SCOMAgent -NoAPM
• With APM:       Get-SCOMAgent -DNSHostName “NEB-OM-1536628.smx.net” | Repair-SCOMAgent)

Support for SQL 2017 with SCOM 1807

With SCOM 1807, SQL 2017 is supported if it is upgraded from SQL 2016. Fresh installation of SQL 2017 with SCOM 1807 is not supported with SCOM 1807.

More details on upgrading Operations Manager 1807 database to SQL Server 2017 is available here.

XPlat log rotate

Under error scenarios, the SCX log fills up quickly, which eventually consumes all available free space on the system disk. As a result, the system becomes unresponsive unless the logs are cleaned up manually. To address this issue, we have introduced log rotate feature for SCX agent. This will help to rotate old logs of SCX agent and save disk space.

More details on Log rotation for Linux agent is available here.

We have updated Operations Management Suite connection onboarding wizard in System Center Operations Manager to communicate with the new APIs.

This change has been necessitated by Log analytics (and the rest of OMS services) moving to Azure portal and the OMS portal being retired, more details on OMS portal moving to Azure is available here.

For configuring new connections to Operations Management Suite with System center Operations Manager, you need to import the product version specific management packs (links given below). If you have already configured connection to OMS with SCOM then you do not need to import these management packs, however if you reconfigure your existing connection then you need to import this management pack.

New Operations Management Suite onboarding wizard in System center Operations Manager:

Download links:

• For System Center Operations Manager 1801, download the management pack from here.
• For System Center 2016 Operations Manager, download the management pack from here.
• For System center 2012 R2 Operations Manager, download the management packs from here.

System Center Operations Manager continues to be the tool relied upon by enterprise customers for IT operations and monitoring. Global Service Monitor in SCOM provides the ability to monitor the availability of external web-based applications from multiple locations across the globe. As of November 07, 2018, we will retire the Global Service Monitor and recommend that customers transition Global Service Monitor users to next generation web application monitoring capabilities allowing them to take advantage of our Azure hosted services for these capabilities, powered by Azure Application Insights.

Application Insights is an extensible Application Performance Management (APM) service for monitoring applications on multiple platforms. It offers greater control, and richer alerting, diagnostics, dashboarding and reporting capabilities over an interactive data analytics platform. With the transition to Azure Application Insights, customers stand to benefit in the long term from Azure monitoring investments including improvements in reliability and performance.

GSM Customers will be notified of the retirement through an alert in the SCOM console sent down from the GSM. If you are a GSM customer, during your transition, you do not need to change your tests; Application Insights supports the tests GSM supported (single URL ping and multi-step web tests), the frequency of the tests and locations supported are the same as well. The migration script (Link to Migration Script) will provision your tests with the same configuration in Application Insights. The migration script will also provision alert rules based on what you are currently using in SCOM . Please use the migration script to migrate your GSM tests to Application insights by the end of October 2018. Post migration, SCOM customers can use the Azure Management Pack (CTP version) (Link to Azure MP) to integrate with Application Insights and view the alerts from their tests in Application Insights in the SCOM console.

We thank the SCOM customers for their usage of the GSM service. This transition provides yet another value to System Center customers as they continue to be able to take advantage of Azure management offerings. Should you have any questions, please contact your account team or Microsoft Support.

FAQ

1. What is GSM?

System Center Global Service Monitor is a cloud service that provides a simplified way to monitor the availability of external-web-based applications from multiple locations around the world. See https://technet.microsoft.com/library/jj860368(v=sc.12).aspx.

2. What is Azure Application Insights?

Application Insights is an extensible application performance monitoring service in Azure, supporting applications on a variety of platforms. See https://azure.microsoft.com/services/application-insights/

3. Does my price increase because of this transition?

GSM was provided as a software assurance benefit of your System Center purchase. When you migrate to Azure Application Insights, Microsoft will transition migrated tests and alert rules at no additional charge

4. Do I get any other Azure benefits as part of this transition?

No. Only the migrated tests, and the alert rules associated with them will be provided at no additional charge. All other Azure consumption will be subject to applicable pricing.

5. So, if I add more availability tests or use Application Insights for server-side monitoring, I will be charged?

Yes, that is correct. Only the migrated tests are provided at no additional charge. All other use is subject to applicable pricing.

6. What happens if I don’t migrate the tests?

Existing GSM tests will stop working after 11/07/2018. We strongly encourage you to migrate the tests and validate the alert rules in Azure well before that date.

7. What happens if I don’t migrate tests using the migration script provided by Microsoft?

Only the tests which are migrated using the script, would be provided at no additional charge in Azure Application Insights.

This is an update for our customers who are hitting below exception while configuring Log Analytics workspace from SCOM console. This blog talks about workaround for this issue, please follow the mentioned steps.

Workaround:

–          Copy the Advisor dll (version 1.0.5) from this link to Console folder (C:\Program Files\Microsoft System Center\Operations Manager\Console).

–          Try to configure your Log Analytics workspace connection and this time it will work.

–          Remove this Advisor dll from Console folder after Log Analytics configuration is done.

[Note]: If you will not delete Microsoft.IdentityModel.Clients.ActiveDirectory  from Console, then you will hit the above exception while adding subscription to Azure MP.

What is causing this exception?

This exception will only occur when you have Azure MP installed on your system.

The reason is both Azure MP and Advisor MP use different versions of Microsoft.IdentityModel.Clients.ActiveDirectory library.

When the intended version of this library isn’t found, Console throws FileNotFound exception

To bring Alerts/Performance data from Azure to SCOM, Azure Management pack can be used. Azure Management Pack guide talks in detail about the Azure Management Pack capabilities. Please refer that more details.

This blog will talk about how we can see the Alerts for Application Insights Availability Tests in SCOM console. Let’s start.

Install latest Azure Management Pack from https://www.microsoft.com/en-us/download/details.aspx?id=50013.

Import the MP from Operations Console.

Now go to Administration Tab -> Microsoft Azure -> Add Subscription and connect to your Azure subscription with your credentials.

You will see your subscription id listed like above under Subscription ID.

Next step is to author management pack template to monitor Azure resources.

From the SCOM Console left pane select Authoring. Now Under Management Pack Templates select  Microsoft Azure Monitoring -> Add Monitoring Wizard and follow below steps.

Please ensure to create a New Management Pack for Azure Management Pack.

We are selecting only Application Insights components and web tests here.

In Application Insights, for a ping test/multi step web tests, users can choose to configure Classic Alerts/Metric Alerts for their tests.

We want to see  both Alertrules (Classic Alerts) and Metricalerts (metric alerts) for our Azure tests, so we select both these below.

Under components (Microsoft.insights), there is a list of metrics available which can be selected to Collect Data in SCOM.

But to collect this data, your application which is hosted in Azure should be instrumented to collect all this metrics. If your application isn’t instrumented t0 collect this metrics in Azure, Azure Management Pack cannot collect this data. In short, Azure MP will only collect/show metrics that you are collecting at in Azure.

Alert If checkbox below is to raise Alerts in SCOM for the Threshold value that is specified in Threshold column. Condition can be changed to Greater Than/Less Than as per requirement.

For example if you want to raise an Alert in SCOM when Receive Response Time is greater than 2 seconds, than we change the Threshold value of Receiving Response Time to 2.

After this complete the wizard by hitting Next >.

After this is done, depending upon how many resources you have under your subscription, Azure MP will load the resources in SCOM. Usually it’s less than a minute.

Go to Monitoring Tab and under Service State you will find all your Application Insights components and their Health State.

If you want to see Health State by the Resource Group, please select Resource Group State. In the below screenshot, all the Resource Groups, under my subscription are listed.

To see all the resources data consolidate at one place, go to Service State Tab.

If you want to see Active alerts for your resource group, then right click your Resource Group Name and select the Alert View.

It will show all the Active Alerts as below. Select the alert and Alert Description would be available under Alert Details.

You can select Alert Properties like any other Alert in SCOM for this Alert from Azure resource.

We have improved the Alert Description of Metric Alerts generated by Application Insights Ping test. The new Alert would look like following.

You can configure metric alerts in Azure Portal for your Availability Ping test like below.

Go to Application Insights -> Availability -> Add Test

Enter the required details and select the highlighted Alert type and Alert Status to create metric alerts. For these alerts, you will see the description as mentioned above.

For our customers who have SCOM 1801, they can use HTML5 dashboard for viewing the Alerts and Performance data from Azure in SCOM.

Please leave in comments what are the new features you would like to see in next release of Azure Management Pack.

Thanks,

Neha

Please share your feedback about SCOM at https://systemcenterom.uservoice.com/forums/293064-general-operations-manager-feedback

We have started releasing version agnostic management packs for our customers. In the past we used to release a new management pack when new version of Windows and Windows features will be available for monitoring. Customer will have to  install and manage different management packs for monitoring their workloads. Going forward the same management pack will work with difference Windows versions.

For example: Customer want to monitor Windows Server 2016 and Windows 1709, they will only require one management pack for this. Once we add support for Windows Server 2019, the same MP would be updated to support Windows 2019 and 2016.

We have updated many important management packs which monitor windows workloads to version agnostic. Please find the list here.

https://social.technet.microsoft.com/wiki/contents/articles/16174.microsoft-management-packs.aspx

We use a naming convention for our version agnostic management packs which is, minimum supported version and plus.

For eg, “Microsoft System Center Management Pack for Windows Server Operating System 2016 and 1709 Plus”.

Please use our feature Updates and Recommendation, which can help with :

• Install the required management pack for monitoring a workload running on agent.
• Recommend to update the management pack as soon as, newer version is available.

Thanks,

Neha

The existing alert closure experience for the alerts generated by monitors has been revamped to be more meaningful and provide better value.

If the alert was generated by a monitor, as a best practice, you should allow the monitor to auto-resolve the alert when the health state returns to healthy or close the alert manually when the health state returns to healthy (if auto-resolve is set to false).

If you close the alert while the object is in a warning, critical or unhealthy state, the problem remains unresolved, and no further alerts are generated, unless the health state for the monitor has also been reset (If the monitor is not reset, the same condition that generated an alert can occur again but no alert will be generated because the health state has not changed.)

This behaviour, which often led to a scenario where there is no active alert in the system while an underlying problem is not resolved. Closure of alerts generated by monitors without resolving the underlying problem is fixed with SCOM 2019. An alert which has been generated by a monitor cannot be closed unless the health state of the corresponding monitor is healthy.

Behavior in operations console

If you close an alert generated by a monitor (from the Operations Console “Active alerts” view) which is in a unhealthy state then the following message will be displayed and the alert will not be closed:

“Alert(s) in the current selection cannot be closed as the monitor(s) which generated these alerts are still unhealthy. For more details on the alerts which could not be closed, view the “Alert Closure Failure” dashboard in the Operations Manager Web Console”

To close this alert the health state of the monitor has to be reset, if “auto-resolve” for this monitor is set to true then the alert will be auto closed with the health state reset else the alert has to be manually closed after the health state reset.

Behaviour in Web console

If you close an alert generated by a monitor (from the “Alert Alerts Dashboard” or any dashboard or the alerts drill down page of the web console) which is in a unhealthy state then the following message will be displayed and the alert will not be closed:

Active alerts dashboard (closing 1 alert generated by monitor which is in a unhealthy state, by using the “Set resolution state” action)

Alerts drill down page (closing the alert generated by monitor which is in a unhealthy state, by changing the “Resolution State”)

To forcefully close these kind of alerts, reset the health state of the monitor from the task available in the alerts drill down page:

Or

Navigate to the new “Alert Closure Failure” dashboard available in the monitoring tree of the web console, this dashboard lists all the active alerts in SCOM which were unable to close because the monitor which generated these respective alert is still unhealthy. You can select the alert which you want to forcefully close and reset the corresponding monitor by using the “Reset Health” action.

Note: This dashboards displays all the active alerts which were unable to close, irrespective of the tool from where the alert closure has been triggered.

If an alert closure has been triggered from the third party tools/systems (incident management/ticketing systems…) and if the alert was unable to close as the corresponding monitor is still unhealthy then we will be passing an exception with the alert details which can be leveraged by third party tools/systems.

The following 2 APIs have been enhanced to enable this new behaviour (more detailed documentation on the changes to the below APIs will be published soon):

• https://msdn.microsoft.com/en-in/library/microsoft.enterprisemanagement.monitoring.monitoringalert.update.aspx
• https://msdn.microsoft.com/en-us/library/hh327241.aspx

While leveraging SCOM REST API, if you get the error message “The given key was not present in the dictionary.“ then it means that the request body is not being parsed correctly. For resolving this error, make sure that the Content-Type header is set to “application/json” and JSON.stringify() is called on the data value to convert it into string.

Below is a sample snippet of the script with the usage of Content-Type header and  JSON.stringify to resolve such errors:

window.onload = function () {
                $.ajax({
                        url: "/OperationsManager/data/performance",
                        type: "POST", 
       headers: {
                 "Content-Type": "application/json"
                },
                        data: JSON.stringify({
                        "duration":1440,
                        "id":"721BEA34-B0E4-DC97-5169-52808F731A6B",
                        "performanceCounters":[ 
                               {
                                       "objectname":"Health Service",
                                       "countername":"agent processor utilization",
                                       "instancename":""
                               }
                        ], 
                        }),