Tag: script

SNOW REST integration prerequisites

SNOW REST integration prerequisites
SNOW REST integration prerequisites

Did you know –

These PowerShell scripts allow organizations to specify which alerts/events that need to go to ITSM tool.

Does not matter to the tool, whether Broadcom (Spectrum/DXOI), SolarWinds, MECM/MEM/MCM, SCOM

Pretty much ANY tool that can leverage PowerShell scripts and/or REST calls can utilize this script.

The following ServiceNow ‘SNOW REST integration prerequisites’ are required before proceeding.

TEST/PROD ServiceNow (SNow) URL(s)

ID

Password

Incident short_description naming convention

ServiceNow SNOW Alert rule (to make events create incidents)

ServiceNow SNOW Incidents require additional variables to match ServiceNow selections

 

SNOW Incident short_description field is the title of the incident

Pre-define this in the SNOW REST Event/incident injection, to meet organizational naming conventions

Description can be additional details about the issue to be investigated, resolved.

SNOW Incident short_description, description fields
SNOW Incident short_description, description fields

 

Examples of short_description titles

# Setup SNOW Event Name standard

Example SNOWAlertName

$SNOWAlertName = “<Org> <Team> SCOM Test Event – $Alert”

Example SNOWAlertName

$SNOWAlertName = “<Team> <ORG> SCOM Event – $AlertName”

Example SNOWAlertName

$SNOWAlertName = “<Team> <ORG> SCOM $AlertName”

Example SNOWAlertName

$SNOWAlertName = “##CUSTOMER## ##TEAM## SCOM Event – $AlertName”

Example SNOWAlertName

$SNOWAlertName = “##TEAM## ##CUSTOMER##: SCOM – $AlertName”

Example SNOWAlertName

$SNOWAlertName = “##TEAM## ##CUSTOMER##: SPECTRUM – $AlertName”

Example SNOWAlertName

$SNOWAlertName = “##TEAM## ##CUSTOMER##: SOLARWINDS – $AlertName”

 

SNOW Incident fields

Direct Incident REST injection requires additional fields, such as caller, business_service, category, subcategory, channel, impact, urgency, priority, assignment_group
SNOW Incident fields
SNOW Incident fields
Additional SNOW incident fields
Additional SNOW incident fields

 

Additional information

REST/RESTAPI https://www.techtarget.com/searchapparchitecture/definition/RESTful-API

SNOW Utah Connector https://docs.servicenow.com/bundle/utah-it-operations-management/page/product/event-management/task/t_EMConfigureSCOMConnector.html

Additional blogs showing scope and options using ServiceNow for ITSM tool

https://kevinjustin.com/blog/2024/03/27/servicenow-event-integration/

https://kevinjustin.com/blog/2024/03/27/servicenow-incident-integration/

https://kevinjustin.com/blog/2024/04/30/servicenow-connector-for-scom/

https://kevinjustin.com/blog/2024/05/24/lots-of-options-to-create-servicenow-incidents-through-powershell-scripts-connectors-and-3rd-party-vendors/

Install SCOM agent MSI via command line

MECM application for SCOM agent MSI
MECM application for SCOM agent MSI
Shout out to AT and Aris for his help with this!

 

Install SCOM agent MSI via command line and roll into a ‘SCOM agent’ MECM application package.

Why an application/package?  Many times, servers are built, and the IT Enterprise doesn’t find out device is NOT monitored until it’s involved in an outage.  Proceed to add to your Configuration management tool will provide a consistent configuration to avoid the ‘NOT monitored’ configuration.

 

While there are a few options to build out a MCM/MEM/MECM/SCCM application/package to install the SCOM agent on managed windows machines.  In August, I posted Neal’s updates to install/configure the SCOM agent.  Neal’s scenario works great for a new environment, and it’s simple PowerShell.  Also, if Neal’s scenario with PowerShell is NOT your preference, try the batch file below.  Another key point, the script has logic for multiple forests and SCOM gateways (to connect said forests).  Basically test the command line script, then roll into a MCM/MEM/MECM/SCCM application/package.  Have the SCOM agent added to task sequence which consequently includes the SCOM agent in the default build.

 

 

