[OpsMgr 2012] Operations Manager integration with System Center 2012 Virtual Machine Manager fails with error 10218

When creating the integration from System Center 2012 Virtual Machine Manager (SCVMM 2012) to Operations Manager, the integration fails with the following error :

Error (10218) Setup could not import the System Center Virtual Machine Manager Management Pack into Operations Manager server because one or more required management packs are missing. The SCVMM Management Packs cannot be deployed unless the following component management packs are present in Operations Manager 2007:
Windows Server Internet Information Services 2003,
Windows Server 2008 Internet Information Services 7,
Windows Server Internet Information Services Library,
SQL Server Core Library.

NOTE All required Management Packs have been imported in Operations Manager.

Read Microsoft Article ID: 2674625

In this scenario, the Virtual Server 2005 R2 Management Pack was imported which imports the Microsoft Virtualization Core Library. The cause of the problem is that SCVMM 2012 will import a newer version of the Microsoft Virtualization Core Library Management Pack and the old version cannot be present in order for integration to complete successfully.



There are two potential solutions:

• Remove the old version of the Microsoft Virtualization Core Library and the Microsoft Virtual Server 2005 R2 Management Pack.

or

• Configure a second Operations Management group for the SCVMM 2012 integration and configure the SCVMM 2012 server as well as the Hyper-V servers to report to this new management group.  

The Microsoft Virtualization Core Library is a Hyper-V Management Pack developed by the Hyper-V team. It has been updated to support the latest version of Hyper-v and improve monitoring of the hosts.

This posting is provided "AS IS" with no warranties.

[Orchestrator 2012][OpsMgr 2012] Orchestrator dashboard in Operations Manager 2012

Anders Bengtsson (MSFT) has published an article related to an Orchestrator dashboard in System Center Operations Manager 2012.

He provides a management pack that collects some information in the Orchestrator DB :

• Queue

1. Pending Jobs, show number of runbooks with pending status, meaning they are waiting to start
2. Top minutes in queue, show number of minutes top 1 job have been in the queue.

• Runbook Results

1. Success, show number of runbooks that have ended with success result
2. Warning, show number of runbooks that have ended with success result
3. Failed, show number of runbooks that have ended with success result

• Runbook Jobs. This widget show number of times each runbook have run with success result. You can easy see which runbook that most often executed. The names you see is the name of the runbook.
• Orchestrator Server Status, show status of my Orchestrator roles. In this sandbox all roles are on the same server, SCO01.
• Orchestrator Alerts show alerts generated by my Orchestrator machine.

You can download his example MP here, NOT SUPPORTED – Contoso.Orchestrator – v2 . Note that this is provided “AS-IS” with no warranties at all. This is not a production ready management pack or solution for your production environment, just a idea and an example.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007 R2][OpsMgr 2012] Microsoft Office Web Apps Server Management Pack Guide for System Center Operations Manager

Microsoft Office Web Apps Server Management Pack Guide for System Center Operations Manager guide has been released. It contains a Quick Start section to help you set up the environment, import management packs, and configure the system for monitoring by using SCOM. It also contains monitors and rules for Office Web Apps Server and links that will connect you to information about common tasks that are associated with System Center management packs.

Download it in pdf or docx format from here

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007 R2][OpsMgr 2012] Javascripts used by Operations Manager Management Packs fail to execute with "Can't find script engine"

Here is a new Microsoft article. Javascripts used by System Center Operations Manager 2007 Management Packs for monitoring fail to execute on a specific agent and the following error is generated:

CScript Error: Can't find script engine "JScript" for script "C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 8\1596\DiscoverHealthServiceCommunicationRelationships.js".

Read Microsoft Article

This can occur if there are incorrect permissions applied to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{f414c261-6ac0-11cf-b6d1-00aa00bbbb58}\InprocServer32

To resolve this issue, edit the permissions on the registry key mentioned above and make sure they are as follows:

• SYSTEM (READ ACCESS)
• Administrators(Localsystem\administrators) (READ ACCESS)
• Users (Localsystem\users) (READ ACCESS)
• TrustedInstaller (Full control ACCESS)

KB2750487 applied to

• Microsoft System Center Operations Manager 2007
• Microsoft System Center Operations Manager 2007 Service Pack 1
• Microsoft System Center Operations Manager 2007 R2
• Microsoft System Center 2012 Operations Manager

This posting is provided "AS IS" with no warranties.

[OpsMgr 2012][Orchestartor 2012][SCSM 2012] System Center 2012–Extended OIP–Maintenance Mode POWER!! – Self Service portal

I've wrote last week an article related to maintenance mode in System Center Operations Managers 2012 using Orchestrator.

This week-end Oskar Landman has commented my post on LinkedIn and give me a link to one of his articles. The post explains the use of the Self Service Portal to set OpsMgr objects in maintenance mode.

Read the full article from Oskar Landman

He is giving a simple example with screenshots and shows how you can use the System Center 2012 Extended OIP in combination with SCSM and OpsMgr.

Very interesting way to proceed ! :)

Where to find System Center 2012 Extended OIP ? : Just follow this link !

This posting is provided "AS IS" with no warranties.

[Orchestrator 2012] System Center 2012 Extended Orchestrator Integration Pack V2

Although the current System Center 2012 integration packs are a good starting point for automating System Center there can be numerous extra activities to make the live of a System Center administrator / consultant even easier.
Because of this Oskar Landman (MVP, Microsoft Partner) has created an Extended OIP to include more activities.
Since the SDK for both SCSM and Opsmgr are both basically the same, writing code using the SDK can be used on both products which makes writing activities twice as efficient.

Currently the OIP Contains 12 activities:

• Managementpack - Export – Activity with possible filters to export any management pack from both SCOM as well as SCSM into a directory.
• Class - Get class – Activity to get a class with possible filters on every property to het classes from both SCOM and SCSM.
• Rule - Get Rule – Activity to get a rule with possible filters on every property to het classes from both SCOM and SCSM.
• Managementpack - Import – takes a directory and imports any management pack from the directory into the management group works on SCOM and SCSM.
• Managementpack - List – activity to get a management pack with possible filters on every property to get management packs from both SCOM and SCSM.
• Managementpack - Seal – Takes a directory with unsealed XML;s, a key file and company name and seals every management pack and sends the exported management packs to a separate directory.

The other 6 activities make your life even easier to create a really sophisticated way to schedule and use maintenance mode on OpsMgr 2012!

• Class – Get Class Instances – Takes a class (Internal Name) and retrieves all class instances. Can be filtered by using the filtering options in the activity.
• Class – Get GroupClass Instances – Takes a group (Internal Name) and retrieves all members of the group
• SCOM MaintenanceMode – Start Group – Takes a group (Internal Name) and retrieves all members of the group and place them in maintenance mode.
• SCOM MaintenanceMode – Stop Group – Takes a group (Internal Name) and retrieves all members of the group and turn maintenance mode off.
• SCOM MaintenanceMode – Start Object – Takes an object and places the object in maintenance mode.

To get the V2 Version including all 12 activities - http://www.authoringfriday.com/2012/10/27/system-center-2012extended-oipmaintenance-mode-power/

