As soon as I started the Microsoft.EnterpriseManagement.GatewayApprovalTool.exe I received to following error. 

Microsoft.EnterpriseManagement.gatewayApprovalTool.exe /ManagementServerName=<managementserverFQDN> /GatewayName=<GatewayFQDN> /Action=Create

Microsoft.EnterpriseManagement.GatewayApprovalTool
Copyright (c) Microsoft Corporation. All rights reserved.

The request failed with the following error:
Index was out of range. Must be non-negative and less than the size of the collection.

Parameter name: index

It took me a while to figure out what "index" could be meant, because there was no additional information in Event Log or somewhere else.

Then I figured out that the customer removed the old RMSEmulator role from there SCOM environment, which is fine if no workflow from any third party or custom MPs are targeted to the RMSe instance.

Remember in SCOM 2012 we introduced resource pools and the old Root Management Server has been retired. So there is a possibility now to remove the legacy Root Management emulator instance from SCOM by using PowerShell.
blogs.technet.com/b/momteam/archive/2011/08/22/topology-changes-in-system-center-2012-operations-manager-overview.aspx

If you run into that situation that the geateway approval tool returns an "Index was out of range" error, you can fix it as following:

1. Test if an RMSe instance exists
    
   Get-SCOMRMSemulator (If one RMSe exists powershell report the corresponding Management Server.) In this case you can stop here and need to search for another reason) ;-)
   
   
2. Start Operations Manager Powershell
   
   
3. Create a new RMSe instance on any existent management server in your environment.
   
   Get-SCOMManagementServer –Name <FQDN of Management Server> | Set-SCOMRMSEmulator
   
   
4. Test if the RMSe instance has been created successfully
   
   Get-SCOMRMSemulator (now you should see your management server)
   
   
5. Run the GatewayApprovalTool to prepare your environment for the new gateway. (Remember that
   needs to be done before you install the gateway itself.)
   
   Microsoft.EnterpriseManagement.GatewayApprovalTool.exe /ManagementServerName=<managementserverFQDN> /GatewayName=<GatewayFQDN> /Action=Create
   
   
6. If you want to remove the RMSe instance afterwards again, you can do it by running
   
   Remove-SCOMRMSEmulator

Good luck and have fun!

While troubleshooting an unexpected database growing issue at customer we found out that the main reason for increased data volume in operational database was the MP "Windows Server Print Server 2008 Management Pack".

Drilling down I saw there are a few rules that collect a very high amount of performance values.

Finally the reason were wrong configured collection rule collecting data from the wrong target.

This issue applies to Windows Server 2008 / R2 Print serer only. Windows Server 2012 and Windows Server 2003 are fine.

Looking into the specific collection rule "Performance Measuring: Print Queue\Jobs" we see on Windows Server 2012 as Target "Windows Server 2012 Print Services Role"

.... and this Rule is collecting all instances of performance counter Print Queue / Jobs.

The same thing we see on Windows Server 2008 Print Server with a small difference. Here we see as Target "Windows 2008 Print Service Printer Queue" instead of "Windows Server 2008 Print Service Role"

But the data source is configured in the same way as in 2012 MP. 

What does this mean?

In case you have 250 print queues on your Windows 2008 Print Server installed the MP will discover all 250 print queues. Each of them will start collecting performance values for ALL instances of this counter which are 250 in total.

This means that rule is collecting 62500 performance values (250 x 250) every 15 minutes instead of 250 values only. 

Finally I found that there are 7 collection rules (4 enabled / 3 disabled by default) configured in this way.

Depends on how many printer queues you are monitoring this might cause a large data increment on your OpsMgr Database.

If you are affected by this issue you might temporarily disable these rules until the MP has been fixed.

Alternatively you can create your own collection rule using the right target "Windows Server 2008 Print Service Role".

Hope we get the MP fixed very soon

So you can easily change your regional settings and restart the OpsMgr console to switch display strings.

