Optimizing Outlook Anywhere with Juniper...

App Note

© Juniper Networks, Inc. 1

Optimizing Outlook Anywhere with Juniper WXC Based on WXOS 5.7.2 and Exchange/Outlook 2007

Table of Content

1 INTRODUCTION 2

1.1 What is Outlook Anywhere? 2

1.2 Why use Outlook Anywhere in combination with Junipe r WXC? 3

1.3 WXC requirements 3

2 STEP-BY-STEP CONFIGURATION INFORMATION 4

2.1 Exchange server configuration 4

2.2 Juniper WXC appliance 13

2.3 Outlook client 16

2.4 Verify functionality 21

3 TEST RESULTS 24

3.1 Cold run results 24

3.2 Warm run results 26

4 REFERENCES 28

4.1 Internet links 28

Author: Johan Fagerlund EMEA Tech Lead – Application Acceleration http://www.juniper.net/us/en/products-services/application-acceleration/

Optimizing Outlook Anywhere with Juniper WXC – App Note


1 Introduction The goal of this document is to provide detailed information on how to use the Juniper WXC appliances to optimize the communication option called “Outlook Anywhere” between Microsoft Exchange server and Microsoft Outlook client.

This application note consists of three main sections. The first section provides some background information on the Outlook Anywhere communication option and why it would be interesting for customer to use in combination with the Juniper WXC solution. The second section will provide detailed step-by-step information on how to configure the Juniper WXC appliance, Exchange server and Outlook client. The last section will provide some test results based on testing in a lab environment.

1.1 What is Outlook Anywhere?

For the communication between the Microsoft Exchange server and the Microsoft Outlook client there are several protocol options you can select. The most common communication protocol is a RPC based protocol sometimes referred to as MAPI/AirMAPI. Other options include POP3/IMAP/SMTP.

Outlook Anywhere was introduced in Exchange/Outlook 2003 under the name “RPC over HTTP”, but changed name to Outlook Anywhere when Exchange/Outlook 2007 was introduced. The Outlook Anywhere option allows the RPC protocol to be tunneled over HTTP/HTTPS. This allows Outlook users to connect to their Exchange server over Internet as it uses standard TCP ports (80 or 443).

NOTE!!! It is important to understand that Outlook Anywhere tunnels the RPC protocol inside HTTP/HTTPS frames. It does not convert the RPC

protocol into regular web requests.

Although it is possible to run Outlook Anywhere (RPC over HTTP) in clear text the recommendation is to encrypt the communication using SSL.

For more basic information you can check this link: http://technet.microsoft.com/en-us/library/aa996072(EXCHG.65).aspx

Another thing that can be of interest for you is a bit more detail on how the Outlook Anywhere (RPC over HTTP) actually works. On the link below you will find more detailed information: http://msexchangeteam.com/archive/2008/06/20/449053.aspx

NOTE!!! The above have other impact then the fact there is a SEND vs. RECEIVE channel on the RPC level which also means there are two separate

TCP sessions established between Outlook client and the RPC Proxy server. This is useful to know for troubleshooting or if you like to use the Flow

Diagnostics tool to have a closer look at each flow.



1.2 Why use Outlook Anywhere in combination with Ju niper WXC?

The Juniper WXC appliances can optimize application traffic using several features, compression, TCP acceleration, application specific acceleration (AppFlow) and application control (QoS or PBM). For older (pre Exchange/Outlook 2003) versions of the RPC protocol (MAPI) WXOS supports all of the above features. For newer (Exchange/Outlook 2003 or newer) versions of the RCP protocol (AirMAPI) we do support all features, except application specific acceleration.

With the introduction of the Exchange/Outlook 2003 software combination Microsoft by default uses software based compression for the RPC communication. This a lightweight compression algorithm that does provide some improvements, but far from the benefits that MSR and NSC provides. To fully utilize the compression features (MSR/NSC) in WXOS you should disable the software based compression. For more information see section 2.1.x.

With the introduction of the Exchange/Outlook 2007 software combination Microsoft also by default uses software based encryption for the RPC communication. With the software based encryption enabled the Juniper WXC appliance can not provide any compression for this type of traffic. To fully utilize the compression features (MSR/NSC) in WXOS you should disable the software based encryption. For more information see section 2.1.x.

So if the customer has no issues with disabling the software based compression and encryption you do not have to read any further in this document. But if the customer does require encryption between the Exchange server and Outlook client you should keep reading. This is where the Outlook Anywhere communication option comes into play in a Juniper WXC environment.

To maintain the end-to-end encryption between the Exchange server and the Outlook client AND get the benefit of compression in the Juniper WXC (MSR/NSC) you would use the Outlook Anywhere (using a SSL encrypted communication). When running Outlook Anywhere over HTTPS basic implicit mode SSL is used which is supported in the WXOS SSL Optimization feature. So by using the SSL Optimization feature in WXOS the Juniper WXC appliances can provide compression benefits to the communication between the Exchange server and the Outlook client.

NOTE!!!! This does not mean you can leave the RPC compression and/or encryption policies to the default. Remember that when using Outlook

Anywhere the Outlook client simply tunnels RPC communication over HTTP/HTTPS. This means that by default in Exchange/Outlook 2007 when using

Outlook Anywhere the HTTPS/SSL wrapper is encrypting and already encrypted RPC communication. Hence you still need to disable encryption and

compression for RPC to allow the Juniper WXC to do its thing. The HTTPS/SSL wrapper provides the encryption.

1.3 WXC requirements

There are two basic requirements:

1. The appliances must be running WXOS 5.5 or later. The reason being that WXOS 5.5 is the first release to support SSL Optimization.

2. You need the Juniper WXC Encryption Service license on both the appliance in the branch office and data center to be allowed to configure the SSL optimization feature.

The SSL Optimization will work on any WX or WXC appliance, including stacked appliances. Having said this you will definitely see a huge benefit for mail applications (like Exchange) on the WXC appliance due to the fact they use diks based compression/Network Sequence Caching.

NOTE!!!! On stacked appliances we do not support IPSec between the Juniper WXC appliances



2 Step-by-step configuration information The information below focus on the key steps in getting the Juniper WXC to optimize the Outlook Anywhere over HTTPS communication between the Exchange server and Outlook client in the lab environment below. It is not intended to be a complete Exchange/Outlook or Juniper WXC installation/administrators guide.

NOTE!!! Each customer environment will look different, so you need to adapt to each customer environment.

The diagram above shows the overview of the lab environment used for this application note. Basically there is a branch network where there is a Windows XP client which runs the Outlook client. In the branch network there is a WXC appliance used to optimize the traffic towards the data center network. In the data center network there is another WXC appliance that optimize the traffic towards the branch network. Also in the data center is a Windows 2003 server running all services including Domain Controller/Active Directory, DNS Server, Certificate Authority and all basic Exchange server roles (Mailbox, Hub Transport and Client Access Server).

2.1 Exchange server configuration

The steps below is based on the fact that the basic Windows and Exchange server software is installed and working. This means the Windows XP client is a domain member and has basic RPC connectivity with the Exchange server. In my lab environment I have all three basic Exchange server roles on the same server. If the customer has a distributed Exchange environment the steps below would apply to the Client Access server role.



2.1.1 Install the RPC over HTTP Proxy service

1. Click Start , point to Control Panel , and select Add or Remove Programs .

2. Click Add/Remove Windows Components .

3. On the Windows Components page, select Networking Services in the Components window, and then click the Details button.

4. On the Networking Services page, select the check box next to RPC over HTTP Proxy in the Subcomponents of Networking Services window, and then click OK.

5. On the Windows Components page, click Next .

6. Click Finish to close the Windows Components Wizard.

2.1.2 Install a valid SSL Certificate

When Exchange is installed it issues a self-signed certificate for the SSL based Client Access Service (handled through Microsoft’s Internet Information Services). This self signed certificate is not valid for use with Outlook Anywhere. You need to install a SSL certificate that has been signed by a trusted Certificate Authority.

In my lab environment used for this application note I have the Microsoft Certificate Authority installed in the Windows server which means I have created an internal/corporate CA structure. The CA certificate has been installed in the Windows XP machine as a trusted root certificate which means that any server certificate issued by the corporate CA is trusted by the Windows client.

In a real customer environment you probably will create Certificate Signing Request and have it signed by a 3rd party Certificate Authority.

If the customer does not have a valid SSL certificate, please do the following:

• Click Start , point to Administrative Tools , and then select Internet Information Service (IIS) Manager .

• Expand the view and select the Default Web Site .

• Right-click and select Properties .

• Next click on the Directory Security tab followed by the Server Certificate button.



1. Click Next and on the new screen select Remove the current certificate and click Next .

2. Click Next and Finish to complete the removal of the self-signed certificate.

3. Now you need to create a new certificate. Click on Server Certificate and then Next .

4. Select Create a new certificate and click Next .



5. Next select how you like to handle the certificate request. If you are going to use an external 3rd party CA you would select the “Prepare the request now, but send it later” option. In my case I have the Microsoft Certificate Authority available so I can select the “Send the request immediately…” option. Click Next to continue.

6. Next add a name for the certificate. The name is not important as such, but keeping it simple. Click Next to continue.

7. Next fill in relevant information in the Organization and Organization Unit boxes. Again, not important as such, but keep it real. This is information that is visible in the signed certificate. Click Next to continue.



8. Next fill in the common name of the certificate. This information is important to get correct. The common name is going to be used as part of the SSL server side authentication done by the Outlook client when it connects. It will match the common name in the certificate to the host name (DNS name) of the Exchange server when connecting. If there is a mismatch you will not be able to connect. Click Next to continue.

9. Next fill in the Country, State and City information. Again, not important as such, but keep it real. This is information that is visible in the signed certificate. Click Next to continue.

10. Next you can select which TCP port number SSL should use for the web service. The default is 443 which should be OK. Click Next to continue. NOTE!!! If you did choose the “Prepare the request now, but send it later”

option in step 5 you will be prompted to specify the location of the certificate

request file. Next would be step 12.

11. If you did choose “Send the request immediately…” option in step 5 you will need to select the Certificate Authority to send it to. Click Next to continue.

12. Next you will see a summary of the certificate request. Click Next to continue and Finish .

If you are using an online Certificate Authority and the Certificate Authority (like default in Microsoft CA) automatically signs the certificate request the server certificate will be installed automatically. If you are using an external 3rd party CA you need to click the “Server Certificate” button (see step 3 above) and follow the wizard to import the signed certificate.



2.1.3 Enable Outlook Anywhere

Next step is to enable the Outlook Anywhere on the Client Access Server.

• Click Start , point to All Programs , Microsoft Exchange Server 2007 and select Exchange Management Console .

• Expand the Server Configuration menu and select Client Access .

• Select the <server> you like to use for Outlook Anywhere.

• Click on the Enable Outlook Anywhere action item.

1. Enter the external host name used for Outlook Anywhere. This should match the common name of the server certificate created in section 2.1.2 step 8. Click Enable to continue.



2. Next you have to wait for up to 15 minutes to get Outlook Anywhere fully enabled. Click Finish to complete.

3. Check the Application Log in the Event Viewer . When you see a message like this the Outlook Anywhere service is fully enabled.

2.1.4 Check the RPC encryption requirement in the Exchange Server

By default in the installation in my lab environment the Exchange Server does not require RPC encryption, so this would be an optional step. But it is worth checking.

Click Start , point to All Programs , Microsoft Exchange Server 2007 and select Exchange Management Shell .

Now issue the Get-MailboxServer command.

If you see the statement False in the MapiEncryptionRequired column you are good to go.

If you see the statement True in the MapiEncryptionRequired column you need to issue the following command:

Set-MailboxServer <server> -MapiEncryptionRequired:$false

To active the change you need to restart the Exchange server.



2.1.5 Export SSL Server Certificate

This step is optional if you already have a copy of the SSL server certificate and private key to be used in the WXC configuration. In the example below I will create a backup of the SSL certificate from step 2.1.2 to be used in the WXC configuration.

• Click Start , point to Administrative Tools , and then select Internet Information Service (IIS) Manager .

• Expand the view and select the Default Web Site .

• Right-click and select Properties .

• Next click on the Directory Security tab followed by the Server Certificate button.

1. Click Next and on the new screen select Export the current certificate to a .pfx file and click Next .

2. Enter a filename . Click Next to continue.



3. Next enter and confirm a password for the certificate. This password is important to remember as it will be needed when later importing the certificate into the WXC. Click Next to continue. NOTE!!!! A .pfx (PKCS12) file does contain both the server certificate and the

private key.

4. Next you will see a summary of the certificate you are exporting. Click Next to continue and Finish to complete the export.



2.2 Juniper WXC appliance

The configuration steps below will enable the SSL Optimization feature in the WXC Appliances. I will enable SSL Optimization generically for the HTTPS application definition. This involves five configuration steps in both the branch office and data center appliance. In addition there is a sixth step in the data center appliance involving importing the SSL certificate/key which was exported in step 2.1.5.

The common steps for both the branch office and data center device is the following through the WebUI.

2.2.1 Enable TCP Acceleration for the HTTPS application

Go to the Acceleration , TCP Acceleration (AFP) menu.

Next check the check-box for the HTTPS application, scroll to the bottom of the page and click Submit to continue.

2.2.2 Enable compression and NSC the HTTPS application

Go to the Compression , Application Filter menu.

Next check the check-box for Compress and Network Sequence Cache , scroll to the bottom of the page and click Submit to continue.



2.2.3 Mark the HTTPS application as SSL based application

Go to the Device Setup , Applications , Definitions menu.

Next click the hyperlink on the HTTPS application.

Next check the Yes check-box and scroll to the bottom of the page and click Submit to continue.

2.2.4 Enable the HTTPS application for monitoring

Go to the Device Setup , Applications , Monitoring menu.

Next check the check-box for the HTTPS application. To be able to submit the configuration you can have max 40 monitored applications checked. Please uncheck some other application you are not interested in monitoring, like AOL for example. Scroll to the bottom of the page and click Submit to continue.

2.2.5 Enable the SSL Optimization feature

Go to the Device Setup , Encryption , SSL Optimization menu.

Check the Enable SSL Optimization for checked applications radio button.

Click Submit to continue.

NOTE!!! Don’t forget to Save the configuration on the client side WXC appliance at this point.



2.2.6 Import SSL certificate

This step is only needed on the WXC appliance closest to the Exchange server, in this lab environment this is in the data center network.

Go to the Device Setup , Encryption , SSL Certificates menu.

Next click on the Import button in the upper right hand corner.

Next fill in a Friendly Name .

Locate the certificate file created in step 2.1.5

Enter the password protecting the certificate file. Remember the password from 2.1.5 step 3.

Click Submit to finish the configuration.

NOTE!!! Don’t forget to Save the configuration on the server side WXC appliance at this point.



2.3 Outlook client

The steps below outlines the fresh setup of an Outlook 2007 client on a domain attached Windows PC. For already existing Outlook installation where Outlook Anywhere is later added are highlighted in section 2.3.3.

2.3.1 Fresh install

During a fresh install of the Outlook client it will utilize an auto discover feature in the Exchange server that will fill in most of the necessary configuration.

1. The first step after login into the domain is basically to start the Outlook client. This will bring up the E-mail account wizard. Click Next to continue.

2. Next step you basically select Yes to configure an e-mail account for the Outlook client. Click Next to continue.

3. On the next screen the username and e-mail address will be filled in by the information available in the Active Directory for the currently logged in user. Click Next to continue.



4. Next the Outlook client will use the auto discover feature to find the mail server and get the basic settings applied to the local installation. Click Finish to end the E-mail account wizard. NOTE!!!! Now the Outlook client will start and connect to the Exchange server

using normal TCP/IP based RPC (MAPI) connection. It will setup the local

Cache Mode store, etc. Just wait until the client is done.

2.3.2 Outlook Anywhere additions

After the Outlook client is fully in sync with the Exchange server you need to make some modifications to allow the Outlook client to prefer Outlook Anywhere (RPC over HTTPS) and to turn of RPC encryption.

1. Select the Tools , Account Settings menu option in the Outlook client.

2. Next highlight the e-mail account you like to change and click the Change option.

3. Next you will see the basic information about the e-mail account. Click More Settings to continue.



4. Select the Security tab and uncheck the Encryption option. This setting will disable the RPC encryption to allow the Juniper WXC to see the RPC data in clear for compression.

5. Next select the Connection tab and click the Exchange Proxy Settings button.

6. Now check the On fast networks,…. checkbox. This setting, in combination with the On slow networks,… option, will make sure the Outlook client always tries connecting with Outlook Anywhere (RCP over HTTPS) rather then regular TCP/IP based RPC (MAPI) communication. Next click OK to continue. NOTE!!!! Outlook defines a fast connection as a connection that is faster than 128 kilobits

per second (Kbps). Outlook defines a slow connection as a connection that is slower than

or equal to 128 Kbps.



7. Next you are back in the Microsoft Exchange settings menus. Click OK to save the configuration.

8. Next you should see this message. Click OK to continue.

9. You have now returned into the Exchange e-mail account settings page. Click Next to continue.

10. Next click Finish and Close to complete the changes. Next time you are restarting the Outlook client it will use Outlook Anywhere (RPC over HTTPS) rather then TCP/IP based RPC (MAPI)



2.3.3 Updating configuration on existing client

If you already have Outlook clients installed and at a later point in time add the Outlook Anywhere option on the Exchange server you need to update the Exchange E-mail account settings.

If this Outlook client has the ability to use the auto discover service (normally means the Outlook client is connected on the internal LAN/WAN network) you can do the following.

1. Select the Tools , Account Settings menu option in the Outlook client.

2. Next highlight the e-mail account you like to change and click the Repair option. This will kick of the auto discover feature as per 2.3.1 step 4. Next follow all the steps in 2.3.2 to make sure RPC encryption is disabled and the correct Outlook Anywhere settings.

If this Outlook client does not have the ability to use the auto discover service (normally means the Outlook client is outside the internal LAN/WAN network) you simply follow all the steps of 2.3.2 and manually fill in relevant information.



2.4 Verify functionality

There are a couple of basic checks you can do to verify proper functionality.

2.4.1 Verify Outlook Anywhere connection

First thing to verify is that the Outlook client indeed uses Outlook Anywhere (RPC over HTTPS) rather then TCP/IP based RPC (MAPI).

1. Keep <Ctrl> button pressed down while you click on the Exchange task bar icon . Next click Connection Status .

2. Check the Conn column. If it says HTTPS you know the Outlook client uses Outlook Anywhere (RPC over HTTPS). If the client uses TCP/IP based RPC (MAPI) it would tell you TCP/IP in the Conn column instead.



2.4.2 Verify compression of HTTPS sessions

The next thing to verify is if the Outlook Anywhere (RPC over HTTPS) sessions do gets compressed in the WXC appliances. In the WXC configuration option above I did use the generic HTTPS application definition to optimize the Outlook Anywhere traffic. The easiest way to check if compression is working is to:

Go to the Monitor , Compression menu. Select the Application Summary option in the Statistics drop-down menu and click Submit . If you have had some traffic going back and forth between the Outlook Client and Exchange Server you should see significant compression results.

If there are several HTTPS applications that are “sharing” the application definition you might consider creating a custom application definition for the Outlook Anywhere traffic.

Another more detailed way of verifying functionality on the WXC appliance is to:

1. Go into the Monitor , Traffic menu. Select All Compressed in the Traffic drop-down menu. Next click Submit to view results. Now locate, maybe with additional filtering, an Outlook Anywhere flow. Select the Dest Port number and cut the number (or remember it).

2. Next go to the Admin, Tools, Flow Diagnostics tool menu. Fill in the Destination Port number. Click Go to continue. Next you should see the search results. Click on the Magnifying icon to continue.



3. You can verify that is flow is matching the HTTPS application definition. You can verify that the SSL application acceleration module is kicking in. Now click on the Compression link. You should be able to see significant compression results. If everything else looks OK, but the compression results are low, less then 10 %, you should again check that the TCP/IP based RPC encryption has been disabled, see section 2.1.4 and 2.3.1 step 4.



3 Test results The test results presented below are taken from tests performed in the test environment outlined earlier in this document. Each test run, cold vs. warm, includes sending six different e-mails from the Exchange server (using Outlook Web Access on the server) towards the Outlook client in the branch office. Each e-mail was sent with a 30 second interval. Attached to each e-mail was a mix of Word documents, Excel spreadsheets and PowerPoint presentations of varying sizes. Each run generates around 12 Mbytes of data from the Exchange server. All reports are from the data center WXC appliance since the majority of the traffic in being sent from the Exchange server to the Outlook client.

3.1 Cold run results

The results below are for a cold run = no bit patterns in the MSR/NSC byte cache.

The result on the cold run for this traffic mix is expected. The e-mail attachments include not just ASCII text, but also images that are already highly compressed. This means MSR/NSC have a hard time compressing this part of the attachments.

With more ASCII based content of the e-mail the compression results for the cold test run would have been significantly higher.

The diagram to the right shows overall compression results for the cold test run.

The diagram below shows application specific breakdown.

Application Summary

Application Name Percent Traffic Percent Reduction Byt es In Bytes Out

HTTPS 100,0% 46,2% 12 510 814 6 731 677

DNS <1% 18,5% 270 220

0% 20% 40% 60% 80% 100%

Compression SummaryPeak Data Reduction 88,65 %Total Data Reduction 46,19 %Effective WAN Capacity 1,86 XTotal Bytes Into Reduction 11,93 MBTotal Bytes Out of Reduction 6,42 MB

Percentage Reduction

0

10

20

30

40

50

60

70

80

90

100

0 5 10 15 20 25 30 35 40 45 50 55

minutes

% r

educ

tion

Peak Reduction Reduction



The diagram to the right shows the average Inbound (coming into the Local port) vs. Outbound (going out of the Remote port) throughput. The delta is bandwidth saving done by the WXC appliance.

The diagram to the right shows Inbound (coming into the Local port) peak throughput. This is the burst rate the Exchange server is experiencing.

The diagram to the right shows the effectiveness of the Compression/MSR compression engine vs. the disk based compression/Network Sequence Caching (NSC). Basically you see on the cold test run that the main benefit comes from MSR. This is expected as NSC pattern cache is empty and in learning mode.

Detailed Compression InformationTotal Data Reduction 46,20 %Total Bytes Into Reduction 11,93 MBTotal Bytes Out of NSC 10,98 MBEffective NSC Capacity 1,09 XTotal NSC Reduction 8,00 %Total Bytes Out of Reduction 6,42 MBEffective MSR Capacity 1,71 XTotal MSR Reduction 41,52 %

Throughput

0

100

200

300

400

500

600

700

800

900

1000

0 5 10 15 20 25 30 35 40 45 50 55

minutes

Kbp

s

Data In Data Out

Burst Throughput (at Bytes In Peak)

0

200

400

600

800

1000

1200

1400

1600

1800

2000

0 5 10 15 20 25 30 35 40 45 50 55

minutes

Kbp

s

Data In



3.2 Warm run results

The results below are for a warm run = bit patterns are in the MSR/NSC byte cache.

The result on the warm run for this traffic mix is expected. Now the NSC pattern database is fully updated based on what patterns learnt during the cold test run.

The diagram to the right shows overall compression results for the cold test run.

The diagram below shows application specific breakdown.

Compression SummaryPeak Data Reduction 97,55 %Total Data Reduction 95,17 %Effective WAN Capacity 20,69 XTotal Bytes Into Reduction 11,95 MBTotal Bytes Out of Reduction 0,577 MB

Percentage Reduction

0

10

20

30

40

50

60

70

80

90

100

0 5 10 15 20 25 30 35 40 45 50 55

minutes

% r

educ

tion

Peak Reduction Reduction

Application Summary

Application Name Percent Traffic Percent Reduction Byt es In Bytes Out

HTTPS 100,0% 95,2% 12 526 362 605 494

0% 20% 40% 60% 80% 100%



The diagram to the right shows the average Inbound (coming into the Local port) vs. Outbound (going out of the Remote port) throughput. The delta is bandwidth saving done by the WXC appliance.

The diagram to the right shows Inbound (coming into the Local port) peak throughput. This is the burst rate the Exchange server is experiencing.

The diagram to the right shows the effectiveness of the Compression/MSR compression engine vs. the disk based compression/Network Sequence Caching (NSC). As you see on the warm run the NSC part of the compression engine really kicks is, but also the MSR compression engine performs better to a great overall result.

Throughput

0

200

400

600

800

1000

1200

0 5 10 15 20 25 30 35 40 45 50 55

minutes

Kbp

s

Data In Data Out

Burst Throughput (at Bytes In Peak)

0

500

1000

1500

2000

2500

0 5 10 15 20 25 30 35 40 45 50 55

minutes

Kbp

s

Data In

Detailed Compression InformationTotal Data Reduction 95,17 %Total Bytes Into Reduction 11,95 MBTotal Bytes Out of NSC 1,87 MBEffective NSC Capacity 6,41 XTotal NSC Reduction 84,39 %Total Bytes Out of Reduction 0,58 MBEffective MSR Capacity 3,23 XTotal MSR Reduction 69,03 %



4 References

4.1 Internet links

WXOS 5.7 – Operator’s Guide

http://www.juniper.net/techpubs/hardware/wx/srs/57/wxog_57.pdf

All WXOS documentation overview

http://www.juniper.net/techpubs/hardware/wx/

More information about Outlook Anywhere

http://technet.microsoft.com/en-us/library/aa998950%28EXCHG.65%29.aspx

http://technet.microsoft.com/en-us/library/bb123513%28EXCHG.80%29.aspx

More information about changing Microsoft Office settings through the use to Group Policies and Policy Templates

http://support.microsoft.com/kb/924617

Optimizing Outlook Anywhere with Juniper...

Documents

Transcript of Optimizing Outlook Anywhere with Juniper...