This posting is provided "AS IS" with no warranties.

Microsoft Tech Days 2013 - 5,6 and 7 March

SAVE THE DATE!

TechDays 2013 will take place on 5,6 and 7 March.

Direct access

More information will follow soon,
make sure to be the first to know!

Subscribe now to get the freshest TechDays news



This posting is provided "AS IS" with no warranties.

[OpsMgr 2012][Orchestartor 2012] SCOM 2012 – Maintenance Mode and Orchestrator

An interesting article related to maintenance mode in System Center Operations Managers 2012 using Orchestrator.

Read the full article here

Brut force methode used in Operations Manager 2007 (see script below) has been tested in Operations Managers 2012 and since the cmdlet has changed, only the get-date is well working...

$class = get-monitoringclass -name:Microsoft.Windows.Computer
$computer = get-monitoringobject -monitoringclass:$class -criteria:”PrincipalName=’scottmusjm1.tpb.lab’”
$start = get-date
$end = $start.addminutes(30)
new-maintenanceWindow -startTime:$start -endTime:$end -monitoringobject:$computer -comment:”Testing”

New script for Operations manager 2012 should look like (note the use of | where for the get-scomclassinstance) :

$class = get-scomclass -name:’Microsoft.Windows.Computer’
$computer = get-scomclassinstance -class $class | where{$_.name -eq ‘SCOTTMUSJM2.tpb.lab’}
$start = get-date
$end = $start.addminutes(30)
start-scommaintenancemode -Instance:$computer -EndTime:$end -Comment:”Testing”

Result looks good when you execute the line in powershell but no so much : not only does the script not set MM on the health service and the health service watcher, it doesn’t put the objects contained by Windows Computer into MM.

The rest of the article explains how to use Orchestrator to put in maintenance mode and show that all objects have been removed from MM including the health service and the health service watcher.

This posting is provided "AS IS" with no warranties.

[Microsoft] Before opening a case, try FixIt Center Pro and see how it can save you time… and money !

Dsymalla has published a very very usefull link on Technet : Before opening a case, try FixIt Center Pro !

You’re probably asking yourself… What is FixIt Center Pro (FICP)? How is it going to save me time?

These are GREAT question you ask! Well Microsoft is always looking for ways to improve the customer experience through innovation of its products. This is also true with regards to the tools we use on a day to day bases that helps us troubleshoot issues. So let us explain how FICP can help you save time by getting an automated root cause analysis and be your new best friend before opening a case with Microsoft Commercial Technical Support (CTS).

For many years, Microsoft Commercial Technical Support (CTS) would always ask customers to run a data gathering tool called Microsoft Product Support (MPS) Report Tool and manually go through analyzing the files collected one at a time. This is a very tedious job and it’s prone to human error, because we can all look at logs and interpret them differently. As a result, we could potentially miss critical data that can lead to a false root cause analysis.

Now we are providing you a NEW and improved automated tool called the Microsoft Support Diagnostics Tools (MSDT) Analysis Packages which is our replacement for the old MPS Report Tool. These new MSDT Analysis Packages are broken down by technology, using Windows Diagnostics Infrastructure (WDI) framework to collect logs and configuration data from a workstation or server for further analysis.  Then the MSDT Analysis Packages get uploaded to the FICP website that leverages a Unified Diagnostics Ecosystem (UDE). This UDE engine automates and standardizes on support issues reported to Microsoft, then provides a more unified and comprehensive root cause analysis with Recommended Solution steps to complete.

In the past, in order for customers to use MSDT Analysis Package you would have an open case with Microsoft so they could send you an email with a link to download the package.  However now, customers can choose to download any individual stand-alone MSDT Analysis Package by using our technology via Microsoft FixIt Center Pro (FICP) from the following URL link below:

https://wc.ficp.support.microsoft.com/Dashboards/Main/SelfHelpCase/Create?showReturn=True

By going directly to FICP, customers don’t need to have open cases Microsoft in order to use this automated tool. 

Only requirement is to have a valid Microsoft account.

For more information and to see screenshots click >>>>> HERE <<<<

Keywords: Operations Manager, SCOM, System Center, System Center Operations Manager, Troubleshooting, FixIt Center Pro, Microsoft, Support, FICP, Microsoft Case, OpsMgr, OpsMgr 2007 R2, OpsMgr 2012, 2012, 2007, MSDT, Premier Support, UDE, Microsoft Support Diagnostics Tool, Unified Diagnostics Ecosystem, MPS Reports, Toolbox, Toolkit, Tools,

This posting is provided "AS IS" with no warranties.

[OpsMgr 2012] How to add a product key to an eval version of System Center 2012 Operations Manager

How to add a product key to an eval version of System Center 2012 Operations Manager

Direct link to Microsoft article

 To set the product key, use the Set-SCOMLicense cmdlet in PowerShell. To use the Set-SCOMLicense cmdlet you need to use elevated permissions. (Run as Administrator).

1. Open PowerShell as an Administrator
2. Load the OperationsManager Module (import-module operationsmanager)
3. Connect to your ManagementGroup (New-SCOMManagementGroupConnection)
4. Use Set-SCOMLicense -ProductId "yourlicensekey“
5. To check if changes were executed run Get-SCOMManagementGroup | ft skuforlicense, version, timeofexpiration –a 

 

Note: This may require a reboot after running in order to register correctly.

 

For more information on the Set-SCOMLicense cmdlet see http://technet.microsoft.com/en-us/library/hh920237.aspx

(http://technet.microsoft.com/en-us/library/hh920237.aspx) for other considerations.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2012] Unable to install license key on SCOM 2012

Lynne Taggart - MSFT has published an article on issue on adding a product key on  an eval version of System center operation manager. Using the steps  referenced in KB2699998, the PowerShell hangs after you run the

“Set-SCOMLicense -ProductId XXXXX-XXXX-XXXXX-XXXXX-XXXXX“ command and select Y to confirm.

Read the full article here

Cause

An “Unauthorized Access Exception” or simply a lack of “permissions” needed to update the database is being prevented from updating the OperationsManager database. Even though the account is a member of the Domain Administrators.

Resolution
Make sure that the account you are using to run the PowerShell registration commands is not only a local administrator on the management server, but more importantly it has the correct rights to make changes to the “OperationsManager” SQL database. A domain admin account may not work for you depending on how you configure the settings in SQL. I would recommend using the SDK account; if the SDK can not make these changes, then you just might have some bigger issues going on that need to be taken care of.

Since the SDK account is one set of credentials that is used to “update” & “read” the information that is in the operational database. The Operations Manager will ensures that the credentials used for the System Center Data Access service and System Center Configuration service account are assigned to the “sdk_user” role in the operational database. For more information you can learn more here.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007 R2][OpsMgr 2012] How to Use a Textbox Object Picker Control in your Custom Report - Operations Manager

Matt Goedtel (MSFT) has published a very interesting article detailing how to include a textbox in your custom reports by using the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.Textbox control.

Read the full article here



This posting is provided "AS IS" with no warranties.

[OpsMgr 2012] Reports are not populated in the System Center 2012 Operations Manager Reporting Pane

