OpsMgr++ : Command Shell

Automating port monitoring using PowerShell

Boris Yanushpolsky — Sat, 21 Jun 2008 01:27:00 GMT

A while I wrote a blog entry about how you can automate the creation of URL monitoring logic in OpsMgr using PowerShell. One of the questions I have received is "how do you do the same thing for port monitoring ?". Attached is a script that demonstrates how this can be done.

In order to run the script, you need to open the OpsMgr Command Shell and run the following:

CreatePortMonitoring.ps1 -serverName:'TargetServerName.contoso.com' -portNumber:'80' -pollIntervalSeconds:'120' -watcherNodes:"watcher1.contoso.com", "watcher2.contoso.com" -displayName:'Test URL monitoring' -targetMP:'Port Monitoring MP'

Note: If you specify the interval less than 1 minute, the monitoring should still work but you will not be able to load the configuration page and will see a UI error.....

In one of my future posts I will try to explain how this scripts works for those of you who want to automate execution of MP templates.

One more maintenance mode script

Boris Yanushpolsky — Tue, 04 Mar 2008 23:46:00 GMT

Attached is a script that takes a group and puts all the computers in the group (as well as the health service and the healthservice watcher) into maintenance mode.

Here is how you can run the script from the command line to start or stop maintenance mode (without launching powershell.exe)

One of the uses of this script is when you deploy hotfixes to a large number of servers. You can also very easily use Task Scheduler to run this script on a regular basis for your maintenance windows.

Starting MM - powershell "c:\GroupMM.ps1" -groupName:'All Computers' -hours:10 -rmsServerName:'localhost' -startMM:$true

Ending MM - powershell "c:\GroupMM.ps1" -groupName:'All Computers' -hours:10 -rmsServerName:'localhost' -startMM:$false

Troubleshooting event id 33333 logged by the DataAccessLayer

Boris Yanushpolsky — Thu, 24 Jan 2008 05:26:00 GMT

Sometimes after installing an agent or importing a management pack you may see event number 33333 logged by the Data Access layer. In many situations this error is caused by the fact that proxying is not enabled for a particular agent. In OpsMgr SP1, we have added a new rule to pickup this event and generate an alert. The alert looks like the following:

You can figure out using powershell the name of the agent that requires proxying to be enabled using the following command:

Get-MonitoringObject -id:'2090A6E7-27D2-425F-5617-6EE7B2291970' | ft DisplayName

This will provide the name of the agent that needs to have proxying enabled.

Note: You will need to replace the GUID that you use as the parameter to the cmdlet with the first GUID that you see in the alert.

Enumerating Windows Event log manual reset monitors

Boris Yanushpolsky — Sun, 09 Dec 2007 07:51:00 GMT

Couple of days ago I saw a question about how can one find out the list of manual reset event log monitors in a management group. Given that this is a little bit tricky I decided to post a sample so that others could see how to do it as well. Attached is a powershell script that will dump a list of Windows Event log manual reset monitors. All you need to do in order to execute the script is just open up the OpsMgr command shell and type the path of the script (C:\GetManualResetEventLogMonitors.ps1).

Retrieving rules and monitors targeted to a particular class (target)

Boris Yanushpolsky — Wed, 21 Nov 2007 19:28:00 GMT

This question came up several times in various forums so I wanted to post a sample script that shows how you can retrieve the list of both rules and monitors targeted to a particular class (target):

$mc = get-monitoringclass | where {$_.DisplayName -eq 'Windows Server 2003 Logical Disk'}

$rules = $mc.GetMonitoringRules()

$monitoringCrit = [System.String]::Format("TargetMonitoringClassId='{0}'",$mc.Id)

$monitors = Get-Monitor -Criteria:$monitoringCrit

Write-Host "Rules"

Write-Host ""

$rules | Sort-Object DisplayName | ft DisplayName,Name

Write-Host ""

Write-Host "Monitors"

Write-Host ""

$monitors | Sort-Object DisplayName | ft DisplayName,Name

OpsMgr SP1 - Removing instances for which discovery is disabled

Boris Yanushpolsky — Wed, 21 Nov 2007 00:29:00 GMT

One of the issues that we saw in OpsMgr RTM is that if you disabled a discovery using an override let say a particular SQL DB, the instance created by this discovery would not be removed. In SP1 we have added a new cmdlet to force the removal of instances for which discovery is disabled using an override. The cmdlet name is Remove-DisabledMonitoringObject. All you need to do to remove the instances is open up the OpsMgr command shell and run this cmdlet. The cmdlet does not have any parameters. Keep in mind that this cmdlet is only available in SP1 RC.

What's in my groups?

Boris Yanushpolsky — Sat, 27 Oct 2007 04:23:00 GMT

Here is a script I put together that demonstrates how to retrieve all the groups and then retreive the contents of each group as well as the types of objects contained in the group.

In order to run the script you will need to do the following:

1 - Save the script

2 - Open the OpsMgr command shell

3 - Run the following: c:\EnumerateGroupsAndMembers.ps1

Which groups is a particular computer member of?

Boris Yanushpolsky — Fri, 26 Oct 2007 07:17:00 GMT

Given that groups are used for role based security, overrides, reports, and some other features, it might be pretty interesting to know what groups is a particular computer member of. Attached is a sample script that dumps the list of groups that a particular computer is a member of.

Steps to run the script:

1 - Save the script file

2 - Open the OpsMgr command shell

3 - Run the following: C:\GetContainingGroups.ps1 -computerFQDN:'server1.contoso.com'

What if I dont want to put the whole computer into maintenance mode?

Boris Yanushpolsky — Fri, 19 Oct 2007 20:27:00 GMT

Sometimes you may not wish to put the whole computer into maintenance mode. Instead you may wish to put just a number of databases or websites into maintenance mode.

The steps are very simple:

1 - Get the monitoring class that represents the type of monitoring objects that you wish to put into maintenance mode

2 - Get the actual monitoring objects

3 - Iterate through the array of monitoring objects and put them into maintenance mode (dont forget to check whether you got a single monitoring object or an array, this is pretty important)

Here is a sample of how to do this using PowerShell:

$sql2005DBClass = get-monitoringclass | where {$_.DisplayName -eq 'SQL 2005 DB'}

$dbInstances = get-monitoringobject -monitoringclass:$sql2005DBClass | where {$_.Name -match 'TestDB'}

$startTime = [DateTime]::Now

$endTime = $startTime.AddHours(2)

if($dbInstances -is [Array])
{
foreach($dbInstance in $dbInstances)
{
New-MaintenanceWindow -startTime:$startTime -endTime:$endTime -reason:'PlannedHardwareMaintenance' -monitoringobject:$dbInstance -comment:'comment goes here'
}
}
else
{
New-MaintenanceWindow -startTime:$startTime -endTime:$endTime -reason:'PlannedHardwareMaintenance' -monitoringobject:$dbInstances -comment:'comment goes here'
}

This script will find all databases where the DB name is like TestDB and then put then into maintenance mode for two hours.

Specifying a run as account for a run as profile

Boris Yanushpolsky — Tue, 16 Oct 2007 21:04:00 GMT

Here is a sample script that demonstrates how to specify which RunAs account to use for a particular RunAs profile on a particular agent. The main reason I am blogging about this is that the code that needs to be written to do this is not straight forward, and one day you may need to automate this.

The script takes three parameters:

runAsProfileName - This is the name of the RunAs profile as it appears in the OpsMgr console

runAsAccountName - This is the name of the RunAs account as it appears in the OpsMgr Console. This is not the AD account name.

computerFQDN - This is the fully qualified name of the computer on which the RunAs account should be used by any rules/monitors/discoveries/tasks which are using the particular RunAs Profile.

In order to run the script you will need to do the following:

1 - Open the OpsMgr command shell

2 - Run the following: C:\SpecifyRunAsAccountForRunAsProfile.ps1 -runAsProfileName:'SQL Server Monitoring Account' -runAsAccountName:'SQL Monitoring Account' -computerFQDN:'srv1.contoso.com'

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included scripts are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

What's in my management pack?

Boris Yanushpolsky — Wed, 10 Oct 2007 22:17:00 GMT

Here is a simple script that I wrote for someone today to dump the contents of a management pack that include views, rules, monitors, tasks, console tasks. I figured others might find it useful as well.

In order to run the script, open up the OpsMgr command shell and run the following command:

C:\DumpMpContents.ps1 -mpDisplayName:'Windows Server Internet Information Services 2003'

Just replace the MP display name with your management pack name.

Disabled discoveries

Boris Yanushpolsky — Mon, 08 Oct 2007 21:55:00 GMT

Some discoveries in the management packs that ship with OpsMgr are disabled out of the box. One of the reasons is that not everyone might be interested in monitoring certain components. The easiest way to prevent a particular component from being monitored is disable the discovery for it. If OpsMgr cant discover something, it will not execute any rules or monitors which will result in no alerts/performance data/events. If you are interested in seeing what discoveries are disabled by default, here is a simple powershell script that should shed some light on what discoveries are disabled by default:

$mg = (Get-ManagementGroupConnection).ManagementGroup

$discoveries = $mg.GetMonitoringDiscoveries() | where {$_.Enabled -eq 'false'}

$discoveries | select-object DisplayName, @{name="MP";expression={foreach-object {($_.GetManagementPack()).DisplayName}}} | Sort DisplayName | ft

To run the script, open up the OpsMgr command shell and paste in the script. The output will be a table with the names of the discoveries and the management packs in which they are defined.

