Introducing New-ExchangeWebsite for Exchange 2013

Microsoft recently announced support for adding additional virtual directories for OWA and ECP to Exchange 2013. I highly encourage you to read the blog post, Configuring Multiple OWA/ECP Virtual Directories on the Exchange 2013 Client Access Server Role, to understand when this is appropriate, what it entails, and associated caveats.

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.

Syntax:

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.

Read more ...

How to Add Access to the Office 365 EOP Quarantine in Outlook and OWA

Exchange Online Protection (EOP) in Office 365 offers a quarantine feature for administrators and end-users. Administrators can view and release messages that were caught as spam for all users. End-users can view and release their own messages.

The administrative quarantine is accessed from the Office 365 Exchange Admin Center > Protection > Quarantine. Here you will see all the quarantined items for all users in the org.

Administrative Quarantine in the Office 365 Portal

The administrative quarantine is always available to EOP admins. The end user quarantine must be enabled and configured by the admin from Office 365 Exchange Admin Center > Protection > Content Filter, then click the Configure end-user spam notifications link on the right.

When enabled, end-users will receive an email from EOP listing all the new messages held in quarantine since the last notification.

The URL to the end-user quarantine is https://admin.protection.outlook.com/quarantine. In a hybrid scenario, even users without Office 365 licenses can access the end-user quarantine.

End-User Quarantine

That's all pretty cool, but wouldn't it be nice to access the quarantine directly from Outlook? Here's how you configure it:

• Open Outlook as the end-user.
• Right-click the user mailbox and select New Folder.

• Name the folder Quarantine or * Quarantine to have it placed higher in the folder list.
• Right-click the new folder and select Properties.
• Click the Home Page tab.
• Enter https://admin.protection.outlook.com/quarantine in the Address field and then click the checkbox for Show home page by default for this folder. Click OK.

• You will then see the sign on page for EOP within Outlook. After you sign in you can access your end-user archive.

End-User Quarantine within Outlook

Unfortunately you can't view the end-user quarantine using this method from OWA, but I have a work-around. 

• Send yourself an email with the subject of Quarantine and the link to https://admin.protection.outlook.com/quarantine in the body of the message.
• Drag the message from your Inbox to the Quarantine folder you created.

Now you have easy access to the end-user Quarantine from Outlook, OWA, and even mobile devices!

Read more ...

KEMP Series: How to Restrict Exchange Admin Center Access From the Internet Using KEMP VLB

This is part five in a series of articles detailing load balancing for Exchange using the KEMP virtual load balancer (VLB). In this article I will explain how to restrict Exchange Admin Center (EAC) access from the Internet using KEMP LoadMaster.

The other articles in this series are:

• Introduction to Load Balancing for Exchange and Other Workloads
• How to Configure General Settings on the KEMP Virtual LoadMaster
• How to Configure an L7 KEMP Virtual Load Balancer (VLB) for Exchange 2013
• How to Configure an L4 KEMP Virtual Load Balancer (VLB) for Exchange 2013
• How to Restrict Exchange Admin Center Access From the Internet Using KEMP VLB (this article)

My first article explains the basics of load balancing and how to download a free copy of KEMP Virtual Load Master for your home lab. I'll assume you've already configured it for Layer 7 load balancing.

Note: Since the following procedures rely on SubVSs and traffic inspection, this configuration will only work with Layer 7 load balancing. Layer 4 load balancing cannot inspect traffic and therefore cannot be used to deny access to the EAC.

The Exchange Admin Center (EAC) is the web-based management console used to manage your Microsoft Exchange Server 2013 infrastructure. As such, some customers want to block EAC access from the Internet.

The EAC is part of the ECP virtual directory and is the same virtual directory used in OWA to manage user settings, such as Out of Office settings. If you were to disable or not publish the entire ECP virtual directory to the Internet in order to block EAC access, it would prevent external users from accessing many settings from OWA.

