This post was lingering around for a long time, but the last weeks showed me it's time.
Actually I came across this topic last year just before Ignite. But somehow this topic felt into oblivion. To make it short:
It's all about the number of TCP connections an Outlook Client establishes in a Cached Mode. Especially when it comes to shared mailbox or delegate scenarios.
What is Outlook Cached Mode?
Read more about it here. But what you really want to avoid it something like this:
Symptom
By default every profile is set up in Cached Mode and Download shared folders is checked. During the lifetime of an Outlook profile you check several shared calendars, add shared mailboxes (or get them auto-mapped) and, when you're an assistant, you have to maintain several mailbox as you were added as a delegate.
Whenever you add another mailboxes Calendar, your client will download its content. This means you'll establish at least 2 additional connections towards the endpoint and your OST file will grow. In case you reconfigure your profile and remove the extra mailbox, you're good as Outlook will remove all information from your profile, mailbox and clears your OST.
The problem comes when a shared calendar was added. Most of the people just uncheck a shared calendar, when this calendar is not needed anymore. They think that's all, which needs to be done. But here the problem starts:
By unchecking another's calendar, you only change the view in Outlook. Thus means you don't see it anymore, but Outlook has it still configured for downloading data from these mailboxes. Therefore connections get established. This could have severe impact for the user:
- throttling on server-side takes place. You can find more information about throttling here and here.
- increasing OST file size, which can have a negative impact on client-side. There is a recommendation for SSD disk at a certain size. Read this KB article!
- synchronization issues, which could cause serious calendar issues.
This is one of the most root cause for inconsistency I've seen the last years: Caused by synchronization issues of Outlook and mobile device clients!
Workaround
Now that we understand the impact, how can we fix this? I use the word workaround on purpose, as in my opinion this problem should be fixed from Outlook PG.
The only way to get rid of these extra connections is as follows:
- Make sure you have only calendars checked you really need
- Uncheck Download shared folders in you profile:
- On the File tab, click Account Settings in the Account Settings list.
- In the Account Settings dialog box, click the E-mail tab and then double-click your Microsoft Exchange Server account.
- In the Change Account dialog box, click More Settings.
- In the Microsoft Exchange dialog box, click the Advanced tab.
- Click to clear the Download shared folders check box.
Default setting
Make sure Download shared folders is unchecked
Note: Don't forget to restart Outlook! There should also be a pop-up reminding you as follows:
After you have restarted Outlook, all unnecessary connections should be gone. To be on the safe side wait 1-2 minutes to let Outlook get all settings sorted out.
Once this is done you can revert the change and check Download shared folders to take advantage of having a mailbox locally cached.
Which Exchange and Outlook version is affected?
Cached Mode is a pure Outlook feature and it never changed since it was introduced. Therefore any supported Exchange version and Exchange Online is affected .
Why should I care about the connections?
Even if you don't suffer the issues mentioned before like throttling, OST file bloat, synchronization and calendar issues, Outlook establishes additional TCP connections. Thus could have an impact for your network infrastructure. Depending on your on-premises footprint, this might push your server to its limit, when it comes to TCP sessions.
Most mailboxes are in Exchange Online. I don't have to worry about it, right?
You might not suffer any performance impact on your on-premises Exchange servers. You might don't have at all an on-premises Exchange servers. But you have network device/appliances and an internet outbreak. Think about the TCP sessions. You might run into TCP/IP port exhaustion on your proxy or FW. I recommend reading the following articles:
- NAT support with O365
- Ensuring your Proxy server can scale to handle Office 365 traffic
- Office 365 Performance Management
The Exchange administrator has made a change …
I'm sure this is a well known prompt. If not, here are a few links for reading, which explains when this happens:
- Obviating Outlook Client Restarts after Mailbox Moves
- "Microsoft Exchange administrator has made a change that requires you quit and restart Outlook" error when you try to access a moved mailbox in Office 365 Dedicated/ITAR
I have seen this prompt even when I moved a mailbox in the same AD-site from one DAG to another. There was no change in either namespace or PF. What I've found in the MAPI logs using Get-MAPIStats.ps1, was the following error:
MoMTException:0x6BA (rpc Exception) -> [ServerUnavailableException] Connection must be re-established -> [SessionDeadException] Connection has been previously marked as dead….
A few days ago I got this behavior reported by a user running 1701 Build 7766.2122 and this was caused as I moved a mailbox for which this user had the calendar configured, but unchecked. I couldn't repro the behavior with 1705 Build 8021.2213 neither could I find anything in the release notes. But this wouldn't be the first time something got fixed, but not documented.
Conclusion
The documentation about this is very small. As mentioned before I wish the behavior of Outlook would be changed in the way that unchecking a calendar is not only a change of the view. The performance and end-user experience can be really bad. The number of TCP connections is also a mostly underestimated risk companies have to deal with.
I hope this post helps. Feedback is always welcome.
Source: https://ingogegenwarth.wordpress.com/2018/01/30/outlook-cached-tcp-con/
Posted by: budschimkee0193117.blogspot.com
Post a Comment