Compare SolarWinds and SCOM

My Big Fat Greek Wedding - we're all just fruits!
My Big Fat Greek Wedding – we’re all just fruits!

I think of My Big Fat Greek wedding to ‘Compare SolarWinds and SCOM’.  The wedding reception, where the father says the root of his daughter, and son-in-law’s last names, are from the greek word for Orange, and Apple.  “so in the end, we’re all fruits”   We are the same but different, where diversity and inclusion is key.  Everyone’s got a voice.  Contribute, don’t consume 🙂

 

First, I’ve been lucky to administer both tools for Fortune 100 companies (and more tools).  Second, I hope this blog provides some clarification of the strengths, weaknesses, and costs associated with both tools.  Here’s hoping wordpress readers identify with my background – saving money, cutting coupons, looking for on-sale, buy one get one deals.  Thirdly, while everyone’s past experiences may not be the same, cost is still a big factor.  Lastly, proprietary tools, Security, and other requirements can make or break an implementation.

 

 

Here’s a link to a PPT built to ‘Compare SolarWinds and SCOM’ feature wise, that goes along with ‘My Big Fat Greek Wedding’ and the fruit.  PPT title ‘better together’, is loaded with links and breaking out key capabilities.

 

Some items NOT covered in the PPT comparison

Example context – SAW/PAW/Red Forest

Both tools can store credentials within the application, obfuscated.

SCOM allows gMSA’s (managed service accounts) for key services including run as accounts.  View the Monitoring Guys blog plug here for CJ, Scott, and Tyson’s contributions 😛

 

COST

SolarWinds small enterprise example
Windows Server, SQL licenses (no cost given)

Monitors Windows, Non-Windows, Microsoft products

Community of custom application monitoring

Renewal cost per year in 2020 $48K/year
Add HA for SQL Enterprise licenses is same, where SW HA/High availability is the SolarWinds cost, not compute licenses for Windows Server, SQL
***500 license SAM, VOIP, IPAM, NPM/NCM.
Redesigning licensing to unlimited (site license) was $344K
Wow! Site licenses cost considerably more.
Though for clarification, 500 licenses equates to 500 monitors targeted at 500 servers.
SolarWinds costs broken out by feature
SolarWinds costs broken out by feature

Add unlimited VMAN, DPA, SCM, VNQM adds $256K

Add new SolarWinds features

 

Migrate functionality to site license ($48K > $344K)

Adding SolarWinds features with site unlimited licenses
Adding SolarWinds features with site unlimited licenses

 

SCOM small enterprise example

Windows Server, SQL licenses (no cost given)
No license limitation for products/features used, community built solutions

Monitors Windows, Non-Windows, Microsoft products

Large community of custom application monitoring

No yearly support costs (included with Microsoft support agreement)

SQL Enterprise licenses is same, where SW HA/High availability is the SolarWinds cost, not compute licenses for Windows Server, SQL

ESX monitoring via NiCE VMWare 3rd party pay pack is $10K/year
OpsLogix Teams integration helps with NOC/NOSC/SOC integration
Including NiCE Oracle monitoring $10k/year

 

I’ll leave the cost comparisons to you.

Securing the Applications and web consoles

SolarWinds (SW)

Secure SW website search, Smart Cards post, 2FA/MFA/RSA post

NPM (now N-Able RMM – Remote Management & Monitoring)

NCM Thwack forum

SCOM web console

Did you know – gMSA’s (managed service accounts) can be used with SCOM, Windows, AD, etc?  Monitoring Guys blog plug here for CJ, Scott, and Tyson 😛

