Here is a script you can save as a file. I named the script get-rulesforclass.ps1

param ([String] $className)

$class = get-monitoringclass | where {$_.Name -eq $className}

if ($class -eq $null)
{
 throw "Class '$className' not found.";
}

if ($class -is [Array])
{
 throw "More than one class was found with name '$className'.";
}

write-host $class

get-rule | where {$_.Target.Id -eq $class.Id}

Pass the name of the class to the script.

get-rulesforclass.ps1 Microsoft.Windows.Computer

The Target property of the rule is where most people get stuck because it is not clear that you must refer to the Id property off of the target property to perform the comparison against the class's Id.

This is the final blog post to the System Center Operations Manager Command Shell blog. I will be changing my focus and no longer have time to properly contribute to this blog. As this is the last post I will not longer be taking questions or comments. I wish you all the best of luck in your scripting endeavors.

Sayonara! 

Roger Sprague

get-monitoringobject ... | format-list * 

You are probably wondering why you even need to do this.

You are not alone:) 

Each MonitoringObject can be an instance of multiple classes so there is no limit on the number of enumerable properties on each MonitoringObject. To control the formatting experience we only display properties that are essential to identifying the instance you want to manage. To see the remaining properties you must override the default formatter by calling format-list or format-table. When attempting to format an object which has four or more variable length properties I find that format-list works best. Let's take a closer look at displaying all of the properties for each instance of Microsoft.Windows.Computer.

$class = get-monitoringclass | where {$_.Name -eq "Microsoft.Windows.Computer"}

get-monitoringobject -MonitoringClass: $class | format-list *

PS Monitoring:\localhost

>dir | format-list *

And in case you aren't already aware 'fl' is the alias for format-list so the following command will work as well.

dir | fl *

Hope that helps and as always please post your questions and comments and I will make sure they are addressed in future posts.

Roger Sprague

# Summary
#     Delete an agent hosted by a non-existent computer.
# Params
#     AgentNames - An array of strings that contain the FQDN of agents to delete.
# Returns
#     None
function global:Delete-Agent([System.String[]] $agentNames)
{
 $NoAgentsErrorMsg = "`nNo agent names specified. Please specify the FQDN for each agent you want to delete.`n";

 if ($agentNames -eq $null)
 {
  Write-Host $NoAgentsErrorMsg;
  return;
 }

 $administration = (get-item .).ManagementGroup.GetAdministration();

 $agentManagedComputerType = [Microsoft.EnterpriseManagement.Administration.AgentManagedComputer];

 $genericListType = [System.Collections.Generic.List``1]
 $genericList = $genericListType.MakeGenericType($agentManagedComputerType)

 $agentList = new-object $genericList.FullName

 foreach ($agentName in $agentNames)
 {
  $agent = Get-Agent | where {$_.PrincipalName -eq $agentName}
  
  if ($agent -eq $null)
  {
   $msg =  "Agent '{0}' not found." -f $agentName;  
   Write-Host $msg;

  }
  else
  {
   $agentList.Add($agent);
  } 
 }

 if ($agentList.Count -eq 0)
 {
  Write-Host $NoAgentsErrorMsg;
  return;
 }

 $genericReadOnlyCollectionType = [System.Collections.ObjectModel.ReadOnlyCollection``1]
 $genericReadOnlyCollection = $genericReadOnlyCollectionType.MakeGenericType($agentManagedComputerType)

 $agentReadOnlyCollection = new-object $genericReadOnlyCollection.FullName @(,$agentList);

 $msg = "`nDeleting {0} agents:`n" -f $agentReadOnlyCollection.Count;
 Write-Host $msg;
 foreach ($agent in $agentReadOnlyCollection)
 {
  Write-Host $agent.PrincipalName;
 }
 
 $administration.DeleteAgentManagedComputers($agentReadOnlyCollection);
}
 

Hope that helps and as always please post your questions and comments and I will make sure they are addressed in future posts.

Roger Sprague

Here's a link.              

         https://www.microsoft.com/winme/0703/28666/Command_Shell_Intro_Edited.asx

Let me know if you want more videos. 

As always post your questions and comments.

Roger Sprague

Much like the Operations Manager UI Console the Command Shell offers several ways to discover Windows computers. You can either search by computer name or search by LDAP query. Let start by looking at the diferences between each approach.

The following command defines a LDAP query and passes it to the New-WindowsDiscoveryConfiguration Cmdlet thereby creating an LDAP based WindowsDiscoveryConfiguration.

$query = New-LdapQueryDiscoveryCriteria –LdapQuery: “(sAMAccountType=805306369)(name=srv1.contoso.com*)” –Domain:”contoso.com”

$discoConfig = New-WindowsDiscoveryConfiguration –LdapQueryDiscoveryCriteria:$query

In contrast the following command defines a name based WindowsDiscoveryConfiguration that will direct discovery to find both srv1.contoso.com and srv2.contoso.com.

$discoConfig = New-WindowsDiscoveryConfiguration  -ComputerName: "srv1.contoso.com", "srv2.contoso.com"

There is a lot more you can specify when defining a WindowsDiscoveryConfiguration. The following commands will direct the discovery module to use specific credentials, perform verification of each discovered Windows computer and constrain the type of discovered object to a Windows server. The ComputerType parameter is an enum that can be one of Workstation, Server, or Both. The PerformVerification switch is used to direct the discovery module to verify that only available computers should be returned.

# Prompt for credentials used to perform the discovery.

$creds = Get-Credential

# Define a WindowsDiscoveryConfiguration

$discoConfig = New-WindowsDiscoveryConfiguration –ComputerName: "srv3.contoso.com", "srv4.contoso.com" –PerformVerification: $true –ActionAccount:$creds -ComputerType: "Server"

# Select the Management Server used to run the discovery.

$managementServer = Get-ManagementServer –Root: $true

# Start the discovery process.

$discoResult = Start-Discovery –ManagementServer: $managementServer –WindowsDiscoveryConfiguration: $discoConfig

# Check that the discovery process discovered the Windows computers you specified.

$discoResult.CustomMonitoringObjects

# Last but not least install agents on the discovered computers.

Install-Agent –ManagementServer: $managementServer –AgentManagedComputer: $discoResult.CustomMonitoringObjects

Hope that helps and as always please post your questions and comments and I will make sure they are addressed in future posts.

Roger Sprague

Like most blog posts all of the examples are based on working directly from the Root Management Server with a connection defined to localhost. If that is not how you are working simply replace 'localhost' with the name of your connection in the examples.

Monitoring:\localhost

>

Let's start by moving to the location of the Health Service of the computer we want to manage. If you are not sure just list all of the items under Microsoft.SystemCenter.AllComputersGroup by using 'dir' or the 'Get-ChildItem' command

# Move to the AllComputersGroup.

cd Microsoft.SystemCenter.AllComputersGroup

# List all of the member names of the AllComputersGroup

dir | Format-List PathName

# Move to the location of one of the members of the All Computers Group.

cd echo12.contoso.com

# Move to the location of the Health Service running on your agent.

cd Microsoft.SystemCenter.HealthService

Your prompt should look similar to the following. Much like all of the other Monitoring Object centric Cmdlets both Get-Task and Start-Task use the path as a context from which to work.

Monitoring:\localhost\Microsoft.SystemCenter.AllComputersGroup\echo12.contoso.com\Microsoft.SystemCenter.HealthService

>

Now let's get all the tasks for the current Health Service instance.

Get-Task | Format-List Name

We only care about resetting the Health Service store. We need to filter the results so that only the 'ResetHealthServiceStore' task is returned.

