It might have escaped your attention that Windows XP came to the end of the support runway in April 2014, a fact that certainly appears to be the case for the folks who have reported issues running Outlook 2010 on Windows XP against Exchange 2013 CU7 servers.
CU7 shipped in December 2014, some six months after XP was shuffled off to the side (at least in the minds of everyone at Microsoft). There’s a fair chance – perhaps even a 100% chance – that Microsoft did not test Outlook 2010 clients on Windows XP against CU7 during the development cycle. It’s therefore totally unsurprising that some features don’t work. What is surprising is the features that seem to be causing problems because they’re not new stuff.
For the life of me, I can’t think why Outlook 2010, which is a reasonably recent client, would fail to access public folders after mailbox servers are upgraded to CU7. Everything works with CU6 but fails with CU7. Microsoft has been working with public folders to improve their performance and scalability, but it’s not that. The problem report explicitly mentions public folder databases, so we know that old-style public folders are in the mix. In turn, this makes the problem even stranger because old-style public folders have been, well around so long, or certainly long enough to have made Outlook 2010 know exactly how to cope with the little beasties.
Another odd issue is a report that shared mailboxes aren’t functioning as well as they should when Outlook 2010 clients (again on XP) connect to CU7. The mailboxes work as shared repositories, but synchronization isn’t working as automatically as it did before. Manual synchronization works, but users are upset that something has changed.
The folks reporting these issues have noted that they are preparing for migration and just need to keep these XP clients around for a few more months. From their perspective, it’s a royal pain in the rear end to suddenly discover that a server upgrade wreaks havoc on clients, especially in areas of functionality that you would have assumed are stable. So I have some sympathy for their complaints.
But I also sympathize with Microsoft. They told customers that XP was for the scrap heap for a very long time before the day of destiny arrived. Six months on, it’s difficult to criticize Microsoft for failing to ensure that a reasonably new Outlook client running on a very old operating system (in cloud terms) has issues when connected to the latest and greatest on-premises Exchange server.
It could be that Microsoft viewed the demise of Windows XP as an opportunity to trim some of the old code in the server from the Exchange code base. Like any product that has been around for a very long time, Exchange is full of conditional code paths necessary to cope with different circumstances. The rewrite of the Information Store into managed code for Exchange 2013 was a form of code colonic irrigation for the server, but some stuff still lingers on.
And at the same time, Exchange is evolving to cope with cloud services and decisions are being made to upgrade functionality to work better in the cloud. Windows XP clients are not on that particular design chart, so why would we be surprised when problems happen?
I can’t offer much joy to the folks who have to cope with the outrageous slings and arrows of XP. Perhaps you should keep some Exchange 2013 CU6 servers around and place all your public folder databases and mailboxes for XP users on those servers. The tactic will work and reflects reality, even if it seems to be a shame not to be able to run the latest code.
Life can be hard at times, especially if you run XP in 2015.
Follow Tony @12Knocksinna