Configuring AD Delegation, Smart cards and SSL certs (Client Certificate Mapping Authentication, IIS configuration, FIPS

Knowledge sources: Learn.Microsoft.Com, TechNet, blogs, STIG Library and more

 

Vulnerability mitigation

SCOM vulnerability mitigations Blog vuln search, SCOM STIGs plus IIS, Windows Server, SQL, WebServer ALL apply

Solarwinds vulnerability – Trust Center – CVE2023-23836, CVE2021-35211, CVE-2023-33231, all from searches.

NO DISA STIG for SolarWinds, so IIS, Windows Server, SQL, WebServer ALL apply

 

NOTE: I’ve NOT supported SolarWinds recently to see Security scans for other vulnerabilities and STIG settings (Windows Server, SQL, IIS, Network blog.  STIG dashboard ‘how to’

 

 

Licensing

Licensing is a big differentiator cost wise

SolarWinds needs an EA for Windows Server, SQL licenses.

SCOM has been part of the EA (Enterprise agreement) for at least 15+ years (since SCOM2007, if not MOM2005).  Windows Server license (now CPU based), SQL license, however NOT enterprise comes standard.  One reason the System Center suite is successful might be this built-in licensing, as well as the feature depth and cost the tools provide.

 

 

Hardware requirements

In my experience interacting with customers, SolarWinds support recommends hardware configuration well above vendor recommendations.  Support recommendations requesting high compute to provide memory level SQL speed and responsive web console.  However, the compute is basically ESX host level compute in the realm of 128GB of memory per server, in High Availability (HA), meaning x4 – 2 servers for 2 sites.

Monitoring tools are rarely Tier1 Applications with respective Service Level Availability (SLA).  Expectation alone presents a disparity, and false impression.  People just see a tool and base on personal experience.

Ferrari vs. GMC Cyclone - fooled you eh
Ferrari vs. GMC Cyclone – fooled you eh

Is it really surprising if one is faster than the other?

SQL query Plan howto

SQL Query Plan - can't you do anything right?
SQL Query Plan – can’t you do anything right?

Ever need to build out a capability and the SQL query is your blocker?  Use a SQL query Plan ‘howTo’ to figure out what’s taking query so long.  My thanks to Dennis Zwahlen (a Data and AI CSA – LinkedIn ) helping me figure out what was causing a SCOM DW SQL query to render data VERY slowly!

 

Don’t get me wrong, the sheer volume of events is definitely part of the problem.   Event rules are using expressions to further restrict collected event data.

SCOM DW Events ingested for DC Security Events when SIEM is a limit, and NOT using ACS feature

SCOM DW Events ingested for DC Security Events when SIEM is a limit, and NOT using ACS feature.  Will discuss the SCOM DW Event ingestion and additional XML authoring options to turn down the pressure.

 

Time to use the ‘SQL query Plan howto’ blog for SQL execution plan, to help to figure out why the DW Query takes so long.  Using the execution plan, similar to SQL profiler, will provide insight to possibly speed up query, allowing PowerBI app/report rendering of data.

From SSMS > View > Add Display Estimated Execution Plan

From SSMS > View > Add Display Estimated Execution Plan
From SSMS > View > Add Display Estimated Execution Plan

 

SQL execution plan starting from the left documenting SQL query
SQL query plan starting from the left documenting SQL query

SQL query plan starting from the left documenting SQL query

Sort is taking 4.5 minutes in this example of the SQL execution plan visual.  You can see moving right from the Join lines documents how SQL behaves, and how each piece affects overall execution.

SQL query plan starting moving right from the left documenting SQL query
SQL query plan starting moving right from the left documenting SQL query

Hope this helps for another diagnostic SQL step in your tool box!

Updating SQLserver packs to v7.2.0.0

HA HA HA, that's so funny. An error I didn't expect importing the SQL packs 'Updating SQLServer packs to v7.2.0.0'
HA HA HA, that’s so funny. An error I didn’t expect importing the latest SQL packs ‘Updating SQLServer packs to v7.2.0.0’

 

Quick public service announcement – remove the SQL Server Core Custom Monitoring pack before ‘updating SQLServer packs to v7.2.0.0’!  Read to save time and frustration, before importing the packs, as the previous 7.0.42.0 pack isn’t upgradable to v7.2.0.0.

 

 

Updating SQL server packs to v7.2.0.0

Download links for SQL Server with SSIS, Dashboards, SSAS, SSRS

Check Holman’s GitHub Repo for a newer SQL ‘runAs’ pack

Run the MSI’s and copy the files to your file repository on the MS.

If you created custom SQL monitors, backup (export) override pack(s).

Remove the SQL Server Core Custom Monitoring pack.

Import packs and enjoy!

Screenshot list of SQL v7.2.0.0 packs
Screenshot list of SQL v7.2.0.0 packs

This ends the ’emergency broadcasting system’ Updating SQL server packs to v7.2.0.0

SCOM Snapshot Synchronization alerts

Synchronized Swimmers

Updated 4 Apr 2023 with Tyson’s feedback!

 

First, some background – the Snapshot Synchronization alert just tells you there was a SQL issue running the workflow.

Second, the Snapshot Synchronization alert from a health model perspective, is NOT a critical issue (outage).  Create override severity to 1 (warning) to prevent false wake-up calls.  I’ll get this to my GitHub repo shortly!

 

 

 

Let’s troubleshoot the alert

Start with Tyson’s SCOM Maintenance pack, and run the tasks

Tyson’s SCOM Maintenance pack tasks

 

Alternative long steps

Login to server with SSMS installed –

Open SSMS > Connect to the SCOM OpsMgr DB > Click on New Query

***NOTE verify database dropdown shows Operations Manager!

Paste SQL query into the query textbox

Select WorkItemName, b.WorkItemStateName, ServerName, StartedDateTimeUtc, CompletedDateTimeUtc, DurationSeconds, ERRORMESSAGE
from cs.WorkItem a , cs.WorkItemState b
where a.WorkItemStateId= b.WorkItemStateId
and WorkItemName = ‘SnapshotSynchronization’

Screenshot

Snapshot Synchronization alert query

 

 

 

Example SQL Output

SQLQueryExecution

WorkItemName WorkItemStateName ServerName StartedDateTimeUtc CompletedDateTimeUtc DurationSeconds ERRORMESSAGE
SnapshotSynchronization Succeeded SCOMV01 2023-01-24 00:26:23.427 2023-01-24 00:27:46.100 83 NULL
SnapshotSynchronization Failed SCOMV02 2023-01-25 00:27:52.363 2023-01-25 00:28:07.520 15
SnapshotSynchronization Succeeded SCOMV00 2023-01-25 21:43:36.540 2023-01-25 21:45:07.947 91 NULL
SnapshotSynchronization Running SCOMV00 2023-01-25 21:45:32.227 NULL NULL NULL

Solution:
The jobs may show Succeeded by the time you login to SQL = EOJ (end of job)

If Failed is latest date/timestamp, re-run the task “Request Snapshot Synchronization” which can be found when we select  “Management Configuration Service Group” in the below mentioned view.

View:

From Monitoring Tab > Click on Operations Manager folder > Click on Management Group Health widget > Highlight unhealthy state from Management Group Functions.

Click on the ‘Request Snapshot Synchronization’ task to execute the Stored Procedure “SnapshotSynchronizationForce” on the OpsMgr DB.

 

NOTE: There are two tasks with same name but with different targets i.e. ‘Management Configuration Service Group’ and ‘Management Configuration Services’

 

The other task can be found on below view after selecting the Management Server you want the Task to be executed on

View:

From Monitoring Tab > Expand Operations Manager folder > Expand Management Configuration Service folder > Click on Services State view

 

 

Create Override for the alert

To change snapshot monitor to warning

From SCOM Console > Authoring Tab

Expand ‘Management Pack Objects’ > Click on Monitors

In the ‘Look for:’ bar type Snapshot synchronization state and hit enter

Monitor name = Snapshot synchronization state

Right click on monitor > Overrides > Override the monitor > For all objects of class

Click checkbox for Severity > change Critical to Warning

Click Edit – add comment – i.e. date/time changing to warning

Select your override pack > Click OK

Click OK to execute change

Override snapshot monitor to warning

 

 

Resources

Tyson’s MonitoringGuys blog for SCOM Maintenance pack – download here

Link to TechNet article

 

Weird SQL issue from SCOM DB move

Fix SQL2017+ .NET assembly - Weird .NET error
BillMurry-ThatsWeird

This post is courtesy of Andres Naranjo

 

Fix SQL2017+ .NET assembly error

Weird SQL issue from SCOM DB move to new SQL servers

Fix SQL2017+ .NET assembly errors after moving DB’s to new SQL servers.

 

Scenario: Moved the SCOM 2019 databases from a SQL 2014 database engine to a SQL 2019 database engine.  SQL ApplicationThe following error occurred when opening the SCOM admin console:

 

Operations Manager Event Log, Event ID 26317

Date: 10/22/2021 11:17:27 AM

Application: Operations Manager

Application Version: 10.19.10505.0

Severity: Error

Message:

 

An error occurred in the Microsoft .NET Framework while trying to load assembly id 65537. The server may be running out of resources, or the assembly may not be trusted. Run the query again, or check documentation to see how to solve the assembly trust issues. For more information about this error:

System.IO.FileLoadException: Could not load file or assembly ‘microsoft.enterprisemanagement.sql.userdefineddatatype, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. An error relating to security occurred. (Exception from HRESULT: 0x8013150A)

System.IO.FileLoadException:

at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)

at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)