Update: Microsoft just released a new article, Configuring Multiple OWA/ECP Virtual Directories on the Exchange 2013 Client Access Server Role, which describes how to create a separate vDir for the Exchange Admin Center. If you chose the Microsoft solution to disable Internet access to EAC (and I do, if you want Microsoft support) know that you need to follow those step EXACTLY and you will need to redo that setup after every CU. If you wish to load balance the new vDir you will also need to create new SubVSs on the KEMP LoadMaster.

Let's get started configuring EAC restrictions on the KEMP LoadMaster. Log into the LoadMaster with the bal account and navigate to Rules & Checking > Content Rules.

Add each of the following five rules. Be careful to copy and paste each rule entirely and name them "EAC_Block_1-5":

/^\/ecp/PhoneVoice*/|^\/ecp/PublicFolders*/|^\/ecp/Reporting*/|^\/ecp/Servers*/

/^\/ecp/UnifiedMessaging*/|^\/ecp/UsersGroups*/|^\/ecp/Organize/OrganizationRetentionPolicyTags*/

/^\/ecp/Organize/RetentionPolicies*/|^\/ecp/RulesEditor/JournalRules*/|^\/ecp/RulesEditor/TransportRules*/|^\/ecp/tools*/


/^\/ecp/.*Mgmt*/|^\/ecp/AcceptedDomain*/|^\/ecp/AddressList*/|^\/ecp/Antimalware*/|^\/ecp/DLPPolicy*/|^\/ecp/EmailAddressPolicy*/|^\/ecp/Federation*/

/^\/ecp/Hybrid*/|^\/ecp/Migration*/|^\/ecp/OwaMailboxPolicy*/|^\/ecp/Extension/OrgExtensions*/

To do this click the Create New button and enter the new rule name (i.e., EAC_Block_1). Paste the first rule string above into the Match String field and click the checkboxes for Ignore Case and Fail on Match. Then click the Create Rule button.

 Repeat for each of the rules above. Your rule list should now look like this:

Now expand Virtual Services > View/Modify Services and click Modify for the Exchange 2013 virtual service. Click the Add New button under SubVSs. You will see a new SubVS at the bottom of the list. Click the rule None and add the EAC_Block_1 rule to the new SubVS. Be sure to click the Add button to add it. Repeat for each of the five EAC_Block rules.

Click <-Back and then click the Modify button for the new SubVS. Name the SubVS Block EAC and click the Set Nickname button.

Expand Advanced Properties and set the Error Code to 401 Unauthorized. There is no need to enter any real servers for this SubVS.

Click <-Back and then expand Advanced Properties for the Exchange 2013 virtual service. Click the Rule Precedence button for Content Switching. You will see a list of all the rules. Click the Promote buttons to move the five EAC_Block rules so they are at the top of the list.

Now when if you try to access the Exchange Admin Center using the KEMP load balancer VIP you will still be able to logon, but cannot access any of the EAC administration parts.

End users will still be able to access their ECP settings from OWA.

If you want to access the EAC internally, simply use the FQDN of one of your CAS servers to bypass the KEMP load balancer. Alternatively, you can configure another virtual service for internal load balancing that does not use the blocking rules.

This concludes my series on configuring the KEMP virtual LoadMaster. I hope you found these articles useful.

Read more ...

KEMP Series: How to Configure an L4 KEMP Virtual Load Balancer (VLB) for Exchange 2013

This is part four in a series of articles detailing load balancing for Exchange using the KEMP virtual load balancer (VLB). In this article we will be configuring the VLB as a Layer 4 load balancer for Exchange 2013.

The other articles in this series are:

• Introduction to Load Balancing for Exchange and Other Workloads
• How to Configure General Settings on the KEMP Virtual LoadMaster
• How to Configure an L7 KEMP Virtual Load Balancer (VLB) for Exchange 2013
• How to Configure an L4 KEMP Virtual Load Balancer (VLB) for Exchange 2013 (this article)
• How to Restrict Exchange Admin Center Access From the Internet Using KEMP VLB

My first article explains the basics of load balancing and how to download a free copy of KEMP Virtual Load Master for your home lab. As a refresher, here's a brief explanation of the differences between Layer 7 and Layer 4 load balancing.

