With the introduction of Exchange 2013, Microsoft has removed the Exchange Management Console (EMC) and replaced it with the web-based Exchange Admin Center (EAC). The EAC is a web based management console, which makes a lot of sense considering the large cloud implementations that Microsoft has with Office 365. Moving from a thick client to a web client allows for more portability and management from anywhere. The EAC is published through the ECP virtual directory on an Exchange 2013 CAS server. The ECP also allows users to access their options in Outlook Web Access. So if you've published OWA on the internet using Exchange 2013, then you probably have also published the EAC on the internet. If that doesn't seem like a great idea to you, read past the break to see how it can be resolved.
Microsoft does provide a way to disable access to the EAC on a given CAS server. The document for that is right here. To summarize, you run a Set-EcpVirtualDirectory command and set the AdminEnabled property to False. The ECP virtual directory will still allow users to access their options in OWA, but it will not allow access to the EAC. Of course that means that you no longer have access to the EAC as well, so I hope you like PowerShell! Microsoft recommends setting up an additional CAS server for EAC access only, if you don't have an internal only server already. That seems a bit onerous and hamfisted to me. There should be a more elegant solution, and lo and behold there is. The solution is to add a second website to the CAS server and create an ECP and OWA virtual directory in that new website.
The steps for it are not necessarily obvious, so I have laid them out here:
- Add a second IP address to the Exchange 2013 CAS server
- Create the folder in this path %SystemDrive%\inetpub\wwwroot2
- Create a second website in IIS pointed to the wwwroot2 folder and call it CustomEAC
- Bind the website on ports 80 and 443 to the new IP address
- Create a new ECP virtual directory using the command
New-EcpVirtualDirectory -Server ServerName -WebSiteName "CustomEAC" -InternalUrl "https://eac.fqdn.com/ecp"
- Create a new OWA virtual directory with this command
New-OwaVirtualDirectory -Server ServerName -WebSiteName "CustomEAC" -InternalUrl "https://eac.fqdn.com/owa"
- Set the original ECP virtual directory to restrict admin access with this command
Set-ECPVirtualDirectory -Identity "ServerName\ecp (default web site)" -AdminEnabled $false
- Edit the IP Address restrictions to only allow access to the EAC website from the internal subnets
- Add a host record in DNS for the new EAC URL
If you are using a wildcard certificate then you can use the new eac.fqdn.com URL and not get a certificate error, otherwise you will get a certificate error when going to the website. If you have an internal CA, you could always get an SSL certificate for that URL since it's for internal use only anyway. The other option is to use non-standard ports for the second website, but continue to use the original IP Address. For instance you could use 8080 and 8443 for the bindings, and still use the original URL. That would avoid the certificate error issue as well. The question becomes whether you want to remember the alternate ports you used, or the new URL.
I have tested this with Exchange 2013 SP1 and it seems to work without issue. If you come across any problems, give me a holler in the comments!
Labels: Exchange 2013, Microsoft, powershell, Scripts