Set SCOM maintenance mode when all servers in a list are down

I had a customer request where they had relatively consistent errors with a give network and they wanted to suppress alerting when they had this issue arise.

I wrote a PowerShell script that would ping the servers in a file and if all failed would set maintenance mode for a SCOM group of servers.

Below is the script contents.

Set-StrictMode -Version 2
#PS Example Script Here
#Example script ping servers on specific network from hardcoded list if all servers down then put servers in maint
# Mode. If servers respond then take group out of maint
 
 
function CreateMyEvent ($iEID, $sourceEvent, $param1,$param2,$param3,$param4,$param5,$param6,$param7)
        {
            #//Create Source with PS first.
 
            $test1 = " "
#            //10 below is event id, 1 is category.
            $info = "Information";
            $ei = New-Object System.Diagnostics.EventInstance($iEID,1);
        $eventLogTest = New-Object System.Diagnostics.EventLog;
    $eventLogTest.Log = "Application";
            $eventLogTest.Source = $sourceEvent;
        "Writing Eid: " + $iEID + " with parameters"
            $eventLogTest.WriteEvent($ei, @($param1,$param2,$param3,$param4,$param5,$param6,$param7,$test1))
        "Wrote to event log"
        }
 
 
Function GroupMaintMode 
#($ScomServer, $GroupDisplayName, $DurationInMin, $Reason, $Comment)
(
[Parameter(Mandatory=$true)][string]$ScomServer,
[Parameter(Mandatory=$true)][string]$GroupDisplayName,
[Parameter(Mandatory=$true)][Int32]$DurationInMin,
[Parameter(Mandatory=$true)][string]$Reason,
[Parameter(Mandatory=$false)][string]$Comment
){
  
Import-Module OperationsManager
New-SCOMManagementGroupConnection -ComputerName $ScomServer
  
ForEach ($group in (Get-ScomGroup -DisplayName  $GroupDisplayName))
    {
   If ($group.InMaintenanceMode -eq $false)
         {
            $group.ScheduleMaintenanceMode([datetime]::Now.touniversaltime(), `
            ([datetime]::Now).addminutes($DurationInMin).touniversaltime(), `
  
             "$Reason", "$Comment" , "Recursive")
         }
    }
  
}
 
