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/