Tagging External Messages

Posted on May 5, 2021 by Michel de Rooij

Two years ago, I posted a blog on how to implement Transport Rules in Microsoft Exchange to flag messages originating from outside the organization. Goal is to aid end users in identifying messages originating from outside of the organization, by displaying tags in the subject or body part of received messages. This to make them aware – and hopefully more cautious – when it comes to clicking links or opening attachments. Downside of this method is that every inbound message gets a bit cluttered in their subject or body with tags and notifications, which becomes more evident when replying back and forth to external messages. Back then, I already stated a sort of MailTip would be a more preferable and elegant solution.

Onward to 2021, where tagging of external messages became a generally available feature in March for Exchange Online (MC243047, announcement), when used together with Outlook for Web Access (OWA), Outlook for Mac, Outlook Mobile. Outlook for Desktop will also receive support for the feature (supported per version 2105 build 14026.20000, InsiderFast currently). To start adopting this tagging mechanism for new messages, organizations need to deploy an organization level setting using Set-ExternalInOutlook, e.g.

Set-ExternalInOutlook -Enabled $True -AllowList 'contoso.com'

This will enable the tagging of external messages in your tenant, except for domains or e-mail addresses which have been specified through the AllowList. In the example above, messages from contoso.com senders will bypass tagging. The AllowList is limited to 30 entries or 1 kB, whichever comes first. You can reconfigure the AllowList through the hashtable method, e.g.

Set-ExternalInOutlook –AllowList @{Add='fabrikam.com','john@wingtiptoys.com'; Remove='contoso.com'}

After configuring Set-ExternalInOutlook, tagging is not immediate and can take a short while to become active. To inspect current settings, run Get-ExternalInOutlook.

How tagged mail is presented depends on the client. For example, Outlook for Web Access displays an ‘External’ label in the message list, as well as a MailTip at the top of the e-mail contents:

Same goes for Outlook Mobile, where the message list as well as the message view will show an indicator:

Outlook for Desktop
However, Outlook for Desktop does not present a label in the message list, nor exposes a field to filter those external messages, only displaying a MailTip after opening the message:

So, people almost started asking right away if it was not possible to expose External information in the message list. Well, with a little help of “Oldskool” Outlook and forms customization, this is possible, and here is how:

First, we need information related to the MAPI attribute. As the field is not by default available in Outlook, we need to know some of its properties to define it later on. As mention in some of the documents, or Glen Scales’ article on how to identify messages using Graph or Exchange Web Services, the MAPI property tag is 41F28F13-83F4-4114-A584-EEDB5A6B0BFF and its name is IsExternalSender.

Next, we need to construct a .CFG file where we will define the property we want to expose. I’ve already done this part for you, and you can download IsExternalSender.cfg from GitHub. Also download the two .ico files and put them in the same folder as the .cfg file. Note that those .ico files only represent the form. Alternatively, you can copy the .cfg file to your Personal Forms Library folder and skip installing, but this way the instruction is a bit simpler, allows you to pick the Folder Forms Library and will skip the elevated access dialog as the Personal Forms Library is a protected folder.

Open Outlook, go to File > Options > Advanced and click the Custom Forms button. There, click Manage Forms. By default, the form is installed in your Personal Folder Library. You can also pick a mailbox to store the form, allowing it to roam together with the view changes we will perform later. Click Install and pick the prepared .cfg file you downloaded from GitHub, and the following dialog should be shown:

Click OK to confirm you want to load the information in the form file in your personal forms library and close the Forms Manager. Going back to the Outlook navigation view, you can now add an IsExternalSender field to the message list. Right-click the field header and select Field Chooser. In the drop-down list, select Forms.., and add External Tagging Form to the Selected Forms. Field Chooser should now display an available field named IsExternalSender, which you can add to your current view using drag & drop.

Note that the .cfg defines the IsExternalSender as Boolean and showing it as an Icon. This means that for External messages, the column IsExternalSender will contain a checkbox:

When you want, you can create custom fields to adjust how the information is presented. For example, you can create a custom field using a formula to display [EXTERNAL] for IsExternalSender messages, which might be more usable in certain views instead of the checkbox. To accomplish this, select New in Field Chooser,and create a field named ExternalTag, type Formula and enter the following formula:

iif([IsExternalSender]=-1,"[EXTERNAL]","")

You can then add the ExternalTag field to Compact View. Do note the text takes up a row in Compact view, thus might replace sender or the subject depending on layout and field order.

