URGENT: Patch your Exchange Servers NOW!

UPDATE: Microsoft updated it's Microsoft Safety Scanner Tool (MSERT) to scan for malicious files that may be dropped on your Exchange Servers by the latest CVE vulnerabilities. 

You can run this on any Windows server. Run a Full Scan which will scan all files and folders, even those excluded by antivirus. The tool will automatically remove malicious files and, if any were found, prompt for restart to finish up.

THIS TOOL IS NOT A REPLACEMENT FOR THE SECURITY PATCHES. UPDATE YOUR EXCHANGE SERVERS.

See very bottom of Microsoft Exchange Server Vulnerabilities Mitigations – updated March 6, 2021 – Microsoft Security Response Center for info about MSERT.

Direct link to MSERT tool: Microsoft Safety Scanner Download - Windows security | Microsoft Docs

Yesterday Microsoft posted a blog article, Released: March 2021 Exchange Server Security Updates, for a serious zero-day vulnerability in Exchange Server.

URGENT! PLEASE INSTALL THESE SECURITY UPDATES ASAP!  <--Click here

The security update addresses a vulnerability that was released publicly on the web and every script kiddy is playing around with it.

Important Things to Know

• The vulnerability affects ALL versions and update levels of Exchange.
• The attack starts with an unauthenticated request to an Exchange server, so if your Exchange Server is not publicly accessible, less risk can be assumed. You're still open to internal attacks, though. PATCH YOUR SERVERS.
• Security updates have been released for the following Exchange versions and Cumulative Update levels:
• Exchange 2010 SP3
• Exchange 2013 CU23
• Exchange 2016 CU18
• Exchange 2016 CU19
• Exchange 2019 CU7
• Exchange 2019 CU8
• If your Exchange Servers are not at these CU levels, you need to get on the latest CU for your version before you can install the security update.
• Be aware the .NET Framework and Visual Studio C++ runtime prerequisites may be required to update your server to the latest CU. The Exchange CU setup will block installation until the prerequisites are satisfied.
• .NET Framework installations and updates can peg your CPU for a while after restarting. Plan accordingly.
• You MUST run the security update from an ELEVATED CMD prompt. Admins who ignore this have reported that it breaks ECP.
• Hybrid customers are affected, as well. Apply these updates to your hybrid management servers.

Best Practices

• Apply the patches ASAP.
• Always restart the Exchange server BEFORE you install the security updates or upgrade the CU. That way you know that the server reboots properly before you install the updates. It also releases any locked files.
• The update normally takes 15-20 minutes to install. Always restart the Exchange Server AFTER installing the security updates or upgrading the CU (whether it prompts you to, or not). I find that it doesn't warn you to restart about 50% of the time on the dozen or so servers I've upgraded.
• Do not "batch" updates. For example, don't upgrade Exchange 2016 CU17 to CU19 and immediately install the security patch without rebooting. Restart Exchange Server after every update.
• Always keep your Exchange Server up to date with the latest (or second to latest) CU so you can more easily install urgent updates like these.

Helpful Tips

Run the following from an elevated PowerShell or EMS console so you can right-click an MSI or MSP file and "Run as Administrator":

New-ItemProperty registry::HKEY_CLASSES_ROOT\Msi.Patch\shell\runas\command -Name "(Default)" -Value '"%SystemRoot%\System32\msiexec.exe" /p "%1" %*' -PropertyType ExpandString -Force

New-ItemProperty registry::HKEY_CLASSES_ROOT\Msi.Package\shell\runas\command -Name "(Default)" -Value '"%SystemRoot%\System32\msiexec.exe" /p "%1" %*' -PropertyType ExpandString -Force

Use the following PowerShell script to check for compromise. Run elevated. This script does not work on Exchange 2010.

Start-Transcript -Path "Check-Compromise-$env:COMPUTERNAME.log" -Force

Write-Host "Checking for CVE-2021-26858 exploitation..."

findstr /snip /c:"Download failed and temporary file" "%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\OABGeneratorLog\*.log"

Write-Host "Checking for CVE-2021-26857 exploitation..."

Get-EventLog -LogName Application -Source "MSExchange Unified Messaging" -EntryType Error | Where-Object { $_.Message -like "*System.InvalidCastException*" }

Write-Host "Checking for CVE-2021-27065 exploitation..."

Select-String -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\ECP\Server\*.log" -Pattern 'Set-.+VirtualDirectory'

Write-Host "Checking CVE-2021-26855 exploitation..."

$logs = (Get-ChildItem -Recurse -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy" -Filter '*.log' -ErrorAction SilentlyContinue).FullName | sort -Descending

$logCount = $logs.Count

foreach ($log in $logs) {

$i++

$percentage = $i / $logCount * 100

$perc = $percentage.ToString("#")

Write-Progress "Search in progress" -Status "$perc% Complete:" -PercentComplete $percentage

Import-Csv -Path $log -ErrorAction SilentlyContinue | Where-Object { $_.AuthenticatedUser -eq "" -and $_.AnchorMailbox -like 'ServerInfo~*/*' } | select DateTime, AnchorMailbox

}

Stop-Transcript

Review the Check-Compromise-<computername>.log file for results. You can ignore any errors that say something like, "The member '40' is already present." See HAFNIUM targeting Exchange Servers with 0-day exploits for more details.

If your update fails for some reason, you may find that all the Exchange services are stopped and disabled. If you try to rerun the update it will fail again for this reason. Run the following to return the Exchange service to automatic, then reboot and try again ELEVATED.

Get-Service -Name MSExchangeDelivery, MSExchangeRepl,MSExchangeRPC,MSExchangeFastSearch, MSExchangeThrottling, wsbexchange,MSExchangeSubmission, MSExchangeMailboxReplication, MSExchangeMailboxAssistants, MSExchangeIMAP4BE, MSExchangeImap4, MSExchangeIS, MSExchangeDagMgmt, MSExchangeDiagnostics, MSExchangeFrontEndTransport, MSExchangeADTopology, MSExchangeAntispamUpdate, MSExchangeUM, MSExchangeEdgeSync, MSExchangeHM, MSExchangeHMRecovery, MSExchangeServiceHost, MSExchangeTransport, MSExchangeTransportLogSearch, FMS, HostControllerService, winmgmt, remoteregistry, w3svc, iisadmin | Set-Service -StartupType automatic

Whenever a new version of .NET Framework is installed or a .NET Framework update is applied, the server CPU will peg at 90-100% utilization after reboot for up to 40 minutes while it recompiles MOFs. This process is also called NGEN. You will see mscorsvw.exe processes chewing up CPU. The same happens after you install an Exchange update, since Exchange Server is written in .NET.

Use the 7318.DrainNGenQueue.wsf script to speed up .NET Framework recompiling performance by allowing it to use multiple threads and up to 6 cores. Run it after any .NET Framework installation or update.

Read more ...

Keep your Exchange Federation Trust up-to-date

From time to time, Microsoft refreshes the certificate used by the Microsoft Federation Gateway service in Office 365. They just did this again on July 5, 2019. The MFG is the trust broker used by hybrid organizations and by other on-premises orgs that share free/busy information between them. Most Exchange configurations will update the federation trust metadata automatically, but if your on-premises org is running Exchange 2010 or Exchange 2013 on Windows Server 2008 you will need to update this manually.

Begin by testing to see if the metadata is up-to-date in your org by running the Test-FederationTrust cmdlet in EMS from one of your Exchange servers. The cmdlet normally does not require any switches to run.

Exchange will check AD to confirm that the Federation Trust configuration object exists and is valid, the Token Issuer certificate is valid, and then request a delegation token from the MFG. Here's what a good test looks like in Exchange 2010:

Test-FederationTrust from Exchange 2010

Exchange 2013+ performs a few more detailed tests using a built-in test account:

Test-FederationTrust from Exchange 2013

If you see any validation errors, such as the following error, you will need to update your MFG refresh token manually:

Id : TokenValidationType : ErrorMessage : Failed to validate delegation token.

You can update AD with the latest Microsoft Federation Gateway certificate one time by running the following cmdlet from EMS on any Exchange server in your org:

Get-FederationTrust | Set-FederationTrust –RefreshMetadata 

Once updated, run the Test-FederationTrust cmdlet again to confirm the validation and delegation token is valid.

If you want to automate this process, you can create a scheduled task on one of your Exchange servers to update the federation trust once per day. Nothing will actually update in your environment unless Microsoft updates their MFG certificate. Run the following from an elevated CMD prompt or EMS window to create the scheduled task:

Schtasks /create /sc Daily /tn FedRefresh /tr "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -command Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.E2010;$fedTrust = Get-FederationTrust;Set-FederationTrust -Identity $fedTrust.Name -RefreshMetadata" /ru System

Remember, you will only need to do this if your organization runs Exchange 2010 or Exchange 2013 on Windows Server 2008. Later versions of Windows allows Exchange to update the federation trust certificate automatically.

Read more ...

How to Uninstall Antispam Agents on Exchange Servers

UPDATE: The Exchange Team posted an article about this issue today. See Exchange Server Edge Support on Windows Server 2016 Update.

Microsoft announced that they were deprecating support for the SmartScreen spam content filter for Exchange Server in September 2016. See the article, Deprecating support for SmartScreen in Outlook and Exchange for full details.

All that is supposed to mean is that Microsoft is no longer producing anti-spam signatures for Exchange, but I discovered today that the Microsoft Exchange Transport service would not start on my Exchange 2016 Edge Transport servers after a servicing reboot. These Edge servers are running on Windows Server 2016. The Application event log shows the following error:

Log Name:      Application
Source:        MSExchangeTransport
Date:          3/17/2017 2:59:07 PM
Event ID:      16023
Task Category: Configuration
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      mail.contoso.com
Description:
Microsoft Exchange couldn't start transport agents. The Microsoft Exchange Transport service will be stopped. Exception details: Failed to create type 'Microsoft.Exchange.Transport.Agent.ContentFilter.ContentFilterAgentFactory' from assembly 'C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\Hygiene\Microsoft.Exchange.Transport.Agent.Hygiene.dll' due to error 'Exception from HRESULT: 0xC0630005'...

The highlighted section in the error log indicates the problem is with the content filter, which is one of the antispam agents installed with the Install-AntispamAgents.ps1 PowerShell script. Whenever the MSExchangeTransport service is started, the service stops again within a minute and this event is logged.

The fix for me is to remove the content filter transport agent on the Exchange server(s) where the antispam agents are installed. Run the Get-TransportAgent cmdlet from the Exchange Management Shell to see if the antispam agents are installed. These transport agents include the Content Filter Agent, Sender Filter Agent, Sender ID Agent, and Protocol Analysis Agent.

To uninstall these agents use the Uninstall-TransportAgent cmdlet. For example,

Uninstall-TransportAgent -Identity "Content Filter Agent"
Uninstall-TransportAgent -Identity "Sender Id Agent"
Uninstall-TransportAgent -Identity "Content Filter Agent"
Uninstall-TransportAgent -Identity "Protocol Analysis Agent"

For me, all I really needed to uninstall as the Content Filter Agent to get the Transport Service to start.

Once you've uninstalled them you need to restart the Transport Service:

Restart-Service MSExchangeTransport

This will start the Microsoft Exchange Transport Service if it was already stopped and you're back in business. Of course, you still need a good antispam service for on-prem. I use Exchange Online Protection (EOP) which works very well for me and most of my customers.

Read more ...

Fix for Performance Counter Updating Error (Event 106) on Exchange Servers

You may see multiple warnings or errors in the Application event log on Exchange servers for event 106, indicating that performance counters could not be updated.

Multiple Event ID 106 - Perf Counter Events

An example event 106 reads,

Log Name:      Application
Source:        MSExchange Common
Date:          11/29/2016 12:24:28 PM
Event ID:      106
Task Category: General
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      EX16B.contoso.com
Description:
Performance counter updating error. Counter name is Percentage of Failed Offline GLS Requests in Last Minute, category name is MSExchange Global Locator OfflineGLS Processes. Optional code: 3. Exception: System.InvalidOperationException: The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.
   at System.Diagnostics.PerformanceCounter.InitializeImpl()
   at System.Diagnostics.PerformanceCounter.get_RawValue()
   at Microsoft.Exchange.Diagnostics.ExPerformanceCounter.set_RawValue(Int64 value)

The TechNet article, "'Performance counter updating error' after you install an Exchange Server 2013 cumulative update", indicates this is a problem on Exchange 2013 after applying a CU, but I've seen this happen after applying an update rollup, cumulative update, or .NET Framework update on Exchange 2010, Exchange 2013, or Exchange 2016 servers.

I wrote the following PowerShell script to reload the Exchange performance counters. You run it directly on the affected Exchange server from an elevated PowerShell or EMS prompt. The script will reload all the performance counters in the %ExchangeInstallPath%\setup\perf directory.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Setup
$perfcounters = Get-ChildItem "$env:ExchangeInstallPath\Setup\Perf\" *.xml | Where-Object {!($_.psiscontainer)}
$perfcount = $perfcounters.Count

foreach ($perfcounter in $perfcounters) {
New-PerfCounters -DefinitionFileName $perfcounter.FullName -ErrorAction SilentlyContinue
Write-Progress -Activity "Reloading $perfcount Exchange Performance Counters" -PercentComplete (($i++ / $perfcount) * 100)}

The script may take a few minutes to run and will reload all the Exchange performance counters. Once complete, the event 106 warnings or errors should stop.

Read more ...

New Set-AutodiscoverSCP v2 script is on the TechNet Gallery

Set-AutodiscoverSCP.ps1

I just published version 2.0 of my Set-Autodiscover.ps1 script to the TechNet Gallery. This is a complete rewrite of the old script and includes the following new features:

• Made setting the new values easier by cloning an existing server
• Now also configures Outlook Anywhere and all Exchange virtual directory internal and external URLs
• Revised verbiage and use *-ClientAccessService cmdlets for Exchange 2016
• Added -Verbose output to display the values we're configuring
• Improved overall display output

These changes are intended to make the script more powerful and easier to use.

---

How many times have you installed a new Exchange 2010-2016 server only to hear users complain about a security pop-up in Outlook referencing the new server?

This happens because Exchange setup uses the FQDN of the server as the service connection point (SCP) that Outlook clients use for autodiscover requests (for example, https://exch03.contoso.local/autodiscover/autodiscover.xml). This new SCP is configured in Active Directory when the Front-End Client Access role is installed during setup. In most load balanced environments the valid SCP should be something like https://autodiscover.contoso.com/autodiscover/autodiscover.xml. Outlook will prompt users with a security warning because the self-signed Exchange certificate installed by setup is not trusted. If the new server is Internet-facing, ActiveSync clients can also get security warnings on their mobile device.

Read Exchange Active Directory Deployment Site for more information about this behavior.

I wrote a script, Set-AutodiscoverSCP.ps1 (available on the TechNet Gallery), that automatically updates the SCP, Outlook Anywhere FQDNs, and all the virtual directory internal/external URLs for the server your specify to match the values currently configured on another server you specify as soon as the new server is detected in AD. It continually polls Active Directory until it finds the new SCP value and sets the new values. A progress bar indicates that the script is polling AD.

The script is intended to run on another Exchange server in the org running the same version of Exchange as the new server. This is because Exchange 2010 cannot update SCP values for Exchange 2013 or 2016, and vice versa. You can also have the script target a particular domain controller. This is useful when the new server you are installing is in a different AD site.

The syntax for Set-AutodiscoverSCP.ps1 is:

Set-AutodiscoverSCP.ps1 [-Server] <String> [-ServerToClone] <String> [[-DomainController] <String>] [<CommonParameters>]

Two examples of usage:

PS C:\>Set-AutodiscoverSCP.ps1 -Server exch02 -ServerToClone exch01

Example #1 continually queries the current configuration domain controller until it finds an SCP for server EXCH02 and then sets it to match the SCP of EXCH01. It also configures Outlook Anywhere and the internal/external virtual directory URLs to match those found on EXCH01.

PS C:\>Set-AutodiscoverSCP.ps1 -Server exch02 -ServerToClone exch01 -DomainController dc03

Example #2 is almost the same as the command in the previous example, except it continually queries DC03 for the SCP record and configures it on that domain controller. This is useful when configuring a new Exchange server in a different Active Directory site.

The script is designed to be run during installation. Normally, you would run this script from an existing Exchange server of the same version while the new server is being installed.

You can also run the script directly from the server that is being installed. This is useful when you're installing the first Exchange 2013/2016 server in a 2010 environment. You can start running the script on the new server when the Client Access Front End Service is being installed. The caveat is that setup restarts IIS and web services several times during setup, causing the script to possibly stall during configuration of the virtual directories. If that happens, simply CTRL-C to quit the script and run it again.

I've included error handling for the following conditions:

1. The script notifies you what version of Exchange is running the script and warns you to make sure the new server is running the same version. Note that Exchange 2013/2016 servers can update each other. This warning really only applies to Exchange 2010 and Exchange 2013/2016 coexistence. 
2. The script checks that the server, server to clone, and the domain controller (if specified) are pingable. If the servers cannot be pinged, the script will terminate.
3. If a domain controller is specified, it validates that the DC specified is actually a domain controller

Set-AutodiscoverSCP.ps1 is a useful addition to your Exchange toolbox. Please let me know if you have any questions or feature requests. I'll update the script again on the TechNet Gallery as needed.

Read more ...

Turn Exchange Anonymous Relay On or Off with Toggle-ExternalRelayReceiveConnectors.ps1

Toggle-ExternalRelayReceiveConnectors.ps1

I wrote this PowerShell script to make it easy to identify and toggle anonymous relay rights on any of your organization's front-end Receive Connectors.

Most organizations require SMTP relays to internal and external recipients. This allows application servers and appliances, such as copier/scanners, to email messages to those recipients. An internal relay allows these devices to email internal (local) recipients. An external relay allows these emails to also be sent to external recipients outside the organization, such as joe@gmail.com.

It's fairly easy to setup an internal relay in Exchange - just create a new frontend receive connector, specify the IP addresses that can use this connector, and set security to allow Anonymous Users to connect to this receive connector, as shown below.

However, if you try to send an email to any SMTP address outside the organization, the relay connector will reject it with one of these errors (or similar):

550 5.7.1 Unable to relay

-or-

550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain

In order to configure the relay connector to allow sending to remote domains, you need to configure an extended right for Anonymous Users similar to this lengthy cmdlet:

Get-ReceiveConnector "Relay" | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights ms-Exch-SMTP-Accept-Any-Recipient

Trying to determine whether this setting has already been configured on a particular receive connector can be even more challenging. That's why I wrote the script Toggle-ExternalRelayReceiveConnectors.ps1.

The script will display a numbered list of all the front end receive connectors that exist in the entire organization. Connectors with the Anonymous/ms-Exch-SMTP-Accept-Any-Recipient right configured are listed in Yellow. All other connectors are listed in White. Simply enter the number of the connector you wish to toggle and press Enter. If it was off, it will turn it on. If it was on, it will turn it off. It's that simple!

Toggle-ExternalRelayReceiveConnectors.ps1 can be found in the TechNet Gallery.

Read more ...

Chrome Browser Now Warns About Weak SHA-1 Certificates

*** ACTION REQUIRED ***

The Google Chrome web browser is now warning users if Outlook on the web (OWA) or other websites are using SHA-1 SSL certificates.

These certificates are no longer considered secure and should be replaced ASAP. Please read my article, "Is Your Organization Using SHA-1 SSL Certificates?" on Windows IT Pro for more information and steps you should take.

SHA1 certificates are being sunsetted by January 1, 2017. These certs should be replaced or re-keyed with SHA256 certs to improve security and prevent outages.

Read more ...

Don't Delete or Rename the Default MRM Policy

I was troubleshooting an issue with an Exchange 2013 customer where their "Default Archive and Retention Policy" was not being automatically applied to archive-enabled mailboxes. Admins could manually apply the policy, but they wanted it applied automatically when the mailbox is enabled for an in-place archive or Exchange Online Archiving.

It turns out that the only retention policy that will be automatically applied is one named "Default MRM Policy". That name is hard-coded into the product, so if you delete it all you need to do is recreate it with that same name to make it the default policy. There is no property for that policy that makes it the default. It's just the name.

Here's some of the back story. Exchange 2007 introduced Managed Folders, which was an early form of retention management, but it was rather clumsy to work with. Exchange 2010 SP1 and later uses message records management (MRM) policies and policy tags. MRM policies are collections of policy tags that tell Exchange server how manage mail data. Some tags apply by default, such as the "Default 2 year move to archive" tag. Others are personal tags that users can chose to apply to one or more mail items, or entire folders, such as "1 Year Delete". Exchange setup creates the "Default MRM Policy" which includes a default set of policy tags.

The Default MRM Policy does not actually apply to any mailboxes by default, unless the the mailbox is given an archive mailbox. At that time, Exchange looks for an MRM policy named, "Default MRM Policy" and automatically applies it to the mailbox. If the Default MRM Policy does not exist, no retention policy is applied.

If you want to apply a different MRM policy you need to manually update the retention policy in the EAC (Mailbox User > Mailbox Features < Retention Policy - see above) or from EMS:

Set-Mailbox <username> -RetentionPolicy "Sales Dept MRM Policy"

For hybrid customers and those using Exchange Online Archiving, you manage MRM policies for on-prem mailboxes on-prem. The policy settings for these mailboxes will sync to Exchange Online with the DirSync process and will be applied to the online archive mailbox.

If a user mailbox and archive mailbox are both in the cloud, you will apply the cloud version of the Default MRM Policy in Office 365. Here, you should configure the Office 365 version of the Default MRM Policy to match the same settings as on-prem.

Read more ...

Set-AutodiscoverSCP.ps1 script is now on the TechNet Gallery

UPDATE: This script has been significantly updated and enhanced. Please read New Set-AutodiscoverSCP v2 script is on the TechNet Gallery

How many times have you installed a new Exchange 2010-2016 server only to hear users complain about a security pop-up in Outlook referencing the new server?

This happens because Exchange setup uses the FQDN of the server as the service connection point (SCP) that Outlook clients use for autodiscover requests (for example, https://exch03.contoso.local/autodiscover/autodiscover.xml). This new SCP is configured when the Front-End Client Access role or components are installed during setup. In most load balanced environments the valid SCP should be something like https://autodiscover.contoso.com/autodiscover/autodiscover.xml. Outlook will prompt users with a security warning because the server FQDN is not on the Exchange certificate and it is not trusted.

 

Older versions of Outlook (~Outlook 2010 RTM and earlier) used to use the oldest SCP value in the AD site, but newer versions use the newest SCP for foreground and background Autodiscover requests, causing these errors.

I wrote a script, Set-AutodiscoverSCP.ps1 (available in the TechNet Gallery), that automatically updates the SCP for the server your specify to the value you provide as soon as the new SCP for that server is detected in AD. It will continually poll Active Directory until it finds the new SCP value and sets it to the one you specify. A progress bar indicates that the script is polling AD.

The script is intended to run on another Exchange server in the org running the same version of Exchange as the new server. This is because Exchange 2010 cannot update SCP values for Exchange 2013 or 2016, and vice versa. You can also have the script target a particular domain controller. This is useful when the new server you are installing is in a different AD site.

The syntax for Set-AutodiscoverSCP.ps1 is:

Set-AutodiscoverSCP.ps1 [-Server] <String> [-NewSCP] <String> [[-DomainController] <String>] [<CommonParameters>]

Two examples of usage:

PS C:\>Set-AutodiscoverSCP.ps1 -Server exch01 -NewSCP https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Example #1 continually queries the local Active Directory domain until it finds an SCP for server EXCH01 and then sets that SCP to https://autodiscover.contoso.com/autodiscover/autodiscover.xml.

PS C:\>Set-AutodiscoverSCP.ps1 -Server exch01.contoso.local -NewSCP https://autodiscover.contoso.com/autodiscover/autodiscover.xml -DomainController dc03.contoso.local

Example #2 is almost the same as the command in the previous example, except it continually queries DC03.CONTOSO.LOCAL for the SCP record and configures it on that domain controller. This is useful when configuring the SCP for a new Exchange server in a different Active Directory site.

I’ve included error handling for the following conditions:

1. The script notifies you what version of Exchange is running the script and warns you to make sure the new server is running the same version. Note that Exchange 2013/2016 servers can update each other. This warning really only applies to Exchange 2010 and Exchange 2013/2016 coexistence. 
2. The script checks that the server you want to configure is pingable. If the server cannot be pinged, the script will terminate.
3. If a domain controller is specified, it validates that the DC specified is actually a domain controller

Set-AutodiscoverSCP.ps1 is a useful addition to your Exchange toolbox. Please let me know if you have any questions or feature requests. I'll update the script on the TechNet Gallery as needed.

Read more ...

Fix for MSExchange Unified Messaging Event ID 1423 "A TLS API failure occurred. Error = 0x80090331"

I was working with a customer who is implementing Unified Messaging in an Exchange 2013 CU7 environment with Lync 2013. All Exchange servers are running on Windows Server 2012 R2. Exchange UM was configured properly, including setting the Unified Messaging Call Router and Unified Messaging services to "Dual" and configuring valid SSL certs for both UM services. The dial plans and Auto Attendants were created and they started to test.

Calls made to the UM enabled user would go to voicemail, the greeting would play, and the caller could record a voicemail, but the voicemail would not be delivered to the UM user's mailbox. We turned up UM logging using the following cmdlet:

Get-EventLogLevel "msexchange unified*" | Set-EventLogLevel -Level Expert

Another voicemail test showed the following MSExchange Unified Messaging event ID 1423 - A TLS API failure occurred. Error = 0x80090331.



A quick look in the %ExchangeInstallPath%\UnifiedMessaging\voicemail folder on the mailbox server hosting the UM user's mailbox showed all the voicemail WAV files queued for delivery.

I'm familiar with error code 0x80090301 on this event ID, which is caused by too many root certificates in the Trusted Root Certification Authorities store, but this code and error sting is different. 0x8009331 means, "SEC_E_ALGORITHM_MISMATCH - The client and server cannot communicate, because they do not possess a common algorithm." Definitely sounds like a TLS negotiation problem.

After double-checking the UM configuration and the SSL certificate configuration used by the UM services it was found that TLS 1.0 was disabled for clients on the Exchange 2013 servers. The registry key HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client\DisabledByDefault was set to 1. This key doesn't exist by default and was not being configured via GPO, so it must have been configured in their server build. Setting the value to 0 (or deleting the DisabledByDefault key) fixed the problem.

The problem occurred because the UM server acts as both a client and a server to itself. The UM service acts as a client when it reads the voicemail WAV files from the voicemail folder and uses TLS to do so.

Note that there were several improvements to TLS and SSL in Exchange 2013 CU8 and Exchange 2010 SP3 RU9. These versions support TLS 1.1 and 1.2, which should also work. Please read Scott Landry's excellent article, Exchange TLS & SSL Best Practices, for more information.

Read more ...

How to Create Dynamically Adjusting Exchange Retention Policies

Exchange has supported message retention policies since Exchange 2010. Retention Policies are collections of Retention Tags that dictate how emails are retained in Exchange. Usually this is done to comply with business policies on data retention and/or used as a way to move data from the user's primary mailbox to an archive mailbox.

Retention Policies

The retention policy shown above includes several personal policy tags and one default policy tag that moves emails older than 6 months to the archive. You can customize or create new retention policies for your users based on your company's data retention policies. For example, you can create a retention policy to move all emails to the archive mailbox after 1 year and permanently delete all emails older than 5 years.

Only one mailbox retention policy can be assigned to a mailbox at a time. While you can easily change which retention policy is assigned to a mailbox using the the Exchange Management Shell or the Exchange Admin Center, this can be somewhat tedious.

Note that retention tags are time-based, not size-based. If you're trying to manage your mailbox storage with retention policies the same time-based retention policy may result in widely varying mailbox sizes within the Exchange database store, depending on the user. I developed the following process to dynamically adjust user's retention policy based on mailbox size. The larger the mailbox gets, the more aggressive the retention policy applied.

Start by creating multiple default archive and/or delete retention tags. Make sure to select "applied automatically to entire mailbox (default)" to ensure that it applies to all email items. For example,

• Default one year move to archive
• Default 6 months move to archive
• Default 3 months move to archive
• Default 7 year delete
• Default 5 year delete
• Default 3 year delete

Creating a Default retention tag

Next create multiple retention policies that include the default retention tags you created. For example,

• High Retention - Default one year move to archive, Default 7 year delete
• Medium Retention - Default 6 months move to archive, Default 5 year delete
• Low Retention - Default 3 months move to archive, Default 3 year delete

Apply the High Retention policy to all mailboxes using the following EMS command:

Get-Mailbox -ResultSize unlimited | Set-Mailbox -RetentionPolicy "High Retention"

Note that archive retention tags only apply if the mailbox has an archive mailbox, otherwise the archive tags are ignored.

Copy the following script and save it to one of your Exchange servers in the C:\Scripts folder as Apply-RetentionPolicies.ps1:

$mbx = Get-Mailbox -ResultSize unlimited
$mbx | ForEach-Object -Process {
$size = ( Get-MailboxStatistics $_.Alias ).TotalItemSize
If ( $size -gt "10GB" ) {
  Set-Mailbox $_.Alias -RetentionPolicy "Low Retention Policy"
  }
elseif ( $size -gt "8GB" ) {
  Set-Mailbox $_.Alias -RetentionPolicy "Medium Retention Policy"
  }
else {
  Set-Mailbox $_.Alias -RetentionPolicy "High Retention Policy"
  }
}

Adjust the mailbox sizes in the script to meet your company's retention needs. In the example script above mailboxes greater than 10GB get the Low Retention Policy, mailboxes between 8-10GB get the Medium Retention Policy, and everyone else gets the High Retention Policy.

Next, create a scheduled task that runs the Apply-RetentionPolicies.ps1 script once per day.

Set the "Program/Script" property to:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

And set the "Add arguments (optional)" to:

-NonInteractive -WindowStyle Hidden -command $ep = (Get-Item env:"ExchangeInstallPath").Value; . $ep\bin\RemoteExchange.ps1; Connect-ExchangeServer -auto; . C:\Scripts\Apply-RetentionPolicies.ps1

Creating a Basic Scheduled Task

The scheduled task must run using the credentials of an account with Organization Management rights.

With this process, as a mailbox gets smaller from a more aggressive retention policy it will automatically get a longer retention policy.

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 ...