How to report spam that arrives in Office 365 to Microsoft

Ten years ago, Bill Gates told the World Economic Forum that the problem of spam would be solved within two years (by 2006). To be fair to Gates, he also noted that his predictions have not always been on the mark. I guess his views on the demise of spam fall into the “not accurate” because it still exists today. At least, I certainly receive my fair share of offers to join dubious projects to share money, buy different pills, or meet people that I really would prefer to avoid.

But if you’re an Office 365 user, you can help by letting Microsoft know about spam that manages to get through to your Inbox. The techniques used by spammers to defeat defenses evolve and morph all the time and the anti-spam developers have to run to keep pace with new threats. Sending Microsoft examples of spam helps the developers to figure out the characteristics of the message that allowed the spam to get past anti-spam checks. Here’s what you need to do.

Viewing message properties

Viewing message properties

Microsoft has a junk mail reporting add-in for Outlook that you can install and use. If this isn’t possible, you can use the following steps to report a message with Outlook 2013:

  • Open the spam message
  • Click File to go to the “backstage” area.
  • Click Properties to reveal the header information (see above)
  • Copy the Internet headers (CTRL/C).
  • Close the message.
  • Create a new message to forward the spam data (including a copy of the original mesage) to Junk at Office365 dot Microsoft dot com. This address is monitored by Microsoft’s anti-spam team.
  • Paste the details of the message header that reveal the path the message took to your Inbox into the message body and then send the message.

Other clients will have different methods to expose the message headers. The important point is to provide these details to Microsoft as they help to understand how the message was transferred from server to server from origin to final delivery. The information will look something like the extract shown below:

Received: from ( by ( with Microsoft SMTP
Server (TLS) id 15.0.1054.13 via Mailbox Transport; Wed, 22 Oct 2014 09:14:43
Received: from ( by ( with Microsoft SMTP
Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 09:14:42 +0000
Received: from (2a01:111:f400:7e04::154) by (2a01:111:e400:8814::50) with Microsoft
SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Wed, 22 Oct 2014
09:14:42 +0000
Received: from ( by ( with Microsoft SMTP
Server (TLS) id 15.0.1049.20 via Frontend Transport; Wed, 22 Oct 2014
09:14:41 +0000
Received: by with SMTP id ar1so3021765iec.38

The MessageHeaderAnalyzer app (for Outlook 2013 and Outlook Web App) is also a useful way to view message header information. However, the easiest way to get the information needed by the anti-spam team is to extract it as explained above.

Viewing message header information for spam with the MessageHeaderAnalyzer app

Viewing message header information for spam with the MessageHeaderAnalyzer app

I doubt that spam will go away anytime soon. The only way to keep it under some form of control is to make sure that those who are responsible for blocking spam know about how it gets through. Helping them by reporting spam is a good way for you to contribute to the fight.

Follow Tony @12Knocksinna

About these ads
Posted in Email, Office 365, Outlook 2013 | Tagged , , , , | 8 Comments

AQS and KQL: Two query languages for different versions of Exchange

Exchange 2010 uses AQS (Advanced Search Syntax) to construct its discovery searches. Exchange 2013 takes a difference approach and uses KQL (keyword query language). Why the change?

AQS is shared with other Windows search components such as Windows Desktop Search. As explained in my article “Exchange searches are limited to certain item types”, Exchange 2010 only supports a subset of the full AQS capabilities. On the other hand, KQL is shared with other Office 2013 applications, the most important of which is SharePoint 2013 because the two applications can form a single discovery domain across the email stored in Exchange and the documents held in SharePoint.

Giving Exchange and SharePoint a common search syntax makes a heap of sense. Another advantage is gained in that KQL is able to perform “proximity searches”. Take the situation where you want to search for items that mention the words “Azur project” and have the word “bribe” somewhere close to those words. AQS can certainly find anything that includes “Azur project” AND “bribe” but it can’t find “Azur project” with “bribe” within 30 words (in KQL syntax, the word “bribe” is NEAR (n=30) the other phrase). As you can imagine, this capability could be very useful in searches that start out being somewhat imprecise because you’re not quite sure about what you’re looking for. It’s true that searches like this might throw up more results than you are able to deal with on a practical basis, but they could provide a hint as to how searches might be refined to hone in on the critical items.

You don’t need to deploy SharePoint 2013 and Exchange 2013 together to be able to use KQL, but if you do, the searches will uncover information stored in site mailboxes, modern public folders (but not their older equivalents), normal user mailboxes, and other SharePoint sites – and Lync conversations and other interactions if you deploy Lync 2013 alongside Exchange 2013.

Deployed alone, Exchange 2013 is quite capable of using KQL for Exchange-specific multi-mailbox searches executed through the Exchange Administration Center (EAC) console. The only dependency is on the content indexes generated from Exchange mailbox databases by Search Foundation. These content indexes are populated through normal user activity and as the Mailbox Replication Service (MRS) moves mailboxes over to Exchange 2013 servers. You’ll still have to use the Exchange Control Panel (ECP) to perform the older AQS-style searches for mailboxes that remain on Exchange 2010 and then combine the results of both searches by exporting content from both searches to a common discovery mailbox.

You might expect the Search-Mailbox cmdlet to use KQL when executed on an Exchange 2013 server but this is not the case. The older syntax is used. I think this is actually quite logical because it means that code written for older versions of Exchange will run against Exchange 2013 too – and the Search-Mailbox cmdlet is often used to scan mailboxes for content that needs to be removed. Search-Mailbox includes the powerful (and potentially destructive) DeleteContent switch for this purpose. Use with care!

KQL syntax is pretty powerful. I’m sure that the Exchange community will learn KQL tips and techniques to improve searches from those who work with SharePoint and vice versa. It’s nice when a change makes life easier.

Follow Tony @12Knocksinna

Posted in Exchange, Exchange 2010, Exchange 2013 | Tagged , , , , | Leave a comment

Using Search-Mailbox to look for items with a specific date

A question from a reader is often a good start to a useful discussion or to probe into a topic. Tim Read contacted me to discuss some problems he had with using the Search-Mailbox cmdlet (available in cloud and on-premises versions of Exchange). In this case, he was using Exchange 2013 CU5 and wanted to be able to search mailboxes for items that matched specific values for the sender, date, and subject attributes.

Apparently it was easy enough to run a search that found items that matched a combination of sender and subject but things got a little tricky when a date was thrown into the mix and not much joy was extracted from examples found on various sites.

Parser errors were reported when a date was specified, which indicated that the date was in a format unacceptable to Search-Mailbox. Some confusion arose on this point as it is natural to assume that search criteria have to be stated in KQL syntax because this is what is used by the Search Foundation, which provides the indexes that Exchange interrogates to perform mailbox searches.

However, the Search Foundation was only introduced in Exchange 2013 and code written for Exchange 2010 has to continue working on Exchange 2013 or in Office 365. The cmdlet therefore masks the change that occurred in the underlying search engines. Dates should be formatted like any other date consumed by Exchange according to the locale installed on the server.  So 1 October 2014 is “1/10/1014” in Ireland or the U.K. or “10/1/2014” in the U.S. Alternatively, you can pass a date like “14-Oct-2014” in either locale.

Now that we understand how to format dates, we can construct a Search-Mailbox command to do the work. This example creates a collection of mailbox objects from a database and searches them for items sent by a user called “Ben Andrews” (the SMTP email address for the user can also be used) on 13-Oct-2014 with “Interesting” in the message subject. Items in the Recoverable Items folder structure are included in the search.

Get-Mailbox –Database VIP –ResultSize Unlimited | Search-Mailbox -TargetMailbox AdminSearchMailbox -TargetFolder “Search Results” -SearchQuery {Subject:"Interesting" AND From:"Ben Andrews" AND Sent:"10/13/2014"} -LogOnly -LogLevel Full –SearchDumpster

This command will create a log of the discovered items in the target folder in the target mailbox. No items are copied unless the –LogOnly switch is removed. If the command is then rerun, Exchange creates a folder named after the searched mailbox and date and time in the target folder and copies the discovered items there, placing them in sub-folders corresponding to the folders in the source mailbox.

Search-Mailbox is often to remove unwanted items that arrive into user mailboxes. This is done by adding the –DeleteContent switch to a command. Clearly you should not rush into removing content from mailboxes until you are absolutely sure that your command targets the correct items, which is one good reason to run a command with the –LogOnly switch before proceeding to delete anything.

Exchange protects administrators against themselves by requiring those who want to delete content to possess the special “Mailbox Import Export” Role-Based Access Control (RBAC) role. As the role name implies, it is designed to allow administrative access to user mailbox data to import data from PSTs or export items to PSTs. In this instance, it’s used because deleting content is obviously something that should be controlled.

If your account does not hold the role, you won’t see the –DeleteContent switch or be able to use it with the Search-Mailbox cmdlet. You can either create a new RBAC role group containing the role and assign it to the appropriate users or add the role to an existing role group, which means that any user that is already part of the group will be able to use the switch. For instance, here’s how to add the role to the Organization Management role group, which is what I did for my Office 365 tenant.

New-ManagementRoleAssignment -Name "Import Export_Organization Management" -SecurityGroup "Organization Management" -Role "Mailbox Import Export"

You have to create a new EMS session to pick up the RBAC amendments because RBAC only evaluates a user’s permissions when EMS initializes. Once EMS is ready, I can run a command like this to remove the offending content.

Get-Mailbox –Database VIP –ResultSize Unlimited | Search-Mailbox -TargetMailbox AdminSearchMailbox -TargetFolder “Search Results” -SearchQuery {Subject:"Interesting" AND From:"Ben Andrews" AND Sent:"10/13/2014"} -DeleteContent -LogLevel Full –SearchDumpster

So there you are… A reader query that led to some interesting consideration of a very useful command and its various switches. Hopefully this will help others who struggle with similar challenges.

Follow Tony @12Knocksinna

Posted in Exchange, Exchange 2010, Exchange 2013 | Tagged , , , , , | 6 Comments

The strange case of the MailboxSentItemsConfiguration cmdlets

Microsoft introduced the rather useful cmdlet set of Set-MailboxSentItemsConfiguration and Get-MailboxSentItemsConfiguration a long time ago (Exchange 2010 SP2 RU4 – August 2012). As you might recall, these cmdlets allow an administrator to exert control over where Exchange stores copies of messages sent by delegates.

What’s surprising and genuinely puzzling is that the cmdlets were not included in Exchange 2013 RTM and have not appeared in any version since, including Exchange 2013 SP1 (where you might have expected them to show up) or even the latest Exchange 2013 RU6 update. The cmdlets have also failed to show up in Office 365, at least not in my tenant domain.

When the cmdlets first appeared in Exchange 2010 SP2 RU4, I thought that they were an elegant solution to the need to mess with registry settings to instruct Outlook how to handle messages sent by a delegate. I content that the right place is in the Sent Items folder of the mailbox belonging to the user for whom the message is sent. Outlook prefers to squirrel the message away in the Sent Items folder of the delegate’s mailbox.

The registry hack involves creating a new DWORD value called DelegateSentItemsStyle, setting its value to 1, and then restarting Outlook. I’m not saying that I dislike a ramble through the registry. Sometimes you have to get down and dirty to convince Windows and various programs to do the right thing. Thankfully, we have to resort to RegEdit far less now than in the past, but the same major problems exist. First, registry hacking is extremely prone to errors. Second, the registry is specific to a single PC and usually, to a specific version of a product. In this case, the new value has to be added in different places depending on the version of Outlook you use.

In short, a registry hack is a great way for a developer to influence the way a product works for demonstration environments. It is an awful way to accomplish a long-term change in product behaviour that can be managed centrally and endures across multiple product versions and service packs. The Office products attempt to mitigate the problem by being able to set registry values through group templates, but that’s a workaround that has its own particular charms and flaws.

Exchange has done an awful lot over the Exchange 2010 and Exchange 2013 releases to permit administrators to be able to control mailbox settings for users through EMS cmdlets such as Set-MailboxAutoReplyConfiguration. The appearance of the *-MailboxSentItemsConfiguration cmdlet pair seemed to be just another step along the path to allowing administrators to script the correct configuration of user mailboxes as they were created and was, in my mind, a very good thing.

So I remain puzzled and bemused why these cmdlets have not appeared in either Office 365 (where they would seem to be perhaps even more valuable than in an on-premises deployment) or Exchange 2013. The code still works and functions well inside Exchange 2010. I’m sure that the Exchange developers have their own reasons for not bringing it forward into the latest products but I don’t know why. Strange!

Follow Tony @12Knocksinna

Posted in Exchange, Exchange 2010, Office 365 | Tagged , , , , , , | 6 Comments

Recoverable Items and Calendar Versioning

Keeping track of calendar items such as meetings to ensure that a definitive version of the item is available is sometimes hard to do, especially when multiple clients or multiple users access a calendar. Exchange 2010 made architectural changes in the server to concentrate processing in a common set of business logic, a step that helped matters because it stopped items being processed differently in various places.

It is still possible for misbehaving clients to wreak havoc with calendars, as in the case of the woes of Apple’s iOS email app, However, better awareness of potential problems within mobile device vendors, new code to protect Exchange against malfunctioning clients, and the introduction of mobile clients that don’t use ActiveSync (like OWA for Devices) have all helped to reduce calendar problems.

Apart from consolidating the business logic for calendar processing, Exchange 2010 introduced calendar versioning to improve overall reliability for events like meetings. Calendar versioning means that Exchange keeps track of all the changes that occur to calendar events so that the Calendar Repair Assistant (CRA) can validate that the calendar reflects the most current and accurate state. Sounds good, which is why calendar versioning is enabled by default. Enabling the feature comes with a certain price, which Microsoft’s sizing guidelines for Exchange 2013 puts at an increase of approximately 3% in mailbox size.

If you want to disable calendar versioning for a mailbox, you can run the Set-Mailbox cmdlet as follows:

Set-Mailbox –Identity TRedmond -CalendarVersionStoreDisabled $True

After you’ve disabled calendar versioning, the Managed Folder Assistant will clear out the saved items the next time that it processes the mailbox.

So where does the Recoverable Items folder come into play for calendar versioning? Well, Exchange has to hold the changes made to calendar items somewhere if the CRA is to be able to validate matters. As it happens, the Recoverable Items folder is the place where the changes are held, if only because this location is invisible to clients like Outlook and OWA. You could argue that it would be better to record the data elsewhere, such as another hidden folder, but the Recoverable Items folder is available and it is quota-controlled, as we’ll come to later.

The normal state of affairs is to hold “stripped” versions of calendar items in the root of the Recoverable Items folder for 120 days. Stripped means that only the essential details of the items are retained. Attachments any extraneous information are removed. In essence, sufficient information such as meeting location, time, duration, and so on is kept to allow CRA to do its work, but no more.

But when information needs to be preserved, such as on a short term basis (Single Item Recovery) or longer (litigation or in-place hold), then Exchange retains full copies of changed calendar items in the Recoverable Items\Deletions folder (if the item was first soft-deleted and then changed) or Recoverable Items\Versions folder (if the item is changed in the Calendar folder). A stripped version of an item is also preserved if a hard-delete operation is performed against a calendar item in the Recoverable Items\Deletions folder. All of this is done to make sure that information is preserved in an immutable fashion. In other words, users cannot take actions to remove information when they should not.

Getting back to Recoverable Items quotas, it is possible that a mailbox that hosts a very busy mailbox might accumulate a lot of calendar versioning data in the Recoverable Items structure, especially if it is common practice to include large attachments in meeting requests, as is often used when circulating information that will be discussed during the meeting. Despite steps taken by Microsoft in Exchange 2010 SP2 RU2 and RU3 to restrict the amount of quota consumed by calendar versioning, it is conceivable that a large percentage of the recoverable items quota might be taken up by calendar items with a knock-on effect of excessive database growth and potentially problems moving mailboxes. For very active mailboxes, the space consumed by calendar versioning might even push the mailbox to up its recoverable item quota.

All of this goes to prove that the Recoverable Items folder deserves some tender loving care from Exchange administrators. While you might not need to learn the exact details of what happens under the covers until problems occur, it is worthwhile to keep an eye on the use of the Recoverable Items folder in your organization.

Follow Tony @12Knocksinna

Posted in Email, Exchange, Exchange 2013 | Tagged , , , , , | 3 Comments

Exchange Unwashed Digest – September 2014

September 2014 included Exchange Connections in Las Vegas (all seemed to have a great time) plus some upheaval in Microsoft, so there was plenty to discuss in my “Exchange Unwashed” blog at Here’s what happened during the month:

The best Exchange documentation update ever? (Sept 30): I received criticism from some Microsoft employees for posting this note about a change made by a technical writer to the Exchange documentation before they lost access to the corporate network. But it was a good change (now reversed) because it recognized the achievements of some who should be acknowledged. And anyway, if you put something on the Internet, it becomes fair game for commentary…

Microsoft layoffs impact Exchange technical writers – where now for documentation? (Sept 25):  Layoffs are horrible exercises in corporate reductions, but some are worse than others. I didn’t like the way that Microsoft cut some of their technical writing talent during round 2 of their current layoffs because I think it weakens their ability to communicate complex technical content to the Exchange community. When Exchange 2016 comes into sight next year, we will realize the full impact of this change.

Chrome problem for Exchange due to Google haste and Microsoft inattention (Sept 23): The problem caused by Chrome 37 revealed an interesting lack of communication and attentiveness on the part of both Google and Microsoft. I don’t think Google quite realized the impact of the change on enterprise applications (like OWA and EAC) and Microsoft definitely didn’t track the thinking that Google expressed in various forums. So we came to a point where Chrome 37 appeared and everyone had a problem. Not good.

Wrapping up Exchange Connections 2014 (Sept 19): There really is a role for independent technology conferences that focus on real-world problems. At least, that’s what the folks who attended Exchange Connections seem to say after hearing great sessions delivered by great speakers in a great location (the Aria Hotel in Las Vegas). It was nice to avoid lashings of corporate marketing too. I hope that you’ll consider joining us next year.

Product quality and functionality gaps top-of-mind issues at Exchange Connections (Sept 17): The folks who come to Exchange Connections tend to be IT professionals who are responsible for running servers, so when they were asked about current concerns, they reflected on some recent quality problems experienced by Exchange 2013 (CU6 specifically) and a gap that seems to be growing between the functionality available in cloud versions when compared to on-premises software.

Google kills showModalDialog API in Chrome 37 and does evil to Exchange (Sept 15): Google shipped Chrome 37 in late August but it took a little time for software updates to make their way onto user PCs, at which time people started to notice that some of the user interface components in OWA and EAC just didn’t work any more. The problem affected Exchange 2010, Exchange 2013, and Exchange Online and it’s all due to a decision Google took to deprecate the showModalDialog API. After all, it’s old and tired – a bit like me, really. For more details on just how this problem developed, see my September 23 post above.

Office Delve debuts to help Office 365 users find information again (Sept 11): I really like Office Delve, the new Office 365 launched by Microsoft to exploit the power of the underlying “Office Graph” technology. I like Delve because I think it’s an interesting new approach to exposing and eradicating the information silos that develop all so rapidly inside large organizations. Of course, it’s early days yet, but I like what I see…

Yet another co-existence bug in Exchange 2013 CU6 causes ActiveSync failures for Exchange 2007 users (Sept 6): Just when you thought it was safe to start deploying Exchange 2013 CU6 (which really works very well in many circumstances), along came yet another co-existence bug, this time to afflict ActiveSync users whose mailboxes were still on an Exchange 2007 mailbox server. Maybe they should be using a more modern server? Or perhaps these bugs shouldn’t happen…

Sad death of Exchange expert Andrew Ehrensing (Sept 4): This was a really sad note to write, but so many people had experienced the wit and expertise of Andrew Ehrensing that his passing had to be acknowledged. Sad…

Why Exchange 2016 will be coming to you soon (Sept 2): The month opened with a discussion about the next major release of Exchange, expected to appear in late 2015 alongside the rest of Office Wave 16. Will this release include all the functionality now appearing in Office 365? We’ll just have to wait and see.

On to October. Every month brings its own surprises and developments! I’ll try to keep up to speed with what’s happening in the world of Exchange and bring it to you here or in “Exchange Unwashed.” Or you can hear what Paul Robichaux and I have to say about the world of Exchange in the “Exchange Exposed” quarterly podcast, the first episode of which is called “Searching for Stability” and is now available for your download delight.

Follow Tony @12Knocksinna

Posted in Cloud, Exchange, Exchange 2013 | Tagged , , , , , , , , , | 3 Comments

Exchange 2013 workload management controls how the Mailbox Replication service uses system resources

One of the more important changes for the Mailbox Replication service (MRS) in Exchange 2013 that I discovered when researching content for “Microsoft Exchange 2013 Inside Out: Mailbox and High Availability” is how the function of the MRS configuration file has changed. As you might recall from the steps taken to tweak MRS processing in Exchange 2010, the MRS configuration file dictates parameters such as how many concurrent mailbox moves can be performed to a single target database or single target server. It also dictates how many move reports are stored for a mailbox.

You can find the MRS configuration file (MSExchangeMailboxReplication.exe.config) in the \Exchange\V15\Bin directory on multi-role or mailbox servers (for Exchange 2010, the configuration file is in the \V14\bin directory on multirole or CAS servers). The file remains text-based so it can be opened with Notepad. The information that controlled MRS behavior in Exchange 2010 is in the section shown below:

Mailbox Replication Service configurationSetting Name - Default, MinValue, MaxValue

MaxRetries - 60, 0, 1000
MaxCleanupRetries - 480, 0, 600
RetryDelay - 00:00:30, 00:00:10, 00:30:00
MaxMoveHistoryLength - 5, 0, 100
MaxActiveMovesPerSourceMDB - 20, 0, 100
MaxActiveMovesPerTargetMDB - 20, 0, 100
MaxActiveMovesPerSourceServer - 100, 0, 1000
MaxActiveMovesPerTargetServer - 100, 0, 1000

Many of the values for settings like MaxMoveHistoryLength (the number of move reports stored for a mailbox) are increased in Exchange 2013. Most interestingly, the values for MaxActiveMovesPerTargetMDB (maximum number of concurrent moves to a single target database) increases from 2 to 20 while MaxActiveMovesPerTargetServer (maximum concurrent moves to an individual target server) increases from 20 to 100.

You might conclude that the increase is evidence of either radically improved efficiency on the part of MRS in terms of its ability to process mailbox moves or that the newly rewritten managed Store in Exchange 2013 is so much better at dealing with I/O. Some improvements have been made in I/O but the real reason why the new limits exist is that they now act as a backstop for MRS processing.

Instead of being constrained by hard limits, the Exchange 2013 version of MRS is flexible and uses a technique called dynamic throttling to note what’s happening on a server by reference to Exchange’s workload management system. When MRS starts to process mailbox moves, it observes the amount of system resources that it uses and the overall level of system health. If mailbox moves flow well and system resources are not limited, MRS will increase the number of mailbox moves that it processes concurrently. On the other hand, if system resources begin to become scarce, MRS throttles back and processes less work until availability of resources improves.  Although it is unlikely that MRS will ever hit the maximum values defined in its configuration file when processing mailbox moves on production servers, it’s possible that it might on test servers or when systems are running in periods of ultra-low demand.

From Exchange 2013 CU3 onward, you can force MRS to revert to using the limits set in its configuration file by adding a line to the MRS configuration file to disable dynamic throttling. The line is:

DisableDynamicThrottling = “true”

I wouldn’t be in a rush to disable dynamic throttling as, in effect, you then allow MRS to move mailboxes with little real regard for the other workload running on a server. Some more mailboxes might be moved in a shorter period. However, those moves might degrade the responsiveness of the server to client connections. Workload management is designed to arbitrate between competing workloads, favoring critical demands such as those needed to serve users and giving less to background system processes, like mailbox moves. Moving mailboxes is important, but delivering good response to users is even more important.

Workload management exerts a very big influence over Exchange components. This is a good development because it means that the work done by components like MRS can flex in line with available resources instead of being constrained by rigid limits that are acceptable in periods of peak demand but take no account of the valleys that also occur in resource demand.

Follow Tony @12Knocksinna

Posted in Email, Exchange, Exchange 2013 | Tagged , , , , | 2 Comments