On a final note, when wanted you can filter, sort or create Search Folders using the new IsExternalSender field.

Exchange On-Premises
Organizations running Exchange Hybrid, routing inbound messages through Exchange Online, are not able to benefit from external e-mail tagging. IsSenderExternal is only stamped on messages destined for mailboxes in Exchange Online. These organizations have therefor no way to identify these messages landing in their Exchange on-premises environment, and may require them to deploy the less elegant Transport Rules solution regardless.

Outlook Connectivity changes per Nov2021

Posted on December 11, 2020 by Michel de Rooij

In the past, using outdated clients with Microsoft 365 services was a matter of being in an unsupported state with all the risks that go with it. This meant, that things might not work or you could experience reduced functionality. Overall, things usually kept working with a few consequences or glitches here and there.

A change in this stance was announced today per Message Center bulletin MC229143:

To ensure that we meet performance expectations, we are updating the supported versions of Outlook for Windows that can connect to Microsoft 365 services. Effective November 1, 2021, the following versions of Outlook for Windows, as part of Office and Microsoft 365 Apps, will not be able to connect with Office 365 and Microsoft 365 services.

This means, running old unsupported Outlook versions will go from “possible performance and reliability issues” to becoming actively blocked. This block will apply to these versions in the table below; as indicated, these builds were surpassed somewhere in 2017:

Application	Affected Builds	Build Superseded
Office 2013	15.0.4970.9999 and older	October 2017
Office 2016	16.0.4599.9999 and older	October 2015
Microsoft 365 Apps for Enterprise (formerly Office 365 ProPlus) Microsoft 365 Apps for Business (formerly Office 365 Business	1705 and older	June 2017

While it is true that many customers are stretching the lifetime of their on-premises products beyond their support dates, I’m sure – apart from functionality and management options – performance and reliability is becoming more and more of an issue.

Finally, when this notice concerns you, it means you have not been updating your clients for at least 3 years. So, get planning, as you have around 11 months to update your clients. It also may affect any existing plans of moving to Exchange Online in the future, as getting your client-base in a supported state will become a requirement, and will no longer be a serious recommendation.

Ignite: Outlook Calendaring Update

Posted on September 25, 2020 by Michel de Rooij

In the Ignite talk Outlook Calendar: Fundamentals and Collaboration, the unequaled Julia Foran laid out tons of new and coming features for the various Outlook platforms in relation to calendaring. You can watch the video on the Virtual Hub.

I tried to capture those in below table. For more information for some of these features, please watch the recording

Feature	Win	Mac	OWA	iOS	And
Personal calendar side-by-side (Hotmail/Live/MSN, Google)	✔	✔	⭐	✔	✔
Connect Shared & Delegated Mailboxes	✔	✔	✔	⭐	⭐
Importing of ICS attachments	✔	✔	⭐	🕒	⭐
Calendar To-Do pane (My Day)	✔	⭐	⭐
Calendar To-Do pane showing Tasks (My Day)	✔	🕒
Calendar To-Do pane multiple Months support	✔¹
Suggested Times	❔	⭐	✔	🕒	🕒
Advanced Room Finder	✔¹	⭐	✔
Room Suggestions for Recurring Meetings	⭐	🕒	⭐	❔	❔
Room Suggestions showing Room Capabilities (leverages Set-Place / Places REST API)	⭐	🕒	⭐	❔	❔
Room Suggestions and Policies integration AllowRecurringMeeting, BookingWindowInDays, EnforceSchedulingHorizon, MaximumDurationInMinutes	🕒	🕒	🕒	🕒	🕒
Finding a Workspace	⭐¹	⭐	⭐	⭐	⭐
Teams meeting quick-join In-Calendar, Inbox or Search	⭐	⭐	⭐	⭐	⭐
Online meetings by default – Outlook	🕒	⭐	⭐	⭐	⭐
Built-in Breaks – End Late Built-In Breaks – Start Late Setting roams clients, org-wide config coming soon	✔ 🕒	🕒	⭐	🕒	🕒
Meeting Insights – Outlook Meeting Insights – Teams	🕒	⭐ 🕒	✔ 🕒	⭐ ❔	⭐ ❔
Full Mailbox Delegates Delegates receive full calendar permissions instead of the organisation (default) permissions	✔	✔	✔	✔	✔
Week Numbers Setting not roaming yet	✔	✔	⭐	⭐	⭐
Scheduling with time zone selection	✔	✔	✔	⭐	✔
Sync local device calendars Sync back in progress, controllable with InTune policy					⭐
Flexible Week View	✔	✔	⭐	✔	✔
Travel detection with time zone adjustment	✔	✔	⭐	✔	✔
Automatic Removal of orphaned attendees Attendees that left company get removed from meeting after first NDR to organizer.	🕒	🕒	🕒	🕒	🕒

Legend
✔ : Already available
🕒 : Coming
⭐ : New Feature
❔ : Undetermined

Notes
1) Currently available to Office Insiders