Article ID: 2771934 - Last Review: October 23, 2012 - Revision: 1.0

Applies to Microsoft System Center 2012 Operations Manager

http://support.microsoft.com/kb/2771934

Reports do not populate in the System Center 2012 Operations Manager Reporting Pane, or Report data does not seem to be updating.

This can occur if the Data Warehouse Synchronization server entry is deleted.

To confirm this issue in the Operations Console, go to the Monitoring View and click on discovered inventory. Then change the Target type to Data Warehouse Synchronization server by completing the following:

1. Click Change Target Type on the right-hand task pane of the Operations Console
2. In the dialog that opens select View all targets
3. Locate and select Data Warehouse Synchronization Server in the list
4. Click OK

If this returns blank you are experiencing this issue.

 

To resolve the issue run the script provided in the Microsoft article here

Note: You will have to edit the script and enter the Operations Manager Database server name, Data Warehouse servername and console path in the script . This is a PowerShell script which needs to copied to text and rename to .ps1 after entering the required information to run under PowerShell.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007 R2][OpsMgr 2012] Managing SCOM Alerts with powershell scripts

I've recently read an article here that show us how to close unclosed alerts comming from rules in a left SCOM environment and this give me the opportunity to post some scripts to help you to manage alerts in Operations Manager.

First, the article make the difference between alerts comming from monitors (I'll say autoclose alerts) and alerts comming from ruleS (Manual close alert) but forgot to speak about manual reset monitors that generate alerts.

So to close all alerts that are raised by rules :

#Resolve alerts that are created by a rule
#Note the Get-Alert become Get-SCOMAlert with OpsMgr 2012get-alert -criteria ‘ResolutionState != ”255”’ | where-object {($_.IsMonitorAlert -eq $False)}| resolve-alert -comment "Resolving all opened alerts generated by all rules."

What about closing alerts generated by manual reset monitors.

• first, here is a script to retrieve all manual reset monitors

# Search all Manual Reset Monitor$mg = (Get-ManagementGroupConnection).ManagementGroup
$monitorType = $mg.GetUnitMonitorTypes("Microsoft.Windows.SingleEventLogManualReset2StateMonitorType")[0];
$monitorCriteria = new-object Microsoft.EnterpriseManagement.Configuration.MonitorCriteria("IsUnitMonitor='1'");
$monitorTypeCriteria = new-object Microsoft.EnterpriseManagement.Configuration.UnitMonitorTypeCriteria("Name LIKE '%EventLogManualReset%'");
$monitorTypes = $mg.GetUnitMonitorTypes($monitorTypeCriteria);
$monitors = $mg.GetMonitors($monitorCriteria);
$manualResetMonitors =  @()
foreach($monitor in $monitors){
    foreach($monitorType in $monitorTypes){
        if(([Microsoft.EnterpriseManagement.Configuration.UnitMonitor]$monitor).TypeId.Id -eq $monitorType.Id){
   $manualResetMonitors += $monitor
        }
    }
}
# list all manual reset monitors
$manualResetMonitors

•  You're now able to get all information for manual reset monitors and create a script to get alerts for each monitor in $ManualresetMonitors

Script should ne like (not tested yet)

$manualResetMonitors | % {
 #Close all alerts of the specific monitor get-alert | where-object {$_.ResolutionState -eq "0" -and $_.MonitoringObjectId -eq '"'+ $_.Id +'"'} |resolve-alert -comment "Resolving all alerts for all manual reset monitors."
 }


I would like to add an other script that could be usefull when you remove a MP. Save the following script in CloseAlertsForMP.ps1 and call it in a powershell windows connected to the management group in which you want to close the alerts with MP name as argument.

Param ([String] $MPName)
If ($MPName -eq "") { $MPName=(Read-Host "Enter a Management Pack Name ") }
   $mp=Get-ManagementPack | where {$_.name -eq $MPName
   }
If ($mp -eq $null) {
   "The ManagementPack you have put in argument is incorrect or not found"
   "List of available MP"
   Get-ManagementPack | sort -property Name | ft Name
   Exit
   }
$mp.getclasses() | foreach {$criteria="ResolutionState != 255";$alerts+=get-alert -criteria $criteria}$alerts | ft name,customfield1,ResolutionState, Customfield7
$continue =(Read-Host "Do you want to continue ? (y/n)")
if ($continue -ne "y") {
   "No alerts closed"
   "Exit"
   Exit
   }
$alerts | resolve-alert -comment "Closing Alert before Management Pack retirement"

 Hope these fiew line will help you to manage alerts in your environment.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2012] IO Reference Model for SCOM 2012

Thanks to Walter Chomak for his article related to OpsMgr Performance. He provides a table with measured IO that could serve as a planning / diagnostic aid for anyone tasked with supporting a relatively large SCOM 2012 infrastructure.

His conclusion is when you surpass 750 agents, explicit design considerations for IO may not be necessary. Simply follow all guidelines and recommendations by both Microsoft and the SCOM Community.

Direct link to the article

This posting is provided "AS IS" with no warranties.

[Free Ebook] Introducing Windows 8: An Overview for IT Professionals (Preview Edition)

The Windows 8 operating system is the newest member of the Microsoft Windows family. It differs from earlier Windows releases as much for what it does not change as for what it does change. That is, the features that IT pros loved about Windows 7 are still there in Windows 8—just better. The same keyboard shortcuts, management tools, security features, and deployment options are available in Windows 8. But in many cases, Windows 8 improves them in intuitive and significant ways.

Some examples are the ribbon in File Explorer and faster disk encryption when using BitLocker Drive Encryption. This book describes these enhancements plus many of the new features in Windows 8.

Please enjoy this preview edition that contains Chapters 1-11. We will update this post with a link to the final ebook when it is ready.

Download the PDF version of the book here: Introducing Windows 8: An Overview for IT Professionals - PDF ebook

If you prefer a hard copy of the final book, you can order it here for $14.99 from our official distributor, O’Reilly Media.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2012] Exploring Classes and Discovered Instances from OpsMgr Command Shell

Pete Zerger has just published an article to show how to use the Get-SCOMClass and Get-SCOMClassInstance cmdlet.

 Read the full article here

Get-SCOMClass - Syntax given in Technet

Parameter Set: __AllParameterSets
Get-SCOMClass [-ComputerName <String[]> ] [-Credential <PSCredential> ] [-SCSession <Connection[]> ] [ <CommonParameters>]

Parameter Set: FromClassDisplayName
Get-SCOMClass [-DisplayName] <String[]> [ <CommonParameters>]

Parameter Set: FromClassGuids
Get-SCOMClass [-Id] <Guid[]> [ <CommonParameters>]

Parameter Set: FromClassName
Get-SCOMClass [-Name] <String[]> [ <CommonParameters>]

Parameter Set: FromEMO
Get-SCOMClass [-Instance] <EnterpriseManagementObject[]> [ <CommonParameters>]

Parameter Set: FromManagementPack
Get-SCOMClass [-ManagementPack] <ManagementPack[]> [ <CommonParameters>]

Get-SCOMClass - Syntax given in Technet

