Hi
Is there any reason why you put a management server in that location. In general, it isn't the best architecture and you might be best removing it and redesigning the architecture.
http://www.scom2k7.com/when-to-use-a-gateway-for-a-remote-location/
And
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."