2 Replies Latest reply on Jun 27, 2014 4:06 PM by ja2013

    Why is installation of ePO not recommended on a Domain Controller?


      This is mostly an academic question, I would like to know why it is not recommended.

      What problems, difficulties, or vulnerabilities could be expected?


      We would like to install ePO on a secondary domain controller, and we want to be able to make an informed decision on whether to do that or not.

        • 1. Re: Why is installation of ePO not recommended on a Domain Controller?

          Per Microsoft,


          "Antivirus software must be installed on all domain controllers in the enterprise. Ideally, try to install such software on all other server and client systems that have to interact with the domain controllers. It is optimal to catch the malware at the earliest point, such as at the firewall or at the client system where the malware is introduced. This prevents the malware from ever reaching the infrastructure systems that the clients depend on."


          "Because domain controllers provide an important service to clients, the risk of disruption of their activities from malicious code, from malware, or from a virus must be minimized. Antivirus software is the generally accepted way to lessen the risk of infection. Install and configure antivirus software so that the risk to the domain controller is reduced as much as possible and so that performance is affected as little as possible."



          Follow their recommendations regarding exclusions and testing . You'll need to work closely with the Network, Systems and Security Teams for any additional exclusions that may be needed.



          • 2. Re: Why is installation of ePO not recommended on a Domain Controller?

            Here are a few things I hope will help you ponder the decision.


            1. Technically you could install any application on a Primary or Secondary DC as long as it meets the requirements of the application. Just because you can does mean that you should. The resources, memory and cpu, your DC's will require must be maintained at all cost. Since DNS resides on one or more of the DC's you may place an unnecessary demand on this server. ePO as an application requires you to meet minimum memory requirements. That means that you now need to look at how many systems you will be asking ePO to manage. Now that you have a number remember that all of these systems will be communicating to ePO on your DC. That means that deployment task, policies and the master repository will reside on your DC. That equals any and all products that these systems will require and draw them from your DC unless you add distributed repositories.


            I have gone into environments where someone has done this and they have regreted the decision. A roll of the dice on whether a user will suffer by not being able to login because your DC is underrated now that you have ePO installed on it. You now need to consider your node count and make the determination if you plan to use the SQL Express (SQL Lite) from the application. If your answer is yes, don't do it. SQL on your DC? If you go the full SQL route you now have unnecessary communication to an external SQL server and that just doesn't make sense in a DC scenario. With virtualization being so common today I would spin up a separate server, if possible, join your domain and do it the right way.


            In closing I circle back to my original comment. Just because you can doesn't mean that you should.