OpsMgr/SCOM 2007 R2 Implementation and Administration Best Practices – Toolzz.com

OpsMgr/SCOM 2007 R2 Implementation and Administration Best Practices – Toolzz.com OpsMgr/SCOM 2007 R2 Implementation and Administration Best Practices 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 Never put the RMS in Maintenance Mode 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 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.