Deployment Advice: We have Already existing SCOM 2007 R2 environmnet and are looking ahead for Migrating (Not upgrading) to SCOM 2012 Currently We just have 2 Server 1 RMS and 1 DB/DW/ACS servers All our servers are being Monitored by the RMS itself. In the New 2012 Environmnet I wasnt to build a More redundant environment with atleast 5 servers (I know i am getting all virtual servers so can ask for 5 of them) We have around 200 Windows Servers that we need to Monitor + Plus 10 Linux Servers + A lot of Network devices We have 3 Locations , currently we are monitoring all the 3 locatuions from same same Single RMS server that i Spoke of above. But We want to design the new Environment in a better way . Single Managemnet group though. Please give me your thoughts on this. (The only things is all my servers are going to be Virtual - currently we have Physicl RMS and Physical DB/DW server)

Hi, Regarding planning the deployment, I would like to share the following articles with you for your reference: OpsMgr 2012: a quickstart deployment guide http://blogs.technet.com/b/kevinholman/archive/2011/07/26/deploying-opsmgr-2012-a-quick-start-guide.aspx Planning the System Center 2012 - Operations Manager Deployment http://technet.microsoft.com/en-us/library/hh473583 I also think this tool is helpful: Operations Manager 2012 Sizing Helper Tool http://blogs.technet.com/b/momteam/archive/2012/04/02/operations-manager-2012-sizing-helper-tool.aspx Thanks. Nicholas Li TechNet Community Support

Hi Are you happy with current performance? How many servers is ACS enabled for? As suggestions: - SQL - you might want to consider splitting it so that the OperationsManager database is on one SQL Server (or instance) and the DW \ Reporting Services \ ACS is on another. If you need resiliance at the SQL level then consider clustering. - Management Servers. These should all be in the same location as the Databases. --- have 1 to act as Primary for windows agents (agents will automatically failover to other management servers) --- have 1 for non-windows monitoring. If you need resiliance then you can use 2 management servers in a resource pool here. The sizing tool that Nicholas mentions can help but it does tend to over-estimate the number of core servers required. Cheers GrahamRegards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

The performance is ok , but i will want to start fresh. when you say management server should be in ssame location as that of DB , then how will i manage the agents that are at separate location , our issue with the current env is all agents are managed by server at site 1 so if there is link failure for a while we get flooded with alerts which dont make sense. we have a 10MB link between 2 site but it is a little bit latent sometimes. that is the only reason we want the agents there to be monitored by a server which is local to that location. how can i accomplish that with just one management group. we only have 1 domain and all servers are part of that.

how will i manage the agents that are at separate location? Same way as now. Assign them to a management server. Management Servers don't need to be in the same location as the agents. The Management Servers need to be in the same location as the databases. our issue with the current env is all agents are managed by server at site 1 so if there is link failure for a while we get flooded with alerts which dont make sense. You'd get that if you put a management server in the remote site as well. But you would also get latency issues between the Management Server and the database which is far worse. we have a 10MB link between 2 site but it is a little bit latent sometimes That is why the Management Servers should not be with the agents. It is fine for latency between agent and Management Server but not between management server and database. http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/6dae0b67-714a-4b89-8120-6981637a3707 As Kevin Holman states in the above thread: "If I have a remote location, but in the same kerberose realm as my data center, and no firewalls exist, then I would first just design the environment to have the agents report directly to a Management server in the remote data center. People often have this idea that since they have a remote location, they MUST place some sort of server there for moniotring, be it a gateway or a MS. You DONT enhance the design by automatically doing this. Placing a Management server role "across the pond" is almost always a bad idea. People do this because they think having a MS to "queue" data will help when there is latency across the line. In fact - the MS queue is nothing compared to the cumulative power of queues on the agents, and the SQL transport that the MS uses to write to the DB's does not handle latency well at all. Not to mention, I have seen where remote management servers lock tables in the DB for longer periods during insertions, which caused binding for other well connected management servers." Kevin discusses the option of using Gateways in the remote locations in the above thread as well although again, he stresses: " It , < a gateway server> just should be placed by thoughtful and tested design, and not "just because I have a remote location with agents, I need to put something there"" 10 Reasons to use a Gateway: http://blogs.technet.com/b/momteam/archive/2008/02/19/10-reasons-to-use-a-gateway-server.aspx Cheers Graham Regards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

thanks this is great info