iOS 9 Outlook App & Lync 2013 App Issues

Posted on September 17, 2015 by Michel de Rooij

iphone6 After Apple released iOS 9 to the public yesterday. From an Exchange or Office 365 perspective, iOS 9 supports the enhanced calendar features of Office 365 and Exchange 2016 when that is released. Unfortunately, incidents have been reported with the Outlook app and the Lync 2013 App.

Regarding the Outlook App, iOS9 users might not be able to start the Outlook App or the Outlook app will just crash. The far from ideal workaround offered by the Outlook team, is to reinstall the Outlook app.

Of course, this also requires users to reconfigure accounts and Outlook App settings, so organizations can expect some calls to the service desk by users who upgraded. Organizations can report on the currently registered iOS8 devices that syned in the last 30 days, using:

Get-MobileDevice | Where-Object {$_.DeviceOS -like 'iOS 8*' -and $_.whenChanged -gt (Get-Date).AddDays(-30)} | Select UserDisplayName, FriendlyName, DeviceModel, DeviceOS, whenChanged

This will product a list of users, the name of their device, the device model and OS and when it last synced with Exchange. This information can be useful when you want to proactively approach users with iOS8 devices.

For Lync 2013 users, there are sign-in issues when they have configured different region and language settings on their iOS device. Those users will be presented the following:

The issue has officially been confirmed through publication of KB3096704, which states:

“This problem is fixed in the Microsoft Skype for Business for iOS app that will replace Lync for iPhone and Lync for iPad when it’s released. No fix for this issue is scheduled for the current releases of Lync for iPhone and Lync for iPad”.

Since the Skype for Business app is not available yet, this is not good news. Mitigation is possible by matching the region with the language setting (or the other way around), after which you need to reinstall the Lync 2013 app from the store.

With all this in mind, should organizations wish to first test the new iOS against their Exchange environment for potential other issues, you can block iOS 9 from accessing your Exchange 2013 environment, or Office 365 tenant if you must, using the Access/Block/Quarantine feature. First you need to retrieve the reported DeviceOS string for iOS 9 for a device:

Get-MobileDevice | Where-Object {$_.DeviceOS -like “iOS 9*”} | Select DeviceModel, DeviceOSLanguage, DeviceOS

The reported DeviceOS strings then is used to create an ActiveSync device rule. For example, my iPhone 6 reports DeviceOS as “iOS 9.0 13A344”. To block these devices with iOS 9.0 and put them in quarantine, run the following:

New-ActiveSyncDeviceAccessRule -QueryString "iOS 9.0 13A344" -Characteristic DeviceOS -AccessLevel Quarantine

If you would like to know more about the Access/Block/Quarantine option, check out this article.

Outlook 2010 gets MAPI/http support

Posted on December 12, 2014 by Michel de Rooij

Update: Hotfix KB2899591 pulled in Dec2014 due to possible issues, replaced in Jan2015 by KB878264.

A quick heads-up today as the recently released KB878264 hotfix adds MAPI/http support for Outlook 2010 clients. This will benefit organizations using Exchange 2013 SP1 or later considering switching from RPC/http to MAPI/http. The KB article includes details on additional fixes that are included in this hotfix as well.

You can request the hotfix for x86 and x64 versions of Outlook 2010 here.

Links to background information on MAPI/http, its impact on client performance, and impact on network traffic in an earlier blog post here.

Clearing AutoComplete and other Recipient Caches

Posted on July 17, 2014 by Michel de Rooij

Last version: 1.21, April 28th, 2021: Updated formatting and link to GitHub

Anyone who has participated in migrations or transitions to Exchange has most likely encountered or has had to work around potential issues caused by the nickname cache. A “cache,” also known by its file extension, NK2 in older Outlook clients, is a convenience feature in Outlook and Outlook WebApp (OWA) which lets users pick recipients from a list of frequently-used recipients. This list is displayed when the end user types in the first few letters.

