If only certificates were all gift certificates! The ‘ADCS Addendum packs’ disables noisy rules, adds OCSP seed, OCSP responder and OCSP group (classes). Recovery and service monitoring and nCipher event are the main highlights reducing alerts for ADCS 2012,2012R2,2016+. My thanks to Bob Williams CSA, for the assist!
The ADCS Addendum packs discover OCSP (seed class), and OCSP responder registry keys installed on monitored servers.
OCSP seed class
Group discovery tailors OCSP classes, for subscription or alert tuning.
OCSP server group can be used for subscription, or alert tuning (depending on class targets)
Monitors and service recoveries keep OCSP services monitored, and only alert when manual intervention is required.
OCSP service, certsvc monitors and service recovery automations built in
Tailoring the pack(s) to your environment
First, you must have at least ONE (1) set of ADCS Active Directory Certificate Services management packs so the ‘ADCS Addendum pack’ will load. The three versions currently supported have addendums, hopefully 2012,2012R2 are planned to be decommissioned in the short term.
Second, if you don’t have OCSP in your environment, download, and then import into your environment –
ELSE
Update the ‘OCSP Responder’ server name(s) for the group regular expressions.
Update the ‘OCSP Responder’ server name(s) for the group regular expressions.
In your favorite XML editor (mine is Notepad++), open the addendum pack(s), and find/replace for the following strings:
IT Ninja required for improving monitoring hence ‘Why addendum packs’
‘Why addendum packs’? What value can they bring to my customer? Kevin Holman started the Addendum thought process quite a while back. Added functionality to a core application/program/product. The first example of this pack naming convention is his SQL RunAs Addendum to simplify SQL monitoring. Let’s break down a number of examples how the SCOM community has built packs to better monitoring, and how I believe the addendum packs bring IT Ninja lessons from Microsoft experts monitoring to your environment.
Why Addendum packs
Better monitoring from the experts, including customer examples for other ‘blind spots’ in monitoring. Blind spots consist of ‘not monitored’ pieces of infrastructure, from simply an event, ping, service, tcp port check, process, web site, scripted workflow, with the purpose to identify a problem.
The goal of monitoring is to:
Identify, self-heal, automatically run recovery or diagnostic workflows alert when manual intervention is required. Doesn’t matter what tool you use, they all do some portion of these steps.
The addendum packs do these things, adding a few differentiators.
Auto closure daily scripts (close rules/monitors)
Auto reports of problems (M-F 0600-0700 local, reflecting last 24-72 hours of open/closed alerts)
Employ count logic (x in y time)
Self-heal monitors with no new events
Adjust alert severities to health model
where critical (red) = outage, warning (yellow) = issue, informational reports or FYI’s
Capable of updating alerts (status, owner, ticketID+)
Tasks to run workflows on-demand
Recovery tasks – (i.e. service restart automation or TopProcess, Logical disk cleanup, MECM Client cache clean )
Data from StarTrek the next generation – Mr. Tricorder makes me laugh!
‘AD Application monitoring’ > web synthetics, artificial users > android what image comes to mind? Is it a person, or a thing from a Sci-Fi movie? Perhaps Bishop from Aliens, Data from Star Trek. What does ‘AD Application monitoring’ consist of? Currently that means a CRL validity check, and ADFS web synthetic (proving that ADFS is responding). My thanks to Jason Windisch CSA, for the supplied PowerShell!
The purpose of the pack is to add scheduled workflow that acts like the user, identifies if the CRL’s are about to expire. Most times, monitoring stops at ICMP ping. Most times, there’s still an outage, as the network, and servers are responding. The next layer is IIS, Apache, etc. Sometimes the network team gets involved, checking a base IIS URL is configured. Most outages aren’t network, nor IIS wasn’t running. This is why we focus on the web application responding. Does the multi-prong tactical attack make sense?
This pack delivers on-demand tasks, daily reports, and rules/monitors to reflect health. Customize the watcher node, some URL’s, save, and import into SCOM! The purpose
Assign watcher node(s)
Assign a watcher node by creating a registry key.
What does that mean? Watcher nodes are needed to provide user perspective.
Multiple site example
Issue: Users from sites 1,2,3 are having problems accessing web pages. To understand a user in site 2, leverage a server in site 2 to initiate the web request (invoke-webRequest in PowerShell).
Why: Differentiate user experience (per site). Answer the ‘did you know’ – is the application responding from this site/perspective.
Unfortunately, the watcher node concept eludes most administrators. Mastering ‘user perspective’ makes for an invaluable aid moving from reactive ‘fire fighting’ to proactively being told before users. Hopefully this explains the power where monitoring imitates user interactions for key web applications.
How: Create registry key on whatever servers you want to initiate web monitor
From PowerShell (as Admin), or Command Prompt (as admin)
Example of XML snippet from AD Applications management pack
AD Applications Watcher Node – create specific registry key
Set up CRL Validity check and ADFS synthetic
Next, configure the URL’s for the customer environment for the ‘AD Application monitoring’ management pack.
Update AD Applications module types for monitor/rules for CRL and ADFS synthetics
Configure the CRL validity check array
From your favorite XML editor (notepad++ pictured)
Find/Replace ##FQDN##, ##CRLstring##, numbers to customer environment
CRL Validity check, create your array length as needed for customer environment
Configure the ADFS synthetic request(s)
From your favorite XML editor (notepad++ pictured)
Find/Replace $server, ##FederationFQDN##, if necessary, update ADFS URL string if different (the /adfs/ls/idpiniatedsignon.aspx portion) to customer environment
Update ADFS URL for invoke-webRequest, ADFS default URL in specified example
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.
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
Logical disk alerts –
Shows Server, drive, and % full data
Logical disk alerts report, showing zero for the past 72 hours (over a weekend)
Alerts of servers pending restart, not patched, not rebooted
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
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
Long running scripts
SCOM Admin long running scripts alerts report example of long-running report workflows to help tune run-time
ScriptErrors showing key SCOM connectivity issues
SCOM Admin script errors to help diagnose report script syntax errors
Useful links
Other blog posts for addendum management packs and capabilities –
As a SME or team lead, ever need to know ‘Proactive Patching alerts’? i.e. What servers need patches applied, aren’t patching, or were missed? This pack builds on three (3) pillars – Health/Security/Compliance, enabling Cyber teams and more. This became an alternate option to a complex pack, with SSRS report, used by a customer to identify systems. The report was long, and had many blank lines/pages, which required a re-write. This pack started with the pending restart monitor directly from the AquilaWeb reboot pack logic. The logic helps SysAdmin/Domain Admin/NOC/NOSC/SOC teams to know when servers need reboots. This need is driven further due to multiple reboots (sometimes) required with Windows monthly updates, and Application updates. Used across multiple customers, this is the first pack enabling a proactive stance to answer the ‘Am I compliant’ question.
David Allen built the ‘Aquilaweb.Support.PendingReboot.Monitor.PendingReboot’ PowerShell monitor, to tell system owners when the pending restart flag was present. Some builds though, make system changes which repeatedly flip the registry key, causing many alerts. Also, downloading the Aquila pack is a trick, as TechNet was retired.
David provided a great idea, which was built upon. This gave rise to the question of, what if the server was not patched, or not rebooted in a period of time? With my Cyber hat on, this became the next piece of content to create. That gave rise to another question – do these scenarios need to reflect in health (monitor), or not (rule)? We’re all about choices, free will, so the pack is built with those options (rules disabled out of the box).
Pending restart monitor XML showing options
The pack is setup to alert with CBS application updates, SCCM/MECM/Config Mgr Endpoint Management updates, and Windows Updates. This has been my experience for the most accurate reflections of alerts on secure builds where Application/System Owner needs to take action.
Last Patch and Last Reboot monitor/rules in the download, are set to 45 days. Tune this value down, if patching occurs at the 30 day mark, increase if you need more time before alerts.
Last Patch Monitor reflecting number of days
Otherwise, download and import into your environment. Depending on your subscription/notification settings, the Proactive set of alerts are built upon the Windows Operating System class. If subscriptions include the class, the notifications are automatic to System/Application owners.
Question example of two cartoon people discussing something. Both have thought bubble cartoons looming overhead.
Ever run through an event log scenario deciding ‘event collection vs. alert rule’ is the way to filter out the needle from the haystack? There’s a few ways to do this with Monitoring tools. If you’re cloud centric, a KQL query (assuming you’re collecting the event logs, if you’re using Operations Manager (SCOM), there’s a few ways to consume the events. SCOM ACS is basically a DB for collecting Security events, and typically is an unused feature in SCOM by most customers. Kevin Holman’s had many blog posts for ACS, testing the filter, as well as a management pack (MP) fragment (blog here, GitHub fragment library here).
Let’s walk through criteria deciding ‘event collection vs. alert rule’:
Do the event(s) happen often? If so, how often?
Can you filter the event description to limit the amount of gathered event?
Do you need match count or samples before action required? (i.e. count x events in y time)
Is there a regulatory or compliance requirement to collect every event?
Is this something you want to visualize with PowerBI?
For better visualizations, would the EventID help view/sort data in a tabular output? i.e. Think PowerShell property) as well as TimeRaised/TimeGenerated, and Event Description
Example – DC Security events
When there is a regulatory requirement to collect events, we need to decide ‘event collection vs. alert rule, and IF we can filter for specific pieces of the event. Holman has examples of alert parameters, and dynamic data, which are very useful to get the needles out of the haystacks. Depending on your goals, use event parameters, or leverage CustomFields in the alert to build required fields.
Depending on the requirements, event collection is useful to collect related EventID’s with RegularExpressions. Use Event rules WHEN action is required. Leverage Regular expressions help filter what we collect (via event collection or alert rule. By extension, utilize CustomFields in the alerts to help the presentation or SQL query towards a PowerBI report.
Lastly, let’s talk about the use of CustomFields to add additional data to the alert, but NOT in the event description (Holman’s blog here)
For the tabular view of alert data (from PowerShell as with SQL query of Alerts view, we might need to display the data, such as EventDisplayNumber, TimeRaised, Message, (alternate is Parameters, or UnformattedDescription). Additionally, check alert output details, from the SCOM MS in PowerShell via get-SCOMAlert -name “MonitorDisplayNameHere” | fl | more
My PowerShell variables to reset SCOM monitors, includes my Addendum and the core – DNS example provided below (thank you Andrew!)
## Grab the MP, get the Monitors and Rules from the MP, then grab all alerts found inside the Monitors/Rules
$SCOMCoreMP = Get-SCOMManagementPack -DisplayName “Microsoft Windows Server 2016 and 1709+ DNS Monitoring” $SCOMAddendumMP = Get-SCOMManagementPack -DisplayName “Microsoft Windows Server 2016 DNS Monitoring Addendum”
Like Meguiar’s cleaner wax to your car’s finish, this post will help utilize cleaner PowerShell to help reset monitors and rules
Cleaner PowerShell supplied by Andrew Bradley that’s helped simplify the PowerShell code included resetting/closing monitors and rules via a method call. Hard to believe I’ve been quiet on the blog for the past year, as I’ve been working on SCOM management pack addendums. The ‘cleaner PowerShell’ is being integrated into the various addendums.
have been helpful with many customers, by building out better ways to monitor, clean up alerts, and create daily reports. The Addendum packs add report key insights for many 1P (1st party) Microsoft authored management packs.
Methods
Cleaner PowerShell to help reset monitors and rules
## Grab the MP, get the Monitors and Rules from the MP, then grab all alerts found inside the Monitors/Rules
$SCOMCoreMP = Get-SCOMManagementPack -DisplayName “System Center Core Monitoring”
## Grab the MP, get the Monitors and Rules from the MP, then grab all alerts found inside the Monitors/Rules
$SCOMCoreMP = Get-SCOMManagementPack -DisplayName “Microsoft Windows Server 2016 and 1709+ DNS Monitoring”
$SCOMCoreRules = $SCOMCoreMP.GetRules()
$SCOMCoreMonitors = $SCOMCoreMP.GetMonitors()
Adding parameters to datasource/probeaction moduletypes
This post is adding parameters to datasource (DS) or probeaction (PA) moduletypes. Sorry, found this draft from last year that I never published. 🙁 I’m in the ‘missing functionality’ boat. Some would say I’m a dreamer, a good system admin, a car guy who has different ideas than the manufacturer, or something altogether different — you decide 🙂 Hope this blog post helps monitoring experts that author more functionality than what was delivered. Specifically adding parameters to datasource/probeaction moduletype NOT delivered in the OotB functionality?!
Adding parameters to datasource/probeaction moduletypes
First – What is needed
Second – Verify dependencies required for a workflow
Third – Build on example ‘datasource’
Fourth – Configure Monitor/Rule to use Datasource/ProbeAction
Let’s go through step by step through ‘adding parameters to datasource/probeaction moduletypes’ to customize a data source. The datasource requirements are to include/verify the following parameters” TimeOut,TimeOutInMS,MatchCount,SampleCount (match/sample count are intended for rules/monitors)
Pre-reqs (what’s needed for a ModuleType to function)
Working Script – PowerShell/BASH/Perl/SH/KSH
ScriptArgs required at runtime
Other Configuration, or Overrideable Parameters
Using configured parameters properly
Verify ProbeActions (PA) inside DS have relevant parameters
Easiest way to summarize adding a configuration parameter
Must be added to Configuration, OverrideableParameters,ModuleImplementation,
When taking an Out of the box’ OotB’ moduletype to modify, where parameter(s) MUST be used in UnitMonitorType,Rule,Monitor
Quick background for MatchCount/SampleCount:
When adding parameters to datasource/probeaction moduletypes, it’s good to know why this is part of the conversation to be added to monitoring design/implementation.
MatchCount comes in handy for repeated failures BEFORE alerting (count 5 events before alerting)
SampleCount comes in handy for counting number of failed workflows BEFORE alerting (run workflow 6 times failing before alerting)
Example Unix.ShellCommand.Invoke.Script DataSource
Requirement = Add MatchCount/SampleCount (or TimeOut to the PA ProbeAction)
Unseal, and open Microsoft.Unix.ShellCommand.Library.xml in NotePad++, VStudio, (or your favorite XML editor)
Screenshot of default Microsoft.Unix.ShellCommand.Invoke.DataSource
TimeOut and TimeOutinMS are baked in. We begin by adding MatchCount/SampleCount
Adding MatchCount/SampleCount for Configuration, OverrideableParameters, and Module Implementation for DS/PA
How to add MatchCount/SampleCount syntax
Adding MatchCount/SampleCount for Configuration, OverrideableParameters, and Module Implementation for DS/PA
NOTE – sometimes you don’t find an example!
This part gets complicated – how far down the rabbit hole do you need the parameters?
Does the DS workflow only need the respective parameters?
Do you have to add to the corresponding PA’s called in the workflow?
Add MatchCount/SampleCount to OverrideableParameters (if you want capability to override)
<OverrideableParameter ID=”MatchCount” Selector=”$Config/MatchCount$” ParameterType=”int” />
<OverrideableParameter ID=”SampleCount” Selector=”$Config/SampleCount$” ParameterType=”int” />
Add MatchCount/SampleCount to DS MemberModule
<MatchCount>$Config/MatchCount$</MatchCount>
<SampleCount>$Config/SampleCount$</SampleCount>
Add MatchCount/SampleCount to PA Configuration
<xsd:element name=”MatchCount” type=”xsd:unsignedInt” maxOccurs=”1″ minOccurs=”0″ xmlns:xsd=”http://www.w3.org/2001/XMLSchema” />
<xsd:element name=”SampleCount” type=”xsd:unsignedInt” maxOccurs=”1″ minOccurs=”0″ xmlns:xsd=”http://www.w3.org/2001/XMLSchema” />
Add MatchCount/SampleCount to PA MemberModule
<MatchCount>$Config/MatchCount$</MatchCount>
<SampleCount>$Config/SampleCount$</SampleCount>
Unix.ShellCommand.Invoke.Script
Alternate example for monitors, the SQL Windows Replication mgmt pack has a good UnitMonitor/UnitMonitorType example – Microsoft.SQLServer.Replication.Windows.Monitoring.xml
Find example by searching unsealed management pack repository (use Tyson’s SCOMHelper PowerShell module to unseal mp/mpb’s to facilitate a better unsealed mp search) https://monitoringguys.com/2019/11/12/scomhelper/
Detected malicious verification code when verifying element – ever run into this scenario while authoring?
Ever run into the ‘detected malicious verification code’ error while authoring? I ran into the malicious verification error authoring, and couldn’t find any content for this error while authoring a pack.
Watch your copy/paste’s with additional monitoring changes to prevent ‘detected malicious verification code’ errors
In my authoring example, I received the ‘detected malicious verification code error’ after adding Rules, Datasources, and WriteActions (including tasks). I was copying and pasting DataSources (DS) and WriteActions (WA), thought I had it all. Uploaded > got the error, and GRR! Hopefully this will help others authoring to know what to check to get the management pack uploaded.
Simply put – Watch out for typo’s to avoid ‘detected malicious verification code’ errors!
I stumbled across a few websites, but nothing really pointed out to what caused the ‘detected malicious verification code error’ when uploading a management pack. First, check monitor and rules to verify the DS/WA are called correctly (no errors in file names. Check the Tasks as well as DisplayStrings, to make sure everything matches.
Error Seen when uploading Management pack from SCOM Console GUI regarding ‘detected malicious verification code’ error
<ManagementPackNameHere> Reports could not be imported.
If any management packs in the Import list are dependent on this management
pack, the installation of the dependent management packs will fail.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.