Function GroupMaintModeStop
#($ScomServer, $GroupDisplayName, $DurationInMin, $Reason, $Comment)
(
[Parameter(Mandatory=$true)][string]$ScomServer,
[Parameter(Mandatory=$true)][string]$GroupDisplayName,
[Parameter(Mandatory=$true)][Int32]$DurationInMin,
[Parameter(Mandatory=$true)][string]$Reason,
[Parameter(Mandatory=$false)][string]$Comment
){
  
Import-Module OperationsManager
New-SCOMManagementGroupConnection -ComputerName $ScomServer
  
ForEach ($group in (Get-ScomGroup -DisplayName  $GroupDisplayName))
    {
   If ($group.InMaintenanceMode -eq $true)
         {
             "Group is in maint mode, so take it out"
            $group.StopMaintenanceMode([datetime]::Now.touniversaltime(), [Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive)
         }
    }
  
}
  
#Begin of main routine###############################
 
$sourceEvt = "SCOMNetOutage"
if (!(test-path ` HKLM:\SYSTEM\CurrentControlSet\Services\Eventlog\Application\$sourceEvt )) 
{new-eventlog -Logname Application -source $sourceEvt  -ErrorAction SilentlyContinue} 
 
Write-Eventlog -Logname "Application" -EntryType Information -EventID 31 -Source $sourceEvt -Message "Begin Script"
 
$error.clear()
$startD = Get-Date
 
 
#NOTE: your server or list of IP's should be in new line delimited file below, you can change this be editing line below
$info = get-content C:\SCOMNetCheck\ServerList.txt
 
foreach ($serverPing in $info) 
{
 
 
   $serverPing
 
   if ($serverPing -eq "")
   {
      "Skipping blank server in list"
      continue
   }
 
   $pingSuccess = $FALSE
 
   $PingOkMessage = $serverPing + ": Server test-connection succeeded"
#Start all jobs
$scriptblock =  { test-Connection -ComputerName "$args[0]" -Count 1 -Quiet }
#$scriptblock
    Start-Job -ScriptBlock { test-Connection -ComputerName $args[0] -Count 1 -Quiet }  -ArgumentList @($serverPing)
 }
 
#Wait for all jobs that are pinging addresses in file this is threaded to improve speed
Get-Job | Wait-Job
  
#Get all job results
$Output = Get-Job | Receive-Job #| Out-GridView Comand, Name
 
foreach ($res in $Output) {
"res: " + $res
if ($res){
   $pingSuccess = $TRUE
 
}
}
 
 
 
if ($pingSuccess)
{
     write-Host "Found Server that successfully pinged we need to stop maint mode now to Allow for alerting" -ForegroundColor Green
#log event that removing alert suppression
  CreateMyEvent 11 $sourceEvt "Found Server that successfully pinged we need to stop maint mode now to Allow for alerting" "" $serverPing "" "" "" ""
  GroupMaintModeStop -ScomServer "localhost" -GroupDisplayName "Maint Mode Network Group1" -DurationInMin 10  -Reason "ApplicationInstallation" -Comment "Suppress Alerting on network from PowerShell Custom Example script"
 
}
else
{
     write-Host "All Servers failed ping we need to set maint mode now to suppress alerting" -ForegroundColor Red
#log event indicating suppressing alerts. Should probably alert on this condition
  CreateMyEvent 13 $sourceEvt "All Servers failed ping we need to set maint mode now to suppress alerting" "" $serverPing "" "" "" ""
 
#Usage (calling the GroupMaintMode function)
GroupMaintMode -ScomServer "localhost" -GroupDisplayName "Maint Mode Network Group1" -DurationInMin 30  -Reason "ApplicationInstallation" -Comment "Suppress Alerting on network from PowerShell Custom Example script"
 
}
 
"start time:"
$startD
"End time: " 
Get-Date
 
Write-Eventlog -Logname "Application" -EntryType Information -EventID 37 -Source $sourceEvt -Message "End Script"
c:
Return 1

SCOM Maintenance Mode Schedule listing

By default, SCOM schedules are only displayed for the ones that you create as a SCOM operator. SCOM admins will see all SCOM Schedules created by all users.

I thought of options to allow for this and came up with this example management pack that uses a custom report and a web browser widget to provide a direct link to the report contained in this management pack.

Let’s walk through configuring the management pack in your environment.

First, Import this example management pack bundle created with Visual studio authoring extensions and SQL Report builder 2016.

Select Administration – Installed Management packs and right click. Select Import Management packs…

Select Add from disk.

Select No to not search catalog.

Navigate to where you copied the example MP.

Select Open to import.

Select Install to import MP.

Select Close when import completes.

At this point we have the MP imported, however report will fail to run, some additional configuration is required.

Second, Use report viewer 2016 configure dataset.

Download link if you do not currently have it installed. https://www.microsoft.com/en-us/download/details.aspx?id=53613

Logon to your SCOM reporting server where you installed Report Builder and run report builder.

Select Open report and type in http://localhost/reportserver and select open

Navigate to MaintenanceModeScheduleReport folder and select Custom.Report.MaintMode

Select Open to edit the report datasource.

Expand data sources and right click on DataSource1

Select Data Source properties.

Select below options on Credentials tab and enter user name and password of a windows account that has sufficient permissions to run query. In this example I use my SDK account and password.

Select the general tab.

Change Connection string to your SQL dataset server that hosts the Operations Manager Database (not the datawarehouse server) and click test connection to verify credentials work.

Click Save disk icon at top left corner of report builder to save changes. Note my screen capture tools changed the icon. It will appear differently.

At this point the report should run and populate with any Maintenance mode schedules that you have created.

Lastly, Edit custom view to specify your report server.

This will allow the Monitoring view to see Maintenance schedules and users that are not SCOM Admins to see Maintenance schedules that were not created by them and allow for viewing data within the SCOM Web console.

Select Monitoring and expand folder All Scheduled Maint mode.

Click lower wrench and then clear contents.

Select Ok to remove widget.

Delete below

Wait for a minute or two and when you see click to add widget, select it.

Select Web Browser widget and select Next.

Enter a name and select next.

Enter below link in the Web Page URL changing scom19db2 string below with your reporting server name.

“http://scom19db2/ReportServer/Pages/ReportViewer.aspx?%2fMaintenanceModeScheduleReport%2fCustom.Report.MaintMode&rs:Command=Render”

Select Next.

Select Create to add the widget to the dashboard.

Select Close once it is successfully created.

Select the view again and when prompted for your credentials for reporting server type them in and select OK.

Select Close to continue.

If your browser security settings require, select click here to run scripts.

Click ok if any additional internet warning appear.

Note you can scroll to see additional fields if needed.

I added a testuser account with SCOM operator and SCOM report Operator roles.

Now, when I run SCOM console as test user they can now view SCOM Maintenance Schedules.

Hope you find this useful in the event you need anyone other than SCOM administrators to view all SCOM maintenance schedules.

SCOM scheduling maintenance mode tool

Hi,

Mark Manty Premier Field Engineer with Microsoft here with another example for System Center Operations Manager.

You might recall the previous example command line tool that would set maintenance mode for a list of servers in a text file. Today I have an updated example that built upon the existing tool.

You may find that you have many requests for scheduling down time for servers and would rather enable your customers to set their own maintenance mode times without logging into SCOM servers. With this new example you can provide customers with access to copy text file to a share with their list of servers and maintenance mode configuration to allow them to perform this on their own.

I ran this in a test environment and it does not have to run on a RMS or MS to work. It must meet the below requirements in order to run successfully:

  • .NET 3.5 Framework
  • SCOM R2 Console (User Interface installed) or SCOM 2012 Console (tested with SCOM 2012 SP1)
  • Run under an account that has administrative rights to the SCOM Management Group

Extract the file MaintenanceModeListSched.exe from MaintenanceModeListSchedExample_V1.zip to a directory of your choice.

Open Administrative command prompt and edit a text file with the systems you want to put in maintenance mode.

Here I am typing out the text of three example files used to set maintenance mode for. Note the first line is date time in military time. 2nd line is ON or OFF indicating to turn on or off maintenance mode. 3rd line is number of minutes. 4th line is the maintenance mode reason. 5th through last line is the list of servers you want to set maintenance mode on.

Example1.mm is set to run at 4:00 pm or later. Example2.mm is set to run at

6:23 pm. And ExampleFail.mm has a miss-formatted date time field.

Run the maintenancemodelistsched.exe with no parameters to see what the command line tool expects for parameters.

Now run command passing in your RMS name, directory where maintenance mode text files will reside, and wildcard to the file names to process.

Example:

MaintenanceModeList.exe

SCOMRMS c:\Maintmodelistschedule *.txt

Note only the servers in example1 file were set, however the Management servers were not placed in maintenance mode by design. 

See folders and results.txt file contents. Results are appended to this file every time it sets maintenance mode on servers specified in the files.

Screen shot below:

If a file is miss formatted it is moved to the Failed folder for your review.

Note that the file that was processed is moved to the Completed folder and renamed to add date time to ensure unique and allow you to know when this file was processed.

 Event log error is created in the event of a date time parsing error. See event below:

Event log success informational event is raised for every file it processes successfully.

Event 100 is logged every time the tool is run. This could be used to monitor for missed event and alert to notify you when the scheduled task may be failing to execute the tool.

You can create scheduled tasks to run every 5, 10, or 15 minutes to set maintenance mode on the files in a folder of your choice. Then ensure you share out that folder to customers that will be using this process to schedule maintenance mode for their servers. As mentioned earlier you can monitor for events in the event log to alert you when issues occur.

This is an example tool that will enable your customers to schedule maintenance mode on servers without having to understand how to navigate SCOM and also without having to provide access to the SCOM console.

Disclaimer:

This example is provided “AS IS” with no warranty expressed or implied. Run

at your own risk. The opinions and views expressed in this blog are those of

the author and do not necessarily state or reflect those of Microsoft.

Automate closing old SCOM alerts tool

Hi,

Mark Manty Premier Field Engineer with Microsoft here with another example tool for System Center Operations Manager.

Today I have an example tool that can be used to close old SCOM alerts. For those that do not want to use command line PowerShell commands to perform these actions they can use this command line tool to save time closing alerts.

I ran this in a test environment and it does not have to run on a RMS or MS to work. It must meet the below requirements in order to run successfully:

  • .NET 3.5 Framework
  • SCOM R2 Console (User Interface installed)
  • Run as account that has administrative rights to the SCOM Management Group

Extract the files to some directory of your choice.

Open Administrative command prompt and run the CloseOldSCOMAlerts.exe scomrms 48 * Rules

Where scomrms is your root management server name. 48 is the number of hours old alerts to close. * is all alerts (can specify “Health Service” to only close alerts that have “Health Service string in the alert name). Rules specifies only to close alerts that are generated from Rules.

The first two parameters are required. If you do not specify third and fourth parameter it defaults to close all alerts (monitors and rules).

The third parameter can be used to specify a string to match on alert name to close only those that contain that string or you can specify * to close any alert.

The fourth parameter can specify “Rules”, “Monitors”, or ALL. Rules will only close alerts from rules and Monitors will close alerts only from Monitors.

Note that closing alerts that are generated from Monitors Will NOT reset the health of the monitor. It only closes the alert.

If you have an alerting rule that is used to validate alerting is working, this would be an option you could use to schedule closing of old alerts to help ensure these old alerts do not fill up your operations manager database that will impact your performance.

I hope you find this tool useful and enjoy this example tool.

Disclaimer:

This example is provided “AS IS” with no warranty expressed or implied. Run at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.

Get Connected Consoles command line tool for SCOM

Hi,

Mark Manty Premier Field Engineer with Microsoft here with another example for System Center Operations Manager.

Today we are going to walk through an example command line tool that will display the current number of connections to the SCOM SDK service.

In most cases the recommended limit to the number of console connections you should have are 50 simultaneous connections. If you have a large number of agents reporting into one management group the recommended limit declines to 25 simultaneous connections. Discovering whom is connected is the problem we are addressing with this tool today.

I ran this in a test environment and it does not have to run on a RMS or MS to work. It must meet the below requirements in order to run successfully:

  • .NET 3.5 Framework
  • SCOM R2 Console (User Interface installed)
  • Run as account that has administrative rights to the SCOM Management Group

Extract the files to some directory of your choice.

Open Administrative command prompt.

Run the GetConnectedConsoles.exe with no parameters to see what the command line tool expects for parameters.

As you can see, it is only looking for one parameter that is your RMS server name.

The program lists out all the users that currently have a SCOM console connection. Users will be displayed once for every connection they have open.

This is an example tool that will assist in finding who has how many SCOM consoles open.

Disclaimer:

This example is provided “AS IS” with no warranty expressed or implied. Run at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.

SCOM Agent Primary/Failover Management Server configuration tool

Hi,

Mark Manty Premier Field Engineer with Microsoft here with another example tool for System Center Operations Manager.

Today I have an example tool that can be used to view and change SCOM agent’s Primary and Failover management servers. For those that do not want to use command line PowerShell commands to perform these actions they can use this visual tool to configure for agent failover.

I ran this in a test environment and it does not have to run on a RMS or MS to work. It must meet the below requirements in order to run successfully:

  • .NET 3.5 Framework
  • SCOM R2 Console (User Interface installed)
  • Run as account that has administrative rights to the SCOM Management Group

Extract the files to some directory of your choice.

Open Administrative command prompt and run the AgentFailover.exe. Type in your Root Management server name and select Connect to load all agent information.

Select an agent to view it’s current configuration. Use add and remove to change failover agents and/or change the primary Management server using drop down list. Select Apply Changes button to set the new changes.

If you want an updated list of all agents configuration information select Refresh All Information button to do so.

Hope you find this tool useful and enjoy this example tool.

Disclaimer:

This example is provided “AS IS” with no warranty expressed or implied. Run at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.

SCOM maintenance mode setting for list of servers

Hi,

Mark Manty Premier Field Engineer with Microsoft here with another example for System Center Operations Manager.

Today we are going to walk through an example command line tool that will set maintenance mode for a list of servers in a text file.

Customers who have large environments with SCOM agents will at some point in time need to set maintenance mode for a large number of servers. This example tool will read a list of servers and set maintenance mode on them for the number of minutes specified. It can also stop maintenance mode for a list of servers. It validates that the servers in the tex file are not management servers to prevent setting maintenance mode on your SCOM infrastructure.

I ran this in a test environment and it does not have to run on a RMS or MS to work. It must meet the below requirements in order to run successfully:

  • .NET 3.5 Framework
  • SCOM R2 Console (User Interface installed)
  • Run as account that has administrative rights to the SCOM Management Group

Extract the files to some directory of your choice. Tool download here.

Open Administrative command prompt and edit a text file with the systems you want to put in maintenance mode.

Run the maintenancemodelist.exe with no parameters to see what the command line tool expects for parameters.

NOTE: I added an additional parameter that you can use to add your specific comments for the reason you are setting maintenance mode.

Now run command passing in your RMS name, path to server list, ON, number minutes for maintenance mode, and optionally the name of the results file to save results to.

Example:

MaintenanceModeList.exe SCOMRMS c:\Maintmode\serverlist.txt ON 120

Results are saved to results.txt file as a default if you do not provide the output file.

See that the servers I listed in my input file are now in maintenance mode and that they were set to 120 minutes.

Note that the tool will not set maintenance mode on SCOM Management servers. This can be useful to use and prevent users from setting maintenance mode on your SCOM servers causing you headaches to recover from.

Now we can run the tool with below command line to stop maintenance mode on the list of servers we previously set.

MaintenanceModeList.exe scomrms c:\maintmode\serverlist.txt Off

Notice that maintenance mode was turned off for all servers in your input file.

This is an example tool that will speed up the process of setting maintenance mode for a list of servers.

Disclaimer:

This example is provided “AS IS” with no warranty expressed or implied. Run at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.

SCOM Alert Updater Service – connector example updating SCOM alerts

Hi, Mark Manty Premier Field Engineer with Microsoft here with another example for System Center Operations Manager.

Today we are going to walk through an example Windows service that is a SCOM connector.

SCOM download for 2012 and 2016. And now SCOM 2019 files.

Customers who use product connectors often find they need to modify custom fields and place important data there for their incident management systems to leverage. Additionally connector subscriptions criteria is limited, we often will need more granular control of which alerts we want to send across a connector to create incidents. Reducing floods of incidents created from SCOM alerts is a priority with most organizations.

My example connector service provides this capability and is simple to maintain and install, plus I have provided the source code for this example allowing anyone interested the ability to add features and/or functionality.

PFE customers may already be familiar with Boris Yanushpolsky’s Alert Update Connector. This is an example that I developed that simulates similar functionality. Building the service requires Visual Studio 2010 and for the SCOM R2 agent to be installed on the system you are building service. SCOM agent does not have to report to a management group.

I ran this in a test environment and it does not have to run on a RMS or MS to work. It must meet the below requirements in order to run successfully:

• .NET 4.0 Framework

• SCOM R2 Console (User Interface installed) or SCOM 2012 Console installed

• Run as account that has administrative rights to the SCOM Management Group

Let’s dive in.

Select Administration – Settings in SCOM Console and use New… button to create new resolution states for Processed and SendAlert. Processed should be set to 251 and SendAlert can be 252 for example.

Note that the Processed 251 resolution state is hard coded in the service. This is the resolution state that the connector service updates alerts that have been processed. You should use the connector configuration file (more on this file later) to change resolution state to SendAlert 252 value should you want to pass this on to another connector that will then forward these events to your ticketing system.

Create Connector Configuration file One of the items in alertupdaterservice.exe.config file is ConfigurationFilePath. This contains the path and file name that stores your alerts to modify. Below is the text to copy and paste into your Connector.xml file. The first alert source is an example with all possible Property Names you can modify. ResolutionState, CustomField1 – 10.                                                                                                                                                       The two AlertSource configuration items above are examples of how to configure a given rule/monitor to update custom fields and change your resolution state of these alerts to SendAlert. GroupIdFilter can be used to specify only to update the NewValue If it belongs to the specified group. Here are the properties on the alerts that were modified using the service with the connector configuration file above.

Question: How do I find the Id for the alerting monitors and rules that I want to modify?

You can use PowerShell or read MP files xml and dig through the file to find the monitor or alert’s ID. If you are a Premier customer you could use Boris’s ConnectoryConfiguration tool to create your configuration file.

Open Operations Manager Shell and run this command.

get-alert -criteria ‘Name = ”Health Service Heartbeat Failure”’

This will work if you have alerts that are available in the management group. The data returned will have a line for MonitoringRuleId.  This is the value you can specify in the AlertSource section for Id.

MonitoringRuleId : b59f78ce-c42a-8995-f099-e705dbb34fd4

What if you do not have any recent alerts that you can query with PowerShell to find the Id?

get-monitor -criteria ‘DisplayName = ”Health Service Heartbeat Failure”’

Id                     : b59f78ce-c42a-8995-f099-e705dbb34fd4

You can use similar command line for rules by using get-rule command. To get the GroupIdFilter you can use PowerShell to get the Group ID similarly.

get-monitoringobjectgroup Find the group you want and find the associated Id. Id               : 9e249559-e166-0e92-1bfc-fea90a63f843

I started working on a user interface tool to select monitors and rules that would allow you to configure the connector configuration file, however I have not completed this yet.

I may blog about this in future when completed, if I hear back that this is useful and would be a good use of my time. Editing alertupdaterservice.exe.config file.

RootManagementServerName should replace localhost with RMS Server name or one of your 2012 SCOM management servers. If this service is running on one of your management servers or RMS you can specify localhost. PollingIntervalInSeconds number of seconds before it polls and processes new alerts, default is every 10 seconds. ConfigurationFilePath this is the path to your configuration file that has alert id’s along with fields to update. ExcludedResolutionStates value should be 255 which is Closed resolution state. FailoverMS is a semicolon delimited list of management servers should you be using SCOM 2012 that the service will attempt to connect to should the RootManagementServerName connection fail.

Installing Alert Updater Service Run command prompt as administrator.

Change to the directory where you have your files copied, in this case c:\aucs Run below command to install the service.

C:\AUCS>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe c:\aucs\AlertUpdaterService.exe

Note: if you get an error indicating System.BadImageFormatException you are trying to install the 32 bit version of the service using the 64 bit framework or you are trying to install the 64 bit version of the service with the 32 bit .NET framework.

Change “AlertUpdaterService” to automatic start and enter credentials of an account that is in SCOM administrators group.

Change logon credentials and save.

Start the Alert Updater Service.

Open SCOM Console and select Administration – Product connectors – internal connectors. Bring properties up on Alert Updater Connector and select Add… button to create the new subscription for alerts you want this connector to subscribe to.

Enter a subscription name such as “All Alerts alert updater” and select Next.

Select all the groups you want to subscribe to and select next.

Select Next to allow new targets to automatically be added when new ones are created.

Select the criteria you want and select create. In this case I am selecting all severity and all priority alerts from all categories. I am only selecting alerts with a resolution state of New.

Select Apply and OK to save your changes.

Now in your active alerts view you should see most of your active alerts are either in a Processed or SendAlert state.

As alerts are created they are set to New resolution state.

As the connector service processes alerts it will change the resolution state to processed or to the custom resolution state that you specify in your connector configuration file.

Service failover What if you are running this with SCOM 2012 and the management server you are connected to fails?

Here is the is what happens if you have FailoverMS servers listed in your configuration file.

First you get a error event (could be different based on when the failure occurs). In this case we get a 7010 error event. Service failed. Please restart service: The client has been disconnected from the server. Please call ManagementGroup.Reconnect() to reestablish the connection. Then we see a 5002 information event indicating using failover MS. Changing connection to failover MS: SCOM2012MS1. Will attempt to connect to new MS. Then we see a 50 and 55 event indicating connections established. (50) Successfully connected to SDK service on: SCOM2012MS1 (55) Successfully established connector connection

And within a few minutes you should see 700 informational event indicating processing alerts. This event is a heartbeat event indicating we are processing events and working. You could monitor for missed event 700 within 10 minutes and alert if not found. Could indicate service is not working.

Service EventCodes list All events are logged to Application event log with event source of “AlertUpdaterService”.

Below is a list of possible event codes that may be logged by the service. You could add or remove from the source to suit your needs. You can also create a custom management pack to monitor the service for running state and other errors that may occur.

10 = Successfully stopped service.

13 = Service failed to stop within timeout period

20 = Successfully Loaded Service Configuration

21 = RootManagementServer Configuration invalid – Check service configuration file for errors

22 = PollingIntervalInSeconds Configuration invalid – Check service configuration file for errors 23 = PollingIntervalInSeconds Configuration not numeric – Check service configuration file for errors

24 = ConfigurationFilePath Configuration invalid – Check service configuration file for errors

25 = ExcludedResolutionStates Configuration invalid – Check service configuration file for errors

26 = ExcludedResolutionStates Configuration not numeric – Check service configuration file for errors

29 = LoadServiceConfiguration() Catch All Failure: (+ error message) Properties to modify configuration entries:

30 = Successfully Loaded Properties to Modify Configuration

31 = Detected Change in configuration file reloading.

32 = Problem Reloading configuration file Please restart service: (+ message)

33 = Could not configure File Watcher, so will have to restart service if you change configuration file: (+ message)

35 = LoadAlertPropertiesToModify() Configuration File NOT found: (filename)

38 = Failed to write log file for Properties to Modify Configuration: (+ error messsage) warning

39 = LoadAlertPropertiesToModify() Catch all failure: (+ error message) Critical

50 = Successfully connected to SDK service on: (RMS Server Name)

51 = Failed in LoadServiceConfiguration(). Check event log for additional details. Exiting service

52 = Failed in LoadAlertPropertiesToModify(). Check event log for additional details. Exiting service

53 = Failed Loading configuration files. Check event log for additional details. Exiting service: (+ message)

55 = Successfully established connector connection

100 = Could not locate Monitoring Connector. Will attempt to create connector. (Informational)

101 = Failed to create connector Exiting: (+ Message)

102 = Failed to get monitoring connector Exiting: (+ message)

119 = Successfully created Alert Updater Connector (only occurs first time run service if has never been run (55 event otherwise). Creates Connector in SCOM.

700 = Processing Alerts Now. (Can use this with missed event notification to monitor if service is healthy when running.)

710 = Failed parsing Properties:(string parsing)

711 = Failed replacing Properties updating alert(ignore most cases): (string parsing) : (error information)

5000 = There are No backup Management Servers to retry connection.

5001 = Successfully loaded list of failover Management servers:  + (Management server list read from registry HKLM\Software\AUCS\FailoverMS MSList String value)

5002 = Changing connection to failover MS:  + new ManagementServer + Will attempt to connect to new MS.

5010 = Failed last attempt to reconnect to Management Group. Fatal error check health of RMS/MS and restart service.

5011 = Failed last attempt to reconnect MS list to Management Group. Fatal error check health of RMS/MS and restart service.

7010 = Service failed. Please restart service: + (error message)

7012 = Service failed. Please restart service: + (error message)

Alert Parameter Replacement Below is a list of the parameters you can populate custom fields with using the service. Replacement paramters begin and end with ‘$’. Some of these may return null values, so you may find that you do not use them or you may want to tweak the code to return additional or different values.

Replacement Name Description Parameter

$ServerName$ ServerName Computer name that the alert was generated for

$WebConsoleURL$ Link to the alert if you have SCOM Web Console

$Category$ Category Gets the category of the alert.

$ConnectorId$ ConnectorId Gets or sets the globally unique identifier (GUID) for the connector corresponding to the monitoring alert.

$ConnectorStatus$ ConnectorStatus Gets the status of this alert relative to the connector.

$Context$ Context Gets the context of the alert.

$CustomField1$ CustomField1 Gets or sets the value of the custom field 1 for the alert.

$CustomField10$ CustomField10 Gets or sets the value of the custom field 10 for the alert.

$CustomField2$ CustomField2 Gets or sets the value of the custom field 2 for the alert.

$CustomField3$ CustomField3 Gets or sets the value of the custom field 3 for the alert.

$CustomField4$ CustomField4 Gets or sets the value of the custom field 4 for the alert.

$CustomField5$ CustomField5 Gets or sets the value of the custom field 5 for the alert.

$CustomField6$ CustomField6 Gets or sets the value of the custom field 6 for the alert.

$CustomField7$ CustomField7 Gets or sets the value of the custom field 7 for the alert.

$CustomField8$ CustomField8 Gets or sets the value of the custom field 8 for the alert.

$CustomField9$ CustomField9 Gets or sets the value of the custom field 9 for the alert.

$Description$ Description Gets the description of the alert.

$Id$ Id Overridden. Gets the globally unique identifier (GUID) for the alert.

$IsMonitorAlert$ IsMonitorAlert Gets a Boolean value that determines whether the alert was generated by a monitor.

$LastModified$ LastModified Gets the last time, in DateTime format, that the alert was modified.

$LastModifiedBy$ LastModifiedBy Gets the name of the user that last modified the alert.

$LastModifiedByNonConnector$ LastModifiedByNonConnector Gets the last time, in DateTime format, the alert was modified by something other than a connector.

$MaintenanceModeLastModified$ MaintenanceModeLastModified Gets the time, in DateTime format, that the maintenance mode of this alert was last modified.

$ManagementGroup$ ManagementGroup Gets the Management Group that the object is in. (inherited from MonitoringBase)

$ManagementGroupId$ ManagementGroupId Gets the globally unique identifier (GUID) for the Management Group that the object is in. (inherited from MonitoringBase)

$ManagementGroupName$ Management Group name from the alert

$MonitoringClassId$ MonitoringClassId Gets the globally unique identifier (GUID) of the non-abstract monitoring class of the associated monitoring object.

$MonitoringObjectDisplayName$ MonitoringObjectDisplayName Gets the display name of the monitoring object that is associated with the alert.

$MonitoringObjectFullName$ MonitoringObjectFullName Gets the full name of the monitoring object that is associated with the alert.

$MonitoringObjectHealthState$ MonitoringObjectHealthState Gets the health state of the monitoring object associated with this alert.

$MonitoringObjectId$ MonitoringObjectId Overridden. Gets the globally unique identifier (GUID) for the monitoring object that is associated with this alert.

$MonitoringObjectInMaintenanceMode$ MonitoringObjectInMaintenanceMode Gets a value indicating whether the monitoring object associated with the alert is in maintenance mode.

$MonitoringObjectName$ MonitoringObjectName Gets the name of the monitoring object that is associated with this alert.

$MonitoringObjectPath$ MonitoringObjectPath Gets the path to the monitoring object that is associated with this alert.

$MonitoringRuleId$ MonitoringRuleId Overridden. Gets the globally unique identifier (GUID) for the rule associated with the alert.

$Name$ Name Gets the name of the alert.

$NetbiosComputerName$ NetbiosComputerName Gets the name of the computer that raised this alert.

$NetbiosDomainName$ NetbiosDomainName Gets the domain of the computer that raised this alert.

$Owner$ Owner Gets or sets the owner of the alert.

$Parameters$ Parameters Gets a collection of parameters for the alert.

$PrincipalName$ PrincipalName Gets the principal name of the computer that this alert was created for.

$Priority$ Priority Gets the priority of the alert.

$ProblemId$ ProblemId Gets the globally unique identifier (GUID) of the associated monitor if the IsMonitorAlert property is true, otherwise, gets or sets the GUID for the problem.

$RepeatCount$ RepeatCount Gets the repeat count of this alert.

$ResolutionState$ ResolutionState Gets the resolution state of the alert.

$ResolvedBy$ ResolvedBy Gets the user who resolved this alert.

$Severity$ Severity Gets the severity of the alert.

$SiteName$ SiteName Gets the site name of the alert.

$StateLastModified$ StateLastModified Gets the time, in DateTime format, that the state of this alert was last modified.

$TicketId$ TicketId Gets or sets a string identifier for the ticket of the alert.

$TimeAdded$ TimeAdded Gets the time, in DateTime format, the alert was added to the system.

$TimeRaised$ TimeRaised Gets the time, in DateTime format, the alert was raised.

$TimeResolutionStateLastModified$ TimeResolutionStateLastModified Gets the last time, in DateTime format, the resolution state of the alert was modified.

$TimeResolved$ TimeResolved Gets the time, in DateTime format, the alert was resolved.

Example Source Code I am including the example service along with example source code to allow you to see how a SCOM connector could be developed. I created this project with Visual Studio 2010. Note I built this on a system that had SCOM 2007 R2 CU5 updated Console. This is required to build the service as it utilizes the SCOM SDK binaries located in C:\Program Files\System Center Operations Manager 2007\SDK Binaries directory (or drive you installed console to). While this was built using the SCOM 2007 SDK binaries, I did test successfully on SCOM 2007 R2 and SCOM 2012 RC1. Example Source Code   Extract the files from zip file and run Visual Studio 2010. Locate AlertUpdaterService Solution file and open. When the service is started the OnStart method sets global variable bStopped to false indicating the service is running.

Then it creates a new thread that contains the alert updater logic and exits. The OnStop method set’s bStopped variable to true in order for the ConnectorMain thread to know that it should exit processing in order for the service to stop. Wait for the thread to complete processing and then exit OnStop, so the service can stop running.

The service initializes a file watcher on your configuration file that contains alert information to update. Should the watcher fail to initialize it will log an event indicating that you have to restart the service for any changes to take effect. The service should normally load the new configuration file when you change your configuration file and log events indicating reload occurred.

ConnectorMain method loads the service configuration and alert configuration data to get management server name to connect and other configuration data to run the service. Should it fail to load the data it will not run. You should review your configuration file to fix errors should this fail.

Should the service lose it’s connection to SCOM it will retry connection against the Root Management server if running on SCOM 2007 R2. Should this be SCOM 2012 and you specified failoverMS list in the configuration file it will attempt to connect to the failover list in the order specified.

Should it fail to connect to any failover MS in your list it will attempt to connect to the orginal RMS/MS one more time before failing out. It also resets the connection retry count if the last time it retried is greater than 30 minutes ago.

You can change this value by modifying AddMinutes(30) below to the value you desire and rebuild project. Should you be running SCOM 2007 R2 you could populate FailoverMS list with your RMS server name delimited with ; for however many time you would like the retry to occur before the service fails.

In CallMain we connect to the management group get the connector or create the connector if not found. Log results to event log should anything fail. After we successfully get the connector we will use that to get any alerts that it subscribes to.

I added a heartbeat that writes to the event log that could be used with a missed event monitor to alert indicating the service is not processing alerts. You can comment this out or add as a monitoring event that would help validate service is still actively processing alerts. This logs an event approximately every two minutes.

Get the web console URL from SCOM and acknowledge alerts so we do not process them again.

Then we loop on all the alerts that the connector received since last iteration.

We skip processing the excluded resolution state. We also populate the server name should server name be a replacement parameter that the connector needs to update.

We populate string values should any replacement parameters be specified.

Here we set custom fields with the replacement parameter specified.

We now log events to event log indicating status and update the alert connector id to null and specify a string value that we updated the alert with or without changes that will show up in properties history of alert.

I hope you enjoy this example SCOM connector service and let me know if anyone is interested in a User interface tool to configure your connector.xml configuration file with alerts and replacement parameters. If I have time I will work on that example next.

Disclaimer: This example is provided “AS IS” with no warranty expressed or implied. Run at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.

Changing SCOM Health Service Action Account tool

Hi, Mark Manty Premier Field Engineer for Microsoft with an example program to change Agents default Health Service Action Account.

The majority of your agents should be set to “Local System Action Account” with the exception of your Management Servers. This example program allows you to change the default action account associated with a given agent in bulk fashion. If you set your default action account incorrectly and already deployed thousands of agents you will greatly appreciate the tool.

Changing this account in the SCOM console is a manual and slow process for large number of agents. I ran this in a test environment and it does not have to run on a RMS or MS to work.

It must meet the below requirements in order to run successfully:

• .NET 3.5 Framework

• SCOM R2 Console (User Interface installed)

• Run as account that has administrative rights to the SCOM Management Group

See example below where my agents are set to my SCOMAction account. I would like to change those to “Local System Action Account” with the exception being my Management servers.

Download the ZIP file ChangeDefaultActionAccount.zip and extract RunasAccountProfile.exe to a folder of your choice.

Open an administrative command prompt running under an account that has SCOM administrative privileges.

Change to the directory where you extracted RunasAccountProfile.exe.

Run program by typing “RunasAccountProfile.exe” and press enter. Change SCOMRMS to your RMS server name and press “Connect” button.

Select the servers you want to modify Default Action account for.

Note: you can right click select all or deselect all.

Also, you can use the exclude Management servers to exclude them from selection.

If you manually select them they will update the selected Management servers accounts.

After selecting the new action account and the servers to update, select Update to update accounts.

“Complete” message will display when it is done updating. Note the output window displays results of the update.

This program can save a lot of your time updating agents should a large number of agents require changing.   Disclaimer: This example is provided “AS IS” with no warranty expressed or implied. Run at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.

Backup unsealed Management Pack command line tool

Hi, Mark Manty Premier Field Engineer for Microsoft with another example command line tool. Microsoft recommends that you backup unsealed management packs in the event that you need to restore them in the future. This command line tool can simplify the process for you. This example could be scheduled to run to help ensure you have backed up the unsealed management packs in the environment. It also allows for specifying custom query to change the export criteria.

Let’s go.

This sample program (Download Here) takes one required parameter along with one optional second parameter:

• Required: First parameter is the RMS Server name, example MyRMSServer

• Optional: Second parameter is the custom query you would like to specify the management packs to export, example “Sealed = 1”.

Note: if second parameter is not provided it defaults to criteria of “Sealed = 0”   I ran this in a test environment and it does not have to run on a RMS or MS to work.

It must meet the below requirements in order to run successfully:

• .NET 3.5 Framework

• SCOM R2 Console (User Interface installed)

• Run as account that has administrative rights to the SCOM Management Group

Download the ZIP file BackupUnsealedMPs.zip and extract BackupUnsealedMPs.exe to a folder of your choice.

Open an administrative command prompt running under an account that has SCOM administrative privileges.

Change to the directory where you extracted BackupUnsealedMPs.exe.

Run program “BackupUnsealedMPs.exe MyRMSServer” where MyRMSServer is your RMS server name and press enter to run.

Program will create a folder with the format YYYY-MM-DD-HH-MM-SS example: 2012-2-10-8-52-22 and export all unsealed MP’s to that folder.

Optionally you can specify a second parameter to modify what will be exported.

See this link for available properties to specify in your optional query: http://blogs.msdn.com/b/scplat/

Run program BackupUnsealedMPs.exe MyRMSServer “DisplayName Like ‘%Microsoft%’” where MyRMSServer is your RMS server name and press enter to run.

Disclaimer: This example is provided “AS IS” with no warranty expressed or implied. Run at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.