Install SCOM agent command line script

First – NOTE each line has no hidden line feed/carriage returns

Second – go through the variables before testing

Variables to review/replace:

##SCOMManagementGroup##      # SCOM Management group, seen in SCOM console on top left corner

SCOMManagementServer##     # SCOM management Server in primary domain
##SCOMManagementServerGW##     # SCOM first gateway
##SCOMManagementServerGW2##     # Second gateway
##Domain## as forest FQDN
##Domain2## as forest FQDN

Determine domain –

‘systeminfo | findstr /i /c:”domain” | findstr /i /c:”##Domain##”

Example Lab output

C:\> systeminfo | findstr /i /c:”domain” | findstr /i /c:”testlab”
Domain:      testlab.net

 

Third – Find/Replace ##hashtagged## variables and test away!

@echo off

cls

REM This script command line is for NEW installs of the agent (nothing prior)
REM Replace ##SCOMManagementGroup## SCOM Management group, seen in SCOM console on top left corner

ECHO Installing SCOM 2019 Windows Agent…

echo Determining domain….

REM Determine if machine is in DMZ….

systeminfo | findstr /i /c:”domain” | findstr /i /c:”DMZ” && (

echo Machine found to be in DMZ…installing for that enclave and management server: ##Domain2##”

echo.

%WinDir%\System32\msiexec.exe /i %~DP0MOMAgent.msi /qn USE_SETTINGS_FROM_AD=0 USE_MANUALLY_SPECIFIED_SETTINGS=1 MANAGEMENT_GROUP=##SCOMManagementGroup## MANAGEMENT_SERVER_DNS=##SCOMManagementServerGW## SECURE_PORT=5723 ACTIONS_USE_COMPUTER_ACCOUNT=1 NOAPM=1 AcceptEndUserLicenseAgreement=1

echo.

GOTO Logging)

REM Determine if machine is on domain….

systeminfo | findstr /i /c:”domain” | findstr /i /c:”##Domain##” && (

echo Machine found to be in ##Domain##…installing for that enclave and management server: ##Domain##

echo.

%WinDir%\System32\msiexec.exe /i %~DP0MOMAgent.msi /qn USE_SETTINGS_FROM_AD=0 USE_MANUALLY_SPECIFIED_SETTINGS=1 MANAGEMENT_GROUP=##SCOMManagementGroup##  MANAGEMENT_SERVER_DNS=##SCOMManagementServer## SECURE_PORT=5723 ACTIONS_USE_COMPUTER_ACCOUNT=1 NOAPM=1 AcceptEndUserLicenseAgreement=1

echo.

GOTO Logging)

REM Neither DMZ or domain joined found above…look for alternate domain(s)

REM These all share this same management server: FOREST2.FQDN and Gateway server

%WinDir%\System32\msiexec.exe /i %~DP0MOMAgent.msi /qn USE_SETTINGS_FROM_AD=0 USE_MANUALLY_SPECIFIED_SETTINGS=1 MANAGEMENT_GROUP=##SCOMManagementGroup## MANAGEMENT_SERVER_DNS=##SCOMManagementServerGW2## SECURE_PORT=5723 ACTIONS_USE_COMPUTER_ACCOUNT=1 NOAPM=1 AcceptEndUserLicenseAgreement=1

:Logging

ECHO Installing SCOM 2019 Windows Agent Completed…>> C:\Windows\Logs\SCOM2019Agent.log

time /t >> C:\Windows\Logs\SCOM2019Agent.log

date /t >> C:\Windows\Logs\SCOM2019Agent.log

 

Lastly enjoy!   In summary, I hope the ‘Install SCOM agent MSI via  command line’ script helps get the agent deployed faster, and more consistent!

Improving SCOM Monitor reset logic

Faster - Improving SCOM Monitor reset logic
Faster – Improving SCOM Monitor reset logic

 

