We have 2 sites where we have servers and network devices. I was planing on monitoring the servers at Site 1 using server 1 and site 2 using server 2 however i read more and found that since our DB / DW is in site 1 this is not recommended because of latency issues. So i though of asking Shall i manage all my Site 2 servers using a Gateway server at site 2 or is that not recommended The sites have 5MBPS link between them but sometimes the link goes down and we are unnecessarily flooded by alerts related to sever not recable , ping failed, network device unavailable. Any recommend way to do this. Since i am still designing my way through scom 2012

Hi There is no need for a gateway or management sever in site2. Please see the following: 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 putsomething there"" Cheers GrahamRegards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

I checked the Link you mentioned http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/6dae0b67-714a-4b89-8120-6981637a3707 Some Information related to our Sites: 2 Sites Site A (Head Office) Site B (Remote Office) Latency between links 500 MS Link : 5MB In Our current SCOM 2007 R2 We do not use GateWay servers. So the RMS at Site A is managing all the agents in Site B With this we have had issues - When the link goes down , We get noise Alerts about all Site B servers down , Which affect our availablity reports Since SCOM 2012 has capablity of monitoring Network devices are are very much interested in that (This being our prime reason to Migrate/Upgrade) Now the issue is If the Link goes down between Sites , The Windows Agents will Queue the data and sned when the link is back up. Maybe Linux agents Queue the data as well and then send when link is restored. What is going to happen to all our Network device monitoring. (Are we going to loose all the data during that period of time) Our Site B has 60 Windows Servers that need to be Monitored and around 50 Network Devices <So primarly our issue is fake Alerts -- Is there any way we can automatically stop monitoring Site B devices During Link unavailablity So tahtw e dont get fake alerts and Our Availablity reports do not become useless with incorrect downtime information. We would rather have Monitoring unavailable during that time in availablity reports and not consider that as downtime> <With SCOM 2012 our main goal is monitoring network -- so if link goes unavailable -- it is gouing to be bad for our network guys because of alerts etc , they might even ask us not to use SCOM for Monitoring Network device - Which personally will be a disappointment)

The amount of data to work with here is small in orde rto give a good advice. However, you can have agents in site 2 report directly to management servers in site 1. And have management servers in site 1 for isntance monitor the network devices in site 2 as well. Gateway is of course possible. Usually what i see as the two most common gateway scenarios are either to push the agent data through a slow wan line or for communicating with a number of agents in a non-trusted domain. Some other ways might apply. For the first reason you might still need to take into account that in that case the gwateway is yet another device to manage and monitor and adds complexity and a singole point of failure (when placing one.. blablabla). Many people still go for letting the agents talk to the management servers directly. Also from remote locations. And yes if the line goes down you will get alerts for stuff located on the other side of that line (heartbeat failure alerts for agents and such as well). When designing multiple management servers, even on different datacenters, you need to keep the latency as low as possible with the database box. And low is very low here in my experience. Dark fiber glass connections between datacenters with GB type links are OK. :-)Bob Cornelissen - BICTT (My Blog about SCOM) - MVP 2012 and Microsoft Community Contributor 2011 Recipient

The amount of data to work with here is small in orde rto give a good advice. However, you can have agents in site 2 report directly to management servers in site 1. And have management servers in site 1 for isntance monitor the network devices in site 2 as well. Gateway is of course possible. Usually what i see as the two most common gateway scenarios are either to push the agent data through a slow wan line or for communicating with a number of agents in a non-trusted domain. Some other ways might apply. For the first reason you might still need to take into account that in that case the gwateway is yet another device to manage and monitor and adds complexity and a singole point of failure (when placing one.. blablabla). Many people still go for letting the agents talk to the management servers directly. Also from remote locations. And yes if the line goes down you will get alerts for stuff located on the other side of that line (heartbeat failure alerts for agents and such as well). When designing multiple management servers, even on different datacenters, you need to keep the latency as low as possible with the database box. And low is very low here in my experience. Dark fiber glass connections between datacenters with GB type links are OK. :-)Bob Cornelissen - BICTT (My Blog about SCOM) - MVP 2012 and Microsoft Community Contributor 2011 Recipient

The amount of data to work with here is small in orde rto give a good advice. However, you can have agents in site 2 report directly to management servers in site 1. And have management servers in site 1 for isntance monitor the network devices in site 2 as well. Gateway is of course possible. Usually what i see as the two most common gateway scenarios are either to push the agent data through a slow wan line or for communicating with a number of agents in a non-trusted domain. Some other ways might apply. For the first reason you might still need to take into account that in that case the gwateway is yet another device to manage and monitor and adds complexity and a singole point of failure (when placing one.. blablabla). Many people still go for letting the agents talk to the management servers directly. Also from remote locations. And yes if the line goes down you will get alerts for stuff located on the other side of that line (heartbeat failure alerts for agents and such as well). When designing multiple management servers, even on different datacenters, you need to keep the latency as low as possible with the database box. And low is very low here in my experience. Dark fiber glass connections between datacenters with GB type links are OK. :-)Bob Cornelissen - BICTT (My Blog about SCOM) - MVP 2012 and Microsoft Community Contributor 2011 Recipient

Hi, I'm not trying to deviate this thread but what I want to know from SCOM perspective is how efficiently correlation engine works by default in the tool itself. Because if WAN link goes down and if we are monitoring the link then SCOM should generate alert related to link not for those agents which are behind the link. Even if gateway server goes down then SCOM would generate heartbeat alerts for agents which are behind the gateway server. I could be wrong here in my understanding but why can't correlation engine works here and generate only one alert for gateway server rather than throwing multiple alerts... even-though I've heard and have seen over the documents that SCOM has correlation engine? I know that Exchange 2010 MP has correlation engine ... so does that mean SCOM as a tool lacks the functionalityl? Thanks, Varun

Hi Varun The only correlation engine within SCOM is with the Exchange MP. There is no other correlation engine. If you really want to try and automate something then this might help for a stater: http://cornasdf.blogspot.co.uk/2009/10/stopping-alert-floods-when-branch.html#!/2009/10/stopping-alert-floods-when-branch.html Regards GrahamRegards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/