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
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.
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.
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
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.
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.
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.
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.
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
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.
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:
• 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.
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.
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.
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.)
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.
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.
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.