Parameter Set: Empty
Get-SCOMClassInstance [-ComputerName <String[]> ] [-Credential <PSCredential> ] [-SCSession <Connection[]> ] [ <CommonParameters>]

Parameter Set: FromEMODisplayNameParameterSetName
Get-SCOMClassInstance [-DisplayName] <String[]> [-ComputerName <String[]> ] [-Credential <PSCredential> ] [-SCSession <Connection[]> ] [ <CommonParameters>]

Parameter Set: FromEMOIdParameterSetName
Get-SCOMClassInstance -Id <Guid[]> [-ComputerName <String[]> ] [-Credential <PSCredential> ] [-SCSession <Connection[]> ] [ <CommonParameters>]

Parameter Set: FromEMONameParameterSetName
Get-SCOMClassInstance -Name <String[]> [-ComputerName <String[]> ] [-Credential <PSCredential> ] [-SCSession <Connection[]> ] [ <CommonParameters>]

Parameter Set: FromGroup
Get-SCOMClassInstance [-Group] <EnterpriseManagementObject[]> [-ComputerName <String[]> ] [-Credential <PSCredential> ] [-SCSession <Connection[]> ] [ <CommonParameters>]

Parameter Set: FromManagementPackClass
Get-SCOMClassInstance [-Class] <ManagementPackClass[]> [-ComputerName <String[]> ] [-Credential <PSCredential> ] [-SCSession <Connection[]> ] [ <CommonParameters>]

This posting is provided "AS IS" with no warranties.

[OpsMgr 2012] Update Rollup 3 ships, and Stefan Stranger's experience installing it

Because Kevin Holman has not published an article on the latest release of the Update Rollup 3 for System Center 2012 for Operations Manager 2012 Stefan Stranger thought he should do it this time...

Read full article here

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007 R2][OpsMgr 2012] Microsoft Service Bus Management Pack for System Center Operations Manager

This Management pack supports monitoring of the Service Bus Farms.

Direct Link to Microsoft article

Quick details

Version:	1.0.0.0	Date published:	10/19/2012
Language:	English

Files in this download

The links in this section correspond to files available for this download. Download the files appropriate for you.

File name	Size
MicrosoftServiceBusMPGuide.doc	506 KB	Download
ServiceBusMP.msi	620 KB	Download

Overview

The Microsoft Service Bus Management Pack for System Center Operations Manager supports monitoring of the Service Bus Farms.

Feature Summary
The Microsoft Service Bus Management Pack for System Center Operations Manager supports monitoring the following core areas and scenarios:

• Farms
• Hosts
• Farm Management and Gateway DB
• Front End, Back End and Gateway Roles

Release History

• 10/19/2012 - Original release, version 1.0.0.0

System requirements

Supported operating systems: Windows Server 2008 R2 SP1, Windows Server 2012

• This Management depends on the following Management Packs: SQL Server 2012 MP 6.3.173.0 or later

Instructions

Refer to the management pack guide included in this download for detailed instructions on working with this management pack. For the latest MP Guide, please download the .doc file below.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007R2][OpsMgr 2012] Microsoft Workflow Manager Management Pack for System Center Operations Manager

This Management pack supports monitoring of Workflow Farms.

Direct link to Microsoft Article

Quick details

Version:	1.0.0.0	Date published:	10/19/2012
Language:	English

Files in this download

The links in this section correspond to files available for this download. Download the files appropriate for you.

File name	Size
MicrosoftWorkflowManagerMPGuide.doc	669 KB	Download
WorkflowManagerMP.msi	592 KB	Download

Overview

The Microsoft Workflow Manager Management Pack for System Center Operations Manager supports monitoring of the Workflow Farms.

Feature Summary
The Microsoft Workflow Manager Management Pack for System Center Operations Manager provider Availability and Performance monitoring for:

• Farms
• Nodes
• Front-End Roles
• Back-End Roles

Release History

• 10/19/2012 - Original release, version 1.0.0.0

System requirements

Supported operating systems: Windows Server 2008 R2 SP1, Windows Server 2012

• This Management depends on the following Management Packs: SQL Server 2012 MP 6.3.173.0 or later and Microsoft Service Bus MP 1.0.0.0 or later

Instructions

Refer to the management pack guide included in this download for detailed instructions on working with this management pack. For the latest MP Guide, please download the .doc file below.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007R2][OpsMgr 2012] Management Pack samples - Authoring

Brian Wren published in summer 2012 MP samples that have been on OpsManJam for some time.

Direct link to Brian's article

• Sample Management Pack - Business Hours

Sample management pack for Operations Manager 2007 and System Center 2012 Operations Manager.

This management pack provides an example of configuring monitors and rules to run only during business hours.  Examples are provided for a service monitor, a monitor running a script, and monitors and rules based on a Windows event.  Two different monitor types are used for events.  These have identical functionality but illustrate two different strategies for configuring monitor types.
Each monitor and rule must specify parameters for the System.ScheduleFilter module.  StartTime and EndTime provide the time that the monitor or rule should begin functioning, while EndTime specifies the time that it should stop functioning.  DaysOfWeekMask specifies the days of the week that the schedule applies to as described in the following article: http://msdn.microsoft.com/en-us/library/ee692976(v=MSDN.10).aspx.
Both event monitors trigger a critical state from an event with a number of 101 and a source of EventCreate.  They return to healthy with an event number of 102.  The service monitor watches the running state of the Alerter service,  The script monitor will set a state according to the Successful parameter on the monitor type.  If the Successful parameter is false, then a critical state is set.  If the Succesful parameter is true, then a healthy state is set.
All rules and monitors are targeted at a class called MPAuthor.BusinessHours.Target.  This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\BusinessHours. This registry key must be on the same agent computer where the test events are created.

• Sample Management Pack - Network Devices

 This is a sample management pack for Operations Manager 2007 R2.
This management pack provides an example of monitoring network devices.  This includes providing custom monitoring for different brands of SNMP devices and monitoring Syslog mesages from devices that do not support SNMP.
A class is created for each type of SNMP device based on Microsoft.SystemCenter.NetworkDevice.  This provides a target for monitors and rules specific to each type.  For devices that do not support SNMP, a class is created based on System.HardwareComponent.  A device for each type of device is created based on this class that provides the target for monitors and rules specific to that type.

Discovery for SNMP devices is targeted at Microsoft.SystemCenter.NetworkDevice since this represents network devices that have already been discovered.  The name of the target is used to determine the type of device and which class should be created.  Discovery for devices not supporting SNMP is performed from a text log that lists the Name, IP Address, and Type for each device to discover.  This discovery is targeted at a proxy agent that is discovered from a registry key at HKLM\SOFTWARE\MPAuthor\NetworkDevices.  This registry key must also contain a value called ConfigFIle that contains a path to the configuration file.

The classes for the devices are all unhosted.  Unhosted object are typically managed on the RMS, but the discovery scripts create a special containment relationship that causes the object to be managed on the proxy agent.  Any monitors or rules targeted at these classes are loaded on the agent computer.  The managed devices should be configured to send SNMP traps and Syslog messages to the proxy agent.