Layer 7 Load Balancing
L7 load balancing happens at the application layer. Health checks are performed on the applications (for example OWA, EWS, ActiveSync, etc.). The SSL connection must terminate on the load balancer, the content is inspected, and then re-encrypted back to the real servers. This requires that the L7 load balancer has to have an understanding of the applications being load balanced. It also usually involves some sort of persistence, such as cookie-based or source IP. Because of all this, L7 load balancing is more complex. Exchange 2010 required L7 load balancing due to the different ways that each application protocol handled persistence. Exchange 2013 does not require persistence even when using L7 load balancing.

Layer 4 Load Balancing
L4 load balancing happens at the network layer after routing is compete (Routing occurs at Layer 3). Health checks are performed on the servers, not the applications. Layer 4 load balancers do not decrypt, inspect, and re-encrypt SSL traffic. This means L4 load balancers have higher performance and are less complex, but the load balanced application must support it. Exchange 2013 CAS is designed for L4 load balancing, but also supports L7 load balancing.

In my second article I showed you how to configure the general settings for the LoadMaster. This includes configuring Ethernet settings, the Web UI, time and DNS settings, and SSL certificates. These settings are common to all types of load balancing configurations. Now I'm ready to show you how to configure the VLB as a Layer 4 load balancer for Exchange 2013. But first, I need to get some potentially confusing things out of the way.

When an incoming connection goes through a load balancer, the load balancer needs to NAT the connection to the real servers so that the reply comes back through the load balancer, otherwise the real servers will respond directly to the client and the session will break. For example, imagine you, Sally, and Tim are in the same room. You ask Sally a direct question, but Tim responds. You ignore Tim's response because it's out of order.

The computer above communicates with the VIP on the load balancer and expects the response to come from that same IP address. The only three ways to make this to happen are:

1. Use Network Address Translation (NAT) - The incoming client traffic is sent to the real server after performing address translation, which causes server to respond back to the load balancer. The load balancer then forwards the response back to the client.
2. Configure the load balancer as the Default Gateway on the real servers - This forces all outgoing traffic to external subnets back through the load balancer, but has many downsides. For example, you must size load balancer to account for all traffic for given server. While this configuration may be supported for Exchange, it isn't best practice.
3. Use Direct Server Return (DSR) - DSR is a complex load balancing method that has many drawbacks, including the inability to insert cookies or do port translation. It is not supported for Exchange or Lync deployments.

Of these options, only NAT is a viable option. In an interesting choice of wording, KEMP calls this an "L7 connection" to the load balancer. KEMP verbiage is referring to actual TCP layer functionality where the KEMP load balancer accepts the client’s TCP connection and creates a new TCP connection to the server. This is required in order to perform NAT.

While the term can be confusing, and I hope that KEMP is able to change it so it isn’t so, from an Exchange perspective this is still Layer 4 load balancing. The load balancer is not decrypting SSL connections, the client connections can still be configured to be distributed evenly in round robin fashion across the CAS servers with no affinity or persistence requirement, and the traffic is not inspected by the load balancer. As a matter of fact, the SSL certificate doesn't even need to be installed on the load balancer for this to work, which makes it truly "light weight" operation when compared to L7 load balancing which results in much higher resource requirements due to SSL decryption and re-encryption. I'm going to lengths to explain this because when you see "Force L7" in the LoadMaster configuration, I want you to understand why it doesn't translate to Layer 7 load balancing in the way Microsoft refers to it.

OK, so now that's done, let's start configuring the KEMP LoadMaster for Layer 4 load balancing Exchange 2013. There are basically two options for doing this. Option 1 configures a single VIP to load balance all virtual services for all the real servers. This is useful for home lab scenarios where you have a simple consumer-grade router and can only forward all SSL traffic to one IP address. Option 2 configures a different IP address for each virtual service on the real servers.

Note: Neither of these L4 options use the KEMP application templates. Those are only used in Layer 7 load balancing.

Option 1 - Use a Single VIP

Log into the LoadMaster with the bal account and navigate to Virtual Services > Add New. Enter the new virtual IP address, set the port to 443, and enter a Service Name. Then click the Add this Virtual Service button.

