Enabling BitLocker on Exchange Servers

The Exchange Preferred Architecture, for both Exchange Server 2013 and Exchange Server 2016, recommends enabling BitLocker on fixed data drives that store Exchange database files. Over the years, there have been a number of questions regarding how BitLocker should be enabled on servers.

However, before we discuss that, I think it is important to provide an overview of BitLocker, as I have found not many are familiar with the technology.

What is BitLocker?

BitLocker is the built-in Microsoft Windows solution for volume encryption that provides enhanced protection against data theft in form of stolen or lost computers or hard disks.

BitLocker was first introduced in Windows Vista and Windows Server 2008. Since the initial release, there have been several improvements made to BitLocker including, encrypting data volumes, encrypting only used disk space, and provisioning flexibility.

By default, BitLocker uses the AES encryption algorithm in cipher block chaining (CBC) mode with a 128-bit (default) or 256-bit key.

For more information, see the BitLocker Overview on Microsoft TechNet.

How can BitLocker be deployed?

There are multiple ways you can deploy BitLocker on Exchange servers.

  1. Encrypt the operating system volume, as well as, the Exchange data volumes utilizing either network unlock, the Data Recovery Agent and PKI infrastructure, or via TPM (recommended approach).
  2. Encrypt the Exchange data volumes only.

To use BitLocker in a FIPS-compliant manner, keep in mind:

  • Trusted Platform Module (TPM) 1.2 is not FIPS-compliant and uses SHA1. You need to use a TPM 2.0 for FIPS compliance.
  • To leverage the Network unlock feature, you need to take into account the core requirements.
  • Microsoft BitLocker Administration and Monitoring (MBAM) cannot be used to manage BitLocker on server operating systems.
  • If you are not using Windows Server 2012 R2 or later as the base operating system, then you cannot use recovery passwords for BitLocker. For more information, see What's New in BitLocker and KB 947249.

Volume Encryption Method

There are two methods for volume encryption:

  1. Encrypt the entire volume. Use this option when you need to encrypt volumes that already contain existing messaging data. With a 3TB disk, it takes more than 8 hours to encrypt the entire disk.
  2. Encrypt only the used space. Use this for new deployments or for new disks where the volumes have no existing data.

Be sure to place the servers in maintenance mode to prevent impact to end users prior to beginning the encryption of an entire volume. You can expect major performance degradation (~90% CPU utilization) and limited free OS volume space (less than ~2GB) while the volume is being encrypted. Also, be sure to deploy BitLocker one server at a time within a DAG to preserve availability.

OS Volume and Exchange Data Volume Encryption Scenario

BitLocker provides the most protection when used with a TPM. The TPM is a hardware component installed in the server and we recommend a TPM 2.0 chip. It works with BitLocker to help protect user data and to ensure that a server has not been tampered with while the system was offline.

Specifically, BitLocker can use a TPM to verify the integrity of early boot components and boot configuration data. This helps ensure that BitLocker makes the encrypted drive accessible only if those components have not been tampered with and the encrypted drive is located in the original server.

BitLocker helps ensure the integrity of the startup process by taking the following actions:

  • Checks that the early boot file integrity has been maintained, and helps ensure that there has been no malicious modification of those files, such as with boot sector viruses or rootkits.
  • Enhances protection to mitigate offline software-based attacks. Any alternative software that might start the system does not have access to the decryption keys for the Windows operating system drive.
  • Locks the system when it is tampered with. If any monitored files have been modified, the system does not start. This alerts the administrator to the tampering, because the system fails to start as usual. In the event that system lockout occurs, follow the BitLocker recovery process which includes unlocking the system with a password or a USB key.

Important: A TPM can only be used in a physical server deployment. Virtualized servers are not capable of using a TPM. If you encrypt the guest operating system volume, a password or USB key must be used to allow the guest operating system to boot.

Setting up the Environment

The steps below assume the Exchange Server operating system is Windows Server 2012 R2 or later.

Important: When enabling BitLocker on existing Exchange servers, it is important to place the servers in maintenance mode to prevent the encryption process from affecting the end user experience.

  1. Create an Organizational Unit to contain the Exchange servers, if one does not already exist.
    1. Open PowerShell with the appropriate Active Directory permissions.
    2. Execute New-ADOrganizationalUnit "Exchange Servers" -path "dc=contoso,dc=com".
    3. Execute $ExchangeOU = Get-ADOrganizationalUnit -Filter ‘Name -like "Exchange Servers"’.
    4. Execute Get-ADComputer "Exchange Server" | Move-ADObject -TargetPath $ExchangeOU.DistinguishedName.
  2. Create group policy object and link it to the Exchange Servers OU.
    1. Open PowerShell with the appropriate Active Directory permissions.
    2. Execute Import-Module grouppolicy (requires RSAT tools to be installed).
    3. Execute New-GPO -Name "Exchange Server BitLocker Policy" -Domain contoso.com
    4. Execute New-GPLink -Name "Exchange Server BitLocker Policy" -Enforced "yes" -Target $ExchangeOU.DistinguishedName
  3. Install the BitLocker module on the Exchange servers.
    1. Open PowerShell with local administrative privileges.
    2. Execute Install-WindowsFeature BitLocker -Restart.
    3. Reboot the server.
  4. Enable TPM on the Exchange servers.
    1. Refer to your hardware vendor’s BIOS manual for details on how to enable/activate the TPM.
    2. Verify the TPM state by using the Trusted Platform Module Management tool (tpm.msc).
  5. Allow TPM Recovery Information to be stored in Active Directory.
    1. Open the Exchange Management Shell with an account that has the necessary permissions in Active Directory to apply access control entries.
    2. Execute Add-ADPermission $ExchangeOU.DistinguishedName -User "NT AUTHORITYSELF" -AccessRights ReadProperty,WriteProperty -Properties msTPM-OwnerInformation,msTPM-TpmInformationForComputer -InheritedObjectType Computer -InheritanceType Descendents.
  6. Configure the Bitlocker GPO settings.
    1. Open the Group Policy Management Console (gpmc.msc).
    2. Navigate the hierarchy to the Exchange Servers OU.
    3. Right-click the Exchange Server BitLocker Policy and select Edit.
    4. Open Computer Configuration, open Policies, open Administrative Templates, open Windows Components, and open BitLocker Drive Encryption.
      1. In the right pane, double-click Choose drive encryption method and cipher strength. Select the Enabled option. If you want to use AES 256-bit encryption, select it and click OK.

        AES128bit

    5. Open Computer Configuration, open Policies, open Administrative Templates, open Windows Components, open BitLocker Drive Encryption, and finally, open Operating System Drives.
      1. In the right pane, double-click Require additional authentication at startup. Select the Enabled option. If you want to disable or change any of the authentication methods, do so and click OK.

        RequireOSAuth

      2. In the right pane, double-click Choose how BitLocker-protected operating system drives can be recovered. Select the Enabled option. Select the Do not enable BitLocker until recovery information is stored to AD DS for operating system drives option. Click OK.

        OSDriveRecovery

      3. In the right pane, double-click Enforce drive encryption type on operating system drives. Select the Enabled option. Select the Used Space Only encryption option for the encryption type. Click OK.

        UsedSpaceOnly

    6. Open Computer Configuration, open Policies, open Administrative Templates, open Windows Components, open BitLocker Drive Encryption, and finally, open Fixed Data Drives
      1. In the right pane, double-click Choose how BitLocker-protected fixed drives can be recovered. Select the Enabled option. Select the Do not enable BitLocker until recovery information is stored to AD DS for fixed data drives option. Click OK.

        choosefixeddrives

      2. In the right pane, double-click Enforce drive encryption type on fixed drives. Select the Enabled option. Select the Used Space Only encryption option for the encryption type. Click OK.

        UsedSpaceOnly-FD

    7. Open Computer Configuration, open Policies, open Administrative Templates, open System, and open Trusted Platform Module Services.
      1. In the right pane, double-click Turn on TPM backup to Active Directory Domain Services. Select the Enabled option. Click OK.

        TPMBackup

  7. Ensure the group policy is applied to the Exchange servers.
    1. Execute $Servers = Get-AdComputer -SearchBase $ExchangeOU.DistinguishedName -Filter.
    2. Execute Foreach ($Server in $Servers) {invoke-gpupdate -Computer $Servers.Name -Force -Target Computer}.
  8. Enable OS encryption.
    1. Create a recovery key: manage-bde -protectors -add -RecoveryPassword C:
    2. Execute the following against the operating system drive: manage-bde -on C: –usedspaceonly
  9. Enable data volume encryption (C:ExchangeVolumesExVol1 defines the mount point for an Exchange data volume, replace as appropriate).
    1. Create a recovery key: manage-bde -protectors -add -RecoveryPassword "C:ExchangeVolumesExVol1"
    2. Execute the following for each Exchange database volume: manage-bde -on "C:ExchangeVolumesExVol1" –usedspaceonly
    3. Execute the following for each Exchange database volume to enable automatic unlock: Enable-BitLockerAutoUnlock -MountPoint "C:ExchangeVolumesExVol1"

    Note: Bad disk sectors can result in BitLocker volume encryption failure. For more information, please see Event ID 24588.

Exchange Data Volume Encryption Scenario

In the situation where a TPM cannot be used (e.g., the server does not have a TPM, or it is virtualized), encrypting the OS volume requires the use of a password or USB key to allow the operating system to boot. As that can be detrimental for a service like Exchange, you could choose not to encrypt the OS volume. Instead, you only encrypt the fixed data volumes. Since the OS volume is not encrypted, the operating system cannot automatically unlock the encrypted volumes on boot. Therefore, one of two things must happen:

  1. An administrator manually enters the recovery key and unlocks each drive after OS boot.
  2. A scheduled task is invoked to unlock the encrypted volumes during OS boot.

The following steps outline how to setup the scheduled task and assume the Exchange Server operating system is Windows Server 2012 R2 or later.

Important: When enabling BitLocker on existing Exchange servers, it is important to place the servers in maintenance mode to prevent the encryption process from affecting the end user experience.

  1. Create an Organizational Unit to contain the Exchange servers, if one does not already exist.
    1. Open PowerShell with the appropriate Active Directory permissions.
    2. Execute New-ADOrganizationalUnit "Exchange Servers" -path "dc=contoso,dc=com".
    3. Execute $ExchangeOU = Get-ADOrganizationalUnit "Exchange Servers".
    4. Execute Get-ADComputer "Exchange Server" | Move-ADObject -TargetPath $ExchangeOU.DistinguishedName.
  2. Create group policy object and link it to the Exchange Servers OU.
    1. Open PowerShell with the appropriate Active Directory permissions.
    2. Execute Import-Module grouppolicy (requires RSAT tools to be installed).
    3. Execute New-GPO -Name "Exchange Server BitLocker Policy" -Domain contoso.com
    4. Execute New-GPLink -Name "Exchange Server BitLocker Policy" -Enforced "yes" -Target $ExchangeOU.DistinguishedName
  3. Create BitLocker scheduled task service account (_bitlockersvc).
    1. Create a service account following your organization’s policy.
  4. Create security group for BitLocker management, placing the security group in a protected container.
    1. Open PowerShell with the appropriate Active Directory permissions.
    2. Execute New-ADGroup -name "Exchange BitLocker Management" -groupscope Universal -path "cn=users,dc=coe,dc=local".
    3. Execute Add-ADGroupMember "Exchange BitLocker Management" -members "_bitlockersvc", "Organization Management".
  5. Install the BitLocker module on the Exchange servers.
    1. Open PowerShell with local administrative privileges.
    2. Execute Install-WindowsFeature BitLocker.
    3. Reboot the server.
  6. Add BitLocker security management group to local administrators group on the Exchange servers.
  7. Grant the BitLocker security management group permissions to access the msFVE-RecoveryPassword AD object. This allows the accounts to access the recovery password.
    1. Open an elevated PowerShell session with Domain Administrator permissions.
    2. Execute $ExchangeOU = Get-OrganizationalUnit "Exchange Servers".
    3. Execute DSACLS $ExchangeOu.DistinguishedName /I:T /G "contosoExchange BitLocker Management:CA;msFVE-RecoveryPassword".
  8. Configure the BitLocker GPO settings.
    1. Open the Group Policy Management Console (gpmc.msc).
    2. Navigate the hierarchy to the Exchange Servers OU.
    3. Right-click the Exchange Server BitLocker Policy and select Edit.
    4. Open Computer Configuration, open Policies, open Administrative Templates, open Windows Components, and open BitLocker Drive Encryption.
      1. In the right pane, double-click Choose drive encryption method and cipher strength. Select the Enabled option. If you want to use AED 256-bit encryption, select it and click OK.
    5. Open Computer Configuration, open Policies, open Administrative Templates, open Windows Components, open BitLocker Drive Encryption, and finally, open Fixed Data Drives.
      1. In the right pane, double-click Choose how BitLocker-protected fixed drives can be recovered. Select the Enabled option. Select the Do not enable BitLocker until recovery information is stored to AD DS for fixed data drives option. Click OK.
      2. In the right pane, double-click Enforce drive encryption type on fixed drives. Select the Enabled option. Select the Used Space Only encryption option for the encryption type. Click OK.
    6. Open Computer Configuration, open Policies, open Administrative Templates, open System, and open Trusted Platform Module Services.
      1. In the right pane, double-click Turn on TPM backup to Active Directory Domain Services. Select the Enabled option. Click OK.
  9. Ensure the group policy is applied to the Exchange servers.
    1. Execute $Servers = Get-AdComputer -SearchBase $ExchangeOU.DistinguishedName -Filter.
    2. Execute Foreach ($Server in $Servers) {invoke-gpupdate -Computer $Servers.Name -Force -Target Computer}.
  10. Enable data volume encryption (C:ExchangeVolumesExVol1 defines the mount point for an Exchange data volume, replace as appropriate).
    1. Execute the following against each Exchange database volume: Manage-bde -on "C:ExchangeVolumesExVol1" -rp -usedspaceonly.

      Note: Bad disk sectors can result in BitLocker volume encryption failure. For more information, please see Event ID 24588.

  11. Validate recovery keys are stored in Active Directory.
    1. Download the BitLocker Drive Encryption Configuration Guide: Backing Up BitLocker and TPM Recovery Information to Active Directory.
    2. Execute Get-BitLockerRecoveryInfo.vbs.
    3. If script does not return any data, backup the recovery keys by downloading and executing BDEAdBackup.vbs.
  12. Create the script that unlocks the volumes when the operating system boots.
    1. Save the below file to your script directory (e.g., c:bitlocker).

      UnlockDrives.ps1
      $computer = Get-ADComputer $env:computername
      $RecoveryInformations = get-ADObject -ldapfilter "(msFVE-Recoverypassword=*)" -Searchbase $computer.distinguishedname -properties *
      $vols = gwmi win32_encryptablevolume -Namespace "RootCIMV2SecurityMicrosoftVolumeEncryption"
      $lockedvols = $vols | ? {$_.GetLockStatus().LockStatus -eq 1}
      $vols[0].GetKeyProtectors().VolumeKeyProtectorID
      foreach($lockedvol in $lockedvols)
      {
      $RecoveryInformations | % {$lockedvol.UnlockWithNumericalPassword($_."msFVE-RecoveryPassword")}
      }

      Note: This is a basic script to get you started. You may need to extend the duties of this script to ensure that Microsoft Exchange Diagnostics, Microsoft Exchange Health Manager, and Microsoft Exchange Service Host services are restarted in the event they fail to start while the above script unlocks the data volumes.

  13. Create the scheduled task to run at system start and unlock the volumes, replacing the bold items.
    1. Save the below file to your script directory.
    2. Execute schtasks /create /s $env:computername /ru contoso_svcexbitlocker /rp <Password> /XML c:BitlockerUnlockDrivesAtStart.xml /TN UnlockDrivesAtStart.

      <?xml version="1.0" encoding="UTF-16"?>
      <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
      <RegistrationInfo>
      <Date>2015-04-16T12:07:14.9465954</Date>
      <Author>contosoexadmin</</Author>
      <Description>Script unlocks Exchange data drives at OS startup</Description>
      </RegistrationInfo>
      <Triggers>
      <BootTrigger>
      <Enabled>true</Enabled>
      </BootTrigger>
      </Triggers>
      <Principals>
      <Principal id="Author">
      <UserId>contoso_bitlockersvc</UserId>
      <LogonType>Password</LogonType>
      <RunLevel>HighestAvailable</RunLevel>
      </Principal>
      </Principals>
      <Settings>
      <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
      <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
      <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
      <AllowHardTerminate>true</AllowHardTerminate>
      <StartWhenAvailable>false</StartWhenAvailable>
      <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
      <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
      </IdleSettings>
      <AllowStartOnDemand>true</AllowStartOnDemand>
      <Enabled>true</Enabled>
      <Hidden>false</Hidden>
      <RunOnlyIfIdle>false</RunOnlyIfIdle>
      <WakeToRun>false</WakeToRun>
      <ExecutionTimeLimit>P3D</ExecutionTimeLimit>
      <Priority>7</Priority>
      </Settings>
      <Actions Context="Author">
      <Exec>
      <Command>C:WindowsSystem32WindowsPowerShellv1.0powershell.exe</Command>
      <Arguments>-Command .UnlockDrives.ps1</Arguments>
      <WorkingDirectory>DIRECTORY_FOR_UNLOCKDRIVES.PS1</WorkingDirectory>
      </Exec>
      </Actions>
      </Task>

System Changes

It’s important to remember that any of the following system changes can cause an integrity check failure and prevent the TPM from releasing the BitLocker key to decrypt the protected volumes:

  • Moving the BitLocker-protected drive into a new computer.
  • Installing a new motherboard with a new TPM.
  • Turning off, disabling, or clearing the TPM.
  • Changing any boot configuration settings.
  • Changing the BIOS, UEFI firmware, master boot record, boot sector, boot manager, option ROM, or other early boot components or boot configuration data.
  • Applying BIOS/UEFI firmware updates.

As part of your standard operating procedure, it is best to suspend BitLocker encryption (via the Suspend-BitLocker cmdlet) prior to introducing any changes to the server. In addition, be sure to test any hardware and software configuration changes in a lab environment (that has BitLocker enabled) prior to deploying in production.

Also, be sure to develop a standard operating procedure about how to recover in the event the BitLocker recovery must be performed. This will ensure that downtime is minimized. For more information, please see the BitLocker Recovery Guide.

Disk Maintenance Activities

During the server's lifecycle, disks will die. As part of your standard operating procedures, you need to ensure that when a disk is replaced the new volume is formatted and encrypted via BitLocker.

In the event you are using AutoReseed to recover from failed disks, you have two options: format and encrypt the disks prior to usage, or encrypt after failure.

Format and encrypt the disks prior to usage

In this scenario, your standard operating procedure will be to prevent Disk Reclaimer from formatting hot spare disks. Instead, you will format and encrypt all hot spare disks prior to usage.

  1. Disable Disk Reclaimer on the DAG: Set-DatabaseAvailabilityGroup <DAGName> -AutoDagDiskReclaimerEnabled $false
  2. Format and encrypt all hot spares. Do not assign mount points or drive letters.
  3. As disks fail, AutoReseed will assign the hot spare volumes, replacing the failed volumes, and reseed the afflicted database copies.
  4. Schedule a maintenance window. Replace the failed disks. Format and encrypt.

Encrypt after failure

In this scenario, your standard operating procedure will be to allow Disk Reclaimer to format hot spare disks (default behavior). After the spare is formatted and databases are reseeded, you will encrypt the disk.

  1. As disks fail, AutoReseed allocates, remaps and formats a spare disk.
  2. AutoReseed initiates reseed operations.
  3. Using SCOM, or another operations management tool, you will monitor for events 1127 (initiated reseed of a database) and 826 (completed reseed of a database) that are located in the Microsoft-Exchange-HighAvailability/Seeding crimson channel.
  4. Schedule a maintenance outage for the affected server and encrypt the new volume.

Conclusion

Hopefully this information helps understanding BitLocker encryption and configuring BitLocker for Exchange servers. As indicated, the recommended approach is to use a TPM for storing the recovery information and to allow the operating system to unlock volumes automatically during boot. However, if your servers do not have access to a TPM, you can consider encrypting only the data volumes and crafting a mechanism to ensure that the data volumes unlock at OS boot.

If you have any questions, please do not hesitate to ask.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Upgrading to ownCloud Server 8.2

ownCloud82Round
ownCloud Server 8.2 was released yesterday with a much improved user interface and many new admin goodies! It is time to start thinking about upgrading and this blog post aims to tell you everything you need to know. Note that there’s a change in location for the Linux Packages, be sure to carefully read what’s going on there.

Why Should I Upgrade?

ownCloud Server 8.2 introduces many smaller and larger improvements all over ownCloud, from the redesigned user interface with the new sidebar and rewritten Gallery app to many new capabilities for administrators to configure and control ownCloud. You can find out more about what is new in our announcement blog and see a full overview on the website.

@ownCloud @ownClouders We tested 8.2 on 35.000+ installations. Upgrade works smooth! New look & features are fantastic. THX for release

— Owncube (@Owncube) October 21, 2015

If you would like the benefit of these improvements then it’s time for you to move to ownCloud 8.2!

Preparation

Before you upgrade, be sure to carefully read the ownCloud 8.2 release notes. It is very important to note, for example, these things:

  • filesystem_check_changes in config.php is set to 0 by default. This prevents unnecessary update checks and improves performance. If you are using external storage mounts such as NFS on a remote storage server, set this to 1 so that ownCloud will detect remote file changes.
  • XSendFile support has been removed, so there is no longer support for serving static files from your ownCloud server. It does not work with our new High Level File Locking capability (which protects against certain race conditions).

ownCloud updater app

ownCloud updater app in action


There are more important changes like these so give the release notes a good read.

Be sure that you have the base requirements for ownCloud 8.2:

  • A Linux or BSD server (Mac OS X is possible but less tested)
  • MySQL 5.5 + / MariaDB 10.x
  • PHP 5.4 +
  • Apache 2.4 +

There are other web servers (like Ngnix) and databases (like PostgreSQL) supported as well.

Usually, newer versions mean better performance with ownCloud. This is especially true for PHP. If you use ownCloud with other web servers like Ngnix or on platforms like a NAS, be sure to have an extra careful look at the documentation!

Not all ownCloud apps developed for and on earlier releases are yet modified to work with ownCloud 8.2, so we urge you to check if your favorite apps are already compatible with ownCloud 8.2. You can usually check on the online ownCloud app overview.

Upgrading ownCloud

Upgrading ownCloud

When it comes to stability and potential upgrade issues, we always urge users to test ownCloud Betas before of the release and to report any bugs you come across. Only a test on your specific circumstances can tell you if a piece of software will work for you. However, ownCloud 8.2 has seen significant testing, including by using our automated Smashbox testing, a tool developed by CERN. We are therefore very confident in the stability of this release.

We still strongly recommend to make a backup of your database and data. You can find instructions on how to do that here.

Tips in the admin settings

Tips in the admin settings

The Upgrade Itself

We have written a great guide on upgrading ownCloud in our documentation. Carefully read the document, make the appropriate choices about how you will upgrade (with packages, manually or the updater app), and proceed with the steps described.

Note that if you wish to use the updater app, we usually release a new major ownCloud version for the updater app within a week after the release, provided no big problems are found, so this is currently not yet available. If we notice serious upgrade issues we will delay the automatic update until we released the first maintenance update.

Packages

With regard to Linux Packages, there are two major changes.

  • First of all, from now on, packages will appear on download.owncloud.org. For ownCloud 8.2 you can find them on this page. You will find the familiar installation instructions for our supported Linux distributions there.
    If you are currently using the Stable release channel, you will have to manually change over to this new repository!
  • Second, the Linux packages will show a different upgrade behavior. Linux packages before 8.2 send an existing ownCloud server into maintenance mode, install the new code base, perform occ upgrade on behalf of the system administrator, then exit out of maintenance mode. This often came unexpected to the admin and is in general not safe as an unattended install. Third party apps are also likely to break this automated process.
    Linux packages 8.2 and up change an existing ownCloud server into maintenance mode, install the new code base, and leave the server in maintenance mode. It is up to the system administrator to finalize the upgrade.

Troubleshooting

While we strive to keep managing ownCloud as easy as possible (including the upgrade procedure!) and test as many upgrade scenarios, the documentation contains a troubleshooting section with instruction on how to recover from the most typical problems.

If this does not help you, there is a support page on owncloud.org which links to the various resources available to you. Home users should check out the forums, which have a special section devoted to ownCloud 8.2 upgrades with excellent and up to date information. Professional users can find resources on owncloud.com and are strongly urged to wait with the upgrade until the availability of the ownCloud support subscriptions. These will become available next month. It is, as usual, recommended to test this release of ownCloud Server to ensure compatibility with your infrastructure and see if the features fulfill your needs.

Fresh installations

If you currently don’t have ownCloud, there is a new and easy way to get up and running! In the Appliance tab on our download page we offer a fully pre-configured virtual machine image which you can easily run in a tool like VirtualBox. Thanks to the built in ownCloud Proxy app you can have a stable url and an easy way through firewalls blocking you from accessing your ownCloud.

Once your brand new ownCloud 8.2 is up and humming nicely, we’d appreciate it if you would let us know what you think over Twitter and other social media, see owncloud.org/promote for more.

Enjoy ownCloud Server 8.2!

Client Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2010

Our goal with this article is to articulate the various client connectivity scenarios you may encounter in your Exchange 2016 designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2016.

Existing Environment

NoE16Site1

As you can see from the above diagram, this environment contains three Active Directory sites:

  • Internet Facing AD Site (Site1) - This is the main AD site in the environment and has exposure to the Internet. This site has Exchange 2010 servers. There are two namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2010 infrastructure.
  • Regional Internet Facing AD Site (Site2) - This is an AD site that has exposure to the Internet. This site has Exchange 2010 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2010 infrastructure located within this AD site.
  • Non-Internet Facing AD Site (Site3) - This is an AD site that does not have exposure to the Internet. This site contains Exchange 2010 infrastructure.

Note: The term, Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories do not have ExternalURL property populated.

To understand the client connectivity before we instantiate Exchange 2016 into the environment, let’s look at how each protocol works for each of the three users.

Autodiscover

The Autodiscover namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the CAS2010 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the CAS2010 infrastructure and retrieve configuration settings based on their mailbox’s location.

Note: The recommended practice is to configure the 2010 Client Access server’s AutoDiscoverServiceInternalUri value (which is the property value you use to set the SCP record) to point to autodiscover.contoso.com, assuming split-brain DNS is in place. If split-brain DNS is not configured, then set AutoDiscoverServiceInternalUri to a value that resolves to the load balanced VIP for the 2010 Client Access servers in your environment.

For more information on how Autodiscover requests are performed, see the whitepaper, Understanding the Exchange 2010 Autodiscover Service.

Internal Outlook Connectivity

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will connect to the Exchange 2010 RPC Client Access array endpoint (assuming one exists). Keep in mind the importance of configuring the RPC Client Access array endpoint correctly, as documented in Ambiguous URLs and their effect on Exchange 2010 to Exchange 2013 Migrations.

Outlook Anywhere

  1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet and since the target mailbox database is located within the local site, will retrieve the necessary data from the local Exchange 2010 Mailbox server.
  2. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet, determine that the mailbox server hosting the mailbox is located in another AD site (in this case Site3) and proxy the Outlook RPC data to the target Exchange 2010 Client Access server.
  3. Orange User will connect to mail-region.contoso.com as his RPC proxy endpoint. CAS2010 in Site2 will de-encapsulate the RPC data embedded within the HTTP packet and since the target mailbox database is located within the local site, will retrieve the necessary data from the local Exchange 2010 Mailbox server.

Note: In addition to the mail and directory connections, Outlook Anywhere clients also utilize Exchange Web Services and an Offline Address Book, url’s for which are provided via the Autodiscover response.

Outlook Web App

For more information, see the article Upgrading Outlook Web App to Exchange 2010.

  1. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
  2. Blue User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2010 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
  3. For the Orange User, there are three possible scenarios depending on what namespace the users enters and how the environment is configured:
    1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
    2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2010 in Site1 is not configured to do a cross-site silent redirection, therefore, the user is prompted to use the correct URL to access his mailbox data.
    3. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2010 in Site1 is configured to do a cross-site silent redirection, therefore, CAS2010 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server.

Exchange ActiveSync

For more information, see the article Upgrading Exchange ActiveSync to Exchange 2010.

  1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
  2. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any EAS ExternalURLs. CAS2010 in Site1 will issue a cross-site proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
  3. For the Orange User, there are two possible scenarios:
    1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
    2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an EAS ExternalURL. Assuming the device supports Autodiscover and is on a defined list of devices that supports the 451 redirect response, CAS2010 will issue a 451 response to the device, notifying the device it needs to use a new namespace, mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server. If the device is not on the supported list, then CAS2010 in Site1 will proxy the request to CAS2010 in Site2

Exchange Web Services

  1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2010 in Site1 will service the request.
  2. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2010 will then proxy the request to an Exchange 2010 Client Access server located in Site3.
  3. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2010 in Site2 will service the request.

Client Connectivity with Exchange 2016 in Site1

Exchange 2016 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. As a result, Outlook Anywhere has been enabled on all Client Access servers within the infrastructure and the mail.contoso.com and autodiscover.contoso.com namespaces have been moved to resolve to Exchange 2016 Client Access component infrastructure.

2010-2016 Coex Fig2

To understand the client connectivity now that Exchange 2016 exists in the environment, let’s look at the four users.

Autodiscover

The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the MBX2016 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the MBX2016 infrastructure and depending on the mailbox version, different behaviors occur:

  1. For mailboxes that exist on Exchange 2010, MBX2016 will proxy the request to an Exchange 2010 Client Access server that exists within the mailbox’s local site. This means that for Red User, this will be a local proxy to a CAS2010 in Site1. For Blue User and Orange User, this will be a cross-site proxy to a CAS2010 located in the user’s respective site. CAS2010 will then generate the Autodiscover response.
  2. For mailboxes that exist on Exchange 2016 (Purple User), MBX2016 will proxy the request to the Exchange 2016 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.

Internal Outlook Connectivity

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will still connect to the Exchange 2010 RPC Client Access array endpoint.

When you have an Exchange 2016 mailbox you are using Outlook Anywhere (RPC/HTTP) or MAPI/HTTP, either within the corporate network or outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2016 mailboxes.

Important: When you introduce Exchange 2016 into a native Exchange 2010 environment, MAPI/HTTP will be enabled by default. Prior to moving any mailboxes to Exchange 2016, ensure you have configured your load balancer and/or firewall rules to allow traffic on /mapi/* via TCP443 traffic.

In Exchange 2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2016, you have both an internal host name and an external host name. Think of it as having two sets of Outlook Anywhere settings, one for when you are connected to the corporate domain, and another for when you are not. You will see this returned to the Outlook client in the Autodiscover response via what looks like a new provider, ExHTTP. However, ExHTTP isn’t an actual provider, it is a calculated set of values from the EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings. To correctly use these settings, the Outlook client must be patched to the appropriate levels (see the Outlook Updates for more information). Outlook will process the ExHTTP in order – internal first and external second.

Important: In the event that you are utilizing a split-brain DNS infrastructure, then you must use different names for Outlook Anywhere inside and out. Outlook will also prefer the internal settings over the external settings and since the same namespace is used for both, regardless of whether the client is internal or external, it will utilize only the internal authentication settings. By utilizing two namespaces, you can ensure that your internal clients can connect utilizing Kerberos authentication.

The default Exchange 2016 internal Outlook Anywhere settings don’t require HTTPS. By not requiring SSL, the client should be able to connect and not get a certificate pop-up for the mail and directory connections. However, you will still have to deploy a certificate that is trusted by the client machine for Exchange Web Services and OAB downloads.

In environments that are native Exchange 2010, when you introduce Exchange 2016, MAPI/HTTP will be enabled by default. As long as the client supports the protocol, once a mailbox is moved to Exchange 2016, the client will reconfigure itself to use MAPI/HTTP. Upon next boot of the client, MAPI/HTTP will be utilized. It is very important to ensure that you have the correct firewall and load balancer settings in place prior to moving mailboxes, otherwise client connectivity will fail.

External Outlook Anywhere Connectivity

In order to support access for Outlook Anywhere clients whose mailboxes are on legacy versions of Exchange, you will need to make some changes to your environment which are documented in the steps within the Exchange Deployment Assistant. Specifically, you will need to enable Outlook Anywhere on your legacy Client Access servers and enable NTLM in addition to basic authentication for the IIS Authentication Method.

The Exchange 2016 Client Access component’s RPC proxy component sees the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2010 CAS or Exchange 2016 Mailbox server).

  1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in the local site. MBX2016 will proxy the request to CAS2010 in Site1. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
  2. Purple User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
  3. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in Site3. MBX2016 will proxy the request to CAS2010 in Site3. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
  4. Orange User will continue to access his mailbox using the Exchange 2010 regional namespace, mail-region.contoso.com.

Outlook on the web

For Outlook on the web, the user experience will depend on the mailbox version and where the mailbox is located.

  1. Red User will connect to mail.contoso.com as his namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and is located within the local AD site. MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
  2. Purple User will connect to mail.contoso.com as his endpoint. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
  3. Blue User will connect to mail.contoso.com as his namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. MBX2016 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
  4. For the Orange User, there are two possible scenarios:
    1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. In this case, MBX2016 is not involved in any fashion.
    2. Orange User will connect to mail.contoso.com as his namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. MBX2016 in Site1 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server.

Exchange ActiveSync

For Exchange ActiveSync clients, the user experience will depend on the mailbox version and where the mailbox is located. In addition, Exchange 2016 no longer supports the 451 redirect response – Exchange 2016 will always proxy ActiveSync requests (except in hybrid scenarios, where redirection is allowed).

  1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within the local AD site. MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
  2. Purple User’s ActiveSync client will connect to mail.contoso.com as his endpoint. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
  3. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3. MBX2016 in Site1 will issue a cross-site proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
  4. For the Orange User, there are two possible scenarios depending on how the device is configured:
    1. Orange User’s ActiveSync client is configured to connect to mail-region.contoso.com as the namespace endpoint. In this case, MBX2016 is not involved in any fashion. Note that any new device that is configured will automatically be configured to use mail-region.contoso.com.
    2. Orange User’s ActiveSync client is configured to connect to mail.contoso.com as the namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within another AD site. MBX2016 will issue a cross-site proxy request to an Exchange 2010 Client Access server that resides in the same site as the mailbox.

Exchange Web Services

Coexistence with Exchange Web Services is rather simple.

  1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. MBX2016 will then proxy the request to an Exchange 2010 Client Access server within the local site.
  2. For the Purple User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
  3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. MBX2016 will then proxy the request to an Exchange 2010 Client Access server located in Site3.
  4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL.

Offline Address Book

Like with Exchange Web Services, Autodiscover will provide the Offline Address Book URL.

  1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. MBX2016 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question.
  2. For the Purple User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. MBX2016 will then proxy the request to the Exchange 2013/2016 Mailbox server that is hosting the active copy of an OABGEN mailbox that contains a copy of OAB that is closest to the user’s mailbox.
  3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. MBX2016 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question.
  4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Offline Address Book URL.

How MBX2016 Picks a Target Legacy Exchange Server

It’s important to understand that when MBX2016 proxies to a legacy Exchange Client Access server, it constructs a URL based on the server FQDN, not a load balanced namespace or the InternalURL value. But how does MBX2016 choose which legacy Client Access server to proxy the connection?

When a MBX2016 starts up, it connects to Active Directory and enumerates a topology map to understand all the Client Access servers that exist within the environment. Every 50 seconds, MBX2016 will send a lightweight request to each protocol end point to all the Client Access servers in the topology map; these requests have a user agent string of HttpProxy.ClientAccessServer2010Ping. MBX2016 expects a response - a 200/300/400 response series indicates the target server is up for the protocol in question; a 502, 503, or 504 response indicates a failure. If a failure response occurs, MBX2016 immediately retries to determine if the error was a transient error. If this second attempt fails, MBX2016 marks the target CAS as down and excludes it from being a proxy target. At the next interval (50 seconds), MBX2016 will attempt to determine the health state of the down CAS to determine if it is available.

The IIS log on a legacy Client Access server will contain the ping events. For example:

2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /ecp - 443 - 192.168.1.42 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 302 0 0 277 170 0
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /PowerShell - 443 - 192.168.1.27 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 0 0 309 177 15
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /EWS - 443 - 192.168.1.134 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 0 0 245 170 0
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 GET /owa - 443 - 192.168.1.220 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 301 0 0 213 169 171
2015-08-11 14:00:01 W3SVC1 DF-C14-02 192.168.1.76 HEAD /Microsoft-Server-ActiveSync/default.eas - 443 - 192.168.1.29 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 2 5 293 194 31
2015-08-11 14:00:04 W3SVC1 DF-C14-02 192.168.1.76 HEAD /OAB - 443 - 10.166.18.213 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 2 5 261 170 171

If for some reason, you would like to ensure a particular CAS2010 is never considered a proxy endpoint (or want to remove it for maintenance activities), you can do so by executing the following cmdlet on Exchange 2010:

Set-ClientAccessServer <server> -IsOutofService $True

IMAP & POP Coexistence

All this discussion about HTTP-based clients is great, but what about POP and IMAP clients? Like the HTTP-based client counterparts, IMAP and POP clients are also proxied from the Exchange 2016 Client Access component to a target server (whether that be an Exchange 2016 Mailbox server or a legacy Client Access server). However, there is one key difference, there is no health-checking on the target IMAP/POP services.

When the Exchange 2016 Client Access component receives a POP or IMAP request, it will authenticate the user and perform a service discovery.

If the target mailbox is E2010, MBX2016 will enumerate the POP or IMAP InternalConnectionSettings property value for each Exchange 2010 Client Access server within the mailbox’s site. Therefore, it is important to ensure that the InternalConnectionSettings maps to the server's FQDN, and not a load-balanced namespace.

MBX2016 will choose a server to proxy the request based on the incoming connection’s configuration. If the incoming connection is over an encrypted channel, MBX2016 will try to locate an SSL proxy target first, TLS next, plaintext lastly. If the incoming connection is over a plaintext channel, MBX2016 will try to locate a plaintext proxy target first, SSL next, TLS lastly.

Important: Exchange 2016 Mailbox servers do not validate that the POP or IMAP services are actually running on the target Client Access servers. It's important, therefore, to ensure that the services are running on every legacy Client Access server if you have POP or IMAP clients in your environment.

Conclusion

Hopefully this information dispels some of the myths around proxying and redirection logic for Exchange 2016 when coexisting with Exchange 2010. Please let us know if you have any questions.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience