The Email Notification Service (ENS2) can be deployed on a cloud-hosted service or hosting your own ENS instance an on-premises installation.

The various deployment methods for ENS2 are explained in the following sections.

  • Deploying ENS2 on a Cloud-hosted Service with Office 365 or on an On-Premises Exchange
  • Deploying ENS2 on a Cloud-hosted Service with Office 365 or on an On-Premises Exchange with SEGv2 Proxy
  • Deploying On-Premises ENS2 with Office 365 or Exchange in a Single and Multidata Center
  • Deploying On-Premises ENS2 with SEGv2 as the EWS Proxy for Office 365 or Exchange in a Single and a Multidata Center
Note: Deploy ENS2 through a cloud-hosted service unless there is a specific requirement to deploy ENS2 an on-premises installation.

Deploying ENS2 on a Cloud-hosted Service with Office 365 or on an On-Premises Exchange

In this deployment scenario, the ENS2 and Office 365 are in a cloud-hosted environment. The external devices such as iOS, Android, and so on, can access the ENS2 and Office 365 through port 443 to subscribe to the ENS2 and get email notifications.

In an on-premises Exchange setup, as shown in the following topology, the on-premises Exchange server can access the ENS2 and Office 365 through port 443 to subscribe to the ENS2 and get email notifications. ENS2 and the Exchange server interact with each other over port 443 through the EWS protocol.

Deploying ENS2 on a Cloud-hosted Service with Office 365 or on an On-Premises Exchange with SEGv2 Proxy

In this deployment scenario, ENS2 and Office 365 are in a cloud-hosted environment and the ENS2 can be configured with the SEGv2 to secure your organization's email infrastructure. When an external device initiates a registration request to the ENS2, the ENS2 sends the request to SEG, and then request is routed to the Office 365. Any email exchanges or push notifications are routed through the SEG proxy.

On an on-premises setup, all traffic from the ENS2 to the Exchange is routed through the SEG v2. However, the Exchange server can directly interact with the ENS2.

Deploying On-Premises ENS2 with Office 365 or Exchange in a Single and Multidata Center

In a single data center ENS2 deployment scenario, as shown in the following topology diagram, the ENS2 is hosted on an on-premises network within the DMZ zone so that the ENS2 is publicly accessible. The external devices such as iOS, Android, and so on, have access to ENS2 through port 443 to subscribe to the ENS2 and get email notifications.

The ENS database server can be hosted on the on-premises network behind the internal firewall and the ENS2 can communicate with the ENS database through the internal firewall. The ENS database server can be scaled vertically to upgrade the capacity of the existing ENS database server.

The following topology shows the ENS2 deployed in a multidata center, where there might be more than one data center to support a failover. In every data center, for each instance of the ENS, there is always a paired instance of the ENS database and each ENS database can host their own data. In case, the data center 1 fails then the data center 2 becomes active to support failover scenarios.

Deploying On-Premises ENS2 with SEGv2 as the EWS Proxy for OFfice 365 or Exchange in a Single and a Multidata Center

In this deployment scenario, the ENS2 is hosted on-premises and the SEG is installed in between the external devices and the on-premises Exchange. All the EWS traffic coming from the external devices must pass through the SEGv2 and then reach the on-premises Exchange. However, the on-premises Exchange can directly communicate with the ENS2.

The following topology shows the ENS2 deployed in a multidata center, where there might be more than one data center to support a failover. The ENS2 is hosted on-premises and the SEG is installed in between the external devices and the on-premises Exchange. All the EWS traffic coming from the external devices must pass through the SEG and then reach the on-premises Exchange. However, the on-premises Exchange can directly communicate with the ENS2. In every data center, for each instance of the ENS2, there is always a paired instance of the ENS database and each ENS database can host their own data. In case, data center 1 fails then the data center 2 becomes active to support failover scenarios.

Difference between ENS2 Cloud-hosted Deployment and ENS2 On-Premises Deployment

The following table describes the benefits and limitations of deploying ENS2 through a cloud-hosted service and an on-premises deployment.

ENS2 Cloud-hosted Deployment ENS2 On-Premises Deployment
Benefits of deploying ENS2 through a cloud-hosted service:
  • Easiest method of deployment as no infrastructure or maintenance is required.
  • Easily scalable as you can automatically scale up to meet the increasing demands of the user.
  • ENS2 supports the Office 365 cloud strategy deployments.
 Benefits of deploying ENS2 on-premises:
  • Controls the upgrade cadence and can be deployed to the DMZ without exposing the Exchange Web Services (EWS).
Limitations of deploying ENS2 through a cloud-hosted service:
  • ENS2 requires an internet-facing or proxied EWS endpoint (can be restricted to IP ranges) and the email data flows outside the organization network.
Limitations of deploying ENS2 on-premises:
  • Requires additional manual installation and maintenance of the ENS2 and the CNS components.
  • Requires periodic updates to stay updated.
  • Environment scaling requires additional setup and maintenance.
  • High availability requires additional installation and manual resource allocation.
  • Requires additional licensing (Microsoft Windows Server and Microsoft SQL Server) and hardware.