My thanks to Aris Somatis for his deep dive reviewing the packs with me, particularly new use cases.  The PowerShell below builds on Scott Murr’s initial TechNet published logic from years back.  Consequently, the reset logic provides a ‘manual intervention required’ alerting/monitoring system.

 

 

Improving SCOM monitor reset logic

Calling the reset method has been a game changer for my customers – including operators, system and application owners!

Background

Scott’s reset logic, from SCOM2012, helped administrators reset unhealthy monitors where alerts may have been closed.  Because Scott leveraged the ResetMonitoringState method, the community gained a way to keep true health.  Additionally, many administrators and engineers built custom management packs to provide solutions.  Second, the addendum packs blog brought in more options – best practices, lessons from the field (and customers), and health model accurate alerting for what was really broken in the environment.  Third,    addressing ‘gaps’ or ‘blind spots’ from product teams.   As a result of NEW monitoring, the packs may include: rules/monitors, datasource/writeAction (DS/WA) workflows, recovery tasks and automation, count logic monitors, overrides, discoveries, and groups.    Thirdly, to take monitoring to the next level.  To top that off, with very little/NO cost compared to competitors!

PowerShell code

Aris’s Age use case takes this even further.  Using monitor age allows further analysis to dial down ‘monitor reset’ to object is X days old.  Comparatively, the 24-72 hour setup default is used in the addendums, so Age provides a second option.  Third option can rely on SCOM’s built-in cleanup, but that’s typically 14-30 days.   Overall, flexibility is a good thing.

 

# Specify age variable for your environment

$Age = [DateTime](Get-Date).AddDays(-7)

 

PowerShell code snippet

First, the reset logic can pivot on the age requirement.  Then, adjust the Age variable per requirements.  Third, figure out which method applies to gather a unique list of classes, whether by partial string(s), or by management pack name(s).

 

Set age variable (how long ‘OLD’ monitors might be stale and need reset)

# Example sets $Age variable to 7 days ago (-7)

$Age = [DateTime](Get-Date).AddDays(-7)

 

 

Unpack two different ways to gather classes for monitors to reset

# When common string name exists in all classes

Example DFS/FileServices packs all have one of the three strings:

# DFS pack naming

$DFSClasses = @(Get-SCOMClass -Name “*FileServices*”; Get-SCOMClass -Name “*FileServer*”; Get-SCOMClass -Name “*DFS*” )

$DFSClass = $DFSClasses | sort -property Name -uniq

# Debug

$DFSClass.Count

 

# Get AD classes – Microsoft.Windows.Server.AD.2016.Discovery, Microsoft.Windows.Server.AD.Library

$ADLibrary = Get-SCOMManagementPack -name “Microsoft.Windows.Server.AD.Class.Library”

#get-scomclass -ManagementPack $ADLibrary

$ADMonitoring = Get-SCOMManagementPack -name “Microsoft.Windows.Server.AD.2016.Monitoring”

#get-scomclass -ManagementPack $ADMonitoring | fl DisplayName,Name,ID

$ADDiscovery = Get-SCOMManagementPack -name Microsoft.Windows.Server.AD.2016.Discovery

#get-scomclass -ManagementPack $ADDiscovery | fl DisplayName,Name,ID

# ADDS pack naming

$ADDSClasses = @(Get-SCOMClass -ManagementPack $ADLibrary; Get-SCOMClass -ManagementPack $ADDiscovery; )

# NOTE Excluded AD Monitoring pack as NO classes existed

$ADDSClass = $ADDSClasses | sort -property Name -uniq

 

# Debug count of unique classes

$ADDSClass.Count

 

 

Reset monitor PowerShell screenshot

Download from GitHub https://github.com/theKevinJustin/SCOMMonitorReset

SCOM Reset PowerShell
SCOM Reset PowerShell
 
Example PowerShell on HealthService resets
NOTE debug logic enabled
0
Found 0 unhealthy monitors for class Microsoft.SystemCenter.HealthServicesGroup
1
Found 1 unhealthy monitors for class Microsoft.SystemCenter.HealthServiceWatcher

