Mark Manty blog

Registry tweaks for SCOM measure twice cut once

Mark Manty — Fri, 28 Apr 2017 19:49:05 GMT

Hi all, Wanted to call out something that happened recently with a customer. When modifying registry ensure that you double or triple check any changes made: Registry Tweaks (note Kevin's useful and handy reg add commands - that helps prevent below issue from occurring in first place). A customer had inadvertently added the dalinitiateclearpool new qword (instead of dword) and then the sdk service would not stay running. Here are the errors you may see on your management server with incorrect keys created. 26399 and 29380 Scroll down and note in the 29380 event log description we see "DataAccessRegistry.ReadInitiateClearPool" tipping us off on the issue. Simply delete the qword value and create new dword value and then the sdk service runs as designed. Log Name: Operations Manager Source: OpsMgr SDK Service Date: 2/5/2013 1:06:23 PM Event ID: 26339 Task Category: None Level: Error Keywords: Classic User: N/A Description: An exception was thrown while initializing the service container. Exception message: Initialize Full exception: Feature of type From Log Name: Operations Manager Source: OpsMgr SDK Service Date: 2/13/2017 14:25:27 Event ID: 26380 Task Category: None Level: Error Keywords: Classic User: N/A Description: The System Center Data Access service failed due to an unhandled exception. The service will attempt to restart. Exception: Microsoft.EnterpriseManagement.ConfigurationReaderException: The feature named 'OperationsManager' and of type 'Microsoft.EnterpriseManagement.ServiceDataLayer.IDataAccessFeature, Microsoft.EnterpriseManagement.DataAccessService.Core, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' cannot be added to the container. ---> Microsoft.EnterpriseManagement.ComponentActivationException: The constructor for the component threw an exception. Please see the inner exception for more details. ---> System.TypeInitializationException: The type initializer for 'Microsoft.EnterpriseManagement.DataAccessLayer.DataAccessRegistry' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.EnterpriseManagement.DataAccessLayer.GlobalDefaults' threw an exception. ---> System.InvalidCastException: Specified cast is not valid. at Microsoft.EnterpriseManagement.DataAccessLayer.DataAccessRegistry.ReadInitiateClearPool(String product) at Microsoft.EnterpriseManagement.DataAccessLayer.GlobalDefaults.Initialize(String product) at Microsoft.EnterpriseManagement.DataAccessLayer.GlobalDefaults..cctor() --- End of inner exception stack trace --- at Microsoft.EnterpriseManagement.DataAccessLayer.DataAccessRegistry.InitializeStateMap() at Microsoft.EnterpriseManagement.DataAccessLayer.DataAccessRegistry..cctor() --- End of inner exception stack trace --- at Microsoft.EnterpriseManagement.DataAccessLayer.DataAccessRegistry.StateMap(String product) at Microsoft.EnterpriseManagement.DataAccessLayer.RetryPolicy..ctor() at Microsoft.EnterpriseManagement.ServiceDataLayer.DataAccessFeatureImplementation..ctor() at Microsoft.EnterpriseManagement.ServiceDataLayer.DataAccessFeatureImplementation..ctor(EnterpriseManagementObjectViewName objectView) --- End of inner exception stack trace --- at Microsoft.EnterpriseManagement.ComponentActivator.Activate[T](ActivationContext`1 context) at Microsoft.EnterpriseManagement.SingletonLifetimeManager`1.GetComponent[K]() at Microsoft.EnterpriseManagement.FeatureContainer.GetFeatureInternal[T](Type type, String featureName) at Microsoft.EnterpriseManagement.FeatureContainer.AddFeatureInternal[T,V](ActivationContext`1 context, String featureName) --- End of inner exception stack trace --- at Microsoft.EnterpriseManagement.ConfigurationReaderHelper.ReadFeatures(XPathNavigator navi, IContainer container) at Microsoft.EnterpriseManagement.ConfigurationReaderHelper.Process() at Microsoft.EnterpriseManagement.ServiceDataLayer.DispatcherService.Initialize(InProcEnterpriseManagementConnectionSettings configuration) at Microsoft.EnterpriseManagement.ServiceDataLayer.DispatcherService.InitializeRunner(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart(Object obj) Event Xml: 26380 2 0 0x80000000000000 4783657 Operations Manager MyComputer.failure.com Microsoft.EnterpriseManagement.ConfigurationReaderException: The feature named 'OperationsManager' and of type 'Microsoft.EnterpriseManagement.ServiceDataLayer.IDataAccessFeature, Microsoft.EnterpriseManagement.DataAccessService.Core, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' cannot be added to the container. ---> Microsoft.EnterpriseManagement.ComponentActivationException: The constructor for the component threw an exception. Please see the inner exception for more details. ---> System.TypeInitializationException: The type initializer for 'Microsoft.EnterpriseManagement.DataAccessLayer.DataAccessRegistry' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.EnterpriseManagement.DataAccessLayer.GlobalDefaults' threw an exception. ---> System.InvalidCastException: Specified cast is not valid. at Microsoft.EnterpriseManagement.DataAccessLayer.DataAccessRegistry.ReadInitiateClearPool(String product) at Microsoft.EnterpriseManagement.DataAccessLayer.GlobalDefaults.Initialize(String product) at Microsoft.EnterpriseManagement.DataAccessLayer.GlobalDefaults..cctor() --- End of inner exception stack trace --- at Microsoft.EnterpriseManagement.DataAccessLayer.DataAccessRegistry.InitializeStateMap() at Microsoft.EnterpriseManagement.DataAccessLayer.DataAccessRegistry..cctor() --- End of inner exception stack trace --- at Microsoft.EnterpriseManagement.DataAccessLayer.DataAccessRegistry.StateMap(String product) at Microsoft.EnterpriseManagement.DataAccessLayer.RetryPolicy..ctor() at Microsoft.EnterpriseManagement.ServiceDataLayer.DataAccessFeatureImplementation..ctor() at Microsoft.EnterpriseManagement.ServiceDataLayer.DataAccessFeatureImplementation..ctor(EnterpriseManagementObjectViewName objectView) --- End of inner exception stack trace --- at Microsoft.EnterpriseManagement.ComponentActivator.Activate[T](ActivationContext`1 context) at Microsoft.EnterpriseManagement.SingletonLifetimeManager`1.GetComponent[K]() at Microsoft.EnterpriseManagement.FeatureContainer.GetFeatureInternal[T](Type type, String featureName) at Microsoft.EnterpriseManagement.FeatureContainer.AddFeatureInternal[T,V](ActivationContext`1 context, String featureName) --- End of inner exception stack trace --- at Microsoft.EnterpriseManagement.ConfigurationReaderHelper.ReadFeatures(XPathNavigator navi, IContainer container) at Microsoft.EnterpriseManagement.ConfigurationReaderHelper.Process() at Microsoft.EnterpriseManagement.ServiceDataLayer.DispatcherService.Initialize(InProcEnterpriseManagementConnectionSettings configuration) at Microsoft.EnterpriseManagement.ServiceDataLayer.DispatcherService.InitializeRunner(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart(Object obj)

SCOM Alert Update connector example for SCOM 2016

Mark Manty — Mon, 24 Apr 2017 20:10:09 GMT

Hi, With the release of SCOM 2016 I elected to recompile this updated version of SCOM Alert Updater connector example that I describe in a earlier post: AUC Example Instructions on configuration are the same as mentioned in earlier post. Note that I did very limited testing. Built and installed on a all in one SCOM 2016 Lab environment. Validated connector is created and after configuring the connector to get all alerts it processed a handful of alerts. Also, I put connector.xml and AlertUpdaterService.exe.config files in debug folder of zip. When copying text from blog it does not always copy over well, so included the copy I used in my lab environment as an example. This version should allow you to configure on SCOM 2016 without having to grab old DLL's and place in service directories to allow for it to run. It just requires SCOM 2016 Console be installed. It was built with Visual studio 2015 targeting .net 4.5. alertupdaterservicescom2016-v1

Disclaimer:

All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use 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 my employer.

SCOM Auto Author example tool

Mark Manty — Thu, 22 Sep 2016 19:48:46 GMT

Hi, Mark Manty Premier Field Engineer with Microsoft here with another example tool for System Center Operations Manager. This example tool (version 1.2) allows you to use snippet templates that you have created with VSAE allowing command line driven automation using your snippet templates to create monitoring workflows. Did I test every possible monitoring workflow? No, so don’t be surprised if some of your custom templates do not work. If you would like to share the template you use that is failing that would make it much easier to reproduce any issues that are discovered. Included in the zip file are the snippet template examples that I created for testing the tool.

Command line examples

When running the example tool with command line parameters passed, it will perform some validation checks to verify if the line is formatted and ready to add workflow automated from command line. If it finds that there are invalid parameters, it will display this windows with command line help for each Template it finds in the template directory. The tool always expects to see the templatesnippet file passed as first argument. Second argument is the Management pack xml file that it should add workflow to or create new MP if the MP Xml file does not exist. Each subsequent parameter passed is unique to the template snippet specified in the first argument passed. Note that there is a check box selection that can be unchecked to prevent the window from closing automatically. This auto close feature was added to help ensure automated command line would continue running in the event that command line params were incorrect on one line or multiple. Text from Command line help box. Note: I will display until a semi-validated set of command line parameters are passed to me :) Command Line Help: scomautoauthor.exe "C:\SCOMTools\SCOMAutoAuthor\SCOMAutoAuthor\bin\Debug\Templates\SnippetTemplate.EventLog.Monitor.templatesnippet" "c:\temp\My.Management.Pack.Name.xml" "Monitor ID" "Monitor Display Name" "Monitor Target" "Event Log Name" "Event ID" "Event Source" scomautoauthor.exe "C:\SCOMTools\SCOMAutoAuthor\SCOMAutoAuthor\bin\Debug\Templates\SnippetTemplate.EventLog.WindowsComputer.Monitor.templatesnippet" "c:\temp\My.Management.Pack.Name.xml" "Monitor ID" "Monitor Display Name" "Monitor Target" "Event Log Name" "Event ID" "Event Source" scomautoauthor.exe "C:\SCOMTools\SCOMAutoAuthor\SCOMAutoAuthor\bin\Debug\Templates\SnippetTemplate.LocalApplication.Class.templatesnippet" "c:\temp\My.Management.Pack.Name.xml" "Class ID" "Class Display Name" "Registry Key" "Class Description" scomautoauthor.exe "C:\SCOMTools\SCOMAutoAuthor\SCOMAutoAuthor\bin\Debug\Templates\SnippetTemplate.Performance.Collection.Rule.templatesnippet" "c:\temp\My.Management.Pack.Name.xml" "Rule Class Target" "Rule ID" "Counter Name" "Object Name" "Instance Name" "Frequency" scomautoauthor.exe "C:\SCOMTools\SCOMAutoAuthor\SCOMAutoAuthor\bin\Debug\Templates\SnippetTemplate.Service.Monitor.templatesnippet" "c:\temp\My.Management.Pack.Name.xml" "Monitor Class Target" "Monitor ID" "Service Name" "Monitor Display Name" "Monitor Description" Below is an example that you could use to create a MP with discovery, event log, performance collections, and service monitors all from command line. Note that I have spaces in some of the last lines for fields that should not have spaces, demonstrating the tool auto remove spaces to correct. Also, for the service monitors they both have the same Monitor ID specified and the tool automatically fixes that for you also, so the Field is unique in your MP. I imagine some users may not want this auto correction and may change this in future to configure allow auto correction or disable auto correction. scomautoauthor.exe "C:\SCOMAutoAuthor\Templates\SnippetTemplate.LocalApplication.Class.templatesnippet" "c:\MPs\My.Management.Pack.Name.xml" "My.Target2" "My Class Target2 Display Name" "Software\MyTarget2" "My Target2 Class Description" scomautoauthor.exe "C:\SCOMAutoAuthor\Templates\SnippetTemplate.EventLog.Monitor.templatesnippet" "c:\MPs\My.Management.Pack.Name.xml" "Event.Monitor.1" "Monitor Event Log 1" "My.Target2" "Application" "1" "MyEventSource" scomautoauthor.exe "C:\SCOMAutoAuthor\Templates\SnippetTemplate.Performance.Collection.Rule.templatesnippet" "c:\MPs\My.Management.Pack.Name.xml" "My.Target2" "Rule.Collect.Perf1" "Counter1" "Object1" "Instance1" "900" scomautoauthor.exe "C:\SCOMAutoAuthor\Templates\SnippetTemplate.Service.Monitor.templatesnippet" "c:\MPs\My.Management.Pack.Name.xml" "My.Target2" "Monitor.Service.1" "Service1" "Monitor Service1" "Monitor Service1 Description" scomautoauthor.exe "C:\SCOMAutoAuthor\Templates\SnippetTemplate.Service.Monitor.templatesnippet" "c:\MPs\My.Management.Pack.Name.xml" "My.Target2" "Monitor.Service.1" "Service2" "Monitor Service2" "Monitor Service2 Description" scomautoauthor.exe "C:\SCOMAutoAuthor\Templates\SnippetTemplate.Performance.Collection.Rule.templatesnippet" "c:\MPs\My.Management.Pack.Name.xml" "My.Target2" "Rule.Col lect.Perf1" "Counter1" "Object1" "Instance1" "900"

Using with UI

Note that you can also run this in UI. If you run example tool with no command line arguments and UI will be presented where you can enter MP or open MP file and create monitoring workflows by selecting the templates and entering information. This supports adding multiple lines resulting in multiple monitoring workflows being created. Note that you can select Target button to get formatted string that can be used for specifying the target you would like. It will be formatted with Alias reference and the tool will automatically add the correct alias for the references based on the MP you are adding workflows in. You can copy that string to use for your targeting. After adding your monitoring workflows, select Create button to add those workflows to the MP. When it is done it will clear out the date you entered for the workflows indicating it is complete and you can close the application. Note: you can validate MP is ok by importing into test environment, or by using MP Author tool or VSAE to validate MP is correct.

Additional notes

Must run as admin command prompt. Requires .NET 4.5.2 or later. Example tool creates C:\temp directory if does not exist and create files in that directory for adding monitor workflows. We do not clean up those files, so can look at them for troubleshooting purposes. Example tool auto increment the version on the MP file after each monitor workflow is added. So, if your version starts at 1.0.0.0 and you use the example tool to add 2 new monitors, the new version will be 1.0.0.2 Example tool makes backup copies of MP before each monitor workflow is added. The backup files are in the same directory where you create your new or update your MP with SCOM Auto author. They have extensions with date time, so they can be opened with notepad to review changes to MP as each workflow was added. It is safe to delete these files if you prefer to do so.

Installation/Configuration

Copy files in zip file to a directory. If running on system without SCOM console installed, you can copy Microsoft.EnterpriseManagement.Core.dll to same directory so it can find the DLL to allow run successful. Note that the MPs folder listed below contains all the sealed management packs that you may want to reference in the management pack files you are creating. If you need to add additional MP’s to the folder, you can do this and the tool will automatically load the classes and references will be available when building your management packs. Note that after adding new sealed MP files to directory the next time you run the tool it will read those additional or updated MP’s and they will be available for targeting. If tool is already running, close the application and run again for updated list to be available.

How to add additional templates to tool.

You will add three files with the same name and different extensions to the folder named Templates where the SCOMAutoAuthor.exe example tool resides. Screen shot below: The RTF file will contain notes on how to use the template monitor, this is for display purposes only and help for others that may be using your templatesnippet file. It is loaded in tool UI when your template is selected from the drop down menu. The TemplateSnippet file is a VSAE template snippet file you or someone else may have created using Visual Studio Authoring Extensions. The TXT file contains information about the templatesnippet file that helps SCOMAutoAuthor format data and allows for you to select the order in which the input data is required. It also allows for specifying if a data field should be unique within the management pack file you are creating and also if spaces should be allowed in a given field. The program will remove spaces if specified and also ensure the string is unique within an MP by auto adding random number to end of string field until the string field is unique and not found in the management pack. I am not going to cover snippettemplate files format here, however there are many blogs and resources available to learn how to create and use them with Visual Studio Authoring Extensions, a couple are listed below. https://blogs.technet.microsoft.com/kevinholman/2014/01/21/how-to-use-snippets-in-vsae-to-write-lots-of-workflows-quickly/ https://tjmklaver.wordpress.com/2012/06/15/author-your-mp-with-snippet-templates-in-visual-studio/ The TXT file example contents are below: Service Monitor Basic - Target hosted class (Monitor Target, Service Name, Service Monitor display name, Service Monitor description) #text('Monitor Target')#;Monitor Class Target;nospace #text('Monitor Id')#;Monitor ID;UniqueNoSpace #text('ServiceName')#;Service Name;none #text('Service Monitor Display Name')#;Monitor Display Name;none #text('Service Monitor Description')#;Monitor Description;none -- comment field -- Replacement string;Display string for field;(UniqueNoSpace,nospace,none) The first line in the above example is the display name that is displayed in SCOMAutoAuthor tool drop down menu. This helps you to inform the user of what this template creates and is used for. Each subsequent line represents one parameter that is required by the snippetTemplate file and specifies the string that it replaces within snippettemplate file;Display String for the columns; Field requirements (like none, or Must be unique with no spaces, or just should not allow any spaces). If “–-“ is found in first two characters of a line it is treated as a comment line that the tool ignores.

NOTE

Txt file and snippet files #text and alias are CASE SENSITIVE. Replacement of text fails if does not match case.

Version 1.2 and later

Items listed below are included with versions 1.2 and later of this example tool.

Monitor workflows with scripts

Added script file replacement capability with your templates. This allows you to specify a script file for the template to embed in your management pack using command line to create the monitoring workflows. PowerShell.Script.Monitor.Two.State.Timed.ServerOS.Target For this example template the contents of text file are: PowerShell Script Timed two state Monitor (Target Server OS disabled) #text('Monitor Id')#;Monitor ID;UniqueNoSpace #text('Monitor Name')#;Monitor Display Name;none #text('Script Name')#;Script Name (ends with .PS1);endswithps1 $IncludeFileContent/Scripts/MonitoringScript.PS1$;PS Script Path;script #text('Folder')#;Folder Check;none #text('Max Files')#;Max Files In Folder;none -- Example of a comment line In the template snippet file see where Monitoring script is specified and highlighted in yellow. Note that in the template we have surrounding the script. Since most scripts we reference will not be xml safe we simple surround with CDATA to prevent us from having to make our scripts XML safe replacing characters to make them xml safe. This allows us to insert scripts that we have already tested from running without further modification. .. .. #text('Script Name')# .. .. Let me know what you think of the tool and let me know if you find any issues with any templates you use. Would appreciate the template and txt file from any that you experience failures with. I have created a few included and imagine there are some cases where it may fail. I can take a look at it and work on when I have time to correct those issues. Thank you for reading.

Disclaimer:

All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use 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 my employer.

Example tool zip file below SCOMAutoAuthor_v1.2

SCOM scheduling maintenance mode tool

Mark Manty — Tue, 16 Apr 2013 05:47:00 GMT

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. Previous example: https://blogs.technet.com/b/markmanty/archive/2012/05/14/scom-maintenance-mode-setting-for-list-of-servers.aspx

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.

MaintenanceModeListSchedExample_V1.zip

Automate closing old SCOM alerts tool

Mark Manty — Thu, 16 Aug 2012 08:07:00 GMT

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.

CloseOldSCOMAlertsv1.zip

Get Connected Consoles command line tool for SCOM

Mark Manty — Fri, 22 Jun 2012 13:48:00 GMT

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:

GetConnectedConsolesV1.zip

SCOM Agent Primary/Failover Management Server configuration tool

Mark Manty — Tue, 05 Jun 2012 13:13:00 GMT

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:

AgentFailOverV1.zip

SCOM maintenance mode setting for list of servers

Mark Manty — Mon, 14 May 2012 09:15:00 GMT

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.

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. See Maintmodelisttoolv2 download.

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 will speed up the process of setting maintenance mode for a list of servers.

Disclaimer:

MaintModeListToolv2.zip

SCOM Alert Updater Service - connector example updating SCOM alerts

Mark Manty — Thu, 03 May 2012 07:10:00 GMT

Hi, Mark Manty Premier Field Engineer with Microsoft here with another example for System Center Operations Manager. Quick note on updated build for SCOM 2016: AUC updated example Today we are going to walk through an example Windows service that is a SCOM connector. 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. GlobalResolutionState="251"> Id="b59f78ce-c42a-8995-f099-e705dbb34fd4" Type="Monitor" UserName="Domain\username"> Name="ResolutionState" NewValue="252" GroupIdFilter="" /> NewValue="$ServerName$" GroupIdFilter="" /> Name="CustomField2" NewValue="$Id$" GroupIdFilter="" /> Name="CustomField3" NewValue="$Name$" GroupIdFilter="" /> Name="CustomField4" NewValue="$ManagementGroup$" GroupIdFilter="" /> Name="CustomField5" NewValue="$MonitoringObjectDisplayName$" GroupIdFilter="" /> Name="CustomField6" NewValue="$MonitoringObjectFullName$" GroupIdFilter="" /> NewValue="$NetbiosComputerName$" GroupIdFilter="" /> Name="CustomField8" NewValue="$NetbiosDomainName$" GroupIdFilter="" /> Name="CustomField9" NewValue="$PrincipalName$" GroupIdFilter="" /> Name="CustomField10" NewValue="$Severity$" GroupIdFilter="" /> Id="308c0379-f7f0-0a81-a947-d0dbcf1216a7" Type="Monitor" UserName="Domain\username"> Name="ResolutionState" NewValue="252" GroupIdFilter="" /> Name="CustomField1" NewValue="$ServerName$" GroupIdFilter="" /> 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 Parameter	Name	Description
$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 aproximately 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. AlertUpdaterServiceBlog.zip

Changing SCOM Health Service Action Account tool

Mark Manty — Wed, 29 Feb 2012 10:59:00 GMT

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.

Validate that the accounts were updated.

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.

ChangeDefaultActionAccount.zip