Run As Accounts in SCOM!!!!

As accounts define which credentials will be used for certain actions that are carried out by the Operations Manager agent. These accounts are centrally managed through the Operations console and assigned to different Run As profiles. If a Run As profile is not assigned to a particular action, it will be carried out under the Default Action account. In a low-privilege environment, the default account may not have the required permissions for a particular action, and a Run As profile can be used to provide this authority. Management packs may install Run As profiles and Run As accounts to support required actions. If this is the case, their documentation should be referenced for any required configuration. The following table lists the default Run As accounts that are created by Operations Manager during setup. The following table lists the Run As profiles that are created by Operations Manager during setup. Note that if the Run As account is left blank for the particular profile, the Default Action account (either the Management Server Action account or the Agent Action account, depending on the location of the action) will be used. NAME DESCRIPTION RUN AS ACCOUNT Active Directory Based Agent Assignment Account Account used by Active Directory-based agent assignment module to publish assignment settings to Active Directory. Local System Windows Account Automatic Agent Management Account This account will be used to automatically diagnose agent failures. None Client Monitoring Action Account If specified, used by Operations Manager 2016 to run all client monitoring modules. If not specified, Operations Manager uses the default action account. None Connected Management Group Account Account used by Operations Manager management pack to monitor connection health to the connected management groups. None Data Warehouse Account If specified, this account is used to run all Data Warehouse collection and synchronization rules instead of the default action account. If this account is not overridden by the Data Warehouse SQL Server Authentication account, this account is used by collection and synchronization rules to connect to the Data Warehouse databases using Windows integrated authentication. None Data Warehouse Report Deployment Account This account is used by Data Warehouse report auto-deployment procedures to execute various report deployment-related operations. Data Warehouse Report Deployment Account Data Warehouse SQL Server Authentication Account If specified, this login name and password is used by collection and synchronization rules to connect to the Data Warehouse databases using SQL Server authentication. Data Warehouse SQL Server Authentication Account MPUpdate Action Account This account is used by the MPUpdate notifier. None Notification Account Windows account used by notification rules. Use this account's e-mail address as the e-mail and instant message 'From' address. None Operational Database Account This account is used to read and write information to the Operations Manager database. None Privileged Monitoring Account This profile is used for monitoring, which can only be done with a high level of privilege to a system; for example, monitoring that requires Local System or Local Administrator permissions. This profile defaults to Local System unless specifically overridden for a target system. None Reporting SDK SQL Server Authentication Account If specified, this login name and password is used by SDK Service to connect to the Data Warehouse databases using SQL Server authentication. Reporting SDK SQL Server Authentication Account Reserved This profile is reserved and must not be used None Validate Alert Subscription Account Account used by the validate alert subscription module that validates that notification subscriptions are in scope. This profile needs administrator rights. Local System Windows Account SNMP Monitoring Account This account is used for SNMP monitoring. None SNMPv3 Monitoring Account This account is used for SNMPv3 monitoring. None UNIX/Linux Action Account THis account is used for low privilege UNIX and Linux access. None UNIX/Linux Agent Maintenance Account This account is used for privileged maintenance operations for UNIX and Linux agents. Without this account agent maintenance operations will not work. None UNIX/Linux Privileged Account This account is used for accessing protected UNIX and Linux resources and actions that require high privileges. Without this account some rules, diagnostics and recoveries will not work. None Windows Cluster Action Account This profile is used for all discovery and monitoring of Windows Cluster components. This profile defaults to used action accounts unless specifically populated by the user. None WS-Management Action Account This profile is used for WS-Management access. None NAMEx`

Installing and configuring the MMA agent via PowerShell

Pre-reqs to build out an install script/package
MMA agent executable

Workspace ID

Workspace Primary Key





Download MMA agent
Click on Windows Servers from Connected Sources to download Windows Agent

Click on Linux Servers from Connected Sources to download Linux Agent











Obtain WorkspaceID
From the Azure Portal (https://portal.azure.com)

Click on Log Analytics,

Click on Advanced Settings

My view defaulted to Connected Sources > Windows Servers



Save the workspace ID and workspace key to notepad/OneNote for later













Build out command line for setup file
(optionally to include in Application Deployment package)



Grab pre-reqs above: (saved from above to build the command line)

Exe/msi file

Workspace ID

Workspace key



The setup.exe or MSI command line parameters to pass are:

MMA-specific options Notes
NOAPM=1 Optional parameter. Installs the agent without .NET Application Performance Monitoring.
ADD_OPINSIGHTS_WORKSPACE 1 = Configure the agent to report to a workspace
OPINSIGHTS_WORKSPACE_ID Workspace Id (guid) for the workspace to add
OPINSIGHTS_WORKSPACE_KEY Workspace key used to initially authenticate with the workspace
OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE Specify the cloud environment where the workspace is located0 = Azure commercial cloud (default)1 = Azure Government
OPINSIGHTS_PROXY_URL URI for the proxy to use
OPINSIGHTS_PROXY_USERNAME Username to access an authenticated proxy
OPINSIGHTS_PROXY_PASSWORD Password to access an authenticated proxy
Example:

setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=0 OPINSIGHTS_WORKSPACE_ID= OPINSIGHTS_WORKSPACE_KEY= AcceptEndUserLicenseAgreement=1







Other helpful links
Docs site https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-quick-collect-windows-computer

Daniel Orneling Blog https://blog.orneling.se/2017/01/installing-oms-agent-with-powershell/

TechNet gallery https://gallery.technet.microsoft.com/scriptcenter/Install-OMS-Agent-with-2c9c99ab

MMA Agent and SCOM Agent version numbers

This idea sprung from a discussion with Sr. PFE Brian Barrington, and it got me wondering...



FYI - If you're running a SCOM agent, 2016 or above, various Log Analytics solutions may have pre-reqs.



OMS Gateway requires Microsoft Monitoring Agent (agent version - 8.0.10900.0 or later)

Simple English, that means SCOM2016 RTM agent or above





As of 6 Sep 18, MMA agent = 8.0.11103.0

As of 17 Oct 18, MMA agent = 8.0.11136.0





SCOM Agent Version numbers

SCOM2016 RTM 8.0.10918.0
SCOM2016 UR1 8.0.10931.0
SCOM2016 UR2 8.0.10949.0
SCOM2016 UR3 8.0.10970.0
SCOM2016 UR4 8.0.10977.0
SCOM2016 UR5 8.0.10990.0
SCOM1801 8.0.13053.0
SCOM1807 8.0.13067.0



Verify what version is installed
Via SCOM - use Holman's Agent Version Addendum management pack





If you don't have SCOM

From PowerShell

$Agent = get-itemproperty -path "HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup"

$Agent.CurrentVersion















Resources

SCOM Agent Version Addendum pack https://blogs.technet.microsoft.com/kevinholman/2017/02/26/scom-agent-version-addendum-management-pack/

SCOM Agent build numbers https://social.technet.microsoft.com/wiki/contents/articles/34312.system-center-operation-manager-momscom-list-of-build-numbers.aspx

How to multihome a large number of agents in SCOM!!!

Quick download: https://gallery.technet.microsoft.com/SCOM-MultiHome-management-557aba93



I have written solutions that include tasks to add and remove management group assignments to SCOM agents before:

https://kevinholman.com/2017/05/09/scom-management-mp-making-a-scom-admins-life-a-little-easier/



But, what if you are doing a side by side SCOM migration to a new management group, and you have thousands of agents to move? There are a lot of challenges with that:



1. Moving them manually with a task would be very time consuming.

2. Agents that are down or in maintenance mode are not available to multi-home

3. If you move all the agents at once, you will overwhelm the destination management group.



I have written a Management Pack called “SCOM.MultiHome” that will manage these issues more gracefully.



It contains one (disabled) rule, which will multihome your agents to your intended ManagementGroup and ManagementServer. This is also override-able so you can specify different management servers initially if you wish:



image



This rule is special – in how it runs. It is configured to check once per day (86400 seconds) to see if it needs to multi-home the agent. If it is already multi-homed, it will do nothing. If it is not multi-homed to the desired manaement group, it will add the new management group and management server.

But what is most special, is the timing. Once enabled, it has a special scheduler datasource parameter using SpreadInitializationOverInterval. This is very powerful:




86400
14400






What this will do, is run once per day, but the workflow will not initialize immediately. It will initialize randomly within the time window provided. In the example above – this is 14400 seconds, or 4 hours. This means if I enable the above rule for all agents, they will not run it immediately, but randomly pick a time between NOW and 4 hours from now to run the multi-home script. This keeps us from overwhelming the new environment with hundreds or thousands of agents all at once. You can even make this window bigger or smaller if you desire by editing the XML here.



Next up – the Groups. This MP contains 8 Groups.



image

Let’s say you have a management group with 4000 agents. If you multi-homed all of these to a new management group at once, it would overwhelm the new management group and take a very long time to catch up. You will see terrible SQL blocking on your OpsMgr database and 2115 events about binding on discovery data while this happens.

The idea is to break up your agents into groups, then override the multi-home rule using these groups in a phased approach. You can start with 500 agents over a 4 hour period, and see how that works and how long it takes to catch up. Then add more and more groups until all agents are multi-homed.

These groups will self-populate, dividing up the number of agents you have per group. They query the SCOM database and use an integer to do this. By default each group contains 500 agents, but you will need to adjust this for your total agent count.



86400
20:00
Group1
1
500
300



Also note there is a sync time set on each group, about 5 minutes apart. This keeps all the groups from populating at once. You will need to set this to your desired time, or wait until 10pm local time for them to start populating.

Powershelll Commands

get-scomalert -criteria ‘ResolutionState=255 AND Severity>=2’ | select MonitoringObjectDisplayName,Name,Severity,ResolutionState,TimeRaised,TimeResolved,Parameters | export-csv C:\Users\a_sgaruvu\Desktop\ClosedCriticalAlerts.csv



get-scomalert -criteria ‘ResolutionState=0 AND Severity>=2’ | select MonitoringObjectDisplayName,Name,Severity,ResolutionState,TimeRaised,Parameters | export-csv C:\Users\a_sgaruvu\Desktop\NewCriticalAlerts.csv



Get-SCOMGroup -DisplayName “Windows Computers” | Get-SCOMClassInstance | export-csv -notype “C:\Users\a_sgaruvu\Desktop\Windows Computers-1.csv”

Get-SCOMclass -DisplayName “UNIX/Linux Computer” | Get-SCOMClassInstance | export-csv -notype “C:\Users\a_sgaruvu\Desktop\Linux Computers.csv”


Get-SCOMclass -DisplayName “Windows Computer” | Get-SCOMClassInstance | export-csv -notype “C:\Users\a_sgaruvu\Desktop\Windows Computers.csv”

Get-scomagent | export-csv -path "C:\Users\a_sgaruvu\Desktop\SCOM Agents.csv"

Get-SCOMClass | export-csv -path "C:\Users\a_sgaruvu\Desktop\SCOM Class.csv"



Get-SCOMclass -DisplayName “UNIX/Linux Computer” | Get-SCOMClassInstance | export-csv -notype “C:\Users\a_sgaruvu\Desktop\Linux Computers.csv”

Get-SCOMclass -DisplayName “Windows Computer” | Get-SCOMClassInstance | export-csv -notype “C:\Users\a_sgaruvu\Desktop\Windows Computers.csv”

Get-SCOMclass -DisplayName “Network Device” | Get-SCOMClassInstance | export-csv -notype “C:\Users\a_sgaruvu\Desktop\Network Devices.csv”

Get-SCOMgroup -DisplayName “Celgene - ESX Devices” | Get-SCOMClassInstance | export-csv -notype “C:\Users\a_sgaruvu\Desktop\ESX Devices.csv”


Get-SCOMgroup -DisplayName “Storage Devices Group” | Get-SCOMClassInstance | export-csv -notype “C:\Users\a_sgaruvu\Desktop\Storage.csv”