• Sample Management Pack - Working with a Property Bag

 This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of a script returning multiple values in a property bag.  A single monitor type is used that accepts a parameter to specify the desired property. Also illustrated is the use of data source modules returning different data types.  Rules and monitors can use the data source returning the type they require, while they all share the same script.

The script collects different pieces of data from a file.  The name of the file must be specified in the FileName parameter of any rule or monitor.

All rules and monitors are targeted at a class called MPAuthor.PropertyBag.Target.  This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\PropertyBag. This registry key must be on the same agent computer with the file.

• Sample Management Pack - Diagnostics and Recoveries

 This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of a recovery running after a diagnostic.  The recovery only runs if specific criteria is received from the diagnostic output.  It also illustrates how to pass property bag data from the monitor to the diagnostic and the recovery.

In this example, the diagnostic runs in response to a service monitor.  If the specified service is stopped, then the diagnostic runs.  The service used is the WMI Performance Adapter (WmiApSrv), but this can be changed in the properties of the monitor.  The diagnostic runs a script that collects an error code value from the registry at HKLM\SOFTWARE\MPAuthor\DiagnosticAndRecovery\ErrorCode.  If the error code is 3, then the recovery will run.  If it is any other value, the recovery will not run.  The recovery is a script that restarts the service.

A sample diagnostic and recovery are provided for both VBScript and PowerShell.  The functionality of each are identical and only one of the diagnostics should be enabled at a time.

• Sample Management Pack - Process Data Source

 This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager. 
This management pack provides an example of a script processing the output of a data source.  The data source is followed by a probe action that changes the output data type to a property bag. Monitors and rules using the data type specify the property bag values that they require.  Two samples are provided, one using Windows PowerShell and the other using VBScript.
The specific example expects XML in the description of an event.  This simulates a condition where all errors in the application create a Windows event with the same name number and source. The XML includes the specific number and description of the error.  The expected XML format is below.  Sample rules expect an event with a number of 101 and a source of EventCreate.  The EventCreate utility can be used to create sample events.
All rules and monitors are targeted at a class called MPAuthor.ProcessDataSource.PowerShell.Target or MPAuthor.ProcessDataSource.VBScript.Target.  This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\ProcessDataSource. This registry key must be on the same agent computer that the sample event is created on.

• Sample Management Pack - Registry Monitor

 This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of a monitor based on a registry value.  A monitor type is included that will periodically check a specified registry value and compare it to a desired value.  The monitor provides the path to the value, the duration to check, and the value to compare it to.
The included monitor checks the value at HKLM\SOFTWARE\MPAuthor\RegistryMonitor\TestValue and sets the monitor to a critical state if the value is not "ThisValue".  A different registry value and desired value can be used by changing the configuration of the monitor.
All rules and monitors are targeted at a class called MPAuthor.RegistryMonitor.Target.  This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\RegisterMonitor. This registry key must be on the same agent with the registry value being checked.

• Sample Management Pack - Linked Reports

 This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of linked reports.  Two linked reports are included as follows:
Availability Report - The user is not required to provide values for any of the parameters other than the objects.  The data included is from the previous seven days.  The dialog box to select the objects is filtered to only include instances of MPAuthor.LinkedReports.Target.
Performance Report - The user must select the object and date range but does not need to select the details of the report.  It is configured to include performance data from two rules - MPAuthor.LinkedReports.CollectScriptPerformance and MPAuthor.LinkedReports.CollectWMIPerformance.
All rules and monitors are targeted at a class called MPAuthor.LinkedReports.Target.  This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\LinkedReports. This registry key must be on at least one agent computer.  The sample rules and monitor will run on these agents.

• Sample Management Pack - Cookdown

 This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager.
This management pack provides an example of workflows running scripts that support cookdown.  Two example rules are provided in both VBScript and PowerShell with with one supporting cookdown and the other not supporting cookdown.
The sample rules collect as performance data the file size for all files in a specified folder.  The rules are targeted at the class MPAuthor.Cookdown.File, so the agent will run a separate instance of the rule for every file.  The data source module for the rule not supporting cookdown requires the path of the file as a parameter.  Since this will be different for every instance, the module cannot cookdown.  The first data source module for the rule supporting cookdown also requires the file path, but this is used in a condition detection module.  The data source module running the script does not require this parameter.  Since the folder path parameter will be the same for all files, that data source module does cookdown.
Each rule will create an event in the Operations Manager event log to verify each running instance.  The rules that cookdown should create a single event while the rules not supporting cookdown should create multiple events.  Each of the rules is disabled and needs to be enabled before they run.
The event numbers created are as follows:
821 - No Cookdown - VBScript
822 - Cookdown - VBScript
823 - No Cookdown - PowerShell
824 - Cookdown - PowerShell
The discovery for MPAuthor.Cookdown.File is targeted at a class called MPAuthor.Cookdown.Target.  This is discovered by creating a registry key at HKLM\SOFTWARE\MPAuthor\Cookdown. This key must have a value named FolderPath that contains the path of the folder containing the files.  The folder must exist on the agent computer and contain one or more files to discover.

• Sample Management Pack - Discovery

 This is a sample management pack for Operations Manager 2007 R2 and System Center 2012 Operations Manager. 
This management pack provides several examples of different kinds of discovery. Several classes and relationships are included in the management pack to support the sample discoveries.   A basic description is provided for each below, and a more complete description is provided for each Discovery in the management pack.

- Registry Discovery
Creates an instance of a particular class if certain conditions are true.
- Script Discovery
Script to discover instances of a particular class. 
- Script Discovery for Unhosted Class
Script to discover instances of an unhosted class.
- WMI Discovery
WMI discovery to discover instances of a particular class. 
- Discover Containment Relationship with Script
Script to discover instances of a containment relationship.  A script is used because logic is required to parse the a property collected from a registry value.
- Discover Containment Relationship with Registry
Discover a containment relationship from registry values without using a script.  This discovery can only be used when the property value collected from the registry does not need to be parsed.
- Group Population for a Group
Uses GroupPopulator to populate a group with all instances of a particular class.
- Group Population for Distributed Application
Uses GroupPopulator to populate a distributed application with all instances of a particular class.
- Group Population for Computer Group
Uses GroupPopulator to populate the a group  with all instances of Microsoft.Windows.Computer that have an instance of another class.dfg

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007R2][OpsMgr 2012] Basic Troubleshooting Discovery Script

Do you ever get script errors from a discovery scripts?  Or you aren't discovering something that you feel should be discovered?

There are many ways to troubleshoot this discovery process, this will cover the “basics”.

Kevin Holman wrote an article here that explain how to retrieve a discovery script that is failing and how to execute it, passing the required parameter.The goal here is to get the script to run manually – and see if it throws an error, or returns the expected data.

Read the full article here

Stefan Stranger added some checks his help in his article :

1. Verify that MP has been committed on agent
2. Check agent for eventlog errors
3. Check management server for errors
4. Verify that discovery is running
5. Enable debug events in script
6. Debug script on agent

Read the full article here

In my side, the first article I've posted was :

[SCOM 2007] Authoring Management Pack - Create a VBS discovery with a debugging functionnality - PART I

With 2 others parts :