at System.Reflection.Assembly.Load(String assemblyString)

 

Fix SQL2017+ .NET assembly

In addition, Operations Manager event ID’s 26317 events document the error (also check SQL Application log, see Holman’s blog).  Here is an example from the Operations Manager event log:

Screenshot of Operations Manager event log, EventID 26319
Operations Manager event log, EventID 26319

 

 

Weird SQL issue from SCOM DB move to new SQL servers

Cause:

Starting with SQL 2017, SQL restricts trusted managed assemblies.

See more details in Microsoft TechNet article here

First, ensure that SQL CLR execution is enabled with the following SQL query:

 

sp_configure @configname=clr_enabled, @configvalue=1
GO
RECONFIGURE
GO

 

NOTE: It is important to make sure the SQL Server Service is re-started after the query above.

 

Second, execute ‘add trusted’ stored procedure queries to mark both as trusted:

 

EXEC sp_add_trusted_assembly 0xFAC2A8ECA2BE6AD46FBB6EDFB53321240F4D98D199A5A28B4EB3BAD412BEC849B99018D9207CEA045D186CF67B8D06507EA33BFBF9A7A132DC0BB1D756F4F491

EXEC sp_add_trusted_assembly 0xEC312664052DE020D0F9631110AFB4DCDF14F477293E1C5DE8C42D3265F543C92FCF8BC1648FC28E9A0731B3E491BCF1D4A8EB838ED9F0B24AE19057BDDBF6EC

 

 

Verify assemblies are successfully registered as trusted run:

Select * from sys.trusted_assemblies

 

The output should look like this:

SQLTrustedAssemblies output from SSMS

 

At this point, re-start the SCOM services System Center Data Access, and System Center Management Configuration, on all management servers, and re-launch the SCOM admin console to make sure everything is working properly.

 

Quicker ways to start SCOM services

From PowerShell (as Admin)

restart-service healthservice; restart-service omsdk; restart-service cshost

 

Leverage Invoke-Command

# Invoke-Command syntax is PoSH remoting is enabled

#

# Run on multiple servers

# From PowerShell on SCOM Mgmt server, where you have same credential/access

# Example 1

“server1”,”server2″| % {invoke-command $_ -scriptblock {$env:ComputerName; restart-service healthservice; restart-service omsdk; restart-service cshost; get-service healthservice; get-service omsdk; get-service cshost }}

 

# Example 2

# Restart healthservice on MS/Agent

“server1”,”server2″| % {invoke-command $_ -scriptblock {$env:ComputerName; restart-service healthservice; restart-service omsdk; restart-service cshost; get-service healthservice; get-service omsdk; get-service cshost }}

Identify orphaned agent properties

Detective investigating items under a magnifying glass

 

Back again, I’m going to ‘Identify orphaned agent properties’.  For instance, does an agent still show up under Windows Computer, or more classes, like Windows Operating System?  Typically we have handled this by using Holman’s purge blog.

 

 

 

Deleting and Purging data from the SCOM Database

 

 

First, my thanks to Kevin H, Mihai S from the SCOM PG, & Premier Support CSS, for their help.  Let’s begin the ‘Identify orphaned agent properties’ discussion with ‘how’.  First, how do you get an orphaned property?  Second, how to you resolve?

 

Some example scenarios

    1. Server rebuilt with same name.  New agent runs discovery, and creates new set of GUID’s in the database.
    2. The Monitoring Tab > Windows Computer view contains unhealthy <gray> server objects.  Upon further inspection, the server does NOT show up in the Administration > Agent Managed view.
    3. Custom management pack authoring extends the Windows Computer class, or others (via SDK or PowerShell)

 

‘Identify and resolve’ orphaned agent properties

 

    1. Check for COMMIT or Overrides in management packs

PG recommended looking at Windows Computer extended class properties, and Connector Framework discoveries.

Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Commit()

or

Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Override()

 

Search for the ConnectorFramework

Search management packs (MP) via SCOM OpsDB (OperationsManager Database)

    1. Login to your SCOM OpsDB > New Query

select MPName, convert(xml, MPXML)

from ManagementPack

