This post is written by Scott Bradley, a Principal Escalation Engineer for Office in the Microsoft Customer Support Services group.
Delegate Access is an Outlook feature that enables one person to act on behalf of another Outlook user. This feature is a combination of shared folder access and special handing of meeting requests. It is commonly used for manager/assistant duties, such as the assistant scheduling and sending meetings on behalf of the manager, or the assistant monitoring the manager’s email.
When a delegate works with several mailboxes of significant volume, we call this a super-delegate scenario.
Imagine super-delegate Jane, who is a delegate at the highest level of the company. Jane works in Outlook 2010 all day every day, finding emails, handling meeting information, etc. She clicks around and uses various features of Outlook 2010 with great efficiency, and her goal is to have generally good performance for each of her tasks.
Jane typically has an Outlook profile that has:
Very often, the super-delegate also has to adhere to data management constraints that you have implemented in your organization. For example, imagine that you have configured your environment such that:
Sound complicated? We’re here to help. Over the years, Microsoft has developed a set of best practices for configuring super-delegate scenarios. In this blog post, I’ll cover recommendations for:
There are two fundamental choices for configuring super-delegates, each with benefits and limitations. The driving factor for each of these configurations is to control the size of the OST file. For these recommendations we will not consider scenarios where folders are accessed online because the latencies typically associated with online access would be more problematic than the performance considerations around the OST size.
Option A: Add the manager’s account as secondary Exchange accounts (multi-ex)
At the end of this post is a description and screenshot that shows how to create a multi-ex account and also how to add an additional mailbox.
Option B: Use folder Level Sharing
If you decide that the folder level sharing configuration (option B) is the best scenarios for the super-delegates, then you must understand three different methods of setup for the shared folders and the implications of each method. Specifically, it is vital that you understand the “automapping” feature of Exchange/Outlook and how it fits into the folder sharing methods.
Method 1: Standard Delegate/Folder Sharing – This is the method where you just use the delegate feature from Outlook 2010 to assign a delegate. As part of the delegate setup, Access Control Lists (ACLs) are assigned to the delegate folders, and those folders can then be accessed from the delegate machine through various UI choices (Open Other User’s Folder, Open Shared Calendar, Sharing Requests, etc). This method does NOT imply or require permission for the entire mailbox.
Method 2: Add Additional Mailbox – This “legacy” feature from the advanced tab of the account properties, allows the user to add the mangers mailbox STORE to their profile. This is not the same as the multi-ex feature that was described in Option A above. What is required for this method of sharing is that there is at least “folder visible” permission to the root of the mailbox store.
Method 3: Full Mailbox permissions/automapping – When you assign full mailbox permissions for a user to a manager mailbox, Exchange sends down information in the autodiscover data that tells Outlook to automatically add the shared mailbox to the profile. This creates a very unique and challenging set of facts:
Because of the current side effects of automapping, we recommend that it not be used for these super-delegate scenarios. Exchange Server 2010 SP2 provides a PowerShell cmdlet to disable the automapping feature and that should be used when configuring shared folder access.
The preferred method of folder sharing will be driven by the access needs to the folder set. If the delegate user needs access to all folders in the manger store, then the recommendation would be to:
This configuration would accomplish the following:
Outlook and Exchange define the term “delegate” differently. To Exchange, “delegate” just means someone with the send on behalf right for an account. To Outlook 2010, “delegate” means an entire feature set consisting of the send on behalf right, permissions to the delegate folders, a forward rule to forward meeting requests to the delegate, and various properties and code to keep track of “extras” like how many months of free\busy the manager is publishing, and so forth. Therefore, to the question of how delegates should be added, the recommendation is that if you want the full feature set of an Outlook delegate, you must use Outlook to add delegates. If the goal is to only use the sent on behalf feature, or only have permissions to shared folders, etc., the next recommendation is to use the Exchange tools to add delegates.
The only specific issue to be concerned with in terms of other tools, is that both Exchange and Outlook treat permissions on the calendar folder a bit special. There is a special folder on the root the mailbox named “FreeBusy Data” that is used as part of the delegate feature set. The permissions on this folder must be the same as the permissions on the calendar folder. When you use Outlook or Exchange to set permissions on the calendar folder, the permissions are implicitly also applied to this special folder. If you use third party tools that affect permissions and delegates, there is no guarantee that the special Free/Busy Data folder will have the correct permissions applied.
There is no purposeful limit on the number of delegates that you can assign to a mailbox. At some lower layer than the feature (the MAPI layer, the Name Service Provider Interface (NSPI) call used to add the send on behalf right, etc.), you will likely eventually hit some limit that will prevent adding the nth delegate, but that number is beyond the recommended practical limit.
The Outlook Product Team historically has tested four (4) delegates as the recommended maximum for a mailbox. This recommendation is based more on the practical usability for the calendar than any performance or size limitations. Having more than four delegates creates potentially complex scenarios especially in today’s world of mobile devices, OWA, Outlook add-ins, etc. This complexity makes managing the calendar untenable. We also recommend that you follow the published best practices for working with meeting requests. For example, always respond to a meeting request, configure so that only delegates receive a full copy of the meeting request and so on.
Optionally, you should consider including best practices and documentation from all third party calendar vendors in your environment. For example, if you use Android, Apple, or RIM Blackberry devices, then you should maintain current issues list and troubleshooting methodologies from those vendors.
OST and item size recommendations for a delegate working with Exchange on-premises or Office 365 mailboxes must be considered from several points of view in Office 365 scenarios. OST synchronization can take longer from the cloud than from an on-premises Exchange mailbox. For a better experience, we recommend smaller data sizes for scenarios where the delegated mailbox is on Office365.
Consider these recommendations for a super-delegate:
Exchange on-premises mailbox recommendations for Outlook 2010 performance (maximums)OST Size: 25 GBGeneral Folder Item Count: 50,000Calendar Item Count: 5000
Office 365 mailbox recommendations for Outlook 2010 performance (maximums)OST Size: 5 GBGeneral Folder Item Count: 20,000Calendar Item Count: 5000
Since there are several difficulties in predicting variables in the performance equation (speed of hard drives, usage patterns, add-ins, etc.), our sizing recommendations divide the values into three groups. The first group is the “you should almost never have any OST related performance issues” and that value is 5GB. The second group is the “there should be some level of performance issues, but they are considered manageable by users”. This value is 5-25 GB. Finally the third group is the “you will likely see enough performance impact to affect the user experience”. This value is 25 GB.
From the Outlook point of view, the existing sizing recommendations generally apply equally to Office 365 accounts. The Outlook recommendations are for performance of the OST file format as it relates to “offline” operations. In other words, performance that you get when moving items between local folders, creating views for folders with significant number of items, etc. This recommendation is <25GB for the OST size, 5000 items for a calendar folder, and 20,000 items for non-calendar folders. Calendar folders have specific overhead (calculating recurrence patterns) that create the need for smaller folder sizes. Again, this is the recommendation for performance that is typically seen as manageable by users, not the value that ensures high performance.
Office 365 OST size recommendations also aim at having the network performance meet a suitable level. If you have a large OST, the initial time to sync will be long. For example, if you have operations such as Microsoft Records Management changes that require some level of syncing of all items, then the resulting performance and network usage is typically not suitable when the data size is in the 25GB range. Furthermore, there are some factors involved in shared folder scenarios, where data has to be retrieved from the server. So there is some level of potential extra performance hit in these shared folder scenarios. For that reason, the Office 365 sizing recommendations are typically better recommendations when shared folders are in use. And finally, the Office 365 recommendation of 5GB is to ensure high performance in general for the OST operations, independent of the network.
Therefore, depending on your GOAL for OST performance, the sizing recommendations might be different. The Outlook sizing recommendations will be the maximum recommended for general client side performance. But the Office365 recommendations for a smaller OST would provide mitigation against network-related performance issues and provide consistently better performance.For the super-delegate setups on Office 365, if the choice is made to use shared folders instead of the multi-ex account setup, the recommendations would be:OST Size: Some level between 5GB and 25 GB depending on the desired performanceCalendar Item Counts: 5000General Folder Item Counts: 20000
These sizing levels will ensure that the OST itself has generally good performance, the calendar folder has mitigation against potential lag when working with the calendar data, and general folders, including shared folders that have an item count that performs adequately in most usage scenarios. It should be noted that Outlook 2010 is a versatile, feature rich client, and there are always possible usage patterns or workflows that will affect these recommendations. For example, Outlook provides a feature (available from the folder properties dialog) to clear all the offline data for the folder from your OST. If part of your workflow is to clear offline items regularly from a folder, then performance will sufferwhen that folder is synchronized down in the future. If you use filtered or complex view definitions that Outlook must apply to folder data, then you may see performance lags during those operations. These recommendations are aimed at the best “typical” usage patterns for the super-delegate.
For more information, see:
Our best client side monitoring tool is the Outlook Configuration Analyzer Tool (OCAT). OCAT is based on the same technology as the Exchange Server Best Practices Analyzer. It provides both a friendly UI that users can take advantage of to check client health and also a command line version that IT administrators can script to run health checks and collect the resulting reports. The reference material below has a detailed word document with the feature set, how to use it from the IT administrator point of view, and additional information.
Server side, you can use the feature set of PowerShell scripts and commands to retrieve information about mailbox and folder sizes.
For more information, see:
Microsoft provides several reference documents on “best practices” for delegate scenarios. These guides range from beginner level tasks to intermediate handing of the delegate feature. The Microsoft Premier Field Engineering teams also deliver calendar workshops proactively and reactively. Workshops include topics related to troubleshooting calendar problems and best practice recommendations.
Here are some additional training and troubleshooting resources:
The maximum number of rules for Exchange is limited by a storage allocation for the “property” that stores all the rules. Historically that property was limited to 32K. A typical rule takes between 600-800 bytes of data to store. So you would “run out of room” between 40 and 50 rules. In Exchange 2010, you can specify a value larger than 32K for the rules storage. For Exchange Online accounts, you can set that value to as high as 64K. This would allow for close to 100 rules. The recommended maximum number of rules would be determined by the user’s ability to manage the rule set. Especially in scenarios where several rules could affect the same message and the user has to deal with all the logic involved in triggering the rules.
For more information, see Increasing the Rules Limit for Exchange Online.
The Outlook and Exchange team continuously work together to improve the Exchange Online experience. Not only are specific bugs identified and fixed during our “cumulative update” cycle, but other code changes just to improve the stability and performance are included in the cumulative updates. For this reason, our recommendation is to always test and use the latest available cumulative updates when working on Outlook client problems. The mandatory client level for Outlook is to have an Outlook build that is within 1 year of the current date. So for example using October 2012 as the current date, it is mandatory to have the October 2011 CU applied to Outlook when using Exchange Online.
A last factor to consider in terms of performance and stability is to understand the importance of the calendar ecosystem. If a variety of clients are in use (Outlook, OWA, Windows Phone, IPhone, Blackberry), there is a risk to calendar stability, and each of those areas needs attention. Likewise, if you have add-ins for Outlook that extend the calendar feature set, then you have another potential factor in keeping the calendar running smoothly. None of these are necessarily the cause of a problem, but they do introduce complexity and the requirement for teams to work together to understand and troubleshoot problems.
The latest updates for Outlook can always be found at: http://technet.microsoft.com/en-us/office/ee748587.aspx.
Multi-ex is the common name for the scenario where you add a complete SECOND account to the Outlook profile. You can add a second account to an Outlook 2010 profile by going to Outlook File, Account Settings and selecting New.
To add an additional mailbox, go to Outlook Account Settings and select the Change button, More Settings and then select the Advanced tab for the EXISTING Exchange account.