Right from Exchange 2013, Exchange Administrative Center is integrated with Exchange Control Panel (ECP) and is available practically from every location on the network (LAN, Internet) until we disable them.

Right after the new Exchange deployment in any environment, it is very important to disable the external ECP access on the servers.

Options

Below are the options available to disable the EAC:

  1. We can install one more CAS server for internal ECP access only and do not add them in the LB which will consume another server just for this functionality alone.
  2. Install a second website with ECP and OWA virtual directories on the internet-facing CAS. We need to assign a second IP address to our server on the second network adapter installed on a CAS server. This is painful to maintain after the every CU updates.
  3. Use IIS IP and domain restrictions in Windows server 2012 to limit access only to /ecp on internal IPs. By doing this we can allow only hosts in the required subnet range to access the ECP.

But in Exchange 2013 restricting ECP will stop the users to access the ECP features in OWA (OWA options) like they have to manage out of office, delivery reports, manage mobile devices etc. All these end users OWA ECP features will be blocked.

If access is turned off in Exchange 2013 we will receive this below message:

404 – website not found error

But from Exchange 2016 disabling the EAC on the Exchange Server 2016 will not disable the ECP end user level functionality completely. All the end user mailbox level OWA ECP functionality still remains available.

Which means the end user ECP design functionality has been changed from Exchange 2016 which is good for us.

Having all the options above to restrict EAC from an external network a colleague came up with one good option which was nice and is worth sharing in this post.

Let's take an example scenario where three Mailbox Exchange 2016 servers load balanced to accept all the external client connections.

Below is the diagram on which we can configure the probes for ECP access only on two servers to accept the ECP connections and the remaining one we keep them disabled.

EAC

Benefits

Benefits of doing this:

  1. External end user OWA ECP requests will reach mailbox 2 and mailbox 3 and will serve the OWA ECP options along with all other client requests for the users.

    We need to run this command on Mailbox 2 and Mailbox 3 so that the Admin EAC is disabled on them.

    Set-ECPVirtualDirectory -Identity "mailbox2\ecp (default web site)" -AdminEnabled $falsePVirtualDirectory -Identity "mailbox3\ecp (default web site)" -AdminEnabled $false

    After running this command the load balancer will send only the OWA ECP (OWA options) requests to mailbox 2 and mailbox 3. Mailbox 1 will not participate in serving the OWA ECP  OWA options)  requests for the clients while it will serve all other requests like activesync, mapi, autodiscover, oab, etc..,

  2. We are actually utilizing all the resources of the Exchange 2016 Mailbox 1 servers to accept all client connections except for ECP requests.

    On Mailbox 1 what we are doing is having the EAC admin access always enabled. But we are not including the ECP component participation in the load balancer in serving the clients.

    So we are disabling the ECP health check alone on the mailbox 1 server in this example:

    EAC2

    This component we are disabling because the load balancer should send all the other requests to this server to serve the clients while it will not send any ECP requests to this server.