where

   MPXML like ‘%Commit(%’ or

   MPXML like ‘%Override(%’

Export management pack output or snag it/snippet screenshot

Example Snapshot from SQL query

SQL Query output of Management Pack output with Commit or Override
SQL query of MP Commit or Override pack matches

FYI – mgmt packs above use %Commit(%, but not the connectorFramework

 

Correct discoveries that use ConnectorFramework

Replace Discoveries

Update discoveries that contain:

New-Object Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Commit()

New-Object Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Override()

Replace with:

New-Object -comObject MOM.ScriptAPI for discovery

 

Test discoveries that use Remove method

Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Remove()

 

 

 

Example management pack discovery script

Contains

$discovery = New-Object Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData

$discovery.RemoveInternal($Instance,$ClassInstance.GetClasses()[0])

$discovery.Commit($mg)  <– This is the offender that causes the orphans

}

 

SQL on Windows Addendum pack

It’s spring time; time to tune the SQL carb!

 

Carbs are way less easy to find these days, but I’ve been busy tuning the SQL agnostic pack (MSSQL on Windows).

 

Tuning the SQL Agnostic pack would be far less successful without expert help.  My thanks to Brandon Pires – MCS SQL Consultant who helped provide a SQL DBA perspective.   Brandon’s LinkedIn profile

 

Always grab an expert, and for SQL, it’s a DBA.  If you’re new to SCOM, most product teams provide their management packs.  SCOM PFE’s build addendum packs to improve a pack (from our perspective).  Addendum packs make the a pack stronger, for an improved customer experience.  I’m not complaining at what the pack delivers.  The SQL Team is awesome for taking user feedback and making improvements quarterly!

 

Background:

Initially this journey started out with Tim McFadden disabling the duplicate rules/monitors in the SQL MP’s (here).

After talking with Tim and Kevin H, I set out to clean up the SQL version specific packs to remove bloat by creating the version specific OFF packs.  The OFF packs disabled the plethora of SQL performance counters (see MP bloat blog here).

With the SQL Agnostic packs (thank God!), I wanted to deliver an addendum pack to tune the SQL alerts/health for what SQL PFE/Consultants recommended for an improved out of the box experience (OoBE).

 

 

MP Version history
v1.0.0.0 24 Feb 2020 Override to enable SQL Monitoring
v1.0.0.1 24 Feb 2020 Override pack cleanup to human readable format
v1.0.0.2  2 Mar 2020 Overrides for severities and SQL CPU samples
v1.0.0.3  2 Mar 2020 Overrides for SQL rules for warning
v1.0.0.4  4 Mar 2020 Completed overrides for SQL warning rules

v1.0.0.5  1 Apr 2020 Updated rules for backup failures when customer uses Netbackup vs. SQL agent/scheduled tasks

v1.0.0.6  9 Apr 2020 Created groups for seed discovery Test/Dev and Prod; excluded EXPRESS, disabled Securables monitor

v1.0.0.7 15 Apr 2020 Updated pack name to include ‘SQL Server’.

Updated AddendumGroupGUIDUpdate to include RegEx pattern replace
AddendumGroupGUIDUpdate will version pack to v1.0.0.7 for group GUID and regex changes

 

 

Please feel free to download the zip file, which includes the XLS for review of what was updated.

My website download

 

 

Additional References

The Agnostic OFF Pack to turn off the performance rules (found here)

The old SQL version specific OFF packs for the performance counters can be found here.

TechNet Gallery download here

 

Workflow Manager Addendum MP for SQL Aliases

 

A SQL Alias is kinda like wearing disguise glasses…

 

From a security perspective, you can make things difficult for attackers by specifying a SQL alias and different port for SQL.

 

 

 

Symptom – discovery fails for WFM pack

 

Trying to monitor and figure out what the real database name, instance, etc. can be a challenge.

A couple of years ago, I was able to find an example for one customer where the registry key shed light on the alias.

 

The workflow manager management pack has a DataSourceModuleType “Microsoft.WorkflowManager.Addendum.v1.WFCommandExecuterDataSource”, where this change successfully retrieved the sql server name.

This datasource uses the PowerShell script (WorkflowPSDiscovery.ps1)

 

This function was changed in one example

# Get computer name from splitted dataSource
function GetPrincipalName {
param(
$ADDomain,
$ss
)

#$ssWithoutPort = $ss[0].split(‘,’)
#if (-not $ssWithoutPort[0].Contains(‘.’))
#{
# $ssWithoutPort[0] = $ssWithoutPort[0] + “.” + $ADDomain.Name
#}
#$principalName = $ssWithoutPort[0]

$key = ‘HKLM:\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo’
$sqlfromalias = (Get-ItemProperty -Path $key -Name $ss).$ss
$sqlserverstr = $sqlfromalias.Split(‘,’)
$sqlserver = $sqlserverstr[1]
$principalName = $sqlserver

return $principalName
}

 

 

Ran into this discovery issue a second time, and the function didn’t solve the failure.

Real quick – a shout out and my thanks to Chuck Hughes and Mike Sadoff, for their time and testing this more robust discovery method.

 

 

 

Added logic to fix the assumed InstanceName ($instname) – Most likely why my first function worked (configuration had default SQL instance name of MSSQLSERVER )

Added GetSqlAlias function to help decode the disguise

 

 

Gallery download here

 

Don’t forget to override the original workflow manager discovery!

Microsoft.WorkflowManager.v1.Addendum.WFPSDiscovery

Possible SQL issues affecting SCOM performance

 

Good reasons for a Risk Assessment

 

SQL RAS runs 800+ queries to check on target SQL servers

Check Best Practice Recommendations (BPR)

 

May be good opportunity to audit the SQL build for BPR!

 

 

 

Ran across some good examples where SQL settings brought SCOM to a standstill

One was Cardinality Estimation – basically, predicts how many rows a query will return

Part of SQL since 1998 with SQL Server v7.0

 

Let’s figure out what SQL2016 runs OoB (out of box)

 

SQL 2016

SELECT ServerProperty(‘ProductVersion’);
GO 


SELECT name, value
FROM sys.database_scoped_configurations
WHERE name = ‘LEGACY_CARDINALITY_ESTIMATION’;
GO

 

 

The other is CLR Strict Security

SELECT * FROM sys.configurations

WHERE name = ‘clr enabled’

 

 

Talking with Shawn Nakhostin – SQL PFE, we discussed opportunities and questions around SQL optimization and best practices.

Shawn gave me the following feedback on customer performance issues:

I’ve found some customers who have had performance issues with SQL based on organizational SQL settings:

  1. Trace flag 9481
  2. CLR Strict Security is by default enabled

 

Trace flag 9481

Enabling or disabling this TF is not a matter of best practice.

The customer should see what works for them.

Here is the explanation:

Customer started using a new cardinality estimator in SQL Server 2014.

The product team knew that the new CE improved some of the query plans, but not all of them. In other words, they knew that this would improve overall query performance in “some” environments but might have a different impact in other environments.

For this reason, they created TF 9481 so that environments that see query performance degradation after upgrading SQL Server from version 2012 and earlier, they can turn on this trace flag so that the query optimizer uses the old algorithm for CE.

Note:-Trace flag 9481 forces the query optimizer to use version 70 (the SQL Server 2012 version) of the cardinality estimator when creating the query plan.

https://blogs.technet.microsoft.com/dataplatform/2017/03/22/sql-server-2016-new-features-to-deal-with-the-new-ce/

https://support.microsoft.com/en-in/help/2801413/enable-plan-affecting-sql-server-query-optimizer-behavior-that-can-be

 

CLR Strict Security is by default enabled

This causes all assemblies to be treated as unsafe.

As a result, assemblies will not load.

To get the assemblies to load they can do one of the following:

  • Sign the assembly. This may work if you have a few assemblies but becomes a huge task if there are many assemblies to sign.
  • Set the TRUSTWORTHY database property to on.
    • This is not recommended because in some form defeats the purpose of using CLR Strict Security.
  • Add the assembly to the trusted assemblies list.
    • This is called whitelisting, which may be a better option than the previous two.

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/clr-strict-security?view=sql-server-2017

 

 

What ID’s is SCOM using

Ever need to audit what ID’s SCOM is using?

Maybe you have to figure out how someone else setup SCOM.

Did they set up SCOM as recommended for best practices with different AD accounts per role?

 

If the ID’s are not logged during install, it’s a little more difficult to figure out what ID was used.

  • Domain Account for ALL services,
  • Enter in the unique DOMAIN\OMAA, DOMAIN\OMDAS, DOMAIN\OMREAD, DOMAIN\OMWRITE

 

Try these PowerShell commands to find what SCOM is using.

 

ON MS (from PowerShell (don’t need admin unless you’re restarting services)

$Services = ( Get-WmiObject -Class Win32_Service )

$Services | ? { $_.Name -eq “OMSDK” -OR $_.Name -eq “cshost” -OR $_.Name -eq “HealthService” } |

ft name,Startname,StartMode

 

 

 

ON SCOM DB’s, Reporting (from PowerShell (don’t need admin unless you’re restarting services)

$Services = ( Get-WmiObject -Class Win32_Service )

$Services | ? { $_.DisplayName -like “*SQL*” } | ft name,Startname,StartMode

 

 

Source https://blogs.technet.microsoft.com/heyscriptingguy/2012/02/15/the-scripting-wife-uses-powershell-to-find-service-accounts/