Resetting Health State on ' + Microsoft.SystemCenter.HealthServiceWatcher:Microsoft.SystemCenter.AgentWatchersGroup;5e0
4f804-8b71-6eb6-0101-dcbb58022498 + '

Guid
----
0218d239-3d37-f9b1-75d2-6d52c2c7c0c1



Documentation/Sources
Building on Scott’s idea – (retired links)
Original post https://sc.scomurr.com/scom-2012-monitor-reset-cleaning-up-the-environment/
TechNet gallery download https://gallery.technet.microsoft.com/SCOM-2012-Batch-reset-63a17534
Alternate link https://gallery.technet.microsoft.com/scriptcenter/Auto-reset-script-for-d8b775ca
Proactive Daily Reports
Proactive Analyst Reports as a new way to ingest key insights from SCOM
Proactive Analyst Reports as a new way to ingest key insights from SCOM
As a SME or team lead, ever need to know a key insight for the enclave?  Let’s talk about the ‘Proactive Daily Reports’ pack.  This provides you some built-in reports on what transpired in an enclave.  Building again on the Health pillar, we can simplify what owners need to see.  Creating a PowerShell script was a simpler alternative to a complex SSRS report that often broke due to patching, and not following best practices.  The pack shows a simpler way to bring key insights to owners for Pending Reboots, Expiring PKI certificates, Logical Disk alerts, System Admin summary, and SCOM admin reports including long-running scripts, script errors, SCOM errors, and alert updates report.
 
Quick Download: https://github.com/theKevinJustin/ProactiveNOSCDailyTasks
Testing the Proactive Daily reports
Let’s start with some example reports – examples for expiring certificates, Logical Disk, Pending Reboot, System Admin summary, and SCOM admin reports including long-running scripts, script errors, SCOM errors, and alert updates report.
 
Expiring Certs – 
About to expire certificates
Expiring PKI certificates reports
Expiring PKI certificates reports
 
Logical disk alerts – 
Shows Server, drive, and % full data
Logical disk alerts report, showing zero for the past 72 hours (over a weekend)
Logical disk alerts report, showing zero for the past 72 hours (over a weekend)
 
Pending Reboots
Alerts of servers pending restart, not patched, not rebooted
Pending reboot report lists servers pending restart, not patched, not rebooted alerts
Pending reboot report lists servers pending restart, not patched, not rebooted alerts
 
System Admin summary
This is really a consolidation of multiple insights:
Server performance issues

Open ITSM/Remedy tickets

Unhealthy Agents

Pending Reboot, Not Rebooted, Not patched

Disabled/Unhealthy/MaintenanceMode, Repeatedly down Agents

Logical Disk free space alerts

Expiring certificates

AD DC (ADDS) critical alerts

DNS alerts

Group Policy issues
SysAdmin daily summary report example alert
SysAdmin daily summary report example alert
 
SCOM admin reports 
Admin reports have a few separate alert reports, including long-running scripts, script errors, SCOM errors, and alert updates report.
SCOM Admin alerts report example of common SCOM problems
SCOM Admin alerts report example of common SCOM problems
 
Long running scripts
SCOM Admin long running scripts alerts report example of longrunning report workflows to help tune run-time
SCOM Admin long running scripts alerts report example of long-running report workflows to help tune run-time
 
ScriptErrors showing key SCOM connectivity issuesSCOM Admin script errors to help diagnose report script syntax errors
SCOM Admin script errors to help diagnose report script syntax errors
Useful links
Other blog posts for addendum management packs and capabilities –
https://kevinjustin.com/blog/2023/08/15/proactive-patching-alerts/

https://kevinjustin.com/blog/2023/08/14/top-process-powershell-script/

https://kevinjustin.com/blog/2023/08/15/proactive-daily-reports/
https://kevinjustin.com/blog/2023/08/08/create-closed-alerts-view/