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.