[SCOM 2007] Authoring Management Pack - Create a VBS discovery with a debugging functionnality - PART II

[SCOM 2007] Authoring Management Pack - Create a VBS discovery with a debugging functionnality - PART III

Hope wil all this references, troubleshooting a discovery will be easier for you !

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007R2][OpsMgr 2012] Troubleshooting SQL Server Performance on Operational Database and Data Warehouse

Troubleshooting SQL Server Performance on Operational Database and Data Warehouse

 

Operational Database (OperationsManager)

For the OperationsManager database, the most likely bottleneck is the disk array. If the disk array is not at maximum I/O capacity, the next most likely bottleneck is the CPU. The database will experience occasional slowdowns and operational "data storms” (very high incidences of events, alerts, and performance data or state changes that persist for a relatively long time). A short burst typically does not cause any significant delay for an extended period of time.

During operational data insertion, the database disks are primarily used for writes. CPU use is usually caused by SQL Server churn. This may occur when you have large and complex queries, heavy data insertion, and the grooming of large tables (which, by default, occurs at midnight). Typically, the grooming of even large Events and Performance Data tables does not consume excessive CPU or disk resources. However, the grooming pf the Alert and State Change tables can be CPU-intensive for large tables.

The database is also CPU-bound when it handles configuration redistribution bursts, which are caused by MP imports or by a large instance space change. In these cases, the Config service queries the database for new agent configuration. This ususally causes CPU spikes to occur on the database before the service sends the configuration updates to the agents.

Data Warehouse (OperationsManagerDW)

For the OperationsManagerDW database, the most likely bottleneck is the disk array. This usually occurs because of very large operational data insertions. In these cases, the disks are mostly busy performing writes. Usually, the disks are performing few reads, except to handle manually-generated Reporting views because these run queries on the data warehouse.

CPU usage is usually caused by SQL Server churn. CPU spikes may occur during heavy partitioning activity (when tables become very large and then get partitioned), the generation of complex reports, and large amounts of alerts in the database, with which the data warehouse must constantly sync up.

General troubleshooting

To troubleshoot the issue in this situation, collect the following information for each affected management server or gateway:

• Exact Windows version, edition, and build number (for example, Windows Server 2003 Enterprise x64 SP2)
• Number of processors
• Amount of RAM
• Amount of memory that is allocated to SQL Server
• Whether SQL Server is 32-bit and is AWE enabled
  
  Note You can find most of this information in SQL Server Management Studio or in SQL Server Enterprise Manager. To do this, open the Properties window of the server, and then click the General and Memory tabs. The General tab includes the SQL Server version, the Windows version, the platform, the amount of RAM, and the number of processors. The Memory tab includes the memory that is allocated to SQL Server. In Microsoft SQL Server 2008 and in Microsoft SQL Server 2005, the Memory tab also includes the AWE option. To determine whether AWE is enabled in Microsoft SQL Server 2000, run the following command in the Microsoft SQL Query Analyzer:
  sp_configure 'show advanced options', 1
  RECONFIGURE
  GO
  sp_configure 'awe enabled'
  The returned values for config_value and for run_value will be 1 if AWE is enabled.
  
  If OS is 32-bit and RAM is 4 GB or greater, check whether the /pae or /3gb switches exist in the Boot.ini. file. These options could be configured incorrectly if the server was originally installed by having 4 GB or less of RAM, and if the RAM was later upgraded.
  
  For 32-bit servers that have 4 GB of RAM, the /3gb switch in Boot.ini increases the amount of memory that SQL Server can address (from 2 to 3 GB). For 32-bit servers that have more than 4 GB of RAM, the /3gb switch in Boot.ini could actually limit the amount of memory that SQL Server can address. For these systems, add the /pae switch to Boot.ini, and then enable AWE in SQL Server.
  
  On a multi-processor system, check the Max Degree of Parallelism (MAXDOP) setting. In SQL Server 2008 and in SQL Server 2005, this option is on the Advanced tab in the Properties dialog box for the server. To determine this setting in SQL Server 2000, run the following command in SQL Query Analyzer:
  
  sp_configure 'show advanced options', 1
  RECONFIGURE
  GO
  sp_configure 'max degree of parallelism'
  
  The default value is 0, which means that all available processors will be used. A setting of 0 is fine for servers that have eight or fewer processors. For servers that have more than eight processors, the time that it takes SQL Server to coordinate the use of all processors may be counterproductive. Therefore, for servers that have more than eight processors, you generally should set Max Degree of Parallelism to a value of 8. To do this, run the following command in SQL Query Analyzer:
  
  sp_configure 'show advanced options', 1
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  sp_configure 'max degree of parallelism', 8
  GO
  RECONFIGURE WITH OVERRIDE
  GO
• Drive letters that contain data warehouse or Ops and Tempdb files
• Whether the antivirus software is configured to exclude SQL data and log files (Antivirus software cannot scan SQL database files. Trying to do this can degrade performance.)
• Amount of free space on drives that contain data warehouse or Ops and Tempdb files
• Storage type (SAN or local)
• RAID level (0, 1, 5, 0+1 or 1+0) for drives that are used by SQL Server
• If SAN storage us used: amount of spindles on each LUN that is used by SQL Server
• In OpsMgr 2007 SP1: whether hotfix 969130 (data warehouse event grooming) or SP1 hotfix rollup 971541 is applied
• If the converted Exchange 2007 managment pack is being used or has ever been used: amount of rows in the LocalizedText table in the Ops DB and in the EventPublisher table in the data warehouse database
  
  Note To determine the row amounts, run the following commands: 
  USE OperationsManager SELECT COUNT(*) FROM LocalizedText
  USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher

Counters to identify memory pressure

• MSSQL$<instance>: Buffer Manager: Page Life expectancy – How long pages persist in the buffer pool. If this value is below 300 seconds, it may indicate that the server could use more memory. It could also result from index fragmentation.
• MSSQL$<instance>: Buffer Manager: Lazy Writes/sec – Lazy writer frees space in the buffer by moving pages to disk. Generally, the value should not consistently exceed 20 writes per second. Ideally, it would be close to zero.
• Memory: Available Mbytes - Values below 100 MB may indicate memory pressure. Memory pressure is clearly present when this amount is less than 10 MB.
• Process: Private Bytes: _Total: This is the amount of memory (physical and page) being used by all processes combined.
• Process: Working Set: _Total: This is the amount of physical memory being used by all processes combined. If the value for this counter is significantly below the value for Process: Private Bytes: _Total, it indicates that processes are paging too heavily. A difference of more than 10% is probably significant.

Counters to identify disk pressure

Capture these Physical Disk counters for all drives that contain SQL data or log files:

• % Idle Time: How much disk idle time is being reported. Anything below 50 percent could indicate a disk bottleneck.
• Avg. Disk Queue Length: This value should not exceed 2 times the number of spindles on a LUN. For example, if a LUN has 25 spindles, a value of 50 is acceptable. However, if a LUN has 10 spindles, a value of 25 is too high. You could use the following formulas based on the RAID level and number of disks in the RAID configuration:
  • RAID 0: All of the disks are doing work in a RAID 0 set
  • Average Disk Queue Length <= # (Disks in the array) *2
  • RAID 1: half the disks are “doing work”; therefore, only half of them can be counted toward Disks Queue
  • Average Disk Queue Length <= # (Disks in the array/2) *2
  • RAID 10: half the disks are “doing work”; therefore, only half of them can be counted toward Disks Queue
  • Average Disk Queue Length <= # (Disks in the array/2) *2
  • RAID 5: All of the disks are doing work in a RAID 5 set
  • Average Disk Queue Length <= # Disks in the array *2
  • Avg. Disk sec/Transfer: The number of seconds it takes to complete one disk I/O
  • Avg. Disk sec/Read: The average time, in seconds, of a read of data from the disk
  • Avg. Disk sec/Write: The average time, in seconds, of a write of data to the disk
    
    Note The last three counters in this list should consistently have values of approximately .020 (20 ms) or lower and should never exceed.050 (50 ms). The following are the thresholds that are documented in the SQL Server performance troubleshooting guide:
    • Less than 10 ms: very good
    • Between 10 - 20 ms: okay
    • Between 20 - 50 ms: slow, needs attention
    • Greater than 50 ms: serious I/O bottleneck
  • Disk Bytes/sec: The number of bytes being transferred to or from the disk per second
  • Disk Transfers/sec: The number of input and output operations per second (IOPS)
  When % Idle Time is low (10 percent or less), this means that the disk is fully utilized. In this case, the last two counters in this list (“Disk Bytes/sec” and “Disk Transfers/sec”) provide a good indication of the maximum throughput of the drive in bytes and in IOPS, respectively. The throughput of a SAN drive is highly variable, depending on the number of spindles, the speed of the drives, and the speed of the channel. The best bet is to check with the SAN vendor to find out how many bytes and IOPS the drive should support. If % Idle Time is low, and the values for these two counters do not meet the expected throughput of the drive, engage the SAN vendor to troubleshoot.

The following links provide deeper insight into troubleshooting SQL Server performance:

• Troubleshooting Performance Problems in SQL Server 2008
  (http://msdn.microsoft.com/en-us/library/dd672789(SQL.100).aspx)
• Troubleshooting Performance Problems in SQL Server 2005
  (http://technet.microsoft.com/en-us/library/cc966540.aspx)

OpsMgr Performance counters

The following sections describe the performance counters that you can use to monitor and troubleshoot OpsMgr performance.

Gateway server role

• Overall performance counters: These counters indicate the overall performance of the gateway:
  • Processor(_Total)\% Processor Time
  • Memory\% Committed Bytes In Use
  • Network Interface(*)\Bytes Total/sec
  • LogicalDisk(*)\% Idle Time
• LogicalDisk(*)\Avg. Disk Queue LengthOpsMgr process generic performance counters: These counters indicate the overall performance of OpsMgr processes on the gateway:
  • Process(HealthService)\%Processor Time
  • Process(HealthService)\Private Bytes (depending on how many agents this gateway is managing, this number may vary and could be several hundred megabytes)
  • Process(HealthService)\Thread Count
  • Process(HealthService)\Virtual Bytes
  • Process(HealthService)\Working Set
  • Process(MonitoringHost*)\% Processor Time
  • Process(MonitoringHost*)\Private Bytes
  • Process(MonitoringHost*)\Thread Count
  • Process(MonitoringHost*)\Virtual Bytes
• Process(MonitoringHost*)\Working SetOpsMgr specific performance counters: These counters are OpsMgr specific counters that indicate the performance of specific aspects of OpsMgr on the gateway:
  • Health Service\Workflow Count
  • Health Service Management Groups(*)\Active File Uploads: The number of file transfers that this gateway is handling. This represents the number of management pack files that are being uploaded to agents. If this value remains at a high level for a long time, and there is not much management pack importing at a given moment, these conditions may generate a problem that affects file transfer.
  • Health Service Management Groups(*)\Send Queue % Used: The size of persistent queue. If this value remains higher than 10 for a long time, and it does not drop, this indicates that the queue is backed up. This condition is cause by an overloaded OpsMgr system because the management server or database is too busy or is offline.
  • OpsMgr Connector\Bytes Received: The number of network bytes received by the gateway – i.e., the amount of incoming bytes before decompression.
  • OpsMgr Connector\Bytes Transmitted: The number network bytes sent by the gateway – i.e., the amount of outgoing bytes after compression.
  • OpsMgr Connector\Data Bytes Received: The number of data bytes received by the gateway – i.e., the amount of incoming data after decompression.
  • OpsMgr Connector\Data Bytes Transmitted: The number of data bytes sent by the gateway – i.e. the amount of outgoing data before compression.
  • OpsMgr Connector\Open Connections: The number of connections that are open on gateway. This number should be same as the number of agents or management servers that are directly connected to the gateway.

Management server role

Overall performance counters: These counters indicate the overall performance of the management server:

• Processor(_Total)\% Processor Time
• Memory\% Committed Bytes In Use
• Network Interface(*)\Bytes Total/sec
• LogicalDisk(*)\% Idle Time

LogicalDisk(*)\Avg. Disk Queue LengthOpsMgr process generic performance counters: These counters indicate the overall performance of OpsMgr processes on the management server:

• Process(HealthService)\% Processor Time
• Process(HealthService)\Private Bytes – Depending on how many agents this management server is managing, this number may vary, and it could be several hundred megabytes.
• Process(HealthService)\Thread Count
• Process(HealthService)\Virtual Bytes
• Process(HealthService)\Working Set
• Process(MonitoringHost*)\% Processor Time
• Process(MonitoringHost*)\Private Bytes
• Process(MonitoringHost*)\Thread Count
• Process(MonitoringHost*)\Virtual Bytes

Process(MonitoringHost*)\Working SetOpsMgr specific performance counters: These counters are OpsMgr specific counters that indicate the performance of specifric aspects of OpsMgr on the management server:

• Health Service\Workflow Count: The number of workflows that are running on this management server.
• Health Service Management Groups(*)\Active File Uploads: The number of file transfers that this management server is handling. This represents the number of management pack files that are being uploaded to agents. If this value remains at a high level for a long time, and there is not much management pack importing at a given moment, these conditions may generate a problem that affects file transfer.
• Health Service Management Groups(*)\Send Queue % Used: The size of the persistent queue. If this value remains higher than 10 for a long time, and it does not drop, this indicates that the queue is backed up. This condition is cause by an overloaded OpsMgr system because the OpsMgr system (for example, the root management server) is too busy or is offline.
• Health Service Management Groups(*)\Bind Data Source Item Drop Rate: The number of data items that are dropped by the management server for database or data warehouse data collection write actions. When this counter value is not 0, the management server or database is overloaded because it can’t handle the incoming data item fast enough or because a data item burst is occurring. The dropped data items will be resent by agents. After the overload or burst situation is finished, these data items will be inserted into the database or into the data warehouse.
• Health Service Management Groups(*)\Bind Data Source Item Incoming Rate: The number of data items received by the management server for database or data warehouse data collection write actions.
• Health Service Management Groups(*)\Bind Data Source Item Post Rate: The number of data items that the management server wrote to the database or data warehouse for data collection write actions.
• OpsMgr Connector\Bytes Received: The number of network bytes received by the management server – i.e., the size of incoming bytes before decompression.
• OpsMgr Connector\Bytes Transmitted: The number of network bytes sent by the management server – i.e., the size of outgoing bytes after compression.
• OpsMgr Connector\Data Bytes Received: The number of data bytes received by the management server – i.e., the size of incoming data after decompress)
• OpsMgr Connector\Data Bytes Transmitted: The number of data bytes sent by the management server – i.e., the size of outgoing data before compression)
• OpsMgr Connector\Open Connections: The number of connections open on management server. It should be same as the number of agents or root management server that are directly connected to it.
• OpsMgr database Write Action Modules(*)\Avg. Batch Size: The number of a data items or batches that are eceived by database write action modules. If this number is 5,000, a data item burst is occurring.
• OpsMgr DB Write Action Modules(*)\Avg. Processing Time: The number of seconds a database write action modules takes to insert a batch into database. If this number is often greater than 60, a database insertion performance issue is occurring.
• OpsMgr DW Writer Module(*)\Avg. Batch Processing Time, ms: The number of milliseconds for data warehouse write action to insert a batch of data items into a data warehouse.
• OpsMgr DW Writer Module(*)\Avg. Batch Size: The average number of data items or batches received by data warehouse write action modules.
• OpsMgr DW Writer Module(*)\Batches/sec: The number of batches received by data warehouse write action modules per second.
• OpsMgr DW Writer Module(*)\Data Items/sec: The number of data items received by data warehouse write action modules per second.
• OpsMgr DW Writer Module(*)\Dropped Data Item Count: The number of data items dropped by data warehouse write action modules.
• OpsMgr DW Writer Module(*)\Total Error Count: The number of errors that occurred in a data warehouse write action module.

