Tag Archives: #BestPractise

SCOM 2016: Don’t forget those Antivirus Exclusions!

Something that I find is often missed with a SCOM deployment is putting in place the recommended AV exclusions. Not having these in place can cause issues in your environment.

Note: Paths are examples, amend drive letter as required for your environment.

Processes
Monitoringhost.exe

Directories
The following directory-specific exclusions for Operations Manager include real-time scans, scheduled scans and local scans. The directories that are listed here are default application directories so you may have to modify these paths based on your specific environment. Only the following Operations Manager related directories should be excluded.

Important When a directory that is to be excluded has a directory name greater than 8 characters long, add both the short and long directory names of the directory to the exclusion list. These names are required by some AV programs to traverse the subdirectories.

SCOM Management Servers
C:\Program Files\Microsoft System Center 2016\Operations Manager\Server\Health Service State

 Agent machines
C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State

SCOM SQL Servers
These will include the locations for your SCOM databases and log files as well as you SQL master and tempdb
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data
C:\MSSQL\DATA
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Log

File Extensions 
SCOM Management Servers / Agent machines
EDB
CHK
Log

SCOM SQL Servers
MDF
LDF

SCOM: Objects, Classes, Targeting and You

This posting will be part of my SCOM basics series and covers the key concepts of Objects and Classes.

Objects

An object is the basic unit of management in Operations Manager. An object typically represents something in your computing environment, such as a computer, a logical disk, or a database. It could also represent something more abstract, such as an application, an Active Directory domain, or a DNS zone. An object can also be referred to as an instance of a particular Class.

Classes

A class represents a kind of object, and every object in Operations Manager is considered an instance of a particular class. All instances of a class share a common set of properties. Each object has its own values for these properties which are determined when the object is discovered.

Most management packs define a set of classes that describe the different components that make up the application that is being monitored and the relationships between those classes

Targeting

A target in the Operations console represents all instances of a particular class. For example, a viewlists all of the objects that are instances of the class that is used as the target class for the view, and a monitor is applied to all objects that are instances of the monitor’s target class.

targets

Classes have two further categories. Base Classes and Hosted Classes

Base Classes

Every class in Operations Manager has a base class. A class has all the properties of its base class and could add more. All of the classes from the different management packs installed in your management group can be arranged in a tree with each class positioned under its base class.

When you select a class as a target that is a base class for other classes, the monitor or rule applies to all instances of each of those classes. For example, if you use Windows Operating System as the target for a monitor, then the monitor applies to all instances of Windows Client Operating System and Windows Server Operating System. This is because those two classes use Windows Operating System as their base class.

Hosted Classes

Most classes are hosted by another class. When one class hosts another, the hosting class is called the parent, and the class being hosted is called the child. Instances of the child class cannot exist without a parent.

For example, several classes are hosted by Windows Computer because they are components on a computer. It would not make sense to have a logical disk if there was no computer for the disk to be installed on. Therefore, Logical Disk is hosted by Windows Computer. This means that every instance of Logical Disk must have one instance of Windows Computer as its parent.

Note about Groups

I’ve included groups in this posting because it can be a common mistake to try and use a group as a target for a rule / monitor this can cause that rule / monitor to not function correctly as the class for a group only exists on a management server, the group will not be enumerated into it’s members from the target selection.

SCOM: Supercharge console performance

I came across a recent article by Marnix Wolf and S.Carrilho regarding a little known SQL setting known as Max Degree of Parallelism (MDoP)

When SQL Server runs on a computer with more than one microprocessor or CPU, it detects the best degree of parallelism, that is, the number of processors employed to run a single statement, for each parallel plan execution. You can use the max degree of parallelism option to limit the number of processors to use in parallel plan execution.

This becomes an issue on servers with hyper-thread enabled processors, as by the nature of hyper-threading the system thinks that there are more cores available then there physically are.

This setting can be found under SQL Server advanced properties:

mdop

In order to calculate the recommended value for this setting we need to use the MDoP calulator which makes use of two queries:

1. Output of following query from the SQL Server instance: 

SELECT COUNT(DISTINCT memory_node_id) AS NUMA_Nodes FROM sys.dm_os_memory_clerks WHERE memory_node_id!=64

2. Launch Powershell and get the output of following PS command:
Get-WmiObject -namespace “root\CIMV2” -class Win32_Processor -Property NumberOfCores | select NumberOfCores

3. Input these value into the calculator:

mdopcalc

In this example the SQL query returned a value of 1 and the PS returned a count of 4 cores, the calculator recommends an MDoP setting of 4.