Sometimes it might be required to start the console to show only English Display Strings in OpsMgr console but let regional settings for other applications set to your language (e.g. Excel).

In this case you can use the following Powershell command to force OpsMgr console to start in English independent from you regional setting.   

$key = get-item -path 'hkcu:\Control Panel\International'
$curLocale = $key.GetValue('Locale')
$curLocaleName = $key.GetValue('LocaleName')
$curShortDate = $key.GetValue('sShortDate')

If (test-path -path 'hklm:\Software\Microsoft\System Center Operations Manager\12\Setup')
{
$opsMgrConsole = ((get-item -path 'hklm:\SOFTWARE\Microsoft\System Center Operations Manager\12\Setup').GetValue('InstallDirectory') + '\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe')
}
elseif (test-path -path 'hklm:\Software\Microsoft\Microsoft Operations Manager\3.0\Setup')
{
$opsMgrConsole = ((get-item -path 'hklm:\Software\Microsoft\Microsoft Operations Manager\3.0\Setup').GetValue('InstallDirectory') + '\Microsoft.MOM.UI.Console.exe')
}

set-itemproperty -path $key.PSPath -name 'LocaleName' -value 'en-US'
set-itemproperty -path $key.PSPath -name 'Locale' -value '00000409'
set-itemproperty -path $key.PSPath -name 'sShortDate' -value 'M/d/yyyy'

start-process $opsMgrConsole -wait
start-sleep -Seconds 10

set-itemproperty -path $key.PSPath -name 'LocaleName' -value $curLocaleName
set-itemproperty -path $key.PSPath -name 'Locale' -value $curLocale
set-itemproperty -path $key.PSPath -name 'sShortDate' -value $curShortDate

This script works for OpsMgr 2007 R2 and OpsMgr 2012.

PS D:\>Get-ScomAgent
Get-SCOMAgent:Object reference not set to an instance of an object.

I figured out that this error was related to one specific SCOM Agent.

The error did not report any details what's wrong.

I resolved the problem by removing the affected agents from SCOM.
After new approving the agent the command let Get-SCOMAgent worked fine again. 

To identify the affected Agent I used the following PowerShell command:

get-scomclass -name "Microsoft.SystemCenter.Agent" | get-scomclassinstance | sort displayname | foreach {Get-SCOMAgent $_}

This command determines all instances based on agents class. It walks through all agent instances separately and will run into the same issue. But you easily identify what agents is the problematic one.

Now you can remove the agent from SCOM Console. After some minutes it will appear under "Pending Management" again.

After approving the command let should work fine again.  

In my test environment with just one single MS I would expect to see only one single entry in the performance view Client Connections, because there is only one SDK Service running in my environment.

But checking the performance view I see more than 20 entries, but only one graph. Why?

Looking into the collection rule data source points me to the right direction.

Looking into Performance Monitor I saw that the performance counter name contains a process ID

That means each time if the SDK restarts, it get a new process ID and the Performance Counter Instance name is different. So this will result in multiple graphs in OpsMgr console.

Over time you will get more and more entries there.

Hmm, ok but.... how can I fix this? And primarily how can I get rid of the multiple empty entries?

Let's start with the second question first.

• Remove the multiple old empty entries form this view by removing the MP "System Center Operations Manager Data Access Service Monitoring" manually or by using Powershell

get-SCOMManagementpack -name "Microsoft.SystemCenter.OperationsManager.DataAccessService" | Remove-SCOMManagementpack

   After removing the original MP your multiple performance counter entries are gone.

To fix this behavior until this might be fixed in a future MP update, you can create your own performance collection rule.

• You can create your own rule, based on a PowerShell script. The following script provides you the actual value of SDK Client Connections and returns it as an OpsMgr PropertyBag.

