If you've already read that post, I'll summarize here. The reasons you may have for adding additional OWA/ECP virtual directories are:
- You want to separate admin and user ECP access to prevent access to the Exchange Admin Center from the Internet.
- You have different users within one organization who require a different OWA experience, such as a different Public/Private File Access or other policy or segmentation features.
The EHLO blog post does an excellent job explaining how you go about doing this. Basically, you add a secondary IP address to the Exchange 2013 server, create a new SSL website bound to that IP address, copy content from three different folders, set NTFS permissions, create new OWA and ECP virtual directories, and reconfigure the original OWA/ECP virtual directories to work as you want. Peesa cake. :)
Oh, - and this is very important - whenever you apply an Exchange cumulative update (CU) you need to completely undo everything you just did and reconfigure the settings all over again. Ugh. That's why I wrote the following PowerShell script to automate the process.
New-ExchangeWebsite.ps1 performs all the steps listed in the blog article in an automated fashion. If the script detects that an OWA_SECONDARY folder already exists, it removes that existing configuration before configuring the new website. Whenever you install the latest CU or replace the SSL certificate, all you need to do is run the script again with the proper parameters.
The goal of this script is to perform the exact same steps documented in the EHLO Blog post so you remain in a supported state. If Microsoft improves or changes these steps, I will update the script to match.
The script supports full PowerShell functionality just like a real cmdlet. For example, it supports Get-Help and -Verbose parameters.
New-ExchangeWebsite.ps1 [-NewWebsiteIP] <IPAddress> [-Thumbprint] <String> [[-DisableEacOnDefaultWebSite]<Boolean>] [[-DisableFbaOnDefaultWebSite] <Boolean>] [<CommonParameters>]
By default the script automatically disables Exchange Admin Center access and leaves Forms Based Authentication enabled on the Default Web Site.
-------------------------- EXAMPLE 1 --------------------------
PS C:\>New-ExchangeWebsite.ps1 -NewWebsiteIP 10.1.20.35 -Thumbprint 663F465DE17FD039979B8CE769118FA2A5AF157D
This command configures a new website named OWA_SECONDARY in IIS. It configures the website to use the IP address 10.1.20.35 and binds the SSL certificate with the specified thumbprint for HTTPS. It sets the necessary ACLs and copies all the required files and folders. Finally, it disables Exchange Admin Center access on the Default Web Site because that's the default setting and resets IIS.
-------------------------- EXAMPLE 2 --------------------------
PS C:\>New-ExchangeWebsite.ps1 -NewWebsiteIP 10.1.20.35 -Thumbprint 663F465DE17FD039979B8CE769118FA2A5AF157D -DisableFbaOnDefaultWebSite $true
This command is almost the same as the command in the previous example, except it also disables Forms Based Authentication on the Default Web Site.
-------------------------- EXAMPLE 3 --------------------------
PS C:\>New-ExchangeWebsite.ps1 -NewWebsiteIP 10.1.20.35 -Thumbprint 663F465DE17FD039979B8CE769118FA2A5AF157D -DisableFbaOnDefaultWebSite $true -DisableEacOnDefaultWebSite $false
This command is almost the same as the command in the previous example, except it does not disable Exchange Admin Center access on the Default Web Site.
Warning: Brain Must Be Engaged
Before you run the script, you must add a second IP address to the Exchange 2013 server and you must have a trusted SSL certificate installed with the correct FQDN for the new website (for example, eac.contoso.com or use a wildcard cert).
I wrote some basic error checking into the script. It must be run from EMS on an Exchange 2013 server, the IP address you specify must exist on the server and it must not be the only IP address, and the certificate thumbprint must be valid. If any of these conditions are not met, the script terminates. That said, you still need to be sure you specify the correct IP address for the new website and you must supply the correct SSL thumbprint (use the Get-ExchangeCertificate cmdlet for this).
If you decide to rename the folders or website after configuration all bets are off. Be smart, leave them alone.
You can download a ZIP copy of the script here. Comments? Questions? Leave them below.