I’ve had situations in the past where no amount of tweaking seemed to improve console performance and this certainly a factor I will be taking into account in the future. Definitely give Marnixs’ article a read as he covers the topic in more detail with additional findings from his field experience.

There are other ways to improve console performance, I will combine them together in a future blog post about complete console tuning.

SCOM: Agent health and you

I often find it interesting, particularly among younger engineers how little emphasis is placed on this icon greyagent , discussions usually center around phrases like “it’s only one grey agent” and there is little urgency in fixing that agent.

I use one agent as my example because what does that one agent really mean. Well it of course does depend on each environment and requires some understanding of the clients business. For example it’s the end of the month and greyagent is the payroll server, or perhaps you are supporting a web based business such as an online retailer and greyagentis their web front end. Management servers may be the heart and soul of Operations Manager but without the lifeblood of the agents you don’t have much to work with.

Agents watch data sources on the monitored computer and collect information according to the configuration that is sent to it from its management server. The agent also calculates the health state of the monitored computer and objects on the monitored computer and reports back to the management server. When the health state of a monitored object changes or other criteria are met, an alert can be generated from the agent. This lets operators know that something requires attention. By providing health data about the monitored object to the management server, the agent provides an up-to-date picture of the health of the device and all the applications that it hosts.

 

Below is a diagram of the data flow from the agent to the management server and from there through to the Ops and DW databases.

 

Agent Flow

 

I posted an article earlier in the year about agents not submitting performance data that shows how to pickup agents that may not be working even if they show green in the console. It just emphasises that just because agents look like they are working it doesn’t mean they are 100%

Hopefully this article helps to raise awareness of the importance of greenagent2 happy SCOMing.

 

SCOM: Caution with management packs in large environments

Kevin Holman recently published a great article about the inherent pitfalls of importing a management pack into an environment without understanding the intended scope, scalability, and any known/common issues.

Specifically he discusses the Dell  Hardware Management Pack (Detailed Edition) which has a small scalability limitation of 300 agents.

The lesson to learn here is – be careful when importing MP’s.  A badly written MP, or an MP designed for small environments, might wreak havoc in larger ones.  Sometimes the recovery from this can be long and quite painful.   An MP that tests out fine in your Dev SCOM environment might have issues that wont be seen until it moves into production.  You should always monitor for changes to a production SCOM deployment after a new MP is brought in, to ensure that you don’t see a negative impact.  Check the management server event logs, MS CPU performance, database size, and disk/CPU performance to see if there is a big change from your established baselines.

 

Go here for the full article, definitely worth the read.

SCOM 2012: Survival Guide

I came across a great article on TechNet which is essentially a compilation of useful SCOM information, it includes everything from the basics and key concepts, to deployment guidelines and information on how to configure and use different features.

This is definitely one to keep in your favorites

Go here for the full article

SCOM: Troubleshooting Flow For Slow SCOM 2012x Consoles

A while ago I had an issue at a customer where their SCOM console would experience huge performance degradation at random intervals.

This is a slow and complex situation to troubleshoot which is why I am glad to see a comprehensive and well laid out Troubleshooting plan from Marnix Wolf.  This is a must read to better understand the areas that can impact your SCOM environment performance and more importantly your user experience, as people don’t want to use a console that’s slow.

Click here for the full article.

SCOM: Common sense, keep your Management Packs up to date.

Something I’ve noticed, being exposed to a variety of SCOM deployments, is that in quite a few cases Management Packs are installed and never looked at again. Generally this seems to stem from either the engineer looking after the environment doesn’t know any better or is perhaps too cautious to perform an update but there may be other specific reasons such as client restrictions.

Never the less it is good practice to check all of your management packs regularly, I’d say at least once a month, to see if any updated versions are available.

The easiest way to check MPs available through the catalog is to use the wizard in the SCOM console and search for “Updates Available for installed Management Packs” 

In my experience once you have found a new version of a particular MP has been released it is always a good idea to download the MSI from the relevant site instead of using the wizard. This is because if a new management pack has been added to the package that wasn’t there in the previous version then you will not detect it as an update for an installed Management Pack.

DL MP1

mp dl2

If you have management packs not available through the catalog then they unfortunately need to be checked against the latest version at the vendor site manually.

Remember: If possible always test before deploying a new version of a management pack, if you don’t have access to a lab then an alternative is to keep an eye on community blogs and sites like System Center Central and MP Wiki, to see if any issues crop up.

If you have a good method for keeping your management packs up to date leave a comment.