Enabling encrypted optimization

1. Choose Networking > Active Directory: Domain Join and join the server-side SteelHead to the same Windows Domain that the Exchange Server belongs to and operates as a member server. An adjacent domain can be used (through cross-domain support) if the SteelHead is running RiOS 6.1 or later. It is not necessary to join the client-side SteelHead to the domain.

4. RiOS supports both NTLM and Kerberos authentication. To use Kerberos authentication, select Enable Kerberos Authentication support on both the client-side and server-side SteelHeads. Both SteelHeads must be running RiOS 7.0 or later. Windows 7 clients must not be configured to use NTLM only.

In RiOS 7.0 and later, Windows 7 MAPI clients must use Delegation mode unless you join the server-side SteelHead using Active Directory integration for Windows 2003 or 2008. Transparent mode is the default in RiOS 6.5 and later. Use Transparent mode for all other clients and for Windows 7 MAPI clients when the server-side SteelHead is joined as an Active Directory integrated.

Windows 7 clients running RiOS 6.1.x with MAPI encryption enabled cannot connect to a Microsoft Exchange cluster even after auto or manual delegation mode is configured. You must configure the Active Directory delegate user with the Exchange Cluster node service exchangeMDB. By default the Exchange 2003 and 2007 cluster nodes do not have exchangeMDB service and hence these must be defined manually in a domain controller. If your configuration includes an Exchange cluster working with encrypted MAPI optimization, you must use manual delegation mode. For details, see the SteelHead Deployment Guide - Protocols.

Both the server-side and client-side SteelHeads must be running RiOS 5.5.x or later.

When this option is enabled and Enable MAPI Exchange 2007 Acceleration is disabled on either SteelHead, MAPI Exchange 2007 acceleration remains in effect for unencrypted connections.

Provides encrypted MAPI with transparent NTLM authentication. By default, this setting is enabled with encrypted MAPI optimization.

Transparent mode supports all Windows servers, including Windows 2008 R2 (assuming they are not in domains with NTLM disabled). Transparent mode does not support Windows 7 clients or Windows 2008 R2 domains with NTLM disabled. Windows 7 clients must use Delegation mode.

In RiOS 6.1 and later, transparent mode includes support for trusted domains, wherein users are joined to a different domain from the Exchange Server being accessed.

Provides encrypted MAPI optimization using the Kerberos delegation facility. Select this mode if you are encrypting MAPI traffic for Windows 7 or earlier client versions. The server-side SteelHead must be running RiOS 6.1 or later.

CIFS SMB Signing and Encrypted MAPI optimization share the delegate user account. If you enable Delegation mode for both features, the delegate user account must have delegation privileges for both features as well. If you are upgrading from RiOS 6.0, a delegation account might already be in place for CIFS SMB Signing.

In RiOS 6.1 and later, Delegation mode includes support for trusted domains, wherein users are joined to a different domain from the storage system being accessed.

Delegation mode requires additional configuration. To configure Delegation mode, choose Optimization > Active Directory: Service Accounts.

Enable Kerberos Authentication Support provides encrypted MAPI optimization with end-to-end authentication using Kerberos. The server-side SteelHead uses Kerberos to authenticate users.

In addition to enabling this feature, you must also join the server-side SteelHead to a Windows Domain and add replication users under Optimization > Active Directory: Service Accounts.

The server-side SteelHead must be joined to the same Windows Domain that the Exchange Server belongs to and operates as a member server.

Enables a mechanism for sustaining Microsoft Exchange MAPI connections between the client and server even after the Outlook client has shut down. This method allows email data to be delivered between the Exchange Server and the client-side SteelHead while the Outlook client is offline or inactive. When a user logs into their Outlook client, the mail data is already prepopulated on the client-side SteelHead. This accelerates the first access of the client’s email, which is retrieved with LAN-like performance.

Transparent prepopulation creates virtual MAPI connections to the Exchange Server for Outlook clients that are offline. When the remote SteelHead detects that an Outlook client has shut down, the virtual MAPI connections are triggered. The remote SteelHead uses these virtual connections to pull mail data from the Exchange Server over the WAN link.

You must enable this control on the server-side and client-side SteelHeads. By default, MAPI transparent prepopulation is enabled.

MAPI prepopulation does not use any additional Client Access Licenses (CALs). The SteelHead holds open an existing authenticated MAPI connection after Outlook is shut down. No user credentials are used or saved by the SteelHead when performing prepopulation.

The client-side SteelHead controls MAPI v2 prepopulation, which allows for a higher rate of prepopulated session, and enables the MAPI prepopulation to take advantage of the read-ahead feature in the MAPI optimization blade.

MAPI v2 prepopulation is supported in RiOS 6.0.4 or later, 6.1.2 or later, and 6.5 or later. The client-side and server-side SteelHead can be running any of these code train levels and provide v2 prepopulation capabilities. For example, a client-side SteelHead running RiOS 6.0.4 connecting to a server-side SteelHead running RiOS 6.5 provides v2 prepopulation capabilities. In contrast, a 6.0.1a client-side SteelHead connecting to a RiOS 6.5 server-side SteelHead supports v1 prepopulation, but does not provide v2 prepopulation.

If a user starts a new Outlook session, the MAPI prepopulation session terminates. If for some reason the MAPI prepopulation session does not terminate (for example, the user starts a new session in a location that is different than the SteelHead that has the MAPI prepopulation session active), the MAPI prepopulation session eventually times-out per the configuration setting.

MAPI transparent prepopulation is not started with Outlook Anywhere connections.

Specifies the maximum number of virtual MAPI connections to the Exchange Server for Outlook clients that have shut down. Setting the maximum connections limits the aggregate load on all Exchange Servers through the configured SteelHead. The default value varies by model. For example, on a model 5520 the default is 3750.

You must configure the maximum connections on both the client-side and server-side of the network. In RiOS 7.0 and later, the maximum connections setting is only used by the client-side SteelHead.

Sets the number of minutes you want the appliance to check the Exchange Server for newly arrived email for each of its virtual connections. The default value is 20.

Specifies the number of hours after which to time-out virtual MAPI connections. When this threshold is reached, the virtual MAPI connection is terminated. The time-out is enforced on a per-connection basis. Time-out prevents a buildup of stale or unused virtual connections over time. The default value is 96.

Enables bandwidth optimization for the MAPI over HTTP transport protocol on a client-side SteelHead. You must also create an in-path rule using the Exchange Autodetect latency optimization policy to differentiate and optimize MAPI over HTTP traffic.

Microsoft implements the MAPI over HTTP transport protocol in Outlook 2010 update, Outlook 2013 SP1, and Exchange Server 2013 SP1.

To view the MAPI over HTTP optimized connections, choose Reports > Networking: Current Connections. A successful connection appears as MAPI-HTTP in the Application column.

When you have verified appropriate changes, you can write the active configuration that is stored in memory to the active configuration file (or you can save it as any filename you choose).

In out-of-path deployments, if you want to optimize MAPI Exchange by destination port, you must define a fixed-target, in-path rule that specifies these ports on the client-side appliance:

You can configure SteelHeads to operate with Exchange Server clusters that use load balancers (such as CAS) to provide dynamic MAPI port mappings for clients.

• Disable MAPI port remapping using the no protocol mapi port-remap enable command. After entering this command, restart the optimization service.