Enterprise Manager and Firewalls

Just a short post, since this is a fairly common question I see. This morning someone asked me a question about Enterprise Manager and firewalls. They have an environment with EM targets placed in different zones / networks – with firewalls between. In the documentation, it states “Each Management Agent is configured to upload data to one OMS. As a result, if there is a firewall between the Management Agent and its OMS, you must configure the firewall to allow the Management Agent to upload data to the OMS using the upload URL.”

and then further

“In addition, each OMS must be able to contact any Management Agent in your enterprise so it can check for the availability of the Management Agent. As a result, you must be sure that your firewall is configured so that each OMS you deploy can communicate over HTTP or HTTPS with any Management Agent in your enterprise. Otherwise, an OMS without access to a particular Management Agent may report incorrect information about whether or not the Management Agent is up and running.”

So their question was would this mean that it actually is easier to run different OMS’s (each with their own OMR) for each zone?

Of course, the answer to this is there is no easy answer. Well, there is an easy answer I guess – poke a hole in the relevant firewalls to allow communication between the agents and the OMS. For some reason, though, that easy answer breaks the heart of just about every network admin out there.

The problem is if you DON’T do that, you open yourself to a world of hurt. Think about the following list of issues that I can come up with off the top of my head for having multiple EM installations (and of course, there may well be more!):

  • You now have more than one system to patch when it comes time to patch EM. Now, you may have a Dev EM and a Prod EM to test patches to EM itself, but that’s a different issue (and one that makes sense to have, BTW!). Having multiple Prod EMs to patch is just extra work.
  • You now have more than one place to look at when you’re monitoring. Is the alert you got sent this morning from Prod EM 1 or Prod EM 2?
  • You now have more than one place to put your monitoring templates. Of course, you can export a template from one system and import it to another, but again you’re duplicating work.
  • You now have more than one place to define your administrators. If you have any sense at all, you won’t be using SYSMAN but have your own accounts defined. If those accounts are used in both systems, you need to create them in both, and maintain and manage them in both. If an administrator leaves, you have to manage what happens to their account in multiple places. Again, more work.
  • You now need to run Self Update in two different systems to patch plug-ins and so forth. Again, more work.

Are you getting the picture? Having more than one Production EM to monitor different systems is just MORE WORK! Of course, there have been places I’ve worked that have mandated this because of the firewall issues, so you may not be able to escape it. But my advice is clear – never have two Production EM systems unless it’s absolutely necessary.


After 22 years of working at Oracle in just about every role except Marketing and Support, I am now working as a Senior Managed Services Consultant with Red Stack Tech, specializing in Oracle Database technology, High Availability and Disaster Recovery solutions. I am also a member of the OakTable Network, and have presented at RMOUG Training Days, Hotsos Symposia, Oracle OpenWorld conferences, and other user group events. I have co-authored the Expert Oracle Enterprise Manager 12c and Practical Oracle Database Appliance books published by Apress, and am one of the authors of the Building Database Clouds in Oracle Database 12c book published by Addison Wesley.


  1. Thanks for the post

Leave a Reply

Your email address will not be published. Required fields are marked *