Under Standard Options, leave "Force L7" checked and uncheck "Transparency". Keep the default values for Persistence (None) and Scheduling Method (Round Robin).

Confirm that SSL Properties > SSL Acceleration is disabled (unchecked). Leave Advanced Properties and ESP Options with their default settings.

Expand Real Servers. Since we're doing L4 load balancing we cannot configure vSubs and you can only monitor one virtual server (OWA, ActiveSync, MAPI, etc.). In this example, I will monitor the OWA virtual server.

Enter /owa/healthcheck.htm for the URL to health check and click the Set URL button. Change the "HTTP Method" to GET and enter OK for the "Reply 200 Pattern". Then click the Set Pattern button.

Now it's time to add your real servers. Click the Add New button. Add the first real server's IP address and click the Add This Real Server button. Repeat for each of your real servers. When you're done click <-Back twice.

Now you will see the new Exchange 2013 virtual service that L4 load balances the real servers. Ignore the fact that it shows L7 for the Layer, as this is really only the connection type (see explanation above). Note that the SSL certificate is installed on the real servers, not the load balancer.

That's all there is for this configuration. As noted earlier, we're only monitoring the OWA virtual server on the real servers for health checks. If another virtual server, say ActiveSync, goes offline on one of the real servers the load balancer will still direct traffic to it. Likewise, if the OWA virtual server goes offline on one of the real servers that server will be marked as down and no traffic will be directed to it, even though other virtual servers may be healthy.

Option 2 - Use Separate VIPs for Each Virtual Server

This option requires nine separate VIPs on the load balancer, one for each Exchange 2013 virtual server. It also requires nine different names on the SAN certificate or use of a wildcard cert.

Log into the LoadMaster with the bal account and navigate to Virtual Services > Add New. Enter a new virtual IP address, set the port to 443, and enter a Service Name (i.e, EX2013 ActiveSync). Then click the Add this Virtual Service button.

Under Standard Options, leave "Force L7" checked and uncheck "Transparency". Keep the default values for Persistence (None) and Scheduling Method (Round Robin).

Confirm that SSL Properties > SSL Acceleration is disabled (unchecked). Leave Advanced Properties and ESP Options with their default settings.

Expand Real Servers. Enter /microsoft-server-activesync/healthcheck.htm for the URL to health check and click the Set URL button. Change the "HTTP Method" to GET. Enter OK for the "Reply 200 Pattern" and click the Set Pattern button.

Now it's time to add your real servers. Click the Add New button. Add the first real server's IP address and click the Add This Real Server button. Repeat for each of your real servers. When you're done click <-Back twice.

Repeat for each Exchange 2013 virtual server: Autodiscover, ECP, EWS, MAPI, OAB, OWA, PowerShell, and RPC. Nine virtual services in all. 

Thankfully you can make this easier on yourself by duplicating VIPs. Select a Virtual Service in View/Modify Services and click the Duplicate VIP button. Enter the new virtual IP address and click the Duplicate VIP button. Change the "Service Name" and click the Set NickName button, then change the health check URL and click the Set URL button. Rinse and repeat for each virtual server.

Note that the SSL certificate is installed on the real servers, not the load balancer.

With this configuration the load balancer will direct traffic to any available virtual server on any real server. The downside to this approach is that it requires your router to send traffic for each namespace to a different VIP and you have many more names to manage on your SSL certificates. 

This concludes the Layer 4 setup options for Exchange 2013. My final article in the series will explain how to restrict Exchange Admin Center access from the Internet.

Read more ...

KEMP Series: How to Configure an L7 KEMP Virtual Load Balancer (VLB) for Exchange 2013

This is part three in a series of articles detailing load balancing for Exchange using the KEMP virtual load balancer (VLB). In this article we will be configuring the VLB as a Layer 7 load balancer for Exchange 2013.

The other articles in this series are:

• Introduction to Load Balancing for Exchange and Other Workloads
• How to Configure General Settings on the KEMP Virtual LoadMaster
• How to Configure an L7 KEMP Virtual Load Balancer (VLB) for Exchange 2013 (this article)
• How to Configure an L4 KEMP Virtual Load Balancer (VLB) for Exchange 2013
• How to Restrict Exchange Admin Center Access From the Internet Using KEMP VLB

My first article explains the basics of load balancing and how to download a free copy of KEMP Virtual Load Master.

In the second article I showed you how to configure the general settings for the LoadMaster. This includes configuring Ethernet settings, the Web UI, time and DNS settings, and SSL certificates. These settings are common to all types of load balancing configurations. Now I'm ready to show you how to configure the VLB as a Layer 7 load balancer for Exchange 2013.

As a refresher, here's an explanation of the differences between Layer 7 and Layer 4 load balancing.

Layer 7 Load Balancing
L7 load balancing happens at the application layer. Health checks are performed on the applications (for example OWA, EWS, ActiveSync, etc.). The SSL connection must terminate on the load balancer, the content is inspected, and then re-encrypted back to the real servers. This requires that the L7 load balancer has to have an understanding of the applications being load balanced. It also usually involves some sort of persistence, such as cookie-based or source IP. Because of all this, L7 load balancing is more complex. Exchange 2010 required L7 load balancing due to the different ways that each application protocol handled persistence. Exchange 2013 does not require persistence even when using L7 load balancing.

Layer 4 Load Balancing
L4 load balancing happens at the network layer after routing is compete (Routing occurs at Layer 3). Health checks are performed on the servers, not the applications. Layer 4 load balancers do not decrypt, inspect, and re-encrypt SSL traffic. This means L4 load balancers have higher performance and are less complex, but the load balanced application must support it. Exchange 2013 CAS is designed for L4 load balancing, but also supports L7 load balancing.

Download and Install the Templates

Start by downloading the LoadMaster templates from the KEMP documentation website. Templates contain the preconfigured setups for common load balanced applications. For Microsoft products that includes Exchange 2010 / 2013, Lync 2013, ADFS 2.0, and Remote Desktop Services (RDS).

Expand Microsoft > Exchange 2013. You will see that the Exchange 2013 templates include Core Services, ESP Services, and Additional Services. Edge Security Pack (ESP) Services include security configurations for Internet facing applications, such as pre-authentication templates. The Additional Services template includes secondary client access protocols such as POP and IMAP, as well as SMTP.

Download the Core Services template to a folder on your local computer. This will be a single Exchange2013Core.tmpl file.

Log into the LoadMaster with the bal account and navigate to Virtual Services > Manage Templates. Click Choose File, browse to the Exchange2013Core.tmpl file, and click Add New Template. The LoadMaster will display the four templates you just installed.

Configure Layer 7 Load Balancing

Expand Virtual Services > Add New to begin adding a new virtual service for Exchange 2013. Enter the virtual address (VIP) for your load balanced set of Exchange 2013 CAS servers (which should be every Exchange 2013 server in the AD site - you are doing only multi-role servers, right?) If you configured a custom port (8443) in general settings, you can use the same IP address that you use to access the VLB management UI.

Select the Exchange 2013 HTTPS Reencrypted template from the dropdown list. This will automatically populate port, protocol and service name. Since I will be using SSL bridging, I changed the service name to Exchange 2013 HTTPS Bridged. Click Add this Virtual Service.

The LoadMaster will then take you to the configuration of the new service. Examine the Basic Properties. Note that here you can activate or deactivate the virtual service.

Standard Options shows that Transparency is Disabled, persistence is set to None, the load balancing method uses Round Robin, and Idle Connections timeout in 1800 seconds (30 minutes).

Expand SSL Properties and you will see the SSL certificate you installed in my General Settings article as an Available Certificate. Select that certificate and click the ">" button to move it to Assigned Certificates.

I recommend configuring the VLB to use only TLS 1.x since TLS 2.0 and TLS 3.0 connections have known vulnerabilities. Click the TLS 1.x Ciphers Only checkbox which removes all the TLS 2.0 and 3.0 ciphers, Select all the ciphers and click the ">" button to move them to Assigned Ciphers, then click the Set Ciphers button. 