$ID = (get-process -name Microsoft.Mom.Sdk.ServiceHost).ID
$CookedValue = (Get-Counter -Counter "\OpsMgr SDK Service(microsoft.mom.sdk.servicehost-pid$ID)\Client Connections").CounterSamples | Select -ExpandProperty Cookedvalue
$Value = ([math]::Round($CookedValue, 2))
$Value

$oAPI = new-object -comObject "MOM.ScriptAPI"
# Create the property bag
$pb = $oAPI.CreatePropertyBag()
# Populate the property bag with data from the registy
$pb.AddValue("Value", $Value) 
$pb

• Here is a MP Example how you can create a powershell performance collection rule:

<?xml version="1.0" encoding="utf-8"?><ManagementPack ContentReadable="true" SchemaVersion="2.0" OriginalSchemaVersion="1.0" xmlns:xsd="www.w3.org/2001/XMLSchema" xmlns:xsl="www.w3.org/1999/XSL/Transform">
  <Manifest>
    <Identity>
      <ID>SDKConnectionCount.FixMP</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>SDKConnectionCount.FixMP</Name>
    <References>
      <Reference Alias="MicrosoftSystemCenterInternal">
        <ID>Microsoft.SystemCenter.Internal</ID>
        <Version>7.0.8427.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="MicrosoftSystemCenterDataWarehouseLibrary">
        <ID>Microsoft.SystemCenter.DataWarehouse.Library</ID>
        <Version>7.0.8427.1</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="SystemCenter">
        <ID>Microsoft.SystemCenter.OperationsManager.DataAccessService</ID>
        <Version>7.0.8560.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>7.5.8501.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="SystemCenter1">
        <ID>Microsoft.SystemCenter.NTService.Library</ID>
        <Version>7.0.8560.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="Performance">
        <ID>System.Performance.Library</ID>
        <Version>7.0.8427.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>7.5.8501.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="SC">
        <ID>Microsoft.SystemCenter.Library</ID>
        <Version>7.0.8427.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="Health">
        <ID>System.Health.Library</ID>
        <Version>7.0.8427.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
  </Manifest>
  <TypeDefinitions>
    <ModuleTypes>
      <DataSourceModuleType ID="SDKConnectionCount.FixMP.TimedPowershellScript" Accessibility="Internal" Batching="false">
        <Configuration>
          <IncludeSchemaTypes>
            <SchemaType>Windows!Microsoft.Windows.PowerShellSchema</SchemaType>
          </IncludeSchemaTypes>
          <xsd:element minOccurs="1" name="Interval" type="xsd:integer" xmlns:xsd="www.w3.org/2001/XMLSchema" />
          <xsd:element minOccurs="1" name="ScriptName" type="xsd:string" xmlns:xsd="www.w3.org/2001/XMLSchema" />
          <xsd:element minOccurs="1" name="ScriptBody" type="xsd:string" xmlns:xsd="www.w3.org/2001/XMLSchema" />
          <xsd:element minOccurs="1" name="TimeoutSeconds" type="xsd:integer" xmlns:xsd="www.w3.org/2001/XMLSchema" />
        </Configuration>
        <OverrideableParameters>
          <OverrideableParameter ID="Interval" Selector="$Config/Interval$" ParameterType="int" />
          <OverrideableParameter ID="Timeout" Selector="$Config/TimeoutSeconds$" ParameterType="int" />
        </OverrideableParameters>
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <DataSource ID="Scheduler" TypeID="System!System.Scheduler">
                <Scheduler>
                  <SimpleReccuringSchedule>
                    <Interval>$Config/Interval$</Interval>
                  </SimpleReccuringSchedule>
                  <ExcludeDates />
                </Scheduler>
              </DataSource>
              <ProbeAction ID="PS" TypeID="Windows!Microsoft.Windows.PowerShellPropertyBagProbe">
                <ScriptName>$Config/ScriptName$</ScriptName>
                <ScriptBody>$Config/ScriptBody$</ScriptBody>
                <TimeoutSeconds>$Config/TimeoutSeconds$</TimeoutSeconds>
              </ProbeAction>
            </MemberModules>
            <Composition>
              <Node ID="PS">
                <Node ID="Scheduler" />
              </Node>
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.PropertyBagData</OutputType>
      </DataSourceModuleType>
    </ModuleTypes>
  </TypeDefinitions>
  <Monitoring>
    <Rules>
      <Rule ID="SDKConnectionCount.FixMP.OM2012.CollectionRule.SDKClientConnections" Enabled="true" Target="SystemCenter!Microsoft.SystemCenter.ManagementDataAccessService" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>Custom</Category>
        <DataSources>
          <DataSource ID="DS" TypeID="SDKConnectionCount.FixMP.TimedPowershellScript">
            <Interval>300</Interval>
            <ScriptName>getSDKConnections.ps1</ScriptName>
            <ScriptBody>