Root management server role

Overall performance counters: These counters indicate the overall performance of the root management server:

• Processor(_Total)\% Processor Time
• Memory\% Committed Bytes In Use
• Network Interface(*)\Bytes Total/sec
• LogicalDisk(*)\% Idle Time

LogicalDisk(*)\Avg. Disk Queue LengthOpsMgr process generic performance counters: These counters indicate the overall performance of OpsMgr processes on the root management server:

• Process(HealthService)\% Processor Time
• Process(HealthService)\Private Bytes (Depending on how many agents this root management server is managing, this number may vary and could be several hundred Megabytes.)
• Process(HealthService)\Thread Count
• Process(HealthService)\Virtual Bytes
• Process(HealthService)\Working Set
• Process(MonitoringHost*)\% Processor Time
• Process(MonitoringHost*)\Private Bytes
• Process(MonitoringHost*)\Thread Count
• Process(MonitoringHost*)\Virtual Bytes
• Process(MonitoringHost*)\Working Set
• Process(Microsoft.Mom.ConfigServiceHost)\% Processor Time
• Process(Microsoft.Mom.ConfigServiceHost)\Private Bytes
• Process(Microsoft.Mom.ConfigServiceHost)\Thread Count
• Process(Microsoft.Mom.ConfigServiceHost)\Virtual Bytes
• Process(Microsoft.Mom.ConfigServiceHost)\Working Set
• Process(Microsoft.Mom.Sdk.ServiceHost)\% Processor Time
• Process(Microsoft.Mom.Sdk.ServiceHost)\Private Bytes
• Process(Microsoft.Mom.Sdk.ServiceHost)\Thread Count
• Process(Microsoft.Mom.Sdk.ServiceHost)\Virtual Bytes

Process(Microsoft.Mom.Sdk.ServiceHost)\Working SetOpsMgr specific performance counters: These counters are OpsMgr specific counters that indicate the performance of specific aspects of OpsMgr on the root management server:

• Health Service\Workflow Count: The number of workflows that are running on this root management server.
• Health Service Management Groups(*)\Active File Uploads: The number of file transfers that this root management server is handling – i.e., configuration and management pack uploads to agents. If this value remains higher for a long time, and it does not drop, this indicates that not much discovery or management pack is being imported at the moment, and that there could be a problem in file transfer.
• Health Service Management Groups(*)\Send Queue % Used: The size of the persistent queue.
• Health Service Management Groups(*)\Bind Data Source Item Drop Rate: The number of data items dropped by the root management server for database or data warehouse data collection write actions. When this counter value is not 0, the root management server or database is overloaded because it can’t handle the incoming data item fast enough or because a data item burst is occurring. The dropped data items will be resent by agents. After the overloaded or burst situation is finished, these data items will be inserted into the database or into the data warehouse.
• Health Service Management Groups(*)\Bind Data Source Item Incoming Rate: The number of data items received by the root management server for database or data warehouse data collection write actions.
• Health Service Management Groups(*)\Bind Data Source Item Post Rate: The number of data items that the root management server wrote to the database or to the data warehouse for database or data warehouse data collection write actions.
• OpsMgr Connector\Bytes Received: The number of network bytes received by the root management server – i.e., the size of incoming bytes before decompress.
• OpsMgr Connector\Bytes Transmitted: The number of network bytes sent by the root management server – i.e., the size of outgoing bytes after compression.
• OpsMgr Connector\Data Bytes Received: The number of data bytes received by the root management server – i.e., the size of incoming data after decompression.
• OpsMgr Connector\Data Bytes Transmitted: The number of data bytes sent by the root management server – i.e., the size of outgoing data before compression.
• OpsMgr Connector\Open Connections: The number of connections open on the root management server. It should be same as the number of agents or management servers that are directly connected to it.
• OpsMgr Config Service\Number Of Active Requests: The number of configuration or management pack requests that are being processing by the Config service.
• OpsMgr Config Service\Number Of Queued Requests: The number of queued config or management pack requests sent to the Config service. If it is high for a long time, the instance space or management pack space is changing too frequently.
• OpsMgr SDK Service\Client Connections: The number of SDK connections.
• OpsMgr DB Write Action Modules(*)\Avg. Batch Size: The number of a data items or batches that are received by database write action modules. If this number is 5,000, a data item burst is occurring.
• OpsMgr DB Write Action Modules(*)\Avg. Processing Time: The number of seconds that a database write action modules takes to insert a batch into a database. If this number is often larger than 60, a database insertion performance issue is occurring.
• OpsMgr DW Writer Module(*)\Avg. Batch Processing Time, ms: The number of milliseconds that it takes for a data warehouse write action to insert a batch of data items into a data warehouse.
• OpsMgr DW Writer Module(*)\Avg. Batch Size: The average number of data items or batches that are received by data warehouse write action modules.
• OpsMgr DW Writer Module(*)\Batches/sec: The number of batches received by data warehouse write action modules per second.
• OpsMgr DW Writer Module(*)\Data Items/sec: The number of data items received by data warehouse write action modules per second.
• OpsMgr DW Writer Module(*)\Dropped Data Item Count: The number of data items that are dropped by data warehouse write action modules)
• OpsMgr DW Writer Module(*)\Total Error Count (This is number of errors happened in data warehouse write action modules.

This posting is provided "AS IS" with no warranties.