Bypassing Focused Inbox and Clutter Folders

Posted on Leave a commentPosted in Clutter, Focused Inbox, IAmMEC, Office 365, Outlook

For the last few years Exchange Online mailboxes have been processed by a service call Clutter, which moved the less important emails, or indeed the clutter, to a dedicated folder. This is now in the processes of being replaced by the Focused Inbox, which is client version dependant and is all based on views on the mailbox and not different folders.

The way to ensure mail is not marked as clutter, or shown in the Other view when your mailbox is processed by the Focused Inbox, is to mark the item as such, or to actively engage with the item. That is if you reply or read the emails from these recipients they do not go into Clutter/Other, but if you ignore them or delete them before they are read then this makes them candidates for future processing by the Focused Inbox or Clutter engine.

There are though times when occasional emails need to be in your Inbox and not the Other view or the Clutter folder. The best two ways to do this are as follows:

Management Hierarchy

The processing engine for Clutter/Focused Inbox will not place items from your Direct Reports or management chain in the Other view/Clutter folder nor will it place any emails from yourself into the low priority location. The Direct Reports and your management chain is known to the processing engine as it is part of Active Directory. So as long as your manager (and everyone else’s manager) attribute is populated in Active Directory and synced to Azure Active Directory then this configuration can be honoured.

Transport Rules

The other way to ensure certain messages always go to the Inbox is to have the message processed by a transport rule. Transport rules, like the management chain above are only available in Office 365 Business and not The two Transport Rule placeholders below add the Clutter and Focused Inbox rules (there are two different rules, so if you added the Clutter one in the past a new one is needed for Focused Inbox). They add the rule with a arbitary placeholder, so that the rule never fires (unless you really happen to enter the demo text!). So once you add these rules change them to suit the conditions of your environment. For example if you have a “company wide communications” email sender then you could set the rule to be when that sender sends emails. The two rule placeholders you need in remote PowerShell to Exchange Online are:

   1: New-TransportRule -Name "Bypass Focused Inbox" -SubjectContainsWords "This is a placeholder rule that does nothing, change this action to suit the requirements of the client" -SetHeaderName "X-MS-Exchange-Organization-BypassFocusedInbox" -SetHeaderValue "true" -Comments "<date> - <name> - Any mail that meets the conditions of this rule will go into the Inbox or Focused Inbox and not the Clutter or Other folder in Exchange Online"

   2: New-TransportRule -Name "Bypass Clutter" -SubjectContainsWords "This is a placeholder rule that does nothing, change this action to suit the requirements of the client" -SetHeaderName "X-MS-Exchange-Organization-BypassClutter" -SetHeaderValue "true" -Comments "<date> - <name> - Any mail that meets the conditions of this rule will go into the Inbox or Focused Inbox and not the Other view in Exchange Online"

Change these rules to suit your requirements

The Case of the Disappearing Folders

Posted on 3 CommentsPosted in 2013, exchange online, IAmMEC, MVP, Office, Office 365 ProPlus, Outlook

Here is a issue I have come across at one of my current clients – you create a folder in Outlook 2013 when in the “Mail” view (showing only mail folders – your typical default view) and the folder does not get created. For example, in the below picture the user is in the middle of creating a folder called “Test Inline” as a child of the “SO” folder:


Upon pressing Enter, the folder disappears and fails to be created:


So where does one see this issue? It happens when the parent folder in question, in this case the “SO” folder is created by Microsoft’s PST Capture Tool. The PST Capture Tool creates a parent folder in the Online Archive in Exchange (in this case Exchange Online but it does not matter which Exchange Server) named after the PST file, so in this case SO.pst was uploaded by the PST Capture Tool. Any attempt to create folders inline below this parent folder fails! If you drag content into this folder it will not allow you to drop the content in, and the folder appears to be read-only.

If you change Outlooks view to Folder view (click the … on the Outlook 2013 view bar to the right) then you can create folders (using a dialog) and that works fine – this is how “Test Dialog” was made in the above pictures.

In Outlook 2010 all works as expected! In Outlook 2013 the issue appears to be the way Outlook handles folders that have a MAPI property on the folder created with a null value. In tools such as MFCMapi and OutlookSpy you can view the MAPI properties of a folder and the folder created by PST Capture Tool has a property call PR_CONTAINER_CLASS_W with a null (empty) value. Normally, Outlook will make folders that have “IPF.Note” as the value of this folder, if this is a mail and notes folder (i.e. not a calendar or contact etc folder). But clearly there is a problem, as Folder view allows you to create subfolders when the parent’s PR_CONTAINER_CLASS_W value is null and so does Outlook 2010 and coincidently does OWA!

The fix, but I do not have it ready yet, is to run an EWS script to reset the PR_CONTAINER_CLASS_W property of this folder to IPF.Note or wait for an update to Outlook from Microsoft, and for that I have contacted them.

With thanks to fellow MVP Jaap Wesselius for double-checking this for me and testing it in Outlook 2010.

Continuing Adventures in AD FS Claims Rules

Posted on 7 CommentsPosted in 2013, activesync, ADFS, ADFS 3.0, exchange online, https, Office 365, Outlook, OWA for Devices, Web Application Proxy

Updated 20th April 2017

There is an excellent article at which discusses the use of Claims Rules in AD FS to limit some of the functionality of Office 365 to specific network locations, such as being only allowed to use Outlook when on the company LAN or VPN or to selected groups of users. That article’s four examples are excellent, but can be supplemented with the following scenarios:

  • OWA for Devices (i.e. OWA for the iPhone and OWA for Android), also known as Mobile OWA
  • Outlook Mobile Apps
  • Using Outlook on a VPN, but needing to set up the profile when also on the VPN
  • Outlook restrictions when using MAPI over HTTP
  • Legacy Auth and Modern Auth Considerations

OWA for Devices and AD FS Claims Rules

OWA for Devices is an app available from the Apple or Android store and provides mobile and offline access to your email, adding to the features available with ActiveSync. Though OWA for Devices is OWA, it also uses AutoDiscover to configure the app. Therefore if you have an AD FS claim rule in place the blocks AutoDiscover you will find that OWA for Devices just keeps prompting for authentication and never completes, though if you click Advanced and enter the server name by hand ( then it works.

Using OWA for iPhone/iPad diagnostics (described on Steve Goodman’s blog at you might find the following entries in your mowa.log file:

[NetworkDispatcher exchangeURLConnectionFailed:withError:] , “Request failed”, “Error Domain=NSURLErrorDomain Code=-1012 “The operation couldn’t be completed. (NSURLErrorDomain error -1012.)” UserInfo=0x17dd2ca0 {NSErrorFailingURLKey=, NSErrorFailingURLStringKey=}”

And following the failure to reach successfully you might see the following:

[NetworkDispatcher exchangeURLConnectionFailed:withError:] , “Request failed”, “Error Domain=ExchangeURLConnectionError Code=2 “Timeout timer expired” UserInfo=0x17dc6eb0 {NSLocalizedDescription=Timeout timer expired}”

and the following:

[PAL] PalRequestManager.OnError(): ExchangeURLConnectionError2: Timeout timer expired

[autodiscover] Autodiscover search failed. Error: ExchangeURLConnectionError2: Timeout timer expired

[actions] Action (_o.$Yd 27) encountered an error during its execution: Error: Timeout timer expired

[autodiscover] TimerCallback_PeriodicCallback_HandleFailedAutodiscoverSearch took too long (XXXms) to complete

The reason is that the first set of AutoDiscover lookups work, as they are connecting to the on-premises endpoint and authentication for this endpoint does not go through AD FS. When you reach the end of the AutoDiscover redirect process you need to authenticate to Office 365, and that calls AD FS – and that might be impacted by AD FS claims rules.

The problem with OWA for Devices and claims rules can come about by the use of the AD FS Claims Rules Policy Builder wizard at This tool can be adjusted quite easily for AD FS 2012 R2 (change line 218 to read “If (($OSVersion.Major –eq 6) –and ($OSVersion.Minor –ge 2))” (look for AD FS servers that are –ge [greater or equal to 2] rather than just 2). The AD FS Claims Rules Policy Builder has a setting called “Block only external Outlook clients” – and this blocks Outlook, Exchange Web Services, OAB and AutoDiscover from being used apart from on a network range that you provide. The problem is that you might want to block Outlook externally, but allow OWA for Devices to work.

To solve this problem make sure you do not block AutoDiscover in the claims rules. In the “Block only external Outlook clients” option, its the 2nd claim rule that needs to be deleted, so you end up with just the following:


With AutoDiscover allowed from all locations, but EWS and RPC blocked in Outlook, you still block Outlook apart from on your LAN, but you do not block OWA for Devices. Use to test Outlook Autodiscover after making this change and you should find that the following error is not present when AutoDiscover gets to the stage.

The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL for user

The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.

An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).HTTP Response Headers:

If you changed an existing claims rule you either need to restart the AD FS service or wait a few hours for it to take effect.

OWA Apps and AD FS Claims Rules

The above section covers why MOWA (Mobile OWA) needs AutoDiscover to work. The same is true for any client application such as ActiveSync or Outlook for iOS / Outlook for Android / Windows Mail etc that needs to run AutoDiscover to determine your mailbox settings. Therefore, as in the above section ensure you are not blocking AutoDiscover from external networks unless apps on mobile devices are also only allowed to work on your WiFi.

Outlook with AD FS Claims Rules and VPN’s

As mentioned above, Outlook can be limited to working on a given set of IP ranges. If you block AutoDiscover from working apart from on these ranges (as was the issue causing OWA for Devices to fail above) then you can have issues with VPN connections.

Imagine the following scenario: Web traffic goes direct from the client, but Outlook traffic to Office 365 goes via the LAN. A split tunnel VPN scenario.

In this example, if AutoDiscover and initial profile configuration has never run you have a claims rule that allows Outlook to work on the VPN (as the public IP’s for your LAN/WAN are listed in the claims rules as valid source addresses), but AutoDiscover fails due to the same rules (as the web traffic is coming from the client and not the LAN). Therefore AutoDiscover fails and Outlook is never provisioned, so it appears as if Outlook is being blocked by the claim rules even though you are on the correct network for those claim rules.

Outlook with MAPI over HTTP

Updated April 20th 2017

A new connection protocol was released with Exchange Server 2013 SP1 called MAPI/HTTP and has been available in Exchange Online for a time before the release of it on-premises. After this protocol was released, support was made available for it from a range of client versions and currently it works with Outlook 2010 and later (as long as you are on the supported versions and not Outlook 2010 SP1 for example). There is no support for MAPI/HTTP on Outlook 2007 which is why this client will stop working with Office 365 in October 2017 (as Microsoft turn off RPC/HTTP at that time).

With this new protocol in place for Outlook 2010, it is important to ensure that the AD FS claim rule for x-ms-client-application with a value of Microsoft.Exchange.RPC is updated to include Microsoft.Exchange.Mapi and Microsoft.Exchange.Nspi. And come October 2017 when RPC/HTTP is turned off in Exchange Online, claim rules could be updated to remove Microsoft.Exchange.RPC from their checks.

Therefore if you are an Exchange Online user with claims rules for AD FS you need to add the following rules. These would have the same IP ranges as your Microsoft.Exchange.RPC rule and would be identical to this rule in every way, just the x-ms-client-application string needs to look for the following (one rule for each):

  • Microsoft.Exchange.Mapi
  • Microsoft.Exchange.Nspi

The Microsoft.Exchange.Mapi rule can be named “Outlook MAPI/HTTP” and the Nspi rule can be named “Outlook MAPI Address Book”. You need to keep the Exchange Web Services and Exchange Address Book rules in place, but once all users are migrated to MAPI/HTTP you can remove the Microsoft.Exchange.RPC rule.

Note that Exchange Online caches your AD FS credential’s for 24 hours for connections from a single IP address, so if you successfully connect to Exchange Online (say because you have not got the Microsoft.Exchange.Mapi block in place) then you will not connect back to AD FS for 24 hours and so not be affected by new rules that are added after you connect. If you want to test if your new Microsoft.Exchange.Mapi block rules work then you need to connect to Exchange Online via a different IP address, so a trip to the nearest coffee shop in the quest for network lockdown on your companies expense is called for!

Also it is possible to create a single rule rather than the multiple rules listed above. A single rule would contain the claim rule clause similar to the below:

exists([Type == "", Value =~ "Microsoft.Exchange.WebServices|Microsoft.Exchange.RPC|Microsoft.Exchange.Mapi|Microsoft.Exchange.Nspi"])

Note that this is different from what the Rule Builder wizard creates, as that creates a string comparison value, which is compared to the result with ==, but when more than one possible string is stored in the value the comparison operator needs to be =~ which is string compared to RegEx, as the | sign makes the value in the claim rule a RegEx expression.

Legacy Clients and Outlook 2016

Outlook 2016 supports modern authentication out of the box (unlike Outlook 2013 which required client side registry keys and certain hotfixes). But you still need to enable Modern Authentication on your tenant in Exchange Online.

To check if Modern Auth is enabled run Get-OrganizationConfig | FL *OAuth2* from a remote PowerShell session connected to Exchange Online. The value of OAuth2ClientProfileEnabled will be $True if Modern Authentication is enabled. If it is not enabled then Outlook 2016 will use Legacy authentication protocols and so will be blocked by the claim rules discussed here. If you enable Modern Auth though, Outlook 2010 is impacted by Claim Rules and Outlook 2013 June 2015 update + reg keys and Outlook 2016 and later are not impacted by the claim rules above (see below for these). Outlook with Modern Auth is restricted with the use of Conditional Access in Azure AD Premium. If you do not turn on Modern Auth you can use the legacy auth claim rule restrictions until the point where Microsoft enable Modern Auth for you – therefore it is best that if you are doing this then make your changes at your schedule and enable Modern Auth now, EMS to block Outlook 2016 and claim rules to block Outlook 2010 until the point where Microsoft removes support for that product.

Therefore a single claims rule for blocking legacy auth would look like the following:

exists([Type == ""])
 && exists([Type == "", Value =~ "Microsoft.Exchange.WebServices|Microsoft.Exchange.RPC|Microsoft.Exchange.Mapi|Microsoft.Exchange.Nspi"])
 && NOT exists([Type == "", Value =~ "\b51\.141\.11\.170\b"])
 && exists([Type == "", Value == "/adfs/services/trust/2005/usernamemixed"])
 => issue(Type = "", Value = "true");

Note that in the above, though this comes from ADFS on Windows Server 2012 R2, we are still recommending the use of x-ms-proxy and x-ms-forwarded-client-ip. That is because the insidecorporatenetwork claim cannot be used for legacy authentication, as all auth request originate from Exchange Online (active auth) which is never on-premises! This claim rule is added to the Office 365 Relying Party Trust Issuance Authorization Rules after the default Permit Access to All Users rule that the Convert-MSOLDomainToFederated cmdlet or AADConnect configures. The claim rule permits access to all, then denies access if an legacy authentication session happens for Outlook protocols where the forwarded IP address is not the public IP for your LAN

Use Claim Rules to Block Modern Auth Clients

So the final scenario here, newly added to this old post in April 2017, requires issuing deny’s to claims when insidecorporatenetwork is false for the protocols/user agents that you want to block. For example the following will block all modern auth requests from outside the network from all applications apart from ActiveSync and AutoDiscover (as AutoDiscover is used by ActiveSync to set up the mobile device initially):

exists([Type == "", Value == "false"])
 && NOT exists([Type == "", Value =~ "Microsoft.Exchange.ActiveSync|Microsoft.Exchange.Autodiscover"])
 && exists([Type == "", Value == "/adfs/ls/"])
 => issue(Type = "", Value = "true");

Errors in Moving Exchange Archive Mailboxes to Office 365

Posted on 1 CommentPosted in 2010, 2013, archive, cloud, exchange, exchange online, Office 365, Outlook

I was trying to move an Archive mailbox to the Office 365 service from my demo environment the other day when I came across an error I thought I would note down here for completion. I could not find the error elsewhere on the internet

An archive mailbox must be enabled before it can be moved

Now this sounds a stupid sort of error, because if I am moving an archive mailbox then it must already be enabled or the move mailbox wizard will not let me move it. But the mailbox does have an archive on the Exchange organization on-premises, but when the move has completed it has errors reported.

The reason for the error is all down, in my case, to two things.

  1. Its a demo environment and I am doing things too quickly
  2. DirSync is not working at the moment.

In my scenario the DirSync services on my server had stopped a few weeks ago and I had not started them – ensure that DirSync is running. And secondly, as it was a demo I was doing I was creating an archive mailbox and then moving it to the cloud shortly afterwards. Even if DirSync was running, the chances are that it would not have had a chance to sync the existence of the archive mailbox associated with the user account to Office 365’s directory. Archive mailboxes can only be moved from on-premises to the cloud if the cloud service knows about the mailbox archive to move.

To fix my issue I restarted DirSync services and forced a full sync with the cmdlet Start-OnlineCoexistenceSync –FullSync. See on the steps to force a directory sync for running this cmdlet.

Once the sync was completed and Office 365 directory is aware that my user has an on-premises archive I was able to move the archive to Office 365 and keep the mailbox on-premises.

Of course, if I want to create an archive in the cloud with a mailbox on premises for real (not a demo) then I would just create the archive straight in the cloud. My scenario and the three hour DirSync delay (or forcing DirSync) was only needed as I had created an archive and then moved it.

The New Rights Management Service

Posted on 3 CommentsPosted in aadrm, active directory, certificates, cloud, compliance, dirsync, exchange, exchange online, https, hybrid, journal, journaling, mcm, mcsm, microsoft, Office 365, Outlook, pki, policy, rms, smarthost, transport, unified messaging, voicemail

This blog is the start of a series of articles I will write over the next few months on how to ensure that your data is encrypted and secured to only the people you want to access it, and only for the level of rights you want to give them.

The technology that we will look at to do this is Microsoft’s recently released Windows Azure Active Directory Rights Management product, also known as AADRM or Microsoft Rights Management, or “the new RMS”.

In this series of articles we will look at the following:

The items above will get lit up as the article is released – so check back or leave a comment to this post and I will let you know when new content is added to this series.

What is “rights management”

Simply this is the ability to ensure that your content is only used by whom you want it to be used by and only for what you grant. Its known in various guises, and the most common guise is Digital Rights Management (DRM) as applied to the music and films you have been downloading for years.

With the increase in sharing music and other mp3 content in the last ten plus years, the recording companies and music sellers started to protect music. It did not go down well, and I would say this is mainly because the content was bought and so the owner wanted to do with it as they liked – even if what they liked was legal they were limited from doing so. I have music I bought that I cannot use because the music retailer is out of business or I tried to transfer it too many times. I now buy all my music DRM free.

But if the content is something I created and sold, rather than something I bought I see it very differently. When the program was running I was one of the instructors for the Microsoft Certified Master program. I wrote and delivered part of the Exchange Server training. And following the reuse of my and other peoples content outside of the classroom, the content was rights protected – it could be read only by those who I had taught. Those I taught think differently about this, but usually because the management of getting a new copy of the content when it expires!

But this is what rights management is, and this series of articles will look at enabling Azure Active Directory Rights Management, a piece of Office 365 that if you are an E3 or E4 subscriber then you already have, and if you have a lower level of subscription or none at all you can buy for £2/user/month and this will allow you to protect the content that you create, that it can be used by only those you want to read it (regardless of where you or they put it) and if you want it can expire after a given time.

In this series we will look at enabling the service and connecting various technologies to it, from our smartphones to PC’s to servers and then distributing our protected content to whom needs to see it. Those who receive it will be able to use the content for free. You only pay to create protected content. We will also look at protecting content automatically, for example content that is classified in a given way by Windows Server or emails that match certain conditions (for example they contain credit cards or other personally identifiable information (PII) information such as passport or tax IDs) and though I am not a SharePoint guru, we will look at protecting content downloaded from SharePoint document libraries.

Finally we will look at users protecting their own content – either the photographs they take on their phones of information they need to share (documents, aka using the phones camera as a scanner) or taking photos of whiteboards in meetings where the contents on the board should not be shared too widely.

Stick around – its a new technology and its going to have a big impact on the way we share data, regardless of whether we share it with Dropbox or the like or email or whatever comes next.

Message Classifications, Exchange 2013, Exchange Online and Outlook

Posted on 5 CommentsPosted in 2010, 2013, exchange, exchange online, Office 365, Outlook, rms

Message Classifications are a way to tag email with a property that describes the purpose of the email, for example “Internal Use Only” might be a classification to tell the recipient of the email that the message should not be forwarded. Classifications are configured by administrators and appear shortly after creation in Outlook Web App, but need further work for them to appear in Outlook. Once you have a classification system in place, you can use Transport Rules in Exchange to read the classification and act on the message, for example if the message is classified “Internal Use Only” and the recipient is in an external domain then an NDR could be returned and the message dropped.

This blog post will cover the following:

  1. Creating a message classification
  2. Localising message classifications for different geographies and language groups
  3. Classification considerations when you have multiple Exchange organizations
  4. Creating a transport rule to act on a classified message
  5. Sending messages with classification via OWA
  6. Setting up Outlook to use message classifications
  7. Sending messages with classification via Outlook

Creating a Message Classification

This needs to be done in the Exchange Management Shell. It is a single cmdlet per classification. A simple example being:

New-MessageClassification -Name “CorporateConfidential” -DisplayName “Corporate Confidential” -SenderDescription “This email is confidential for the entire company and not to be distributed outside the company”

This creates a classification called Default\Name. In the above example this would be Default\CorporateConfidential. This value is not seen by anyone other than the administrators of Exchange, users see the DisplayName value. The SenderDescription appears at the top of the message as it is being written in Outlook or OWA and you can have a different RecipientDescription for display in the recipients email. In the above example the SenderDescription (which is required) will also be the RecipientDescription as that was not specifically set.

Localising Message Classifications

If you want to localise the classification continue with something similar to this (translations from Bing!) by changing the display and description text and setting the locale to match:

New-MessageClassification -Name “CorporateConfidential” -DisplayName “Société Confidentielle” -SenderDescription “Cet email est confidentiel pour l’ensemble de l’entreprise et de ne pas être distribués à l’extérieur de l’entreprise” -Locale FR-FR

Once you have the correct translation, which you need for the DisplayName and SenderDescription, you run the cmdlet which sets the language against the previously created classification. Note that at the time of writing this cmdlet does not work in Exchange Online (see reported issue for more).

Classifications and Hybrid Mode (or multiple Exchange organizations)

If you have both installed an Office 365 tenant and on-premises organization (i.e Hybrid Mode) then you should create the classifications in one organisation (recommend the on-premises org) and export them for use in Outlook (see later in the blog). For the other organization (recommend Exchange Online) you should use the same cmdlets to create the classifications again in Exchange Online but specify the ClassificationID that was automatically set when the classification was made on-premises – the same classification in both organizations should have matching ClassificationID. To get the ClassificationID from Exchange on-premises before running the cmdlets again in remote PowerShell use Get-MessageClassification | FT Name,ClassificationID

Creating a Transport Rule That Uses Message Classifications

1Create a new transport rule that implements RMS protection with the “CompanyName – Confidential” template if the message is flagged with the previously created classification. The following screenshot shows the required properties, or you could use PowerShell:

New-TransportRule -Name “Rights Protect Company Confidential Emails PS” -HasClassification CorporateConfidential -ApplyRightsProtectionTemplate “CompanyName – Confidential”

Remember to change the name of the classification and the RMS template name to suit. Also remember that if you have Hybrid Exchange mode enabled, you need to create the transport rule in both locations, therefore you need RMS enabled in both locations (though if you are not using RMS as this example does, you do not need it enabled to do message classificaitions).

Classifications and OWA

Once the rule and the classification are created, send an email using OWA where you have set the classification during composing the email. Note that during testing I found it could take up to 24 hours for Exchange Online to show both the RMS templates in OWA and the message classifications.


Note that at the time of writing there is a bug in OWA in Exchange 2013 that causes transport rules to not see the classification correctly. Tests using Outlook (see the next few steps) will work fine.

Classifications and Outlook

It is more complex to do message classifications for Outlook as you need to export the classifications from Exchange Server as an XML file, place the XML file in a location the Outlook client computer can get to and set some registry keys. The steps are as follows:

  1. To send the email using Outlook you need to first export the message classification using Export-OutlookClassification.ps1 script from Exchange on-premises (in the Exchange/v15/scripts folder of your installation). To export from Exchange Online you need to copy this script from an on-premises installation and run it in your remote PowerShell window connected to Exchange Online.
  2. Once you have the Classifications XML you need to copy this to each Outlook computer and run Regedit on these computers to enable classifications and to point to the classification file. The regedit settings are:
    1. [HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Policy]
    2. “AdminClassificationPath”=”c:\\temp\\temp\\classifications.xml”
    3. “EnableClassifications”=dword:00000001
    4. “TrustClassifications”=dword:00000001
  3. You need to set the path correctly in the registry as to the location (on the local computer or always available network drive) that the classifications xml file is located. This registry set is for Outlook 2013 – change the version number from 15.0 to suit earlier versions of Outlook (2007 = 12.0, 2010 = 14.0).
  4. Once the registry is set and the classifications XML file in the location the registry will look in, restart Outlook and compose a test message, setting the classification you are looking for in transport rules.
  5. When the message arrives at the destination inbox, if it was sent with the classification then it should have the RMS template applied (the action of the transport rule). In the following screenshot you can see two emails in Outlook. The lower email was sent with OWA and due to an OWA bug the classification is set incorrectly and so it is not RMS protected as the transport rule does not fire. The upper email can be seen to have RMS protection, though I cannot screenshot it as it has RMS protection and that stops me using PrintScreen or OneNote screen clipping tools whilst that message is open!

Unknown Error, Outlook 2003 and Exchange 2010

Posted on Leave a commentPosted in 2003, 2010, exchange, Outlook

It’s a well documented issue with Outlook 2003 connecting to Exchange 2010 that means Outlook 2003 is not as responsive in Online mode as it was with legacy versions of Exchange Server (

What is less well documented is an odd error message that can appear because of this interaction.

Imagine the following scenario. User on Outlook 2003 has lots of messages to delete, and deletes them one at a time. Outlook will not refresh the display for up to 5 seconds (the lowest setting that you can tell Outlook to refresh, via the Maximum Polling Frequency registry key). The problem is that if the user deletes a message and it does not disappear from the screen and then (thinking its gone, and the highlight has moved onto the next message) presses delete again. Outlook generates “Unknown Error” – which is not exactly helpful, and could appear as often as every other message that is deleted.

How to fix: Cached mode (though in the scenario I came across the above it was Outlook on a Terminal Server, so that’s not an option), upgrade the client version of Outlook, or use Shift or CTRL select and delete all your emails in one go!

Blogger Blogs in Outlook – Incorrect Dates

Posted on Leave a commentPosted in 2007, Outlook

This has been obvious to me for a while – whenever I viewed this blog in Outlook 2007 via the common RSS feed store, the dates were all incorrect and so new posts appeared at random within the list.

I finally found a fix yesterday – the post was based upon ATOM technology and not RSS technology. I have therefore changed the subscribe link on the site to add ?alt=rss to the end of the link.

If you subscribe to this blog please delete it from your feed store in IE 7 and resubscribe at