We will skip the Advanced Properties, WAF Options, and ESP Options since they are not used in this implementation.

Expand SubVSs and you will see each of the sub-virtual services that the template installed. There is one for each virtual service in Exchange 2013, including ActiveSync, Autodiscover, ECP, EWS, MAPI, OAB, PowerShell, and RPC.

Next we need to add the real servers for each SubVS. Click Modify for the Exchange 2013 HTTPS Bridged - ActiveSync SubVS. Click the Add New button under Real Servers.

Add the IP address of the real server to load balance and click the Add This Real Server button. Repeat for each real server you want to add to the load balanced set.

When you're done adding real servers for this SubVS click <-Back twice to return to the list of SubVSs. Repeat adding real servers for each SubVS.

Click Virtual Services > View/Modify Services. You will see two Virtual Services are published, one for HTTP redirection to HTTPS and the other that has all the SubVSs for Exchange 2013.

If any of  the Real Servers virtual directories are listed in red, it's either because it's missing real servers or they are all down. Click Add New under Certificate Installed. Select the certificate we installed when we configured General Settings and click the ">" button to assign it. Click the Save Changes button.

I usually change the HTTP redirection service to pass-through because I favor doing this on the Exchange servers. Either way you'll need to add the real servers to this rule, as you did above.

If you want to do HTTP pass-through to the real servers click Modify for the redirect. Rename the service name to MAIL_HTTP_PassThrough and click Set Nickname. Expand Advanced Properties. Clear the Error Code and clear the Redirect URL. Expand Real Servers and select HTTP Protocol for the Real Server Check Parameters. Then configure HTTP redirection directly on the Exchange servers.

Congratulations! You have configured Layer 7 load balancing for Exchange 2013.

A Note About Home Routers and Multiple SSL Endpoints

If you're installing this setup behind a home or consumer-based router you probably have few options for port forwarding. Usually you can only configure the router to forward all HTTPS traffic to a single internal IP address, and that will usually be the VLB.

In this case, you can configure the VLB to decide which endpoint to direct SSL or any other traffic to by using a new SubVS. For example, my Hyper-V lab server hosts many VM servers including three Exchange servers and a Thycotic Secret Server. Both the load balanced Exchange servers and the Thycotic server use port 443, so we need to configure the router to send all HTTPS traffic to the VLB, and configure the VLB to handle multiple endpoints.

Configure Multiple Endpoints

Note: If you're only load balancing Exchange and don't need the load balancer to direct HTTPS traffic to other endpoints, you're done and you can skip this section.

To add another endpoint to the VLB, add a new SubVS from Virtual Services > View/Modify Services. Click the Add New button and click Modify. Then enter a name for the SubVS (i.e., SecretServer) and click Set NickName.

Enter a portion of the URL for the virtual directory on the new server (i.e., /SecretServer/Login.aspx) for the URL and click the Set URL button.

Click Add New to create the new SubVS. This will take you to the Real Server parameters page.
Enter the IP address of the real server and click Add This Real Server. Your config should look like this:

Now click <-Back to get back to the SubVSs page. You'll notice that the Rules for this new SubVS show None. We need to configure a rule for the new server.

Expand Rules & Checking > Content Rules and click the Create New button. Enter a name for the Rule, such as Secret_Server. Note that rule names cannot contain spaces.

Enter HOST for the Header Field and the FQDN of the server in the Match String field. Click the checkbox for Ignore Case and click Create Rule.

Go back to Virtual Services > View/Modify Services. Click the Modify button for Exchange 2013 HTTPS Bridged. Now click the red None button for the rule of the SecretServer SubVS. Select Secret_Server from the rules drop-down list and click the Add button.

Now the router sends all HTTPS traffic to the VLB and the VLB sends the traffic to the correct endpoint.

This concludes the Layer 7 setup for Exchange 2013. My next article will cover configuring the KEMP virtual LoadMaster as a Layer 4 load balancer. My last article will explain how to restrict Exchange Admin Center access from the Internet.

Read more ...