$ID = (get-process -name Microsoft.Mom.Sdk.ServiceHost).ID
$CookedValue = (Get-Counter -Counter "\OpsMgr SDK Service(microsoft.mom.sdk.servicehost-pid$ID)\Client Connections").CounterSamples | Select -ExpandProperty Cookedvalue
$Value = ([math]::Round($CookedValue, 2))
$Value

$oAPI = new-object -comObject "MOM.ScriptAPI"
# Create the property bag
$pb = $oAPI.CreatePropertyBag()
# Populate the property bag with data from the registy
$pb.AddValue("Value", $Value) 
$pb
</ScriptBody>
            <TimeoutSeconds>60</TimeoutSeconds>
          </DataSource>
        </DataSources>
        <ConditionDetection ID="cd" TypeID="Performance!System.Performance.DataGenericMapper">
          <ObjectName>OpsMgr SDK Service</ObjectName>
          <CounterName>Client Connections</CounterName>
          <InstanceName>microsoft.mom.sdk.servicehost</InstanceName>
          <Value>$Data/Property[@Name='Value']$</Value>
        </ConditionDetection>
        <WriteActions>
          <WriteAction ID="DB" TypeID="SC!Microsoft.SystemCenter.CollectPerformanceData" />
          <WriteAction ID="DW" TypeID="MicrosoftSystemCenterDataWarehouseLibrary!Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData" />
        </WriteActions>
      </Rule>
    </Rules>
    <Overrides>
      <RulePropertyOverride ID="OverrideForRuleMicrosoftSystemCenterDataAccessServiceCollectClientConnectionsForContextMicrosoftSystemCenterManagementDataAccessServiceaaad7b22a79b41f88df37499e1882aae" Context="SystemCenter!Microsoft.SystemCenter.ManagementDataAccessService" Enforced="false" Rule="SystemCenter!Microsoft.SystemCenter.DataAccessService.CollectClientConnections" Property="Enabled">
        <Value>false</Value>
      </RulePropertyOverride>
    </Overrides>
  </Monitoring>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="SDKConnectionCount.FixMP">
          <Name>SDK Connection Count MP-FIX</Name>
        </DisplayString>
        <DisplayString ElementID="SDKConnectionCount.FixMP.OM2012.CollectionRule.SDKClientConnections">
          <Name>SDK ClientConnections Collection Rule</Name>
        </DisplayString>
        <DisplayString ElementID="SDKConnectionCount.FixMP.TimedPowershellScript">
          <Name>Timed Powershell Script PropertyBag Datasource</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPack>

This sample MP contains as well an override to disable the original collection rule.
If you want to import this sample MP you need to reimport the original "System Center Operations Manager Data Access Service Monitoring" MP of course.
Remember: The original MP provides much more than the collection rule I'm talking here. So you should definitely reimport this original MP again. ;-)
You'll find it on your SCOM 2012 Installation media in folder "Management Packs"

 After importing those two MPs you will see only one graph.

SDKConnectionCount.FixMP.xml