Get-Task | where {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"}

Once you have verified that your filter is working you can start the task.

Get-Task | where {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | Start-Task

Optionally you could create a variable to hold the task you want to start.

$task = Get-Task | where {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"}

Start-Task -Task: $task

The Start-Task Cmdlet will block until the task it is complete. If that is not the desired behavior specify the Asynchronous switch.

Start-Task -Task: $task -Asynchronous

If you want to see the status of your task a later time you can store the Task Result and use it to query for status updates.

$taskResult = Start-Task -Task: $task -Asynchronous

Get-TaskResult $taskResult.Id

If the task requires credentials you must first enter your credentials and store them in a variable.

$creds = Get-Credential

Start-Task -Task: $task -Credential: $creds

Last but not least you can specify overrides for existing properties of a task. I recommend specifying overrides by defining a variable so that you can verify your work before submitting the task. The following example is fictitious and is only used to illustrate how you would define overrides for a task.

$overrides = @{SignatureID=10; AnotherID="1092834098123407953912837"}

Start-Task -Task: $task -Override: $overrides

If you are not sure which overrides are available for a given task you can use the Get-Overrides Cmdlet. The following example lists the overrides for the task stored in the $task variable.

$task | Get-Override 

Hope that helps and as always please post your questions and comments and I will make sure they are addressed in future posts.

Roger Sprague

MCF over tiering is a bit different than normal tiering in that you must define a run-as account used  by the Connector to connect to the tiered Management Group. Let's start by creating a run-as account used to connect to the Management Group you would like to tier. There is no Cmdlet for creating a run-as account so we must use PowerShell script to make Operations Manager SDK calls.

 

$runAsAccount = New-Object Microsoft.EnterpriseManagement.Monitoring.Security.MonitoringWindowsCredentialSecureData;

# Use Get-Credential to get a password in the form of a SecureString type.
$tierCreds = Get-Credential;

# Assumes the user name is in format "domain\user".
$domain,$userName, $junk = $tierCreds.UserName.Split("\");
$runAsAccount.Name = "My Tiered MCF Run-As Account"; # The name for this run-as account.
$runAsAccount.UserName = $userName;
$runAsAccount.Domain = $domain;
$runAsAccount.SecureData = $tierCreds.Password;

$mg = (Get-Item .).ManagementGroup; # Get a reference to the SDK Management Group object.
$mg.InsertMonitoringSecureData($runAsAccount); # Insert the run-as account.

That's that was a bit verbose. Just to make sure everything worked as expected run the following command and verify your new run-as account exists.

Get-RunAsAccount | fl Name

Next we need to create a tier.

# Get the credentials required to connect to the tiered Management Group.
$creds = Get-Credential ;

# Create the tier.
$tier = New-Tier -Name: "MyMcfTier" -ManagementServerName: "server2" -Credential: $creds -RunAsAccount: $runAsAccount;

Make sure your tier exists.

Get-Tier | fl Name

Next we need to create the Connector. There is no Cmdlet for creating a Connector so we must use PowerShell script to make Operations Manager SDK calls.

$connectorInfo = New-Object Microsoft.EnterpriseManagement.ConnectorFramework.ConnectorInfo;
$connectorInfo.Name = "McfOverTieringConnector";
$connectorInfo.Description = "McfOverTieringConnector Description"
$connectorInfo.DiscoveryDataIsManaged = $false;
$connector = $mg.GetConnectorFrameworkAdministration().Setup($connectorInfo);

Make sure your connector exists.

Get-Connector | fl Name

Last but not least we need to add the connector to the tier.

Add-ConnectorToTier -Tier: $tier -Connector: $connector;

Clearly the Command Shell could benefit from a New-RunAsAccount Cmdlet and a New-Connector Cmdlet to simplify this process. In the mean time I recommend you create functions that encapsulate any process that can't be completed using Cmdlets if you must complete the process multiple times.

Start by connecting to the Management Group you want to make your top most tier and run the following commands.

$mgName = "The name for the tier you are creating.";

$msName = "The name of your Root Management Server of the Management Group you would like to tier";

$creds = Get-Credential; # The credentials needed to connect to the Management Group you would like to tier.

$tier = New-Tier -Name: $mgName -ManagementServerName: $msName -Credentials: $creds;

That's fairly easy and can be done without using variables. Here is a hypothetical example.

$creds = Get-Credential;

New-Tier -Name: Building10 -ManagementServerName: building10 -Credentials: $creds

Now that you have created the tier you need to verify that it works.

Start by creating a connection to the tier you just created.

$creds = Get-Credential; # The credentials need to connect to the tiered Management Group.

Get-Tier | where {$_.Name -eq "Building10"} | New-ManagementGroupConnection

cd \ # Move to the root of the provider as that is where you will discover all available connections.

dir # List all connections to find the connection you just created.

cd localhost.building10 # Set the location to the connection you just created. 

Notice that the tiered connection contains the host name of the Root Management Server from which the tier was acquired to help disambiguate a tiered connection from a direct connection to the same Management Group.

You can treat a tiered connection just like any other connection to a Management Group. Keep in mind the data is traveling through the Management Group from which the tier was acquired therefore most operations will be significantly slower than working directly with the Management Group. Some operations can be performed across multiple connections. Take a look at One Provider To Rule Them All! for more info on working with multiple connections.

To start, create a connection to each Management Group you want to manage. For example...

# Connect directly to a Management Group

New-ManagementGroupConnection mg1.redmond.corp.microsoft.com

or

# Connect to a Management Group that is a child tier of the current Management Group.

$creds = Get-Credential

Get-Tier | where {...} | New-ManagementGroupConnection -Credential:$creds

Next, move to the root of the Monitoring drive so you can see the connections you have created.

Monitoring:\...\> cd \

Monitoring:\> dir

That's it!

>>All operations from the root of the Monitoring drive will affect all connected Management Groups.<<

In case you are wondering how useful this is here are a few examples.

1. Find a Monitoring Object across all of your Management Groups.

dir -R | where {$_.Name -match "foobar"}

2. Install a management pack across all connected Management Groups.

Install-ManagementPack C:\ManagementPacks\CustomMP.xml

3. Get alerts across all connected Management Groups

Get-Alert ...

4. Get events across all connected Management Groups.

Get-Event ...

and so on...

Most GET Cmdlets work the same way even though they are spanning multiple connections. Cmdlets that affect change may not work as expected and will usually fail because they are passed an object that is unique to one Management Group.

BE CAREFUL!  Objects like ManagementPacks, Classes and Relationship Classes which are unique within one Management Group have the same identifier across all Management Groups and therefore can be inadvertently manipulated across multiple Management Groups when multiple connections exist.

BE VERY CAREFUL! More than one connection to the same Management Group can be created with a different name making it is very easy to inadvertently run the same command against the same Management Group multiple times.

As you may already know, the PowerShell is an extensible environment, as such we have tried to create a useful starting point for you by loading the Operations Manager Cmdlets and functions within a PowerShell environment named “Command Shell”. For those of you who need to customize the PowerShell experience the "Command Shell" may not meet your needs. If you want access to Operations Manager Cmdlets from any PowerShell instance you must first load the Operations Manager snapin. Here is an example.

Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client

Before you can start using the Operations Manager Cmdlets you must set the location to the root of the Operations Manager snapin. There are several ways of working with a provider. I recommend you create a drive so you can easily work with multiple Operations Manager connections.

# Set the location to the root of the provider namespace.

cd OperationsManagerMonitoring::

 

# or

# Create a drive that maps to the root of the provider namespace.

New-PSDrive -Name: Monitoring -PSProvider: OperationsManagerMonitoring -Root: \

cd Monitoring:\

Now that you are working with the correct provider you can create a connection to the Management Group you intend to manage.

# Replace 'localhost' with the name of your server if connecting remotely.

New-ManagementGroupConnection localhost 

cd localhost

Creating A Console File

That was fairly easy but what if you want to automate these commands every time you start the PowerShell. That requires adding a startup script and/or a console file. I suggest creating a console file to begin with to make the management of snapins easier.

Start by creating a copy of the PowerShell shortcut. 

Create a new console file by launching the new shortcut and running the following commands.

Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client

Export-Console $home\myconsole

Close the PowerShell instance and open the properties of the new shortcut. Add the following as a parameter to powershell.exe in the Target field.

-PSConsoleFile myconsole.psc1

Adding A Startup Script

Now launch the new PowerShell shortcut. You may notice that the Operations Manager startup banner is missing as well as the default connection and all of the Operations Manager functions. The startup banner and functions can also be included in the startup of your custom PowerShell instance by creating a startup script.

Start by creating a file called mystartup.ps1 located in $home from within PowerShell. Add the following lines to the startup script to move to the Operations Manager installation directory.

$pf = (gc Env:\ProgramFiles)

cd "$pf\System Center Operations Manager 2007"

To add ONLY the Operations Manager functions add the following line to your script. If you decide to go this route you should also consider adding commands to connect to the Management Group you itend to manage.

.\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Functions.ps1

To add the Operations Manager functions, the default connection and the startup banner add the following line to your startup script. I suggest using this approach until you are familiar with Operations Manager connection Cmdlets.

.\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1

Now you need to call the startup script from your PowerShell shortcut. Open the shortcut properties and add the following arguments at the end of the Target field.

-NoExit .\mystartup.ps1

That’s it! Now you can fully customize your powershell startup experiance while still having immediate access to Operations Manager functionality.