The potential issue revolves around end users using those lists to send messages, as the list contains cached recipient information. Because this information is static, it may become invalid at some point. Thus, when users pick recipients when sending messages, they may be sending messages to non-existent recipients or invalid e-mail addresses, which create issues like non-delivery of e-mail.

Read the full article over on ENow Solutions Engine blog.

Clean-AutoComplete

Using the script mentioned in the article, which can be used to clear cached recipient information, is straightforward. It requires Exchange 2010 or later and Exchange Web Services Managed API 1.2 (or later) which you can download here. Alternatively, you can copy the Microsoft.Exchange.WebServices.DLL with the script as it will also look for it in the current folder.

The script Clean-AutoComplete.ps1 has the following syntax:

Clear-AutoComplete.ps1 [-Mailbox] <String> [-Server <String>] [-Impersonation] [-Credentials <PSCredential>] [-Type <Array>] [-Pattern <String[]>]

Where:

Mailbox is the name or e-mail address of the mailbox.
Server is the name of the Client Access Server to access for Exchange Web Services. When omitted, the script will use AutoDiscover.
Switch Impersonation specifies if impersonation will be used for mailbox access, otherwise the current user context will be used.
Credentials specifies the user credentials to use.
Type specifies what cached recipient information to clear. Options are Outlook (Outlook AutoComplete stream), OWA (OWA Autocomplete stream), SuggestedContacts, RecipientCache or All. Default is Outlook,OWA.
Pattern is the pattern of e-mail entries to remove from cache. Only works with OWA, SuggestedContacts and RecipientCache type clearances.

So for example, suppose you want to clear the Autocomplete stream used by Outlook on a mailbox, you can use:

Clear-AutoComplete.ps1 -Identity Olrik -Type Outlook -Verbose

To remove the Autocomplete stream used by OWA on your Office 365 account, you can use:

Clear-AutoComplete.ps1 -Identity olrik@office365tenant.com –Credentials (Get-Credential) –Type OWA

Be advised that clearing the Outlook AutoComplete stream will only have effect for Outlook running in Online mode. Outlook caches this information as well in the OST file, leaving the options of running Outlook with the /CleanAutocompleteCache switch, or remove and let Outlook recreate the OST file. The temporary Stream_AutoComplete *.dat files created under %USERPROFILE%\AppData\Local\Microsoft\Outlook\RoamCache are used by Outlook to speed things up.

Disabling Auto-Complete and Suggested Contacts
Alternatively, you can disable Auto-Complete, the equivalent of unchecking the Outlook option ‘Use Auto-Complete List to suggest names when typing in the To, Cc and Bcc line‘, by setting the following registry key:

Note: In the examples below, you need to modify the version number in the examples corresponding to the Outlook version you wish to apply these settings against. Use 16.0 as indicated for Outlook 2016, but change it to 15.0 for Outlook 2013, or 14.0 for Outlook 2010.

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences\
ShowAutoSug=0 (REG_DWORD)

To configure this setting using a Group Policy, use the following registry setting:

HKEY_CURRENT_USER\Software\Policies\Microsoft\office\16.0\Outlook\Preferences\ShowAutoSug=0 (REG_DWORD)

You can also disable Suggested Contacts folder, the equivalent of unchecking the Outlook option ‘Automatically create Outlook contacts for recipients that do not belong to an Outlook Address Book’, with the following registry key:

HKEY_CURRENT_USER\Software\Microsoft\office\16.0\Outlook\Contact\CreateContactsForOneOffs= 0 (REG_DWORD)

The related Group Policy setting is:

HKEY_CURRENT_USER\Software\Policies\Microsoft\office\16.0\Outlook\Contact\CreateContactsForOneOffs= 0 (REG_DWORD)

Feedback
Feedback is welcomed through the comments. If you got scripting suggestions or questions, do not hesitate using the contact form.

Download
You can download the script from GitHub here.

Internal Message Classifications visible in Outlook

Posted on March 11, 2014 by Michel de Rooij

Message classifications were introduced with Exchange 2007 which seems like ages ago now. They are a piece of metadata which you can assign to messages, for example the intended audience or sensitivity of messages. These message can then be treated accordingly by the recipient or you can leverage transport rules functionality and Rights Management Services to act on or protect these messages.

Let’s assume you have created a custom message classification using the following cmdlet:

New-MessageClassification –Name ‘InternalUseOnly’ –DisplayName ‘Internal Use Only’ –SenderDescription ‘This message is for internal use only.’

When you retrieve the list of message classifications using Get-MessageClassifications you will notice three additional classifications:

Exchange comes with these message classifications which are used by Exchange internally: ExAttachmentRemoved, ExOrarMail and ExPartnerMail. These should not be used by users, let alone be visible. To make them hidden, the PermissionMenuVisible attribute is set to $false for these classifications. This will make them not show up in Outlook WebApp:

Now, using classifications in Outlook is less admin-friendly and requires exporting of classification information and configuring Outlook to read these classifications from a file. In short, the process described on TechNet TechNet to use message classifications from Outlook is as follows:

From the Exchange Management Shell, run the Export-OutlookClassification.ps1 script from Exchange scripts folder, e.g.

& ‘C:\Program Files\Microsoft\Exchange Server\v15\Scripts\Export-OutlookClassification.ps1’ | Set-Content ‘C:\OutlookClass.xml’

Next, copy the XML file to a location on the client or networked location which is readable by Users. On the client, make the following registry changes:

[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Policy]
"AdminClassificationPath"="c:\\Classifications.xml"
"EnableClassifications"=dword:00000001
"TrustClassifications"=dword:00000001

Note: For the purpose of this example the XML is stored as C:\Temp\OutlookClass.xml . Note that “15.0” is for configuring Outlook 2013, replace with 14.0 for Outlook 2010 and 12.0 for Outlook 2007.

Restart Outlook so it will use these settings. When composing a message you will now see the message classification options appear under Options > Permission:

Apart from the message classification “Internal Use Only” we created, you will also see that Outlook shows the internal classifications by their display name. That should not be happening.

When you open up the Outlook classifications export file, you will spot that it contains all classifications, including the internal ones:

So, what you can do now and what the documentation seems to fail to mention, is that after exporting message classifications you may want to remove the internal classifications “Attachment Removed” (ExAttachmentRemoved), “Originator Requested Alternate Recipient Mail” (ExOrarMail) and “Partner Mail” (ExPartnerMail) from the XML export file. Downside is that message with these internal classifications will not display the related description in Outlook, but that should not be an issue and a better option than users being able to select them.

When you have removed the three entries from the XML file and restarted Outlook, the built-in options will no longer be on the permission menu:

So long RPC/HTTP, Hello MAPI/HTTP

Posted on January 22, 2014 by Michel de Rooij

Microsoft published three sessions from the Redmond Interoperability Protocols Plugfest 2013 on Channel 9 on the protocol MAPI over HTTP or MAPI/HTTP which looks scheduled to arrive with Exchange 2013 Service Pack 1.

This protocol is set to (over time!) replace the RPC/HTTP protocol we all know. RPC/HTTP, or Outlook Anywhere, is used by Outlook to communicate with Exchange Server and is most often seen with clients working remotely. With Exchange Server 2013, support for MAPI was dropped and RPC/HTTP became the only protocol. With Exchange 2013 SP1 it seems we will receive an alternative which is set to replace RPC/HTTTP, MAPI/HTTP.

Of course, the information is preliminary and subject to change as Exchange 2013 SP1 hasn’t been released yet, but it won’t harm to get familiar with the planned changes. It also remains to be seen how quick organizations will adopt this new protocol, which I’m pretty sure we will soon see getting supported by Office 365.

MapiHttp in Exchange 2013 SP1
Joe Warren, Principal SDE at Microsoft delivering a presentation covering the Exchange 2013 MapiHttp protocol implementation in Exchange 2013 SP1. Topics: What is MAPI-HTTP?, Why do MAPI-HTTP?, Goal of MAPI-HTTP, Why not rebuild with EWS?, Existing RPC-HTTP, New MAPI-HTTP, What does a MAPI-HTTP request look like?, What does a MAPI-HTTP response look like?, Session Context, Request Types, Sequencing & Protocol Failures. Click here.

Outlook 2013 Client Protocols
Shri Vidhya Alagesan, SDE at Microsoft presenting on Outlook 2013 Client Protocols from a client’s perspective. Topics: Client side view of Outlook-Exchange MAPI-HTTP protocol using WinHTTP, Error Handling & RPC Vs. MAPI-HTTP with sub-topics of Architecture Overview, Outlook & WinHttp, Cookies, Connection Status Dialog, Timeout, Pause/Resume & Protocol Switching. Click here.