This happens if your configured locale doesn't use AM/PM time symbols. In this case you can't schedule any Maintenance Mode in the afternoon/evening. :-(

The reason is that the Schedule Maintenance Mode tool uses 12 hours instead of 24 hours with this local settings.

This is a known issue blogs.technet.com/b/momteam/archive/2011/06/21/schedule-maintenance-mode-reskit-tool-info.aspx

As a small workaround you can change your local settings on the system you run the ScheduleMaintenanceMode.exe by setting the AM/PM Symbol on your local settings option.

Once you set this, start the Schedule Maintenance Mode tool again. Now you are able to set schedules in the evening too. ;-)

Have fun ;-)

Looking at this class we see all synchronization rules targeted on it.
So if no instance of this class is available no synchronization rule can run.

Unfortunately you will not see any alert because the rules will not run in general and a rule which is not intended to run can't be monitored.
(Like a monitor for a service, if the service itself doesn't exist.)

This issue affects "only" synchronized data (like Alerts, State Changes, Availability Data, new/updated MPs, ......).
Data that will be stored directly to the OperationsManagerDW database (like Performance data, Events, ....) are not affected.

Resolution:
We resolved the issue by reinstalling OpsMgr Reporting. The installation of OpsMgr Reporting created this synchronization object again.

Recommendation:
It looks like this can happen in particular circumstances.
Please check always if the "Datawarehouse Synchronization Server" exists after moving the RMS role to another Management Server.
Use the Discovered Inventory view in your OpsMgr Console and Change target Type to "Datawarehouse Synchronization Server"

Alternatively you can quickly check if your alert data becomes synchronized by running the following SQL query against DW. This shows all alerts stored or updated within the last 24 hour from DWH DB

Use OperationsManagerDW
SELECT AlertName, DWCreatedDateTime, DWLastModifiedDateTime
  FROM [OperationsManagerDW].[Alert].[vAlert]
  where (DWCreatedDateTime > DATEADD("HOUR",-24,getutcdate())) or (DWLastModifiedDateTime > DATEADD("HOUR",-24,getutcdate()))
  order by DWCreatedDateTime desc

There you should find any records added or updated after you moved the RMS ( if any alert was raised or updated after the move of course ;-)
Hint: Data in DWH are stored in UTC time!!

Important Note:
If you identified the issue you should act as soon as possible. Remember you typical keep data in you operational DB 7 days only (by default). After this time period OpsMgr will groom the data from operational DB and can't synchronize it anymore.
Otherwise you might lose historical data.

As Example: You need a dynamic group that contains all windows computers where a windows service "xyz" is installed. 

Such a containment group can't be created via OpsMgr UI.
You can create a group of specific instances itself, but it's not possible to search all computer objects that are hosting this specific instances (e.g. service).

Nevertheless there is a way to create such a group by using the Authoring Console or by modifying the MP xml.

Many customers are not familiarly with developing MPs by using Authoring Console, so I'll describe the xml method here.

The quick and easy way without using the authoring console (Example: for Computers hosting specific Windows service):

First of all you need to discover the specific service you want to look for.

Use the Windows Service Template to discover the service on your agents. In this example I'll use BITS service. 

Now you need to create a new group using the OpsMgr Console. Please store the group in the same MP where you stored the services template before.

Remember: Creating a group via UI will generate a GroupID with a GUID (like UINameSpacee1bb42b5fc114d91ac4fa985886d35f3.Group). It is not easy to find the corresponding group discovery inside the xml.
To make it a bit easier to find the discovery rule please put in any noticeable value (like "####") as filter.

Once you've created the group please export the unsealed MP where you stored the new created group and the service template.

Open the xml file and search for your service discovery <ServiceName>BITS</ServiceName>

      <Discovery ID="ServiceStateProbePage_fb07b209c8a2443dbb86a8f00bcddcd0.DiscoveryRule" Enabled="false" Target="MicrosoftWindowsLibrary6172210!Microsoft.Windows.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryClass TypeID="ServiceStateProbePage_fb07b209c8a2443dbb86a8f00bcddcd0" />
        </DiscoveryTypes>
        <DataSource ID="DS" TypeID="MicrosoftWindowsLibrary6172210!Microsoft.Windows.Win32ServiceInformationProviderWithClassSnapshotDataMapper">
          <ComputerName>$Target/Property[Type="MicrosoftWindowsLibrary6172210!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
          <ServiceName>BITS</ServiceName>
          <Frequency>60</Frequency>
          <ClassId>$MPElement[Name="ServiceStateProbePage_fb07b209c8a2443dbb86a8f00bcddcd0"]$</ClassId>
          <InstanceSettings>
            <Settings>
              <Setting>
                <Name>$MPElement[Name="MicrosoftWindowsLibrary6172210!Microsoft.Windows.Computer"]/PrincipalName$</Name>
                <Value>$Target/Property[Type="MicrosoftWindowsLibrary6172210!Microsoft.Windows.Computer"]/PrincipalName$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/ServiceName$</Name>
                <Value>$Data/Property[@Name='Name']$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/ServiceProcessName$</Name>
                <Value>$Data/Property[@Name='BinaryPathName']$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/DisplayName$</Name>
                <Value>$Data/Property[@Name='DisplayName']$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/Description$</Name>
                <Value>$Data/Property[@Name='Description']$</Value>
              </Setting>
              <Setting>
                <Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name>
                <Value>BITS</Value>
              </Setting>
            </Settings>
          </InstanceSettings>
        </DataSource>
      </Discovery>

Once you found your discovery you need to copy the class ID.

Here it is: ServiceStateProbePage_fb07b209c8a2443dbb86a8f00bcddcd0 (Hint: My ClassID is valid in my sample only, this GUID will not work in your MP. ;-)

Now search inside the xml file for your group marker (e.g. "####")

    <Discoveries>
      <Discovery ID="UINameSpacee1bb42b5fc114d91ac4fa985886d35f3.Group.DiscoveryRule" Enabled="true" Target="UINameSpacee1bb42b5fc114d91ac4fa985886d35f3.Group" ConfirmDelivery="false" Remotable="true" Priority="Normal">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryRelationship TypeID="MicrosoftSystemCenterInstanceGroupLibrary6172210!Microsoft.SystemCenter.InstanceGroupContainsEntities" />
        </DiscoveryTypes>
        <DataSource ID="GroupPopulationDataSource" TypeID="SystemCenter!Microsoft.SystemCenter.GroupPopulator">
          <RuleId>$MPElement$</RuleId>
          <GroupInstanceId>$MPElement[Name="UINameSpacee1bb42b5fc114d91ac4fa985886d35f3.Group"]$</GroupInstanceId>
          <MembershipRules>
            <MembershipRule>
              <MonitoringClass>$MPElement[Name="MicrosoftWindowsLibrary6172210!Microsoft.Windows.Computer"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="MicrosoftSystemCenterInstanceGroupLibrary6172210!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <Property>$MPElement[Name="MicrosoftWindowsLibrary6172210!Microsoft.Windows.Computer"]/PrincipalName$</Property>
                  </ValueExpression>
                  <Operator>Equal</Operator>
                  <ValueExpression>
                    <Value>#####</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
            </MembershipRule>
          </MembershipRules>
        </DataSource>
      </Discovery>

Replace the whole Section between <Expression> and </Expression> by the following lines. Please use as ClassID your own ClassID copied above.

       <Expression>
        <Contains>
          <MonitoringClass>$MPElement[Name="ServiceStateProbePage_fb07b209c8a2443dbb86a8f00bcddcd0"]$</MonitoringClass>
        </Contains>
      </Expression>

Save the MP file and import it again into your Management Group.

Now you will find all Windows Computer Objects hosting the "BITS" service.

There is one disadvantage on this group type. You'll not be able to change these groups via OpsMgr UI anymore.

Opening this group in OpsMgr UI you will see only the xml code. Any future change needs to be made in xml file again.

Another example:

Group containing all windows computers hosting a specific service but only computers with a host name matches wildcard DA*

       <Expression>
                <And>
                <Expression>
                    <RegExExpression>
                      <ValueExpression>
                        <Property>$MPElement[Name="MicrosoftWindowsLibrary6172210!Microsoft.Windows.Computer"]/PrincipalName$</Property>
                      </ValueExpression>
                      <Operator>MatchesWildcard</Operator>
                      <Pattern>DA*</Pattern>
                    </RegExExpression>
               </Expression>
               <Expression>
                  <Contains>
                  <MonitoringClass>$MPElement[Name="ServiceStateProbePage_fb07b209c8a2443dbb86a8f00bcddcd0"]$</MonitoringClass>
                  </Contains>
                </Expression>
                </And>
              </Expression>

As I heard from customers, most of the customer try to fix such issues by flushing the health service state or deleting the whole Health Service folder.
Both methods are very strong, mostly unnecessary and can cause other bad side effects.

Most of the customer are not aware of the "System Center Internal Task Library" Management Pack. So I want to explain it here.

You can't find this Management Pack in the online MP catalog because it was delivered already with the OpsMgr installation media.
You will find the Management Pack on your OpsMgr DVD in the folder ".\Support Tools\i368". It is called Microsoft.SystemCenter.Internal.Tasks.mp

When you import this MP you'll get 4 new tasks visible in your OpsMgr console.

These tasks are targeted to "Entity" so you'll see them on any class you select in the OpsMgr Console.

What can you do with these tasks?

Show local cache for state change events. 
This task will show you the actual state change events stored in the local Health Service cache on the agent.

Resubmit local cache for state change events.
This task submits the local cached state change to the OpsMgr Databases again.
This can fix your rollup issue, because the new submitted state change force a recalculation of the roll-up monitor as well.

Show Running Rules and Monitors for this Object.
This task shows you all running workflows targeted to the selected object. It will tell you which workflows are loaded for this objects (e.g. Logical Disk) on this agents.

Show Failed Rules and Monitors for this Object
This task shows you all failed workflows targeted to the selected object. It will tell you which workflows currently failed for this objects (e.g. Logical Disk) on this agents.

There are two other tasks available that shows you all failed and running workflows on the selected Healthservice.
Show Failed Rules and Monitors for this Health Service / Show Running Rules and Monitors for this Health Service
Those tasks are targeted to the Health Service class and you can find them on the view Operations Manager / Agent / Agent Health State / Agent State.
They will show you all failed or running workflows of all instances hosted on the selected Health Service.


 

When discussing advantages and disadvantages of self-tuning-threshold monitors in OpsMgr with customers I often be asked how we can really SEE a calculated baseline.

According to this technet page we can switch on the baseline on performance views by right mouse click and select "Show Baseline"

In most cases you can't see anything that's looking like a "baseline".

To really see the calculated baseline you need to ensure a few things:

1. You need to switch on "Show Baseline" option on the performance view.
2. You need to have selected a counter that really has got a calculated baseline (check column "Baseline") . This flag will switch to "YES" once the baseline calculation has finished (depends on the configured business cycle).
3. Important: You need to show a time range beginning at least one complete business cycles backwards. (Attention: Weekly business cycle starts on Saturday 10PM (UTC). To be sure to see the baseline better take 2 weeks backwards)
   I know that sounds silly because typically you store only 1 week performance data in your operational DB, but remember the baseline calculation started already one week before.

 (Today: 4/17/2011)

..... to see the actual running baseline calculation for the next week you can extend the time range to one business cycle (1 week) into the future.

 I hope that helps understanding some strange alerts fired from baseline monitors. ;-)