SCOM best practices and web resources (a different version)

Best web resources:

http://blogs.technet.com/b/kevinholman/

Recommended toolbox:

– SCOM 2007 R2 resource kit

– effective configuration viewer

– MP viewer

– Override explorer

– MPtoXML.ps1

– Remote maintenance mode scheduler

Best practices for SCOM:

General

  • Always run 64 bits hardware, OS and 64bits SQL
  • Be sure to have enough bandwidth for core OpsMgr components and agents.
  • Virtualization is supported on all OpsMgr roles but don’t cluster the Root Management server virtual.
  • Snapshot backup is not supported for disaster recovery

Operational Database

  • Limit the number of consoles sessions to less than 50
  • Configure the SQL OpsMgrDB to use simple recovery unless you plan to use log shipping
  • Be sure to have quick disks because of extensive I/O usage
  • When using multi clustering be sure the connection is very fast because of disk latency
  • Database grooming, don’t increase the default 7 days

RMS (Root Management server)

  • Never connect agents directly to the Root Management Server
  • Never connect gateway servers directly to the Root Management Server
  • The Root Management Server is most critical in RAM followed by CPU
  • Limit console connections and SDK clients (webconsole, third party tools)
  • Do not run the console on the RMS
  • The console can be used on a TS Server, but be careful with the size of each localappdata (cache file location)
  • Never put the RMS in Maintenance Mode
  • R2 improvement note: RMS can be clustered after RMS is deployed as a single server.

Management server

  • Management servers talks to Root Management Servers but writes directly to OpsMgrDB
  • Keep them close to the Root Management Server, OpsMgrDb, OpsMgrDW because of latency
  • Memory and CPU

Gateway Server (remote office)

  • Data compression by almost 50%
  • Dedicated management server for all gateways when using a large number of agents (R2 will support 1500)

Console

  • Use Clear the console cache /clearcache only when you have console issues else never use it
  • The console can be used on a TS Server, but be careful with the size of each localappdata (cache file location)
  • Customize views for each admin specialist (views by products or by service line)
  • Don’t run the console on the management server
  • Create a terminal server jump box where all your tooling is up to date with a single upgrade location.

Reporting Datawarehouse

  • Limit the number of users who can generate reports
  • Separate the SQL Data files from the transaction logs onto different disk array’s

Get a DR plan

  • Be sure you have a Disaster Recovery plan with DB and encryption key backup and test this.

Grooming:

  • Operations Database, don’t increase the default 7 days
  • Operations Database, Consider reducing performance and event data to 4 or 5 days
  • Data warehouse, use the data warehouse MP reports to examine your DW content.
  • ACS Database, R2 improvement note: Microsoft Data warehouse report MP will be loaded on install.

Notification:

  • Use alert aging to reduce false positive
  • Always configure a SMTP failover host for the notification
  • Ensure RMS communication with the communication channel (don’t forget your RMS cluster node!).
  • R2 improvement note: 5 concurrent command limit will be removed
  • R2 improvement note: Immediately send and alert from the management console.

 

source: http://itworldjd.wordpress.com/2011/10/19/scom-best-practices-and-web-resources/

Advertisements

SCOM 2007 Administrative and implementation best practices

The best practices are collected and created by the OpsMgr team with feedback of the communication, Customers and MVP’s so the real world scenarios really get back in the following optimization tips.

Agent management:

  • Never connect agent directly to the Root Management server.
  • Never connect gateway server directly to the Root management server.
  • R2 improvement note: SCOM 2007 R2 gateway server will support up to 1500 agents.

Scalability:

  • Always run 64bits hardware, 64 bits OS and 64bits SQL.
  • Always consider bandwidth considerations for core OpsMgr component and agents.
  • R2 improvement note: RMS can be clustered after RMS is deployed as a single server.

Cross platform (R2):

  • Provision management server(s) specifically for non windows monitoring

Grooming:

  • Operations Database, don’t increase the default 7 days
  • Operations Database, Consider reducing performance and event data to 4 or 5 days
  • Data warehouse, use the data warehouse MP reports to examine your DW content.
  • ACS Database,
  • R2 improvement note: Microsoft Data warehouse report MP will be loaded on install.

Notification:

  • Use alert aging to reduce false positive
  • Always configure a SMTP failover host for the notification
  • Ensure RMS communication with the communication channel (don’t forget your RMS cluster node!).
  • R2 improvement note: 5 concurrent command limit will be removed
  • R2 improvement note: Immediately send and alert from the management console.

Maintenance mode:

  • Never put the RMS in Maintenance Mode (MM).
  • Never put an object longer in MM than it needs to be, due to loss of perf data and availability data.
  • R2 improvement note: Computer, Health service and Health Service watcher will be in MM from the console and scripts.

Console Management:

  • Don’t run the console on the management server
  • Avoid using /clearcache
  • Create a terminal server jump box where all your tooling is up to date with a single upgrade location.
  • Make upgrade scenarios much easier.

Due to the amount of best practice and environmental scenarios differences not all topics are covert in this article.

So for all the SCOM administrators out there have a good look in your environment and start optimizing your operation, the benefits will be huge!

 

Source: http://www.systemcentercentral.com/scom-2007-administrative-and-implementation-best-practices/