Exchange 2013 Protocols
Andrew Davidoff, Senior Software Developer Engineer in Test at Microsoft presenting on the Exchange 2013 protocol families and important protocol updates for Exchange 2013. Click here.

Apart from these sessions on protocol change announced for Exchange Server 2013 SP1, Microsoft also published some other interesting Exchange-related sessions:

Exchange 2013 Web Services Overview
Harvey Rook, Principal Development Lead, and Naveen Chand, Senior Program Manager Lead, deliver a presentation on Exchange Web Services best practices. Click here.

Exchange RPC and EWS Protocol Test Suites
Jigar Mehta, Software Development Engineer in Test provides an in depth overview of the test suite packages for the Exchange RPC and Exchange Web Services protocols. Click here.

Outlook versions supporting Personal Archives and Retention Policies

Posted on February 4, 2013 by Michel de Rooij

In an earlier article here, I mentioned which Outlook 2010 versions were eligible for Personal Archives.

Now, with the release of Office 2013, and Outlook 2013 in particular, it’s good to get an update on the Outlook versions and their support of Personal Archives and Retention Policies in Exchange Server 2010 or Exchange Server 2013.

The following Outlook versions support Personal Archives and Retention Policies:

Retail Licenses	Volume Licenses
Outlook 2013 stand-alone Outlook 2010 stand-alone Outlook 2007 stand-alone Outlook 2007 included with Microsoft Office Ultimate 2007	Outlook 2013 stand-alone Outlook 2013 included with Microsoft Office Professional Plus 2013 Outlook 2010 stand-alone Outlook 2010 included with Microsoft Office Professional Plus 2010 Outlook 2007 stand-alone Outlook 2007 included with Microsoft Office Professional Plus 2007 Outlook 2007 included with Microsoft Office Enterprise 2007

Few notes:

As mentioned here, Outlook 2007 doesn’t support adjusting retention policies;
Personal Archives and Retention Policies require an Microsoft Exchange Server Enterprise Client Access License.

Discontinued support of ActiveSync in GMail

Posted on December 21, 2012 by Michel de Rooij

Few days ago, Stuart J. Johnston of TechTarget approached me and several other Exchange fellows to ask how we thought the discontinued support of ActiveSync in GMail, part of Google’s “Winter Cleaning” operation, would impact users. You can read Stuart’s article here.

For reference and because Stuart only used a single quote from my (I think) extensive response, I’ve included my take on the situation below. Interestingly, today it turns out Google lost an ActiveSync patent case against Microsoft in a British court. Exchange fellow Tony Redmond did a nice writeup on that case and his personal involvement in that case here.

PS: I’ve already asked Stuart to fix my last name in the quote.

Regarding the discontinued support of ActiveSync in GMail, I think impact on both the Exchange as well as the GMail population varies.

First of all, the measure is aimed at new, free GMail accounts. I don’t know exact numbers, but I can imagine the number of people still not having a free GMail account is relatively minimal. Also, EAS will remain available to paid accounts.

Second, EAS is a means – no end – to synchronize information like mail, contacts or agenda. Consumers will adapt and switch to alternative protocols (or plugins) to synchronize this information between their Google account and their device. I think the effect of the information exchange becoming less efficient and the lack of information push is negligible.

Thirdly, Android and iPhone – covering 85% over the smartphone market – provide apps specifically aimed at GMail or other Google services. For those not using Google’s apps, the end user experience may be affected and all the additional tools required to fully synchronize with desktops won’t help.

Worst off are Windows Phone users or Windows 8 users using the built-in Mail app (Surface RT). While the Windows Phone user base may be relatively small, the Windows 8 user base is growing and they are both forced to use IMAP, which only does mail and there are – AFAIK – no *DAV apps in the Store to synchronize calendar or contact information.

While I do understand Google’s case, which is probably more a cost reduction and (resource) focus shift measure rather than another act in the Google vs Microsoft war, I also believe there might be a fair chance of Google shooting itself in the foot by dropping EAS. Microsoft’s free outlook.com service keeps supporting EAS (not surprisingly) and Microsoft has already taken up on plugging outlook.com as the alternative for Google

Finally, I’m in favor of competition which drives innovation. The whole GMail versus Hotmail/Office365 is no exception. However, it gets annoying when vendors drop functionality end users are accustomed to, making them have to put energy into looking at solutions or alternatives, which may become tiresome at some point.