Getting Started
Starting the System Center Command Shell 2
Connecting To a Management Group. 2
Overview
This document is intended to help users familiar with PowerShell to start using the commands provided by the System Center Operations Manager Command Shell. This document looks at common scenarios and provides examples and tips for each scenario.
??? – Technical detail that is not necessary to continue reading but maybe useful.
!!! – Warning that the information must be read and followed as it pertains to the rest of the guide.
[ ] – A replacement parameter is required that you must specify.
Resources
This document barely scratches the surface of the functionality provided by Operations Manager Command Shell. To learn more use the online help and the Get-Help command. To see all available Operations Manager commands use the Get-OperationsManagerCommand function.
If you need help getting started using the PowerShell read the “
Getting St
arted Guide” included with PowerShell.
You find out more about PowerShell here…
https://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx
You can download PowerShell from here…
https://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx
!!! Please send your questions and comments to the SDK/Operations Manager Command Shell news group microsoft.beta.opsmgr.sdk.powershell available on betanews.microsoft.com.
Starting the System Center Command Shell
The System Center Command Shell is accessible from the System Center UI Console as well as the Start menu. Use the right-click context menu in the UI Console to launch a Operations Manager Command Shell that sets the location to the target object. Use the Start->Programs->System Center
!!! - The remainder of this document assumes that you have an open Operations Manager Command Shell.
??? -The Operations Manager Shell is merely an extension to Monad/PowerShell, called a snapin. The Operations Manager Command Shell snapin can be loaded by any instance of Monad/PowerShell. The Operations Manager snapin is named “Microsoft.EnterpriseManagement.OperationsManager.ClientShell”. Use Get-PSSnapin –Registered to list the registered snapins. Use Add-PSSnapin to add the Microsoft.EnterpriseManagement.Shell snapin to the current PowerShell instance.
Connecting To a Management Group
!!! - The following examples use a fictitious topology containing a Root Management Server with the name ‘computer1’ and computers with names ‘computer2’ and ‘computer3’ in a domain named ‘MyDomain’.
By default a connection to a Management Group is created when starting the Operations Manager Command Shell. Connections are made to the Root Management Server of a Management Group. The startup procedure of the Operations Manager Command Shell sets the current location to the root of the default connection. This is also referred to as the root of the instance space. Here is an example of the Operations Manager Command Shell startup prompt.
PS Monitoring:\localhost>
In the rare case when you need to change the connection or connect to more than one Management Group you can use the New-ManagementGroupConnection Cmdlet. The New-ManagementGroupConnection Cmdlet can create a connection to the Root Management Server in a Management Group. Here is an example of using the New-ManagementGroupConnection Cmdlet.
PS Monitoring:\> New-ManagementGroupConnection
-ConnectionString: [Root Management Server Name]
Once you have created the connection you need to move to the root of the of that connection. Use Get-ChildItem to determine the names of the root items of the instance space.
Use Set-Location to move to the root of the connection. Here is an example…
Get-ChildItem
PathName : localhost
ManagementGroup : computer1
ManagementServerName : localhost
Drives : {}
Set-Location localhost
??? - You can also use the cd alias and tab completion to select the connection. You can then use the dir alias to list items at the current location.
Administration
Agent Management
After installing Operations Manager your first task is to discover and deploy agents on the computers you want to manage. The Operations Manager Command Shell provides you with the ability to perform computer discovery as well as device discovery. Each agent computer must be targeted to at least one Management Server within a Management Group. Depending on your configuration you may have more than one Management Server therefore you must first decide which Management Server to which you would like the new agent computers to report. This can be done by calling Get-ManagementServer. Once you have decided which management server you want to use you must store it in a variable so that it can be passed to the Install-Agent command for deploying the agent to a computer. Let’s take a look at this in more script centric terms.
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true
# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration
-ComputerName: computer2, computer3
# Discover the computers.
$discoResult = Start-Discovery
-ManagementServer: $managementServer
-WindowsDiscoveryConfiguration: $discoConfig
# Install an agent on each computer.
Install-Agent
-ManagementServer: $managementServer
-AgentManagedComputer: $discoResult.CustomMonitoringObjects
The first step is to get the desired management server. In this example the same management server will perform discovery, agent installation and will act as the Root Management Server for both agents. The second step creates the discovery configuration used to define the type of discovery to perform. The third step starts discovery and blocks until it completes. The final step installs an agent on the discovered computers. This process is not for the faint of heart but can be easily automated with a PowerShell function or script.
Once the installation is complete a pending action is created for each agent. The pending action allows for a short period of time before the agent is added to Operations Manager. If you want to complete the process immediately you can approve the pending actions for computer1 and computer2 by using the Approve-AgentPendingAction command. If on the other hand you change you mind and you don’t want the computers to be managed then run the Reject-AgentPendingAction Cmdlet.
Get-AgentPendingAction | where {$_.AgentName –like ‘computer*’} |
Approve-AgentPendingAction
Once the pending actions are approved you can use the Get-Agent command to see that computer2, and computer3 are now managed. Prior to approving the pending action computer2 and computer3 may not be returned from the Get-Agent command.
If for some reason you no longer wish to manage a computer the agent can be uninstalled by running the Uninstall-Agent command.
Get-Agent | where {$_.RootName –like ‘computer*’ } |
Uninstall-Agent
Computer Maintenance
Once a computer is managed by Operations Manager, a maintenance window must be defined before taking the computer offline for maintenance otherwise alerts may be generated when the computer is offline. The Operations Manager Command Shell provides commands for getting and defining a maintenance window. Keep in mind that a maintenance window can be defined for entities hosted by a computer as well as the computer itself. The following example illustrates the use of the New-MaintenanceWindow command.
$computer = Get-Agent | where {$_.Name -like ‘computer*’}
$computer.HostComputer | New-MaintenanceWindow
-StartTime: ‘5/22/2006 00:30’
-EndTime: ‘5/22/2006 12:30’
-Comment: "Install security patch"
If the existing maintenance window needs to be modified use the Set-MaintenanceWindow command. You can not modify the start time for a maintenance window once it has been defined using the Command Shell. Use New-MaintenanceWindow to define an alternate maintenance window if the start time must be changed. Use Get-MaintenanceWindow to see the state of the current maintenance window. Use the InMaintenanceMode property to determine if an object is in maintenance mode.
$computer.HostComputer | Get-MaintenanceWindow
$computer.HostComputer | Set-MaintenanceWindow -EndTime: "5/24/2006 12:30"
Default Settings
All of the configurable default settings used by Operations Manager are configurable using the Command Shell. Use Get-DefaultSetting and Set-DefaultSetting to manage default settings such as the Agent Heartbeat Interval.
Set-DefaultSetting -Name: Agent\Heartbeats\Interval -Value: 50
Get-DefaultSetting | where {$_.Name –eq ‘Agent\Heartbeats\Interval’}
User Roles
User roles are an integral mechanism for managing access to Operations Manager functionality in a role based fashion. To see the available user roles use the Get-UserRole command. Here is an example of adding a user named ‘tomg’ to the Operations Manager Operators user role.
$userRole = Get-UserRole |
where {$_.Name –eq ‘OperationsManagerReadOnlyOperators’}
$userRole.Users.Add(‘tomg’)
$userRole.Update()
The following example searches for all user roles in which ‘tomg’ is a member.
Get-UserRole | where {$_.Users –match ‘tomg’}
Authoring
Management Packs
The monitoring extensibility of Operations Manager is built on Management Packs which can be installed, uninstalled and exported. The following example demonstrates commands for managing Management Packs.
$myMPs = Get-ManagementPack | where {$_.Name –match “MyMP”}
Install-ManagementPack –FilePath: c:\MyMP.xml
Get-ManagementPack | where {$_.Name –match “MyMP”} |
Uninstall-ManagementPack
Management Packs can be exported and then installed on another Management Group. This feature is useful if you use a staging server to test Management Pack changes. Use Export-ManagementPack and specify the directory into which you want to the Management Pack exported.
Get-ManagementPack | where {$_.Name –match “MyMP”} |
Export-ManagementPack –Path: “c:\MyMPs”
Rules
It is sometimes useful to disable a rule when planned changes occur to a topology or application in which Monitoring Objects of the same Monitoring Class are affected. Use Enable-Rule and Disable-Rule for managing rules that are NOT contained in a sealed Management Pack. Use Get-Rule for finding rules in any installed Management Pack.
Get-Rule | where {$_.Name –match “MyRule”} | Disable-Rule
Get-Rule | where {$_.Name –match “MyRule”} | Enable-Rule
Monitoring
Navigation and Scoping
SC Operations Manager uses an abstraction called a MonitoringObject that allows applications and services as well as computers to be similarly modeled for both monitoring and management purposes. The Command Shell heavily utilizes the MonitoringObject abstraction and its type object, MonitoringClass, to allow you to retrieve and filter monitoring and management information.
By default the Operations Manager Command Shell sets the current PowerShell provider to the OperationsManagerMonitoring provider which displays the location of the MonitoringObject membership relationship space starting with a connection to a Root Management Server. Here is an example where ‘computer1’ represents the name of a Root Management Server.
PS Monitoring:\computer1>
In addition to computers, services and applications a MonitoringObject can represent a logical group within Operations Manager. Use the intrinsic Get-ChildItem command to list the root Monitoring Objects within a connection. Much like the PowerShell’s File System provider the OpsMgr provider is hierarchical, therefore most of the read commands used with the File System provider also work with the OpsMgr provider.
PS Monitoring:\computer1>Get-ChildItem
In addition to the intrinsic provider commands of the PowerShell most of the Operations Manager Command Shell commands are aware of the current location of the OpsMgr provider. Moreover all of the Operations Manager Command Shell commands that are aware of the current OpsMgr provider location can work from the root of the provider path thereby allowing you to run commands across multiple connections. The following example gets all of the top level MonitoringObjects across all available connections to a Root Management Server.
PS Monitoring:\>Get-ChildItem
!!! Be careful. There is no ‘undo’ feature in the PowerShell therefore any commands that affect change should be used with extreme caution especially when run from the root of the OpsMgr provider.
Just as moving to the root of the path increases the scope of a command, moving down the path to a specific MonitoringObject decreases the scope of the command. The following command gets the alerts for a specific Monitoring Group.
PS Monitoring:\localhost\Microsoft.SystemCenter.AllComputersGroup>Get-Alert
??? Use the cd alias and tab completion to quickly change the provider location.
In addition to the OpsMgr provider the Operations Manager Command Shell also includes the Get-MonitoringObject command that allows you to find a MonitoringObject by MonitoringClass or by ID. Here we are getting all MonitoringObjects that contain the word ‘computer’ in the class name regardless of the group in which the MonitoringObject is contained.
PS Monitoring:\>Get-MonitoringClass | where {$_.Name –match “computer” } |
Get-MonitoringObject
Operational Data
SC Operations Manager monitoring is primarily driven by operational data for each MonitoringObject such as events, state and performance data. Operational data can be retrieved for each MonitoringObject using the Operations Manager Command Shell. MonitoringObjects that represent a group or containment entity typically aggregate or coalesce the operational data for related MonitoringObjects. Here are a few examples use the operational data commands.
PS Monitoring:\localhost>Get-Alert | where {$_.Severity –eq “Critical”}
PS Monitoring:\localhost>Get-State
PS Monitoring:\localhost> Get-Event | where {$_.Number –gt 30000}
PS Monitoring:\localhost>Get-PerformanceCounter |
where {$_.Name –match “Processor Time”} |
Get-PerformanceCounterValue
–StartTime: “5/23/2006”
–EndTime: “5/24/2006”
PS Monitoring:\localhost>Get-Monitor
Managing Alerts
At some point while using Operations Manager you will see one or more Alerts for a Monitoring Object. In order to reset the state of the MonitoringObject the alert must be resolved. The Operations Manager Command Shell provides the Resolve-Alert command for resolving one or more alerts. Here is an example.
PS Monitoring:\localhost> Get-Alert |
where {$_.ResolutionState –eq “New” –and $_.Owner –eq “me” } | Resolve-Alert “resolving all new alerts”
Comments
Anonymous
November 08, 2006
PingBack from http://www.snowland.se/2006/11/09/powershell-opsmgr/Anonymous
November 13, 2006
Just wondering here... So we have 10 custom fields with alerts. I was wondering if I'm going to have the ability to update any of these alert fields using PowerShell.Anonymous
November 14, 2006
Is it possible to disable a specific monitor using shell command?Anonymous
November 27, 2006
You can update the custom fields of an alert by setting the property and calling the Update method. Here is an example... $alert = Get-Alert | where {...} $alert.CustomField1 = 10 $alert.Update("")Anonymous
March 03, 2007
http://www.microsoft.com/systemcenter/opsmgr/evaluation/default.mspx System Center Operations ManagerAnonymous
June 27, 2007
The comment has been removedAnonymous
February 05, 2009
Le PowerShell c'est bien , l'utiliser c'est mieux. Je vous invite donc si vous ne l'aviez pas deja fait...Anonymous
February 16, 2009
I have written a script TestAlert.ps1 which contains Get-Alert cmdlet. I want to run the script from PS Monitoring:localhost> anybody has got any idea?Anonymous
February 26, 2009
  Voici une liste de liens trés pratique sur tous les sujets SCOM , installation , configuration...