If you decide to enable some of the disabled discoveries, you will need to create an override since the management packs are sealed and you cannot modify them directly.

Setting specific failover management servers

Boris Yanushpolsky — Tue, 11 Sep 2007 23:40:00 GMT

Unless you are using AD integration, when the agent cannot communicate with its primary management server, it can pick up any management server to failover to. The only way in the console to provide a specific list of failover servers is it use AD integration. If you are not using AD integration but still want to specify particular failover servers for agents, here is a script that can help:

param($agentComputerName,$failoverManagementServerName)

$agent = get-agent | where {$_.PrincipalName -eq $agentComputerName}

$primaryManagementServer = $agent.GetPrimaryManagementServer();

if($primaryManagementServer -eq $null)
{
"Primary management server not found"
return
}

$failoverManagementServer = Get-ManagementServer | where {$_.PrincipalName -eq $failoverManagementServerName}

if($failoverManagementServer -eq $null)
{
"Failover management server not found"
return
}

if($failoverManagementServer.PrincipalName -eq $primaryManagementServer.PrincipalName)
{
"The failover management server cannot be the same as the primary management server"
return
}

$failoverServers = New-Object System.Collections.Generic.List``1"[[Microsoft.EnterpriseManagement.Administration.ManagementServer,Microsoft.EnterpriseManagement.OperationsManager,Version=6.0.4900.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35]]"

$failoverServers.Add($failoverManagementServer)

$agent.SetManagementServers($primaryManagementServer,$failoverServers)

Steps to run the script:

1 - Save the script to a PS1 file.

2 - Open the OpsMgr Command Shell

3 - Run the script and pass the agent fqdn and the failover server fqdn. Here is an example: C:\SpecifyFailoverServer.ps1 -agentComputerName:'agent1.contoso.com' -failoverManagementServerName:'mgmtsrv2.contoso.com'

Stopping maintenance mode

Boris Yanushpolsky — Thu, 30 Aug 2007 21:52:00 GMT

I wrote a blog post several weeks ago about putting a computer into maintenance mode using PowerShell. For some reason after posting the script there was a white space infront of one of the parameters which resulted in the health service watcher object not being put into maintenance mode. I just fixed it and updated the post.

In the last week I got questions from several people on how to stop maintenance mode for a computer using PowerShell. Here is a script that I put together that does the job:

param($computerPrincipalName)

$computerClass = get-monitoringclass -name:Microsoft.Windows.Computer

$healthServiceClass = get-monitoringclass -name:Microsoft.SystemCenter.HealthService
$healthServiceWatcherClass = get-monitoringclass -name:Microsoft.SystemCenter.HealthServiceWatcher

$computerCriteria = "PrincipalName='" + $computerPrincipalName + "'"
$computer = get-monitoringobject -monitoringclass:$computerClass -criteria:$computerCriteria

$healthServices = $computer.GetRelatedMonitoringObjects($healthServiceClass)
$healthService = $healthServices[0]

$healthServiceCriteria = "HealthServiceName='" + $computerPrincipalName + "'"
$healthServiceWatcher = get-monitoringobject -monitoringclass:$healthServiceWatcherClass -criteria:$healthServiceCriteria

"Stopping maintenance mode for " + $computerPrincipalName
$computer.StopMaintenanceMode([System.DateTime]::Now.ToUniversalTime(),[Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive);

"Stopping maintenance mode for the associated health service"
$healthService.StopMaintenanceMode([System.DateTime]::Now.ToUniversalTime(),[Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive);

"Stopping maintenance mode for the associated health service watcher"
$healthServiceWatcher.StopMaintenanceMode([System.DateTime]::Now.ToUniversalTime(),[Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive);

In order to run this script you will need to do the following:

1 - Save to a a file (C:\StopMaintenanceMode.ps1)

2 - Open up the OpsMgr Command Shell

3 - Type the following:

C:\StopMaintenanceMode.ps1 -computerPrincipalName:"dc.contoso.com"

The computerPrincipalName should contain the FQDN of the computer.

Converting a sealed management pack to readable XML

Boris Yanushpolsky — Thu, 16 Aug 2007 02:44:00 GMT

Ever wanted to dig into a management pack but could not because it is sealed? One workaround is to import the management pack into a management group and then export it. There is a much quicker way to do this using PowerShell and the SDK.

Attached is a small script that will do the trick. The prerequisite for this script to work is that you have the OpsMgr console or Management server and PowerShell installed.

The script is attached to this post.

Here is how you can run the script to get the XML representation of a sealed MP:

powershell d:\MpToXml.ps1 -mpFilePath:'d:\Microsoft.Exchange.Server.2003.Monitoring.mp' -outputDirectory:'d:\'

When importing management packs into a management group, you should still use the sealed version as it provides a lot of benefits for upgrades and rolling back changes compared to unsealed management pack which you can easily modify.

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included scripts are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm