Many of the customers I work with are currently making their way through an Office 365 technical pilot that needs to include Mac OS X machines as well as various versions of Windows.  The Windows stuff seems fairly well documented and since we now have a GA release of Lync 2011 for Mac OS X I thought I would write a post about using OS X with Office 365…

Note:  Most of this is documented on the following page, however it does not include Lync or any screenshots..

• http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh180727.aspx
  

Software requirements for Mac OS X and Office 365

There are some things that you need to know before rushing out to connect your Max OS X machines to Office 365.  Firstly you will need a version of Outlook that supports Exchange Web Services (EWS).  Older versions of Outlook for Mac used WebDAV which is not provided in Exchange Server 2010 and therefore is also not available in Office 365.  Plus there are some minimum versions of Mac OS X and Browsers that are supported…

• Microsoft Office for Mac 2011 Service Pack 1+
• Microsoft Lync for Mac 2011 (v14.0.1)
  
• Microsoft Office for Mac 2008 12.2.9+
• Microsoft Entourage 2008 for Mac, Web Services Edition
  
• Mac OS X 10.5.8+
  
• Safari 4 or 5
• Firefox 3.5 or 4
• Chrome 3

Note: If you are using an internal CA for any of your Exchange or ADFS servers you must import the root CA certificate onto your Mac before working through these steps…

For the purposes of this article I will concentrate on Office 2011 since it represents the best end user experience and it is also the version I have the most experience with (and happen to have handy!).

Connecting to Office 365 Web Portal

OK, so this bit isn't very exciting however it is always my first step since it proves that my Office 365 account credentials are good and that the Mac has connectivity to the Office 365 service and ADFS.

1. Open your browser (In this example I am using Safari 5)
2. Navigate to https://portal.microsoftonline.com
3. Login with your Office 365 user credentials
4. Click on the Outlook link to connect to Outlook Web Access
5. Select the Language and Time Zone preferences (if prompted)

Assuming everything went well, you should now be looking at your Office 365 users Outlook Web Access page via OS X Safari!  For some of my customers this is actually “good enough”, however for the large majority they need the rich experience provided by Outlook and Lync on their Mac… so we need to continue on

Connecting Outlook 2011 for Mac to Office 365

Ok, so we have already connected to OWA via Safari so the next thing to do is configure Outlook.  When you start Outlook for Mac 2011 the first thing it will ask you to do is to Add Account…

• Click the checkbox to make Outlook the default application for e-mail, calendar and contacts then click Add Account

• Once the Add an Account page is displayed, click on Exchange Account
• Fill in your account details on the Exchange Account Information Page, ensure that Configure Automatically is checked and then click on Add Account

• Outlook will warn you that your AutoDiscover request has been redirected to a different server
• Ensure that the Always use my response for this server checkbox is checked and click on Allow

• At this point Outlook will reconfigure itself to connect to your Office 365 mailbox by using the data from AutoDiscover
• I typically also change the Account Description on the next page to show that it is an Office 365 Account

• Close the Accounts Window and Outlook should show as connected and begin synchronising your mailbox content…

Connecting Lync 2011 for Mac to Office 365

NOTE:  Lync 2011 requires an update to connect to Office 365 which is provided here…

• http://support.microsoft.com/kb/2634523

I have to admit that despite being a Microsoft Employee I am also a Mac user (occasionally anyway) and for me Lync was the missing piece of the puzzle for making a Mac a usable experience.

Anyway, enough of that lets move on to connecting Lync…

• Start Lync for Mac 2011
• The first thing that Lync will ask is to set it as the default application for presence – if you want presence information then select Use Lync
• The next screen will be the Lync for Mac 2011 login screen
• Click on the Advanced icon at the bottom

• Click on the Advanced button at the bottom of the Lync client
• Set Internal Server name to sipdir.online.lync.com:443
• Set External Server name to sipdir.online.lync.com:443
• Click OK

• Enter your login account details and password
• Check the Remember my password checkbox and click Sign In

• If everything went to plan, you should now see your Microsoft Lync for Mac 2011 client open up and show as connected!
• I suspect this isn't actually that exciting to everyone, but I (and some of my customers) have been waiting for nearly a year to get this far!

The screenshot below shows my OS X Lion desktop connected to Microsoft Office 365 via a federated Active Directory account… and who says Microsoft and Apple cant work together!

Conclusion

As a regular Mac and Windows user it is vital to me that my systems are able to collaborate and share data effectively.  It is also vital that I am able to communicate and collaborate effectively with my colleagues running Windows or Mac machines.  I have to say that prior to having Lync my Mac experience was definitely lacking… however now I can connect Outlook and Lync to Office 365 I am able to function just as effectively on my Mac as I am on my Windows 7 machine.  Being able to join conference calls, share my desktop etc even when I am on my Mac is a huge improvement to my productivity…

Having worked with a few customers who have a Mac OS X community to support I have to say that connecting them to Office 365 has been relatively painless…  in fact it is arguably easier to connect a Mac running Office 2011 to Office 365 than Windows; largely since OS X doesn't require any patch updates or the Windows Live Sign In Assistant to connect reliably.  The biggest problem area that I have seen is that organisations who have chosen to use their internal CA to issue certificates for their internal Exchange and ADFS services, must remember to import the root CA certificate on every new Mac that is deployed… failure to do this leaves the machine unable to authenticate to ADFS and AutoDiscover failing to configure Outlook.

Overall though I have to say that this is great work from both the Office 365 and Office 2011 for Mac teams…!

Hello everyone … My name is John Rodriguez, and I'm a Principal PFE based in Minneapolis, MN. I'm also one of Neil's frequent collaborators, particularly on load simulation tools. When he wrote his recent article on performance analysis of Jetstress data, I suggested that he include some of our time-saving tips. He's a busy chap, and asked me to write the article instead. So, to that end, I'm here as a guest contributor to share with you some of the things we as performance specialists do within Perfmon. [Neil: Actually John taught me Exchange perf when I first joined Microsoft in 2007 and again when I went through MCM; it is a great honour to have him write stuff for my blog, so thanks again John J].

If you spend a lot of time in Perfmon, whether for general performance analysis, reviewing Jetstress data, or trying to identify the source of a bottleneck, you tend to look for ways to automate tasks – to simplify things. Thankfully Perfmon provides some extremely useful interfaces which provide us with our time-saving opportunities.

When you first launch Performance Monitor, and switch to the Performance Monitor node, you should see the general screen with a single counter (usually Processor(_Total)\% Processor Time). In the example below, I've deleted the default counter and added four specific ones of great Exchange importance: MSExchangeIS\RPC Averaged Latency, \RPC Operations/sec, \RPC Packets/sec, and \RPC Requests.

How did I add those counters? Believe it or not, I pasted them. Pasted? Into Perfmon? Really? Yes, really. Here's how.

When you first launch Perfmon and want to add counters, you can click the green Plus symbol, or right-click the display and select "Add Counters…" as shown below.

Now, if you look at the context menu, you can see an option to "Save Settings As…" This is one of the most underappreciated items in Perfmon, and enables a lot of incredibly useful behavior. "Save Settings As" predictably enough saves the existing set of counters to an HTML file which you can then open and edit to your heart's content. If you right-click the file and select Open With > Notepad, you should see a bunch of entries beginning with <PARAM NAME="Counter#" and then details on the counters themselves, like so:

[It's important to select Open With > Notepad, rather than double-click on the file. We'll see why in a minute.]

Notice that there's no server name in this data – the value is just the counter name – "\MSExchangeIS\RPC Averaged Latency", "\MSExchangeIS\RPC Packets/sec", and so on. This means that this set is rather portable – to our great advantage. I can use this information to automatically add a whole group of counters to Perfmon at once. But we're not going to load them from the file – we're going to paste them into Perfmon! This may sound odd, but Perfmon actually supports copy-and-paste. If I want to add all of those counters at once, I can simply open that HTML file with Notepad, copy the contents (select all, copy), open Perfmon, click anywhere in the right-hand pane, and then click Ctrl-V, Perfmon will add all of those counters at once. In other words, if you add the counters to one server, and save the settings to HTML, you can quickly add all of those counters for any other server! This is extremely useful, but we're only just getting started.

Now that we have our settings file (in my case, "rpc counters.htm"), we can perform a few little tricks. First, since it's HTML, we can actually open this settings file with Internet Explorer. Unless you've weakened the security settings for IE, you'll need to click "Allow blocked content", but do that and you see Perfmon embedded within Internet Explorer:

Notice that Perfmon includes not just the counter list I added before, but visible data points as well (which was saved in the settings file). But more importantly, this is a fully functioning instance of Perfmon. Notice the two green buttons in the menu bar at the top of the Perfmon instance – the one on the left (similar to the "Play" button on a CD or DVD player) switches the display to live data, while the second (the "Skip Forward" button) leaves the display paused but updates the data to the present moment.

The green "Play" button has changed to a blue "Pause" button, and many of the other buttons have also been enabled as well (including add and remove counters).

"This is nice," you may say to yourself, "but what good does it do?" Well, for one thing, you can select a specific set of counters, save the settings file, and then distribute the settings file to your teammates so that they can open that same set of counters. This is very useful if you have a large set of counters and want to make sure that everyone's looking at the same data.

Where the "Save Settings As" option really becomes useful is when you're working with performance logs (BLG files). In this case, I've captured performance data using a custom Data Collector Set, and the results of the data are saved in C:\Perflogs\Admin\New Data Collector Set\DC1_datetime.log. I switched back to the Performance Monitor tab, and selected View Log Data from the action menu (you can also press Ctrl+L to do the same thing).

On the Data tab, I select all four counters from the log file and add them into the list to display.

Because I don't have very much data in the BLG, the resulting display isn't terribly exciting. But it's not the display that I'm concerned with here – it's what I can do with the data I selected. Again, I right-click and select "Save Settings As" and save the list of counters to another HTML file. [Side note: when you select "Save Settings As" when viewing data from a BLG, other options become available, including Save Data As, which gives you the option to reduce the size of an existing BLG by saving only a subset of data points.]

However, when you open this second HTML file, you'll notice that things look a little different. The counter names are prefaced by the server name:

My lab machine is named DC1, but if I want to use this on a performance log I collected from DC2, all I need to do is a simple find-and-replace in the HTML file, open the appropriate saved log (View Log Data), and then perform the same copy/paste trick listed above. Again, Perfmon will add all of the relevant counters directly into the display. That means that you can create the list of counters once and use that same list for every single BLG you want to review. Just change the name of the server within the HTML file for each server, then paste the contents.

To summarize, Perfmon allows you to save and load sets of performance counters, and you can use this functionality to make your performance life a little easier. By saving the settings to disk, you can ensure that you use the same list every time, even if you've closed Perfmon. You can launch Perfmon from within Internet Explorer using a saved settings file, which helps ensure consistency so that everyone uses the same counters. Last, you can use a settings file as a template to view the same set of counters from different BLG files from different servers.

Hopefully these tricks help you become more efficient in your use of Perfmon. Let us know in the comments!

I have been involved in a number of discussions recently regarding Outlook performance troubleshooting in the cloud. Mostly these discussions were in the context of why the customer didn't want to move to the cloud since they figured it would be impossible to troubleshoot Outlook performance afterwards

Discussion Summary:

When we have clients and Exchange on terra firma we can monitor some performance counters such as RPC Average Latency on Exchange and use the Outlook and client performance counters to establish if a poor end user experience is being caused by the Exchange Server, the Network or the Client machine. If we move the messaging service out to the Office 365 cloud we can no longer monitor RPC Average Latency so we don't know if poor performance at the client is being caused by network or the Exchange server.

Outlook Performance

This started me thinking about how to deal with this situation and what items make up the client experience from an Outlook performance perspective.

The following items can both have a fairly dramatic effect on Outlook client performance and either could cause the end customer to pick up the phone to support and say that "E-mail is slow".

• MAPI RPC Latency
• Client system performance

If we make the assumption that our service is running in the Office 365 cloud, how do we go about determining the actual cause of Outlook performance problems?

MAPI RPC Latency

RPC Latency is made up of two parts

• Server side RPC processing
• Round-trip-time Network Latency

Network latency is probably the easiest to examine on the surface since we really just need to use ping.exe to find out what our TCP round-trip-time (RTT) value is to the target server. There is a snag though, as you might expect…

Here is the ping response from my Office 365 server…

Not exactly useful since ICMP Echo is blocked at the external firewall. So, if we can't use ping.exe how do we determine our Network RTT latency? Well, luckily Outlook has us covered here and keeps a track of some stuff that can help us out…

In your task tray you should see an Outlook Icon. If you hold down CTRL + RIGHT CLICK on this icon it will show the Outlook context menu…

From the Outlook Context menu select "Connection Status"

In the Connection Status dialog box find the columns called Avg Resp and Avg Proc. The difference between these two values represents the network latency for each connection.

In this example you can see that I have two logical connections listed as Mail (To see the physical TCP connections use TCPview). This is normal for a cached mode Outlook 2007+ client. One connection is used for item synchronisation and the other is reserved for sending new messages. This architecture prevents sending a large message from blocking Outlook receiving new items like it did in Outlook 2003.

Generally speaking the connection with the larger Req count is for synchronisation which is the one we will use in this example.

• Avg Resp is 87ms
• Avg Proc is 10ms

This means that my Network RTT time is 77ms and the Server side RPC processing latency is 10ms.

In my example this makes perfect sense since I am based in the UK and my mailbox is hosted on Office 365 in North America. It also shows that my Network and Server latency are within acceptable limits.

Generally speaking I use the following recommendations to maintain a good client experience in Cached mode for Outlook 2007 and later.

• Max Avg Proc Time (Exchange RPC Latency) = 25ms
• Max Network RTT Time (Network Ping Time) = 300ms
• Max Avg Resp Time (Exchange RPC Latency + Network Latency) = 325ms

Once armed with these values it is possible to direct troubleshooting more specifically. For example, if Network RTT is high you could look at your network links or firewalls. If the Avg Proc time is high then a call to Office 365 support might be in order.

One final point here is to check the Req/Fail column. A high value for Fail represents high number of network disconnection events. If this is combined with a high Avg Proc time it potentially points to a service issue in Office 365, however if Avg Proc is good then it suggests that you may have a network connectivity problem between the client and the service. A common cause of this is source port exhaustion for environments with more than 2000 users.

Client System Performance

So what happens if the Network and Exchange RPC metrics are all good but the end customer is still experiencing poor Outlook performance? Since we have ruled out Network and Exchange performance the most likely culprit is the client workstation.

So what could be causing Outlook performance problems on the local workstation?

For this we need to look at the usual trinity of performance areas within the operating system

• CPU
• RAM
• DISK I/O

To take a look at these further I am going to use Process Explorer.

Client CPU

Outlook is generally not that CPU intensive, however if your CPU is flat out doing other stuff then Outlook will respond slowly. To check this, open Process Explorer and arrange the table in descending CPU order.

We are looking for a few things here. Firstly what is our System Idle Process value? This tells us how much CPU time we have spare. Generally speaking if this value is less than 20% the system will feel sluggish. In my example you can see that I have plenty of CPU time available and so it is unlikely CPU is an issue here.

If Outlook appears at or near the top of this list then the most likely culprits are that you have a faulty add-in installed, (try running Outlook in safe mode), or that your OST file is damaged (Try running the Inbox Repair Tool).

To get a better idea of how Outlook is consuming resources, find OUTLOOK.EXE in the Process list, double click it and then open the Performance Graph tab in the properties dialogue box.

This will show some historical values for CPU Usage for the Outlook process. Even a large Mailbox (mine is 10GB) shouldn't require Outlook to take up a large amount of CPU time.

Client RAM

Insufficient RAM has a number of effects on Outlook. Firstly the process can be starved of physical RAM and so run slowly; secondly the operating system will have to page large chunks of memory to disk which will cause disk I/O problems. Since we are going to look at disk I/O in the next section, I will just look at identifying client memory problems here.

It is important to realise that Windows will page out an amount of memory to the page file and this both normal and advantageous. However, where the system has significantly more committed memory than it can accommodate in physical RAM we may run into performance problems as the process accesses its data in virtual memory and instead has to wait for that data to come from disk. This process is known as hard paging. A sustained high level (>5) of hard page faults is a strong indicator that there is not enough RAM in the system.

Unfortunately Process Explorer can't help us here since it shows a combination of hard and soft paging. For this task we are going to need to break out Performance Monitor (perfmon.exe).

Open, Perfmon and then add in the MEMORY\Page Reads/sec counter.

You can see clearly that this system has to retrieve data from the page file frequently. In fact this is from a virtual machine running Windows 7 and Outlook 2010 in 512MB RAM with a 5GB mailbox. Almost every single action performed within Outlook triggers a spike in Page Reads/sec. The user experience is very slow, however if we look at the Exchange Connection status for this client…

• Avg Resp = 4ms
• Avg Proc = 0ms

This clearly shows that the poor user experience is being driven by the client and not by the server or network and more importantly that a bit of extra RAM is likely to make this customer happy – clever right? J

Client Disk I/O

This is a bit of a soapbox of mine at the moment. As Exchange professionals we go to great lengths to monitor our messaging service on the basis that we want to provide the best user experience. However, the reality is that the most likely cause of poor user experience is accessing a large Outlook OST file stored on an underperforming client system. Over time these OST files generally reach roughly double the size of your mailbox. If we take Office 365 as an example with a 25GB quota, this means that it's not impossible for a user to have a 50GB OST file on their laptop HDD. Let's think about that for a minute… we have a 50GB file, with data in it that we need to access quickly – if that was a Word document or Access database most users would accept a minute or two's delay as it was opened and yet we expect Outlook to open it in 5 seconds or we think something is broken J

Speedy access to a large OST file access relies on two things…

• A fast HDD that isn't dealing with too much other stuff
• A mostly contiguous OST file

HDD Usage

If the hard disk drive is busy doing other things then Outlook in cached mode will perform slowly and deliver a poor user experience.

Physical Disk\Disk Queue Length

This is a measure of how many requests are waiting for the disk. Ideally the disk queue length should be no more than 1.5-2 times the number of disks that make up the volume. For most client workstations this means that disk queue length should be <2. As a general rule don't provide older laptops with 5400rpm HDD's very large mailbox sizes, i.e. don't just give everyone a 25GB mailbox without checking to see if their hardware is going to cope J

Contiguous OST File

Since Outlook makes frequent reads and writes to the OST file it can become very fragmented over time. A heavily fragmented OST file (>1000 frags/file) can lead to poor Outlook client performance.

The easiest way to check and defragment the OST file is via the sysinternals tool contig.exe. First close down any applications that may be accessing the OST file, such as Outlook or Lync.

To check the OST file for fragmentation use the command

• Contig.exe –a <path to OST file>

Note: You must be running contig.exe with elevated privileges to perform defragmentation.

To defragment the OST file use the command.

• Contig <path to OST file>

Conclusion and further reading

Outlook performance is just like any other application. It relies on CPU, Memory, Disk and Network. If any of those resources are performing badly then the end customer is likely to experience poor performance. Exactly the same troubleshooting processes apply on-premises or for Office 365 users. The only real difference that applies to Office 365 performance troubleshooting is that we cannot directly observe Exchange performance counters and so we need to rely on the data that Outlook provides us.

I often see customers struggle to make use of the export mailbox features in Exchange Server 2010.  I suspect this is because it is an area that has changed in the last few years and there is a lot of conflicting information online that doesn't clearly state which version of Exchange the information is for.  I thought I would write this to explain how to export mailbox data in Exchange Server 2010 RTM and the changes that were made in SP1.

Exchange Server 2010 RTM

With Exchange 2010 we introduced RBAC to control access rights, this required a change in role assignments before we could use the cmdlet, it also brought a change to 64-bit only code which meant that we need a 64-bit installation of Outlook before we can successfully export a mailbox…

Requirements

• Permissions assigned to user via RBAC
• Exchange 2010 Management Tools Installed
• 64-bit version of Outlook 2010 installed
• .Net Framework 3.5
• PowerShell 2.0

To assign RBAC permissions to a user…

   1: New-ManagementRoleAssignment –Role “Mailbox Import Export” –User “<username>”

To Assign RBAC permissions to a group

   1: New-ManagementRoleAssignment –Role “Mailbox Import Export” –Group “<usergroup>”

After assigning permissions it may be necessary to logoff and back on or to close and re-open your PowerShell window.

   1: Export-Mailbox -Identity john@contoso.com -PSTFolderPath C:\PSTFiles\john.pst

Exchange Server 2010 SP1

With the release of Exchange Server 2010 SP1 the export-mailbox cmdlet was replaced with new-mailboxexportrequest, it has similar requirements to export-mailbox, however it does not require Outlook to be installed.

Requirements

• Permissions assigned to user via RBAC
• Exchange 2010 Management Tools Installed
• .Net Framwork 3.5
• PowerShell 3.5
• Exchange Server 2010 Service Pack 1

To assign RBAC permissions to a user…

   1: New-ManagementRoleAssignment –Role “Mailbox Import Export” –User “<username>”

To Assign RBAC permissions to a group

   1: New-ManagementRoleAssignment –Role “Mailbox Import Export” –Group “<usergroup>”

After assigning permissions it may be necessary to logoff and back on or to close and re-open your PowerShell window.

   1: New-MailboxExportRequest -Mailbox AylaKol -FilePath "\\SERVER01\PSTFileShare\Ayla_Recovered.pst"

Over the past 18 months I have been dealing with more and more cloud engagements.  One thing that crops up during the planning phase of all of these engagements is network link latency and bandwidth requirements.

Bandwidth prediction is something I am working on in the background, but network link latency seemed like a mystery!.  Everywhere I looked and everyone I spoke to had a different opinion on “maximum latency” for Outlook clients.

So.. I decided to try to devise a test that would let me model the impact of network link latency on Outlook client performance.  My lab already had a network emulator installed that was capable of simulating link latency so all that I needed was a script to automate Outlook to perform some common tasks, then record how long the script took to run – easy right?

Automating Outlook…

I already had some scripts for Outlook 2010 from my bandwidth prediction work, so I decided to make use of them.  The scripts were written with AutoIT which is a regular part of my lab testing toolkit these days!

Software versions in use for all tests…

• Windows 7 Service Pack 1 32-bit
• Outlook 2010 Service Pack 1
• Exchange Server 2010 Service Pack 1

Note: All tests began from a cold start i.e Outlook was not running.

Test definitions

Note: All clients were tested from 0ms added latency to 1000ms in steps of 100ms and then up to failure point from 1000ms onwards in steps of 500ms.  Failure was deemed to be if any single test failed.

Test 1. Sending

• Send 5 messages with 2 x 50kb attachments

Test 2. Opening

• Open 10 messages with 2 x 50kb attachments
• save attachments to disk

Test 3. Delegates

• Open delegates
• Add in a new delegate
• Remove delegate

Test 4. Out of Office

• Open out-of-office
• Enabled message and set OOF
• Switch OOF off

Test 5. Calendar

• Open calendar
• Add in shared calendar
• close shared calendar

Notes:

• For all cached mode tests a final sync was performed and test did not completed until the outbox was empty.
• Outlook Anywhere was configured to connect over HTTPS on fast networks to reduce start-up delays.
• Windows 2008 R2 CA PKI was used to issue Exchange certificates in the lab.

Results

I decided to run tests 1-5 sequentially for three types of client connections

• Outlook 2010 Online
• Outlook 2010 Cached Mode
• Outlook 2010 Outlook Anywhere (RPC/HTTPS)

Note:  All latency values represented are round-trip times RTT as reported by ping.exe from a command line.

Combined test case results

What is evident from this set of results is that the impact of network link latency is linearly related to outlook client performance.  Certainly when we consider a broad range of functions.  Cached mode dramatically reduces the user wait time for send/receive functions, but it was obvious watching the test run that whenever actions were requested that ran outside of the OST file, such as delegate access or out-of-office requests large delays were experienced at higher latency values.  I decided to set the maximum test run time limit at 200 seconds, which was double the test run time with no additional latency applied.  Client behaviour when the test duration was taking 200 seconds was the poorest performance level that I perceived to be acceptable by anyone for this test.  I judged that if any single operation took 10 seconds or more to display a dialog box or the client appeared to hang then it was unacceptable for the end user. 

In this combined test the limiting task was working with the delegate permissions, which was taking approximately 9 seconds to complete at the maximum test run time.  Accessing delegate permissions was similar amongst all connection modes. 

The results for Outlook Anywhere were confusing initially, although the majority of the difference between Cached and Cached-OA is due to the additional time it takes for an Outlook Anywhere connected client to establish its initial connection.  Typically an OA client will take around 10 seconds longer to establish a connection when compared to a normal RPC MAPI connection.  This rises to around 30 seconds at 800ms latency.  Under use both Outlook Anywhere and Cached mode performed with very similar results.

Combined test conclusion

The test results for me were quite interesting.  Prior to this testing I had assumed that Outlook tolerance for link latency was was much worse than the test results show.  This is no doubt due to changes in adaptive TCP windowing on Windows 7 plus improvements in Outlook 2010.  The bottom line is clear though, Outlook 2010 on Windows 7 is able to tolerate quite high network link latency values before performance begins to suffer noticeably.  In the case of Cached mode and Outlook Anywhere both clients were able to tolerate 500ms round-trip-time latency without problem and if your main tasks are sending and receiving mail only, cached mode actually provided a good experience at up to 1000ms round-trip-time latency.  Online mode was far more sensitive to network link latency as expected and performance became noticeably slower at 190ms round-trip-time and above.  Online mode was still usable above 200ms latency but felt sluggish.

Failures

One thing that I didn't account for during this test was that the clients would behave differently as latency increase.  My automated script initially didn't cope very well when Outlook in online mode was subjected to high latency values.  The long pauses before dialog boxes were displayed made things quite tricky at times, AutoIT is extremely capable though which really helped in this testing!.

The following failure points were noted..

• Outlook 2010 Online Mode – General script failure at 800ms (gave in trying to make it work – “Outlook is not responding” )
• Outlook 2010 RPC/HTTPS – Delegates page failed to open at 2000ms
• Outlook 2010 Cached Mode – Delegates page failed to open at 2000ms

Note: Although the cached mode clients failed at 2000ms for delegate access the client continued to provide usable mail performance.  I plan to run further tests in cached mode to see where the break point is for mail only users since this represents the majority of users.  Keep watching my blog for more information on this test

Other thoughts…

This test was designed to isolate the effects of network link latency on client performance, however the reality is that network link latency is only one part of the Outlook client performance experience.  In practice it is more likely that poor client performance is caused by local hardware limitations or insufficient resources allocated on the Exchange Server itself.   This testing does show however, that consolidating Exchange Server resources into central locations is viable with Windows 7 and Outlook 2010.

OK, that's great, but what about OST file resync?

So.. this is an interesting question that came to mind while I was performing this testing.  We can provide a good user experience in normal day to day tasks over quite latent network links, but what happens if I need to rebuild my OST file?  OST file resync is a fairly common occurrence; even if we just consider cases of SATA HDD failure (5% AFR typically), that means in an organisation of 30,000 laptop users there will be approximately 1500 OST resync’s per year (7.5 per working day!) due to HDD failure.  I was curious about how long it would take to synchronise an OST file under specific latency conditions, so I ran some tests….

I created a 100MB mailbox then timed how long that took to synchronise down as latency increased, I then calculated how many seconds it took per 1MB of data.  My plan was to use this to extrapolate how long larger mailboxes would take to synchronise down.

Note: I had initially planned on doing this experimentally but then the reality of having to run 10 or more tests each taking 20 hours or longer to complete set in and I decided to deal with it theoretically.  I may run a few tests to validate the theory when i get time though.

Using this data I was able to extrapolate how long it would take to fully synchronise down a 25GB mailbox (default Office 365 quota limit).  Given the assumption that there is always sufficient network bandwidth available, the data looks as follows…

This data suggests that even if a cached mode client were running over a  500ms round-trip-time network latency connection that it would be possible to fully resynchronise their 25GB OST file within 43 Hours.  This would require a throughput of 1.34Mbits/sec.

One of the customers I am working with is considering a 5GB quota within their Office 365 tenant so I promised them I would consider their case specifically, so here is the data for a 5GB OST sync.

Taking the same point of 500ms, this prediction suggests that their 5GB OST file would be fully synchronised after 8.6 Hours, assuming that the client had 1.33Mbits/sec of network bandwidth available.

To perform your own predictions using this data use the following form…

T = ( M ) x (( 0.0114 x L ) + 0.3208 )

Where

• T = Time to Sync ( seconds)
• M =Mailbox Size (Megabytes)
• L = Network Link Latency Round-trip-time (milliseconds)

Further tests

This testing sparked a few thoughts in my mind, that I just didn't have time to follow up (and I was being harassed by various colleagues and customers to release the data i had!) … anyway, the following are areas i plan to research further when time allows…

• What effect does disabling the Windows 7 TCP Adaptive Windowing feature have on Outlook client performance over latent network links?
• How does Outlook 2007 compare to Outlook 2010 in this test?
• Where do Cached Mode and OA clients break when just sending and receiving E-mail

Final Conclusion…

For me this test data suggests that network latency is not as critical for client performance on Windows 7 with Outlook 2010 cached mode as it used to be on legacy operating systems.  It also shows that the adaptive TCP windowing in Windows 7 goes some way to alleviate the negative effects of network latency.   Certainly for my current projects it has allowed me to consolidate more mailboxes into a central location than i would have initially thought possible and the client involved tells me that end user performance is good.

If you are considering running Outlook clients over high latency connections I would urge you to perform a full user pilot to establish your users tolerance of client performance.  Also some Outlook plugins can have a dramatic effect on how the client performs under very latent conditions.

Neil.

Updated: 17/06/2011