S/MIME in Office 365

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and digital signing of MIME data. Configuring S/MIME in Office 365 is a slightly different procedure than configuring S/MIME on-premises. This blog is for people who want to move from on-premises to Exchange Online and want to continue to use S/MIME. This article will also apply to any Office 365 customers who want to use S/MIME for sending digitally signed and encrypted mails.

Configuring S/MIME will allow users to encrypt and/or digitally sign an email. S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity, non-repudiation of origin (using digital signatures), privacy, and data security (using encryption). Further, Office 365 also provides the capability for end users to compose, encrypt, decrypt, read, and digitally sign emails between two users in an organization using Outlook, Outlook Web App (OWA) or Exchange ActiveSync (EAS) clients.

Below, we will take you through the configuration steps that you will need to follow to configure S/MIME for Exchange Online Only (Scenario 1), and for Exchange Hybrid (Scenario 2).

Scenario 1: Exchange Online

In this scenario, all the users are hosted on cloud and there is no on-premises Exchange organization.

Requirements

1. .SST File (Serialized store): The SST file contains all the root and intermediate certificates that are used when validating the S/MIME message in Office 365. The .SST file is created from certificate store explained below.
2. End user’s certificate for signing and encrypting the message issued from Certificate Authorities(CA) either Windows based CA or Third party CA.

Configuration

Remember that in Exchange Online, only the SST will be used for S/MIME certificate validation.

1. Create a .SST file for the Trusted Root CA / Intermediate CA of the certificate issued to the users:
You can use either Certificate MMC or PowerShell cmdlets to export SST file. I am using Certificate console to export the .SST here:

Open certmgr.msc snap-in, expand Trusted Root Certificate Authorities > Certificates > select the CA Certificates which issued the certificates to end users for S/MIME and right click > All Tasks > Export…

Note: There may be some Intermediate CA’s. You can move them to Trust Root CA folder and select them (including the Trusted CA certificates) and export it all in one .SST file.

2. Select Microsoft Serialized Certificate Store(.SST) > Click Next and save the SST file:

3. Upload .SST to office 365 server:
Update the SST on office 365 exchange server by executing the following commands using remote PowerShell.

$sst = Get-Content <sst file copied from the box>.sst -Encoding Byte

(Example: $sst = Get-Content TenantRoot.sst -Encoding Byte)

Set-SmimeConfig -SMIMECertificateIssuingCA $sst

4. Publish user’s certificate to the Exchange Online GAL (Global Address List) using Outlook. If not published, users will not be able to exchange S/MIME encrypted messages.

Note: To publish the certificate, the user must first have the certificate installed on their local machine.

• On the File menu in Outlook 2013, click Options.
• On the Outlook Options window, click Trust Center, click Trust Center Settings..., and then click Email Security.
• In the Trust Center window, click Settings… (Here, you need to choose certificate issued by the CA you are going to use for S/MIME).
• In the Change Security Settings window, type the Security Settings Name (you can name it anything) and choose Signing and Encryption certificate. Select the appropriate certificate assigned in previous steps, leave the Algorithm default and click OK.

• Once the information is selected, you will notice the Default Setting is populated with Security Settings Name. Now you can click the Publish to GAL button. To publish the certificate to the GAL, click OK.

5. To confirm the certificate is published in AAD (Azure Active Directory), connect to Exchange Online using remote PowerShell and run following command. Check to make sure that the UserSMimeCertificate attribute is populated with the certificate information. If not, return to step 4.

Get-Mailbox <user> | FL or FT *user*

6. Once you confirm the end user has the certificate on their machine under certificates > personal store and also published in AAD, the users can use Outlook, OWA, or EAS to send and receive S/MIME messages.

Note: Make sure you check S/MIME Supported Clients section below before exchanging S/MIME messages.

Scenario 2: Exchange Hybrid

In Exchange Hybrid topology, some mailboxes are homed on-premises and some mailboxes are homed online, and users share the same e-mail address space.

Requirements:

1. Public Key Infrastructure (PKI). You can use Active Directory Certificate Services to issue certificates to the end users.
2. SST File (Microsoft serialized certificate store). Tenant admins will have to configure their tenant in O365 with signing certificates issuing CA & Intermediate certs information. They will have to produce a SST file, which is a collection of certificates, and then later import it into O365 to validate S/MIME.
3. DirSync. You will need version 6593.0012 or higher of the DirSync tool. DirSync is used to synchronize the Active Directory user object to the Azure AD, so that cloud users can also see the certificate information of recipients when performing S/MIME (encrypt) operation.

You can verify the DirSync version following these steps:

• Open Control Panel.
• Click Programs.
• Click Programs and Features.
• Click Windows Azure Active Directory Sync tool.
• Check the version as the screenshot below:

Configuration:

1. Public Key Infrastructure (PKI)

The users in your organization must have certificates issued for digitally signing and encryption purposes. You can either install Certificate Authority On-premises to issue certificates to the end users or have third party certificates issued to them. There are two attributes in a user object where certificate information stored: 1) UserCertificate and 2) UserSMimeCertificate.

UserCertificate is populated automatically in on-premises deployment with a Windows root CA. This is populated at the time the user enrolls for a user certificate. This could be done manually for each user, or an administrator can set a GPO to automatically enroll all users.

Certificates are stored in the userSMimeCertificate attribute when an Outlook client publishes a certificate to GAL. Outlook 2010 and above will populate both attributes with the same certificate http://support.microsoft.com/kb/2840546. But Outlook 2007 and below will not. http://support.microsoft.com/kb/822504

2. When setting a SST file, remember in Exchange online, only the SST will be used for S/MIME certificate validation.

Create a SST file for the Trusted Root CA / Intermediate CA of the certificate issued to the users:
You can use either Certificate MMC or PowerShell cmdlets to export the SST file. I am using the Certificate console to export the SST here:

Open certmgr.msc snap-in, Expand Trusted Root Certificate Authorities > Certificates > select the CA Certificates which issued the certificates to end users for S/MIME, and right click > All Tasks > Export…

Note: There may be some Intermediate CA. If there are, move them to Trust Root CA folder and select them, including the Trusted CA certificates, and export them all in one .SST file.

Select SST > Click Next and save the SST file:

Upload .SST to Office 365 server:
Update the SST on Office 365 Exchange server by running the commands below using remote PowerShell:

$sst = Get-Content <sst file copied from the box>.sst -Encoding Byte

(Example: $sst = Get-Content TenantRoot.sst -Encoding Byte)

Set-SmimeConfig -SMIMECertificateIssuingCA $sst

3. If end users are issued third party certificates, they can publish the certificate information to the GAL by following these steps:

Note: To publish the certificate, the users must first have the certificate installed on their local machine.

• On the File menu in Outlook 2013, click Options.
• On the Outlook Options window, click Trust Center, click Trust Center Settings..., then Email Security.
• On Trust Center window, click Settings… (Here, you need to choose which certificate you are going to use for S/MIME).
• In the Change Security Settings window, type the Security Settings Name (you can name it anything), Choose Signing and Encryption certificate, select the appropriate certificate assigned in previous steps, leave the Algorithm default, and click OK.

• Once the information is selected, you will notice the Default Setting is populated with Security Settings Name. Now you can click the Publish to GAL button. To publish the certificate to the GAL, click OK.

• To confirm that the certificate is published in AAD (Azure Active Directory), connect to Exchange Online using remote PowerShell and run the following command. Check to see if the UserSMimeCertificate attribute is populated with the certificate information. If not, return to step 4.

Get-Mailbox <user> | FL or FT *user*

If Windows Certificate Authority is used, then the CA will publish the certificate information into the user object. In both cases, you need to use DirSync to replicate the on-premises Active Directory information to the cloud so that cloud users can exchange S/MIME messages.

4. After the above steps, your end users can use Outlook, OWA, or EAS to send and receive S/MIME messages.

Note: Make sure you check S/MIME Supported Clients section below before exchanging S/MIME messages.

S/MIME Supported Clients

All the client machines should have the PKI issued user certificate installed under (whichever is applicable)
Certificates - Current User
- Personal - Certificates
­­­­- Trusted Root Certification Authorities - Certificates
- Intermediate Certification Authorities - Certificates

If the PKI issued certificate is not available, users will not be able to send digitally signed messages or decrypt the S/MIME encrypted messages.

Outlook Web App:

• OWA for S/MIME - Supported only on Windows Vista or greater with browser IE9 and above. Not supported on other browsers or on MOWA (Mobile for Outlook Web Access).
• Third party certificates aren’t supported for OWA S/MIME; only Windows Certificate Authority issued certificates are supported.
• To use Outlook Web Access with the S/MIME control, the client system on which the user is running Internet Explorer must have Outlook Web Access with the S/MIME control installed. S/MIME functionality in Outlook Web Access cannot be used on a system that does not have Outlook Web Access with the S/MIME control installed.

SMIME control in OWA requires .Net 4.5. All users accessing their mailboxes using OWA should install this on their machine. .Net 4.5 can be installed from Microsoft Downloads page.

Outlook

• Outlook 2010 and above are supported.

EAS Clients

• Windows phone 8.1 is a supported EAS client for S/MIME. To learn how to install a certificate on Windows Phone 8.1, see Installing digital certificates.
• For any other devices, you need to check with the device vendors.

FAQ

1. Do both of these user object attributes (UserSMIMECertificate and UserCertificate) need to be populated with certificate information?

Either, or both.

2. Do we support S/MIME for Cross Org/Cross Tenant?

Cross Org/Cross Tenant S/MIME is not supported in Outlook Web App and EAS (Exchange Active Sync)

With Outlook, it is a supported scenario. So, when we are looking for certificates for recipients, we check in all the Address Books.  This includes the Global Address Book (GAL), the Contact Address Book (contacts folder), as well as any other address books (which includes LDAP address books). As long as we can find an entry in an address book for the recipient and it contains a certificate that we trust, then we can use it and send S/MIME mail.

Note: Certificate in Exchange online GAL (Contact) currently not supported.

3. When I select Encrypt mail and click on Send button in Outlook/OWA, I get error saying that the sender does not have a certificate. Why?

In the example below, David is a sender. He was trying to send an S/MIME encrypted email message to a couple of recipients who have certificates published in the Active Directory, but David himself doesn’t have a certificate. When he clicks Send, he gets the below error.

So, when sending an S/MIME encrypted message, we always check the sender’s certificate so that the message is encrypted such that the sender himself can see it from his Outlook ‘sent items’ folder.

References

Understanding S/MIME

Special thanks to Frank Brown, Mike Brown, Timothy Heeney, Tariq Sharif, Vikas Malhotra and Eduardo Melo for reviewing this post!

Suresh Kumar

Editor's Note: Updates added below for important information related to Exchange Server 2010 SP3 Update Rollup 8.

The Exchange team is announcing today a number of releases. Today’s releases include updates for Exchange Server 2013, 2010, and 2007. The following packages are now available on the Microsoft download center.

• Exchange Server 2013 Cumulative Update 7
• UM Language Packs for Cumulative Update 7
• Exchange Server 2010 SP3 Update Rollup 8
• Exchange Server 2007 SP3 Update Rollup 15

These releases represent the latest set of fixes available for each of their respective products. The releases include fixes for customer reported issues and minor feature improvements. The cumulative updates and rollup updates for each product version contain important updates for recently introduced Russian time zones, as well as fixes for the security issues identified in MS14-075. Also available for release today are MS14-075 Security Updates for Exchange Server 2013 Service Pack 1 and Exchange Server 2013 Cumulative Update 6.

Exchange Server 2013 Cumulative Update 7 includes updates which make migrating to Exchange Server 2013 easier. These include:

• Support for Public Folder Hierarchies in Exchange Server 2013 which contain 250,000 public folders
• Improved support for OAB distribution in large Exchange Server 2013 environments

Customers with Public Folders deployed in an environment where multiple Exchange versions co-exist will want to read Brian Day’s post for additional information.

Cumulative Update 7 includes minor improvements in the area of backup. We encourage all customers who backup their Exchange databases to upgrade to Cumulative Update 7 as soon as possible and complete a full backup once the upgrade has been completed. These improvements remove potential challenges restoring a previously backed up database.

For the latest information and product announcements about Exchange 2013, please read What's New in Exchange 2013, Release Notes and Exchange 2013 documentation on TechNet.

Cumulative Update 7 includes Exchange-related updates to Active Directory schema and configuration. For information on extending schema and configuring Active Directory, please review Prepare Active Directory and Domains in Exchange 2013 documentation.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current Cumulative Update release.

We know that many of you are anxiously awaiting the release of our quarterly Exchange updates planned for November. Earlier today the Exchange Team decided to hold the release of these packages until December. We made this decision to provide more time to resolve a late breaking issue in the Installer package used with Exchange Server 2013. We have discovered that in some instances, OWA files will be corrupted by installation of a Security Update. The issue is resolved by executing an MSI repair operation before a Security Update is installed. We do not believe this is acceptable behavior and is unfortunately something that customers might only discover after they install a Security Update.

As of this blog announcement, we believe the installer defect is limited to Exchange Server 2013. However, we are also evaluating previous versions of Exchange Server and are delaying the planned 2007 and 2010 releases as well to complete that investigation.

The Exchange team remains committed to ensuring that our customers have the best possible experience and because of that we have opted to delay the November releases to address this issue.

Exchange Team

Situation

If transitioning your organization from a non-Exchange system such as Google or Lotus Notes to Office 365, you typically need to follow the IMAP migration path. As diagnosing and remediating any issues you might run into during such a migration can be difficult for people unfamiliar with the matter, we worked with our Support teams to provide some guidance for exactly such cases and packaged it for you in a wizard-like package.

Introducing the IMAP Migration Troubleshooter

IMAP Migrations provide organizations with an effective way to move email from any environment that supports the IMAP protocol. This is usually used for any non-Exchange source email system. If Exchange is the source you would most likely opt for the Staged, Cutover, or Hybrid migration path.

To help you with troubleshooting, we have released a new guided walkthrough (GWT) for IMAP migrations. This link will soon be surfaced in various KB articles as well as the support ticket creation process via the Office 365 portal.

The intent of this GWT is to take a tenant administrator step-by-step though the common troubleshooting tasks to solve their IMAP migration issues. We took the most common migration failure scenarios and put them into this easy to follow guide.

http://aka.ms/IMAPMigrationGWT

Feedback

If you see any issues with the IMAP migration troubleshooter or think there are scenarios that should be added or improved, please let us know at MigrationGWT@microsoft.com.

Special thanks to all that contributed to the creation of the GWT: Kevyn Pietsch, Nagesh Mahadev, Timothy Heeney, Shawn Sullivan, and to the writers and KE team for assisting with collaboration and coordination efforts: Charlotte Raymundo and Sharon Shen.

If you are looking for assistance on any troubleshooting Hybrid migrations, see the Exchange Online Migration Guided Walk Through (GWT).

Kevyn Pietsch, Nagesh Mahadev, Timothy Heeney

What are we talking about today?

In Exchange 2013 CU5 (yes 5, V, cinco, fem, and cinque) we started implementing changes to how Legacy Public Folder endpoint discovery will be performed by Outlook (for Windows) in the future. This work continues behind the scenes and will be completed with the release of Cumulative Update 7. This becomes important in on-premises Exchange coexistence environments where some or all of your on-premises user mailboxes have been moved to Exchange 2013 and your Public Folder infrastructure is still on Exchange 2007 or Exchange 2010. Anyone whom has gone through the Legacy Public Folder hybrid configuration steps for Exchange Online will recognize what we are about to go through for the on-premises edition of Exchange 2013.

Why should I care about this?

Prior to CU7, Exchange 2013 mailboxes using the Outlook client were proxied to the legacy mailbox server hosting the Public Folder being accessed either via RPC/TCP or RPC/HTTP depending on the client’s location, the connectivity model being used, and the configuration on the legacy Exchange servers.

With the introduction of MAPI/HTTP in Exchange 2013 SP1, we identified an issue where clients could not always access the legacy Public Folder environment after moving to the MAPI/HTTP protocol.

An analysis of this behavior led us to understand that a combination of RPC Client Access code and older code within the Outlook client enabled the client to be redirected to the legacy Public Folder store under certain circumstances. While you may be thinking this is great news, it is not the desired state – both Exchange and Outlook need to utilize a common pathway for directing clients to connect to mailbox and Public Folder data. That common pathway is Autodiscover.

In the future, both Exchange and Outlook will remove the old code that enabled the older redirection logic. As a result new configuration steps exist which customers should undertake to coexist with legacy Public Folders and support connectivity with Outlook (for Windows) clients whose mailboxes reside on Exchange 2013, regardless of the connectivity protocol (RPC/HTTP or MAPI/HTTP) in use by their clients.

We are providing you with this information in advance of CU7’s release (No, we’re not going to answer when it will be released other than ‘when it is ready.’J) so you may prepare your environments for the new legacy public folder coexistence method. All of the commands discussed here were available starting in CU5 so you may configure your environment in advance of deploying CU7 if you would like to.

Give me the short version. What do I have to do?

The configuration steps for enabling this new discovery method have been published in the following article.

There are two new commands you will need to execute prior to installing CU7 or just after (we recommend before) to ensure Exchange 2013 CU7 and later will provide Outlook the information it needs to properly discover legacy public folders.

• From a CU5 or later Exchange 2013 Server: Use the Set-OrganizationConfig cmdlet to assign the legacy public folder discovery mailbox(es) to the RemotePublicFolderMailboxes value of the organization.
• From a CU5 or later Exchange 2013 Server: Use the Set-OrganizationConfig cmdlet to set the PublicFoldersEnabled attribute of your Exchange organization from Local to Remote.

With the above settings configured Exchange 2013 will begin returning a new section in Autodiscover responses to Exchange 2013 mailbox users similar to the following and using the new coexistence code paths;

<PublicFolderInformation>
<SmtpAddress>PFDiscovery-001@contoso.com</SmtpAddress>
</PublicFolderInformation>

With this information Outlook will then perform a second Autodiscover request using the provided SMTP address. This SMTP address is for a legacy Public Folder discovery mailbox that resides on an Exchange 2007 or Exchange 2010 mailbox server that also serves a public folder database (PFDB). In the above example Outlook would perform an Autodiscover request for PFDiscovery-001@contoso.com to discover the connection endpoint (RPC, or RPC/HTTPS) to use when the Exchange 2013 user is accessing your organization’s legacy Public Folder. Outlook is not logging on as this mailbox, nor is it actively using this mailbox to access the legacy public folder content. The mailbox strictly exists to be able to perform an Autodiscover request/response such that Outlook receives a valid connection endpoint for your legacy Public Folders.

Without these new settings being configured, Exchange 2013 will continue to use the old code paths which will be removed at some point in the future. It is important that all on-premises Exchange 2013 organizations fully configure their environment to ensure uninterrupted legacy Public Folder access in the future.

I like pictures and examples. Is there a longer version?

Yes, we have you covered. Let us go through configuring an Exchange 2013 environment for Exchange 2010 legacy public folder access as it is the more complicated of the two scenarios to configure. If you need to configure Exchange 2007 there are fewer steps involved and you can reference the TechNet documentation.

1. Identify the Public Folder database(s) you need users to be able to connect to initially by examining the PublicFolderDatabase attribute of your Exchange 2013 mailbox databases. This attribute defines the default legacy public folder database for each Exchange 2013 mailbox database.

   Below we can see there are two legacy public folder databases used as defaults for our Exchange 2013 databases.

   

2. Add the Client Access Server role if the PFDB resides on an Exchange 2010 Mailbox Server without CAS installed. The addition of the CAS role will ensure public folder replica referrals happen appropriately if a folder a user is accessing does not have a local replica in the PFDB. If the PFDB resides on a server with both the Mailbox and Client Access Server roles (Whether Hub Transport or UM are installed are irrelevant here), you can skip this step and go to step 3.
3. After installing the CAS role, if it was necessary, configure the role as you would any other CAS in this AD site with the proper virtual directory and other settings to ensure Autodiscover results for clients are not impacted by a bunch of default virtual directory values. You do not have to add this new CAS role to your load balancer pool if you do not want to. If you did not have to install the CAS role as it was already installed on the PFDB server, please skip to step 3.
4. Create a new empty mailbox database on the Mailbox Server containing the PFDB to be accessed. If this mailbox server is a member of a DAG, please do not create additional copies of this particular mailbox database. You can safely leave this mailbox database as a single copy.

   Note: If you are unable to create an additional mailbox database in this step due to using Exchange Server Standard Edition, you can utilize an existing mailbox database in this case.

5. Skip this step if you are re-using another mailbox database due to Exchange Server Standard Edition limitations. Using the Set-MailboxDatabase cmdlet, exclude this new empty mailbox database from automatic mailbox provisioning by setting the IsExcludedFromProvisioning flag to $True.
6. Skip this step if you are re-using another mailbox database due to Exchange Server Standard Edition limitations. Using the Set-MailboxDatabase cmdlet, set the RPCClientAccessServer value of the new empty mailbox database to the FQDN of the Mailbox Server holding the public folder database to be accessed. The RPCClientAccessServer value is only used for RPC/TCP connectivity and this does not mean a new name is added to your SSL certificate as HTTPS will not be used here (see Item #3 here for explanation).
7. Create a new mailbox inside the empty mailbox database you just created on the server holding your PFDB. This will be known as a Public Folder discovery mailbox. This mailbox is not accessed in any way. This mailbox is used as a target to retrieve connection settings via Autodiscover and nothing more. A naming convention such as PFDiscovery-<ServerName> or PFDiscovery-<###> is helpful to identify these mailboxes in the future. This mailbox must have an SMTP address which can be used by Autodiscover internally, and also used externally if you have external users requiring access to legacy public folders. If you are re-using another mailbox database due to Exchange Server Standard Edition limitations, the mailbox will reside in an existing database.

   Below you can see the mailbox we created and its SMTP address.

   

8. Using the Set-Mailbox cmdlet hide your new discovery mailbox(es) from address lists by setting the HiddenFromAddressListsEnabled parameter to $True.

   

9. Repeat steps 1-7 for additional Public Folder databases if you would like to distribute client connections across more than one PFDB.
10. Prior to running the next two commands we look at the current organization configuration in its default state.

    

11. From a CU5 or higher Exchange 2013 Server: Using the Set-OrganizationConfig cmdlet, assign the PF discovery mailbox(es) to the RemotePublicFolderMailboxes value of the organization.
12. From a CU5 or later Exchange 2013 Server: Using the Set-OrganizationConfig cmdlet, set the PublicFoldersEnabled attribute of your Exchange organization to Remote.

    Running our Set-OrganizationConfig commands.

    

    Note: If you need to add multiple mailboxes you can use this example PowerShell command format.

    Set-OrganizationConfig -RemotePublicFolderMailboxes "PFDiscovery-001", "PFDiscovery-002"

    Validating the changes took place.

    

13. After you configure these two new settings and a few caches expire you should be able to validate you are now getting the <PublicFolderInformation> section back in the initial Autodiscover response for users with Exchange 2013 mailboxes.

    

14. If you were to run your favorite HTTP proxy/logging tool while Outlook is running you would eventually see another Autodiscover query/response for in our example the mailbox PFDiscovery-010@corp.contoso.com returned above. This is when Outlook learns where and how to connect to your legacy Public Folder infrastructure.

    

15. Confirm via Outlook you can connect to the legacy Public Folder hierarchy. Below are examples of using MAPI/HTTP for the primary mailbox and either RPC/HTTP or RPC/TCP for the legacy Public Folders. In our example lab the Exchange 2010 server named CON-E2K10-002 holds the PFDB being accessed. This public folder database was accessed because it is the default public folder database of the Exchange 2013 mailbox database the user resides in. If you are not yet using MAPI/HTTP in your Exchange 2013 environment, then the screenshots below would look the same except for replacing “HTTP” with “RPC/TCP.”

MAPI/HTTP for the Primary mailbox and RPC/HTTP for legacy Public Folders

MAPI/HTTP for the Primary mailbox and RPC/TCP for legacy Public Folders

FAQ

Q: We're running Exchange 2013 SP1 (or earlier) and plan on upgrading directly to CU7. Our Exchange 2013 users seem to be accessing legacy Public Folders without issue today. Does this mean their legacy Public Folder access will break when CU7 is applied?

A: CU7 has logic that will only use the new code paths if RemotePublicFolderMailboxes is not empty and the PublicFoldersEnabled is set to ‘Remote’. If you were to upgrade directly from an SP1 or earlier to CU7, then Exchange will use the old code paths until you complete the necessary configuration steps to ensure users are not interrupted post-upgrade.

Q: Does Outlook Anywhere need to be enabled in the legacy (2007/2010) environment for this to work if we do not currently provide external access to Exchange via OA?

A: No, Outlook Anywhere does not need to be enabled if the only connectivity method you need to provide to legacy Exchange versions is RPC for internal users or external users connecting via a VPN tunnel. If OA is disabled in the 2007/2010 environment, then the Autodiscover results will inform Outlook to use RPC via the EXCH Outlook Provider instead of RPC/HTTP via the EXPR Outlook Provider to connect to the public folder database.

Q: Are there any specific Outlook versions/builds required for this to work?

A: As a general rule we always suggest keeping Outlook up to date with both service packs and public updates, and we maintain that suggestion here. As long as you are running a version of Outlook 2010 or 2013 supported by Office 365 this feature should work. If this guidance ever changes, we will update necessary documentation.

Q: How does Exchange 2013 choose what Remote Public Folder Mailbox to hand out to clients if more than one is configured in the RemotePublicFolderMailboxes variable? Is it random, round robin, looking at availability?

A: By default Exchange looks at the hash of the user calling into Autodiscover and will pick an entry from the array of mailboxes in RemotePublicFolderMailboxes or use the default public folder mailbox value if it is explicitly set on the mailbox. There is no logic based on user location versus PFDB location or anything of such nature.

Q: Will Exchange 2013 check to make sure the server holding a PF discovery mailbox is up and reachable before a client attempts to retrieve its connection settings via Autodiscover?

A: No, there is no availability check to ensure the legacy server is available before the PF discovery mailbox is given to a client to look up via Autodiscover.

Q: How many legacy public folder databases do I need accessible?

A: Public folder scalability guidance for Exchange 2007 and Exchange 2010 recommended no more than 10,000 active users connecting to a single PFDB. Based on that guidance, then at least one PFDB per 10,000 active users should be accessible. If you have 50,000 users in your organization then a conservative number would be to have no less than 5 public folder databases.

Note: This is a starting point. Your environment may vary and as a result require more or even less PF public folder databases as you monitor your system performance, user concurrency, and user client experience in your legacy environment.

Q: How many PF discovery mailboxes do I need?

A: At this time we are suggesting one per PFDB to be accessed.

Q: How do I control what particular PFDB the user connects to first?

A: For environments with geographically disperse locations it may be beneficial to ensure users connect to a PFDB close to their home location on a well performing network link path. You can make this happen by defining the default public folder database on the user’s Exchange 2013 mailbox database and locate users with similar geographical needs in the same Exchange 2013 mailbox database.

The commands are slightly different depending on if you are setting an Exchange 2010 or an Exchange 2007 public folder database as the default for an Exchange 2013 mailbox database. The command will tell you the ‘PublicFolderDatabase’ parameter has been deprecated, but it does do what it is supposed to do for coexistence purposes.

Using an Exchange 2007 Public Folder Database

Set-MailboxDatabase <2013DatabaseName> -PublicFolderDatabase <2007ServerName>\<Storage GroupName>\<PFDatabaseName>

Using an Exchange 2010 Public Folder Database

Set-MailboxDatabase <2013DatabaseName> -PublicFolderDatabase <2010PFDatabaseName>

Q: For Exchanage 2010 do I really need to install CAS on every Mailbox server with a PFDB to be accessed and create a new mailbox database?

A: At this time, yes, but we are evaluating a few other options to help improve and possibly streamline the coexistence configuration in the future. If we are able to streamline this process in the future we will be sure to update you. Remember, you do not need to add the server to your load balancer pool simply because CAS has been installed. The server should not see the volume of client traffic other CAS in the AD site experience.

Summary

After implementing this configuration you will have a more robust and predictable legacy Public Folder connectivity experience with Exchange 2013 Cumulative Update 7 and beyond by making your legacy Public Folder infrastructure discoverable via Autodiscover by your Outlook (for Windows) clients. We look forward to your comments and questions below. Be on the lookout soon for another article that will go into detail on deployment recommendations for Exchange 2013 public folders themselves.

Brian Day
Senior Program Manager
Office 365 Customer Experience

Note: Cumulative Update 7 (CU7) for Exchange Server 2013 will be released soon^TM.

Back in May, I discussed the changes we introduced in Exchange 2013 Cumulative Update 5. Specifically with CU5 and later, an OAB can only be assigned (or linked) to a single OAB generation mailbox. This architectural change addressed two deficiencies in the Exchange 2013 OAB architecture:

1. Enabled administrators to define where an OAB is generated.
2. Removed the capability to have multiple instances of the same OAB.

However, this change did not improve user accessibility in a distributed messaging environment. For example:

Let’s say the blue user, whom we shall now call Scott Schnoll, has his mailbox located in Redmond. Due to a clause in his work contract, Scott needs to work out of the Portland office for the next six months.

In order to keep Scott’s address book up to date, Outlook will trigger an OAB download every 24 hours (based on the time it was last successfully downloaded), connecting to the Redmond CAS infrastructure which proxies the request to the Redmond Mailbox server that hosts the OAB generation mailbox that generates the Redmond OAB.

Having Scott’s OAB files downloaded across the WAN is not an optimal experience. Obviously, the administrator could point Scott’s mailbox to the Portland OAB instance; however, that would require Scott’s client to undergo a full OAB download. Unfortunately, prior to CU7, this is the only way to mitigate this scenario.

Shadow Distribution in Cumulative Update 7

Exchange 2013 Cumulative Update 7 introduces the capability for an OAB generation mailbox to host a shadow copy of another OAB. This functionality enables additional Mailbox servers to be an endpoint for OAB download requests. By default, this feature is disabled and is configurable per OAB.

Referring back to our previous example, once shadow distribution is enabled for the Redmond OAB, Scott’s Outlook client, via the Autodiscover response his client gets from the Portland CAS (which as we know is actually going to be generated on the mailbox server in the Redmond site, as that’s where Scott’s mailbox is), will now access the Redmond OAB using a URL resolving to the Portland CAS infrastructure (https://pmail.contoso.com/oab/redmond oab guid/); this is accomplished by Autodiscover leveraging the X-SourceCafeHeader value specified in the HTTP proxy request. The first time an attempt is made to access this OAB will result in a 404 response as the OAB files do not exist on the Portland Mailbox server that hosts the OAB generation mailbox, OAB Mailbox 1. This event invokes the OABRequestHandler, which initiates an asynchronous transfer, via BITS, of the Redmond OAB files to the Portland MBX server hosting the OAB generation mailbox. During the next attempt to synchronize the OAB, Scott’s Outlook client is able to download the necessary OAB files locally.

How do I enable shadow distribution?

The GlobalWebDistributionEnabled and VirtualDirectoriesproperties of an OAB are still used by Autodiscover to determine which CAS OAB virtual directories are eligible candidates for distributing the OAB. Given the architecture in Exchange 2013, any CAS can proxy an incoming OAB request to the right location, therefore, with CU7 and later, the recommendation is to enable global web distribution for all OABs hosted on Exchange 2013.

Set-OfflineAddressBook <E15OAB> -VirtualDirectories $null
 
Set-OfflineAddressBook <E15OAB> -GlobalWebDistributionEnabled $true

Prior to enabling shadow distribution, you should deploy an OAB generation mailbox in each Active Directory site where Exchange 2013 infrastructure is deployed (assuming CU7 or later is deployed in each site).

New-Mailbox -Arbitration -Name "OAB Mailbox 3" -Database DB4 -UserPrincipalName oabmbx3@contoso.com –DisplayName "OAB Mailbox 3"
 
Set-Mailbox "OAB Mailbox 3" –Arbitration –OABGen $true

Once global distribution is enabled and OAB generation mailboxes are deployed, you can then enable shadow distribution on a per-OAB basis:

Set-OfflineAddressBook "Redmond OAB" -ShadowMailboxDistributionEnabled $true

How do I disable shadow distribution for an OAB?

You can disable shadow distribution on a per-OAB basis:

Set-OfflineAddressBook "Redmond OAB" -ShadowMailboxDistributionEnabled $false

Does accessing a shadow copy trigger a full OAB download?

As discussed in OAB Improvements in Exchange 2013 Cumulative Update 5, the reason we moved to having a single OAB generation mailbox generate an OAB was to ensure that the OAB instance remained unique within the organization. Prior to CU5, all OAB generation mailboxes generated their own unique instances of the OABs, which resulted in full downloads any time a client was proxied to a different OAB generation mailbox.

The shadow copy is only distributed on-demand and is an exact duplicate of the OAB that is generated by the “master” OAB generation mailbox. As a result, an Outlook client will not be forced to perform a full download upon accessing the shadow copy files. The OABv4 conditions in Using Offline Address Books describes the conditions that can trigger a full download of an OAB.

What does the client experience when a shadow copy is triggered?

If the OAB files do not exist on the Mailbox server hosting the OAB generation mailbox, then the Outlook client will report error 80190194 (BG_E_HTTP_ERROR_404).

How does a shadow distributed OAB get updated?

As soon as a new OAB is generated and published on the “master” Mailbox server, all the Mailbox servers hosting shadow copies will stop distributing their now-outdated copies. The first user who requests access to the OAB will trigger a full synchronization of the OAB to the shadow copy. The following events are reported:

Event ID: 102
Source: MSExchange OABRequestHandler
Description: The OABRequestHandler has begun downloading the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57 from the server red-mbx-01.contoso.com.

Event ID: 103
Source: MSExchange OABRequestHandler
Description: The OABRequestHandler has finished downloading the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57.

The OABRequestHandler will make up to three subsequent attempts to copy the OAB files from the Mailbox server where the master OAB generation mailbox is located. If all three attempts fail, the OABRequestHandler will retry the transfer after one hour.

Event ID: 104
Source: MSExchange OABRequestHandler
Description: Download of the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57 failed. The job will be re-submitted. The error was: BG_ERROR_CONTEXT=BE_ERROR_CONTEXT_REMOTE_FILE; error code=0x80190194

Event ID: 105
Source: MSExchange OABRequestHandler
Description: Download of the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57 has failed too many times. The job will not be resubmitted for the next hour.

What happens if I enable shadow distribution for an OAB, but there is no OAB generation mailbox in the site where the user is located?

When shadow distribution is enabled, Autodiscover will return the OAB URL for the site from which the user request initiated. If there is no OAB generation mailbox within that site, then CAS will simply proxy the request back to the Mailbox server hosting the OAB generation mailbox that is responsible for generating the OAB.

Summary

Shadow distribution completes our work on improving the OAB capabilities in the on-premises product and hopefully satisfies the requests from our customers that deploy distributed messaging environments. As always, we welcome your feedback.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Today, we released updated versions of both the Exchange 2010 Server Role Requirements Calculator and the Exchange 2013 Server Role Requirements Calculator.

The Exchange 2010 version is an incremental update and only includes minor bug fixes. You can view what changes have been made, or download the update directly.

In addition to bug fixes, the Exchange 2013 version, on the other hand, includes new functionality.  In particular, the ability to define how many AutoReseed volumes you would like in your design and mailbox space modeling. You can view what changes have been made, or download the update directly.

Mailbox space modeling provides a visual graph that indicates the expected amount of time it will take to consume the send/receive prohibit quota assuming the message profile remains constant.  As you can see from the example below, if I start with a 2GB mailbox with a 200 message profile and allocate a 10GB quota (and assuming no deletes), I expect to consume that quota in roughly 22 months.  Hopefully, this feature will allow you to plan out storage allocation more appropriately moving forward.

As always, we welcome your feedback.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

This morning on The Official Microsoft Blog, we revealed more details about our unified technology event for event for enterprises in May. The event will be known as Microsoft Ignite. If you are one of the many MEC conference alumni this is the conference for you. Microsoft Ignite is for Exchange customers using Office 365 or Exchange Server on-premises. Register now to reserve your spot and we will see you in Chicago on May 4^th!

Shape the event | Join the YamJam

We are committed to making Microsoft Ignite an incredible and valuable event for all of us who are passionate about Exchange, Office, SharePoint, Lync, Project and Visio. We want your feedback to help shape plans for this event. Join us for a YamJam on the Office 365 Technical Network on Tuesday, October 21^st 9:00 am – 10:00 am PDT to ask questions about the event and to provide feedback on what you want to see there. For those unfamiliar with a YamJam, it is similar to a “TweetJam” on Twitter or an “Ask Me Anything (AMA)” on Reddit, except it takes place on Yammer.

How to participate:

1. Request access to the Office 365 Technical Network.
2. Join the Ignite Event group. You can find it by using the Browse Groups function or through the search bar.
3. Log in at 9:00 a.m. PDT on Tuesday, October 21^st to ask questions and provide feedback on what you want to see from the Microsoft Office Division at the conference.

We wanted to give you a heads up that depending on the version of Exchange you are running, there might be some impact to either names of time zones that are changing on October 26, or the way that actual meetings are displayed in affected time zones. Customers using our newer versions of Exchange, 2010 and 2013, can expect meetings to appear on calendars correctly (provided underlying operating systems have been updated). Customers who are running Exchange 2007 might see meetings displayed at wrong times.

We are committed to correct these inconsistencies in our December release wave.

Update 11/11/14: We have just announced that the November 2014 Exchange releases are being delayed by one month, to December. Please see this. We updated the above wording accordingly.

Please see KB article 3004235 for more information.

Nino Bilic

In Exchange 2013 there are indices within a given mailbox database.  The indices are created, maintained, and deleted by the Information Store Worker Process associated with a given database.  These indices are not to be confused with the Exchange content indexes that are built via the Search Foundation engine as they are completely different.

Within an Exchange database there can exist any combination of primary, secondary, and lazy indices There is exactly one primary index and one secondary index on the messages table.  For example, a message table exists where a primary index is created on DocumentID and a secondary index created on FolderID, IsHidden, and MessageID.  Additionally, other lazy indices may be created that reflect client views, search folders, and even views of search folders.  Exchange maintains these indices through two methods, an eager method and a lazy method. Primary and secondary indices are always maintained eagerly. Lazy indices are maintained through the lazy indexing process (although some may be maintained eagerly). There are many lazy indices per mailbox and usually multiple per folder. Confused yet? Let us see if we can explain further…

The eager method says that when an object is inserted into the table the indices must be immediately updated.  In the previous example an insert into the mailbox would require updating the primary index and then all secondary indices created against the same mailbox.  This results in a random write being issued on each insertion.  If a mailbox had 10 indices this would result in 10 random writes.  The performance impacts could be significant depending on the structure of the indices.  In some cases, the lazy indices exist but are actually not utilized.  This results in update cycles being incurred for data that may actually not be utilized.  There do exist certain indices where immediate updating is required – this is why the eager method exists.

The lazy method is often utilized to mitigate the performance impact that indexing could cause.  When an insertion occurs to the folder an entry is created in a lazy indexing maintenance table with information on the lazy indices that require updating.  In this example, two random writes are incurred regardless of the number of lazy indices that require updating.  Subsequently when an index is accessed, before returning the results of that index, we apply the maintenance records found within the table ensuring the index is up to date.  Three major benefits are derived from this method:

• Less random writes are incurred on indices.
• If an index exists but is never used we expend no random writes updating it.
• If multiple records are inserted at the same time when bringing an index current we can derive some write coalescing.

Issue

Customers have noted that on versions of Exchange 2013 prior to Cumulative Update 6 the following errors are recorded in the Application log and are seen resulting in Information Store Worker Process termination and subsequently database failover.  The failovers and terminations may effect single or multiple databases and often result in databases failing over multiple times a day.

Source: MSExchangeIS
Event ID: 1001
Level: Error
Description:
Microsoft Exchange Server Information Store has encountered an internal logic error. Internal error text is (Unable to apply maintenance GetNonKeyColumnValuesForPrimaryKey-norow, index corruption?) with a call stack of (   at Microsoft.Exchange.Server.Storage.Common.ErrorHelper.AssertRetail(Boolean assertCondition, String message)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndex.HandleIndexCorruptionInternal(Context context, Boolean allowFriendlyCrash, String maintenanceOperation, Nullable`1 messageDocumentId, Exception exception)
...(remaining stack redacted)
   at EcPoolSessionDoRpc_Managed(_RPC_ASYNC_STATE* pAsyncState, Void* cpxh, UInt32 ulSessionHandle, UInt32* pulFlags, UInt32 cbIn, Byte* rgbIn, UInt32* pcbOut, Byte** ppbOut, UInt32 cbAuxIn, Byte* rgbAuxIn, UInt32* pcbAuxOut, Byte** ppbAuxOut)).

Source MSExchangeIS
Event ID: 1002
Level: Error
Description:
Unhandled exception (Microsoft.Exchange.Diagnostics.ExAssertException: ASSERT: Unable to apply maintenance GetNonKeyColumnValuesForPrimaryKey-norow, index corruption?
   at Microsoft.Exchange.Diagnostics.ExAssert.AssertInternal(String formatString, Object[] parameters)
   at Microsoft.Exchange.Server.Storage.Common.ErrorHelper.AssertRetail(Boolean assertCondition, String message)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndex.HandleIndexCorruptionInternal(Context context, Boolean allowFriendlyCrash, String maintenanceOperation, Nullable`1 messageDocumentId, Exception exception)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndex.HandleIndexCorruption(Context context, Boolean allowFriendlyCrash, String maintenanceOperation, Nullable`1 messageDocumentId, Exception exception)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndex.GetNonKeyColumnValuesForPrimaryKey(Context context, Object[] primaryKeyValues)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndex.DoMaintenanceDelete(Context context, Byte[] propertyBlob)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndex.ApplyMaintenance(Context context, LogicalOperation operation, Byte[] propertyBlob)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndex.SaveOrApplyMaintenanceRecord(Context context, MaintenanceRecordData maintenanceRecord, Boolean allowDeferredMaintenanceMode)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndex.BuildDeleteRecords(Context context, IColumnValueBag updatedPropBag, Int64& firstUpdateRecord)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndex.BuildUpdateRecords(Context context, IColumnValueBag updatedPropBag, Int64& firstUpdateRecord)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndex.LogUpdate(Context context, IColumnValueBag updatedPropBag, LogicalOperation operation)
   at Microsoft.Exchange.Server.Storage.LazyIndexing.LogicalIndexCache.TrackIndexUpdate(Context context, Mailbox mailbox, ExchangeId folderId, LogicalIndexType indexType, LogicalOperation operation, IColumnValueBag updatedPropBag)
...(remaining stack redacted)
   at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch[T](TryDelegate tryDelegate, GenericFilterDelegate filterDelegate, GenericCatchDelegate catchDelegate, T state)).

Source: MSExchange Common
Event ID: 4999
Level: Error
Description:
Watson report about to be sent for process id: 9112, with parameters: E12, c-RTL-AMD64, 15.00.0913.022, M.E.Store.Worker, M.E.S.Storage.LazyIndexing, M.E.S.S.L.LogicalIndex.HandleIndexCorruptionInternal, M.E.Diagnostics.ExAssertException, a762, 15.00.0913.000.
ErrorReportingEnabled: True

Why does this issue occur?

Prior to CU6 it was possible that certain index maintenance operations would overlap each other. This would result in an inconsistency between an eager index update and a lazy index update that would happen later. More specifically, we missed outputting an update that was needed later which gets the index into a corrupted state. This would essentially mark the index as corrupted when the lazy index operation could not be applied later, causing the crash, and requiring the index to be rebuilt.

How did Microsoft find this bug?

Although the result of the index corruption is a failover there was no availability impact in the service. The failovers successfully fixed the indices and no client impact is occurred. (It should be noted that the same is reported in on-premises installations). Thanks to customers that have enabled automatic error reporting an uptick in reports related to lazy indexing was noticed. This allowed our development teams to evaluate the code in question and issue a fix.

Why does the Information Store Worker Process terminate due to lazy indexing?

The lazy indexing maintenance process encounters issues arising to the maintenance of the indices.  When inserting a record into an index we assume the record should not already be in the index.  When removing or updating a record within the index we expect that the record already exists.  Due to an issue in how the indices were previously built these constraints are violated.  Our method of handling this is to terminate the Information Store Worker Process, which results in a database copy failover.  The index itself is also deleted and then rebuilt the next time the index is accessed.  Although a failover occurred the high availability framework should quickly restore access to the database and the end user should not be impacted.  The corrupted index is self healed.  Indices and index information is logged via transaction logging and subsequently replicated to other database copies if a Database Availability Group is utilized.

Does rebuilding the content index or reseeding the content indices correct this issue?

The status of the content index catalogs has no impact on this issue.  They are two separate indexing concepts unrelated to each other in the context of this issue.

Does reseeding the database copies or removing /adding the database copies correct this issue?

No. The indices are stored within the database and any corrupted indices would be reseeded with the database.

How do I correct the lazy indexing failures and prevent database failovers?

The majority of incorrect indices occur with Exchange 2013 Cumulative Update 5.  The issue was first identified through automatic error reporting in Exchange 2013 and subsequently identified in Office 365.  It was then fixed in a post Exchange 2013 CU5 build deployed to Office 365 where the incidents of index corruption decreased. The fix has been incorporated into Exchange 2013 Cumulative Update 6.  Customers should upgrade to Exchange 2013 CU6 to correct the index creation issue and allow future index operations to proceed successfully.   

Does Exchange 2013 Cumulative Update 6 prevent a lazy indexing failure?

No.  There are certain reasons an index may be considered corrupted.  Isolated index corruption with subsequent self healing may occur.  It is also important to note that indices could have been created in Exchange 2013 CU5 that are corrupted.  When these indices are accessed on Exchange 2013 CU6 and newer a database failover may result as the indices are still corrupted.  Exchange 2013 CU6 corrects the building of the initial indices which should decrease the frequency of lazy indexing resulting in database failovers. 

Can I expect failovers for the foreseeable future?

In the short term after application of Exchange 2013 CU6 customers may continue to experience failovers if a corrupted index is accessed. The Information Store process automatically cleans up indices that are not accessed after 30 days. The issue should self correct either though failover and immediate cleanup or after the indices are aged out.

Can I do something today to correct the corrupted indices?

There are two interventions administrators can utilize to discard corrupted indices. The first is to move the mailboxes to a different database. The move process discards indices during the move. The second is to execute a New-MailboxRepairRequest with the CorruptionType “DropAllLazyIndices” parameter against the mailbox. The New-MailboxRepairRequest effectively sets the index age timeout for a given mailbox to 0. The repair process will render the mailbox inaccessible while the repair is in progress and could have significant performance impacts on the server. WE DO NOT recommend either of these options since they would have to be run in bulk against all mailboxes whether or not they have corrupted indices. There is no proactive method to scan for index corruption and identify mailboxes to target the move or request against.

Customers that have opened cases with support have reported a significant decrease in the number of failovers associated with lazy indexing after the application of Exchange 2013 CU6.  Failovers will continue until all corrupted indices have been accessed, deleted, and subsequently rebuilt.  Customers who experience this issue are advised to test and deploy Exchange 2013 CU6 as soon as possible. If upgrading is not possible the database failovers may continue with no other negative side effects noted.

Tim McMichael
Senior Support Escalation Engineer

Bulk mail is often mistaken for spam and is starting to become a larger problem for organizations. EOP is not very aggressive out of the box when it comes to bulk mail because this type of mail falls into a grey area. Some organizations will want to receive this type of mail, whereas others will not.

Over the last few months we have greatly increased EOPs ability to detect bulk mail which you can take advantage of starting today. This new system is based on a scale which gives customers the ability to set the aggressiveness of bulk mail detection to meet their specific needs.

X-Microsoft-Antispam is a new header that is stamped on all messages traversing Exchange Online and only started appearing in messages few months ago. This new header currently contains two published values to help better detect bulk and phishing emails.

• BCL – Bulk Complaint Level
• PCL – Phishing Confidence Level

The beauty of this header is that it is stamped on incoming messages BEFOREthe EOP transport rules are evaluated. This means EOP transport rules can be written to trigger based on what’s in this header.

One of the goals behind the new X-Microsoft-Antispam header is to allow customers to decide how sensitive they want EOP to be when it comes to bulk mail detection. Currently in the EOP Content Filter there is a bulk mail detection switch that can only be set to either On or Off.

The problem with this switch only being on or off is that bulk mail is a very grey area. What one user considers as bulk another will not. This is why EOP (with no additional configuration added) typically does not block this type of mail. This is also why we are moving beyond the On or Off switch to a multi-value type classification system where customers will be able to set the level that they are comfortable with.

With this new header, you can decide on a scale how sensitive you want the service to be with bulk mail detection. Eventually this will be rolled in to the Advanced Spam Filter options and replace the current bulk On or Off switch, but for now you can write EOP Transport Rules to start taking advantage of this today! You can choose the bulk mail detection level that makes sense for your organization.

At MEC this year there was a great presentation with the title “So how does Microsoft handle my spam?” In this presentation, bulk mail detection is discussed between 22:30 to 28:50 and the speakers provide great insight into this topic. The entire session is great, but I would recommend at least listening to the six minutes where they discuss bulk mail.

What can I do today?

If you are receiving unwanted bulk mail today, the following suggestions can help.

1. Take advantage of the new x-Microsoft-Antispam header by creating an EOP transport rule. The following is an example of a rule that will mark messages as spam if the stamped Bulk Complaint Level is 6 or higher.

For detected messages this rule will set the SCL to 6 which will cause the message to take the spam action you have configured in the content filter. The additional header that this rule adds will make it easy to identify messages that were marked as spam by this rule.
For more information on rules that will increase the bulk sensitivity of EOP see Use transport rules to aggressively filter bulk email messages. This page describes three separate rules, the first of which walks through the creation of the above rule. I would recommend starting only with the first rule that looks at x-Microsoft-Antispam, and if you need even more aggressive filtering, create the subsequent two rules.

2. Educate yourself on the new X-Microsoft-Antispam header. See Anti-spam message headers and Bulk Complaint Level values.

3. Educate your users. If a user recognizes the sender of the bulk message and does not want to receive further mail, they can click the unsubscribe link on the email. If the user does not recognize the sender, they can block the sender or domain in Outlook or OWA by adding the sender to their Blocked Senders list.

4. Submit bulk mail and spam back to Microsoft for analysis. This allows us to continually refine our message filters. See Submitting spam and non-spam messages to Microsoft for analysis.

Note: EOP will always stamp this new header on messages regardless if it already exists or not. This prevents a spammer from manually adding this header themselves and setting a BCL of 0.

Going forward

In the near future it will be easier to take advantage of this new BCL system. We plan to roll this functionality into a slider that will be configurable in the Office 365 portal. Until this happens, creating the transport rule described above will allow you to take advantage of this functionality immediately.

Resources

The following TechNet documentation was updated in July 2014 to include information about the new X-Microsoft-Antispam header.

What’s the difference between junk email and bulk email?
Anti-spam message headers
Bulk Complaint Level values
Use transport rules to aggressively filter bulk email messages

Andrew Stobart

Occasionally I am asked the following question – how can I protect the messaging environment from a rogue administrator? There are essentially two concerns being asked in this question:

1. How do I protect the data from being deleted by a rogue administrator?
2. How do I protect the data from being accessed and/or altered by a rogue administrator?

Sometimes this discussion leads to a discussion about only the chosen backup architecture. The reality is that whether you implement Exchange Native Data Protection or a third-party backup solution, a backup, by itself, does not protect you from rogue administrators; it only mitigates the damage they potentially cause. Any administrator that has the privileged access to the messaging data (whether it be live data and/or backup data), can compromise the system. Therefore, some operational changes must be implemented within the organization in order to reduce the attack surface of an administrator who has gone rogue.

Important: This article is not intended to be a comprehensive set of instructions on how to restrict administrators. Instead, this article will highlight the principles and techniques that can be used.

Immutable Laws of Security

The Microsoft Security Response Center published the Ten Immutable Laws of Security. They are:

• Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
• Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore.
• Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
• Law #4: If you allow a bad guy to run active content in your website, it's not your website any more.
• Law #5: Weak passwords trump strong security.
• Law #6: A computer is only as secure as the administrator is trustworthy.
• Law #7: Encrypted data is only as secure as its decryption key.
• Law #8: An out-of-date antimalware scanner is only marginally better than no scanner at all.
• Law #9: Absolute anonymity isn't practically achievable, online or offline.
• Law #10: Technology is not a panacea.

These guiding principles are a cornerstone in how we secure Office 365 and are equally applicable to on-premises deployments.

Active Directory

Exchange relies on Active Directory, storing configuration data within the configuration partition and storing recipient data within the domain partitions. The forest administrators, who are members of either the Enterprise Admins group or the root Domain Admins group, control all aspects of the directory and control data stored in the directory (though they sometimes delegate specific rights to others so others can perform very specific actions that are usually narrowly scoped within a forest). Likewise, domain administrators in each domain partition own their respective recipient data. Companies normally restrict forest-wide and domain-wide actions to be exclusively performed by forest administrators because of the risk that configuration changes can have broad adverse impact.

Many organizations today operate an Active Directory model with a least-privilege administrative model. If you are not operating in this fashion, this should be a top priority for your organization. Remember, any member of the Enterprise Admins or Domain Admins can alter messaging configuration settings on recipients and/or the Exchange configuration, without utilizing the Exchange Management Tools. For more information, see Best Practices for Securing Active Directory.

In addition to operating Active Directory in a least-privilege manner, it is important to implement background checks and other processes to determine the trustworthiness of your administrators, otherwise Law #6 cannot be mitigated. In addition, you may want to consider investing in an identity management solution, like Forefront Identity Manager, to manage and audit administrative permission requests and approvals.

Permissions

Exchange administrators have a wide variety of tools that they potentially can utilize to manage a messaging environment. The preferred method is via Remote PowerShellas Exchange can then authorize access and audit any actions performed. However, if an Exchange administrator is granted additional permissions in Active Directory (e.g., the ability to modify any attribute on a user), then the administrator can utilize other tools (e.g., LDP, ADSIEdit, local PowerShell, scripts, etc.) to modify recipient and/or configuration data, bypassing the authorization and auditing checks built into the system.

To effectively mitigate any possibility of modifications that could occur outside of the Remote PowerShell framework, it is imperative to follow Best Practices for Securing Active Directory, as previously mentioned. Often times, Exchange administrators are not evaluated with the same rigor as Active Directory administrators; therefore, Exchange administrators must not be granted permissions in Active Directory that allow them to circumvent Remote PowerShell (e.g., recipient modification).

If Active Directory privileges are accurately and narrowly scoped, a rogue administrator will have difficulty making unauthorized changes no matter which tool he/she tries to use.

PowerShell

Exchange leverages Remote PowerShell which is a feature within PowerShell that lets admins run commands on remote systems. Remote PowerShell enables the functionality utilized by Exchange to audit cmdlet execution and enforce authorization through RBAC.

One way to ensure that administrators can only manage the messaging environment through Remote PowerShell is to not allow the installation of the Exchange Management Tools on administrator workstations. Administrators are then forced to use the Exchange Admin Center or to connect to Exchange using Remote Shell.

In addition, PowerShell 3.0 and higher provides robust audit capabilities when module logging is enabled. PowerShell Module logging captures pipeline execution events for specified modules, and records this data in Windows PowerShellEvent log. Among the events logged, Event ID 800 (Pipeline Execution Details) provides command line commands and a script name if one is used. If a script was used, the ScriptName value will be populated with the file name of the script that was executed and an event will be logged for each line in the script, with each event including the command from that line. The data recorded in the event log can be collected, analyzed, and provide auditing data by which an organization can determine what PowerShell operations are occurring in the environment.

Mitigating Data Destruction

An Exchange administrator has the necessary privilege to access and destroy Exchange data. The best way to protect the messaging data from an administrator is to:

1. Shrink the window of opportunity for administrators to perform malicious activities. The mechanisms that can be implemented include removing local administrative access, deploying Applocker, removing access to destructive cmdlets, and deploying lagged database copies.
2. Ensure all administrative actions are logged and implement alerting and reporting based upon monitoring of logged activities.
3. Implement a least-privilege access control model whereby the elevation process grants access only to perform the intended activities. Even more effective is implementing an access control model whereby most or all administrative activities are done via a ‘control plane’ that is used by administrators to request that actions be performed against Exchange and the control plane can then implement business logic upon the request that will determine if the request will actually be executed. The business logic might include a request to a second person to review and approve the action or it might check an employee work scheduling system to see if the original requestor is on vacation, for example.

Removing Local Administrative Access

The majority of Exchange management tasks are accomplished via Remote PowerShell. As a result, the only time an Exchange administrator needs local administrative access to the Exchange server is to perform system updates (installing driver updates, installing Exchange cumulative updates, operating system updates, etc.). Therefore, local administrative access can be restricted and granted only when needed, for a specific period of time, after which access is revoked.

Without local administrative access, administrators will be unable to obtain certain information about the Exchange server health that they may need to appropriately manage the environment. Therefore, administrators should be granted access to the following:

• File shares (secured via read-only access to the appropriate security groups) can be created to enable access to Exchange diagnostic logs (which by default, are located at %Program Files%\ Exchange Server\V15\Logging and %SystemDrive%\inetpub\logs).
• Read-only access to the event logs can be granted by adding the appropriate security groups to the member server’s local Event Log Readers security group.
• Access to performance counters can be granted by adding the appropriate security groups to the member server’s Performance Monitor Users security group.
• To allow administrators to schedule performance counter logging, enable and collect tracing, the appropriate security groups can be added to the member server’s Performance Log Users security group.

In addition, local administrative access on the administrator’s workstations should also be removed. This ensures that administrators can only run approved applications and cannot bypass any security mechanisms you may put into place to audit and monitor their actions. For more information on running Windows in a least privileged manner, see Applying the Principle of Least Privilege to User Accounts on Windows.

By removing local administrative access, Laws #2 and #3 are mitigated.

AppLocker

AppLocker provides organizations with a strong defense in the prevention of malicious software and unapproved applications from affecting your server environment. AppLocker can be used to limit the software that Exchange operators can use so that only an approved list of applications (e.g., Exchange Management Tools, approved PowerShell scripts, etc.) will run on a server where AppLocker policy enforcement is in effect. For more information, see the TechNet article on AppLocker.

AppLocker allows you to mitigate Law #1.

Removing Access to Destructive Cmdlets

Both Exchange 2010 and Exchange 2013 include Role Based Access Control (RBAC), a mechanism by which administrators are authorized to perform certain administrative tasks. RBAC provides the capability for very granular control of managing the messaging environment – for example, restricting access to a particular cmdlet or to a particular property of a cmdlet.

For more information on RBAC, please see the following articles:

• Understanding Role Based Access Control
• RBAC and the Triangle of Power
• RBAC: Walkthrough of creating a role that can wipe ActiveSync Devices

While Administrator Audit Logging will record the actions taken by administrators, it does not prevent the administrators from performing destructive actions if they are authorized to do so. Using RBAC, organizations can reduce the attack surface area by removing access to destructive cmdlets. A destructive cmdlet is any cmdlet that can access, modify, or delete messaging data.

The below table identifies cmdlets and parameters that may be considered destructive (e.g., Remove-Mailbox). Each cmdlet should be evaluated to determine how it is used in your environment and whether it should be removed from day-to-day usage.

Note: The above table does not include the cmdlet list identified in the section “Removing Access to Data Access Cmdlets” below, but they should also be considered as those cmdlets provide access to messaging data.

For example, if I wanted to ensure that my administrators cannot remove database copies and manipulate the lagged database copy’s configuration, I could remove those cmdlets by using RBAC in the following manner:

1. Create two new role groups: Protected Organization Management and Protected Server Management.

   $ORoleGroup = Get-RoleGroup “Organization Management"
    
   New-RoleGroup "Protected Organization Management" -Roles $ORoleGroup.Roles
    
   $SRoleGroup = Get-RoleGroup “Server Management"
    
   New-RoleGroup "Protected Server Management" -Roles $SRoleGroup.Roles

2. Remove the Database Copies role from the protected role groups.

   Get-ManagementRoleAssignment -RoleAssignee "Protected Organization Management" -Role "Database Copies" -Delegating $false | Remove-ManagementRoleAssignment
    
   Get-ManagementRoleAssignment -RoleAssignee "Protected Server Management" -Role "Database Copies" -Delegating $false | Remove-ManagementRoleAssignment

3. Create a Protected Database Copies role.

   New-ManagementRole –Parent "Database Copies" –Name "Protected Database Copies"

4. Remove the Remove-MailboxDatabaseCopy role entry from the Protected Database Copies role.

   Remove-ManagementRoleEntry "Protected Database Copies\Remove-MailboxDatabaseCopy"

   Additionally, you can also remove access to the ReplayLagTime parameter from the Protected Database Copies role, thereby ensuring administrators cannot disable the lagged database copy.

   Set-ManagementRoleEntry "Protected Database Copies\Set-MailboxDatabaseCopy" –Parameters ReplayLagTime -RemoveParameter

5. Add the Protected Database Copies role to the protected role groups.

   New-ManagementRoleAssignment –SecurityGroup "Protected Organization Management” –Role “Protected Database Copies"
    
   New-ManagementRoleAssignment –SecurityGroup "Protected Server Management” –Role “Protected Database Copies"

6. Add users to the protected role groups.

   $OrgAdmins = Get-RoleGroupMember "Organization Management"
    
   $SrvAdmins = Get-RoleGroupMember "Server Management"
    
   $OrgAdmins | ForEach {Add-RoleGroupMember "Protected Organization Management" –Member $_.Name}
    
   $SrvAdmins | ForEach {Add-RoleGroupMember "Protected Server Management" –Member $_.Name}

7. Remove the desired users from the Organization Management and Server Management role groups.

You can repeat the appropriate steps for each destructive cmdlet that needs to be restricted. Use the following cmdlet to determine which roles contain the desired cmdlets:

Get-ManagementRoleEntry "*\<cmdlet>" | fl name,role

Lagged Database Copies

A lagged database copy is a rolling point-in-time (up to 14 days) copy of the database. Lagged database copies were first introduced in Exchange 2007 and have evolved considerably since then. Lagged database copies are part of The Preferred Architecture. While the primary reason for deploying a lagged database copy is protection against rare, catastrophic logical corruption events, lagged database copies can be used to recover mailboxes and/or items that have been deleted by a rogue administrator. By implementing the access control mechanisms previously discussed, the lagged database copy is protected from destruction by a rogue administrator.

Mitigating Data Access

There are several mechanisms you can implement to mitigate unwarranted data access within your messaging environment. These mechanisms include auditing, using Bitlocker to encrypt the disk drives, and removing access to certain cmdlets that enable administrators to gain access to user data.

Auditing

There are several different forms of auditing that can be implemented in the messaging environment. Within Exchange, you can enable Administrator Audit Logging. Administrator Audit Logging captures all operations that are performed within the Exchange Management Shell (EMS) or Exchange Admin Center (EAC).

By default, all cmdlets, except Get- or Search- cmdlets are logged in the audit logs. You can change the cmdlet logging via Set-AdminAuditLogConfig; for example, since Search-Mailbox includes the ability to delete content, you will want to add that cmdlet to the list. Audit logs are stored in an arbitration mailbox. Reports can be accessed via the Search-AdminAuditLog, New-AdminAuditLogSearch cmdlets, or via EAC.

In addition to auditing the actions taken by Exchange administrators managing the service, you will also want to audit server operation events (e.g., logon events). For more information, see the Windows Server Security Auditing Overview article and the Audit Policy Recommendations article for securing Active Directory.

Bitlocker

Another way to reduce the attack surface area is to use Bitlocker to ensure that operators with physical access to the servers cannot remove disk drives and access the data contained on them.

As mentioned previously, separation of roles is imperative, otherwise Law #7 cannot be mitigated. As Bitlocker recovery information is stored in Active Directory (specifically the msFVE-RecoveryInformation attribute), delegation of this data must not be granted to Exchange administrators.

Removing Access to Data Access Cmdlets

Using RBAC, organizations can reduce the attack surface area by removing access to cmdlets that allow access to mailbox data. The below table identifies cmdlets that grant access to data, or enable administrators to hide their tracks. Each cmdlet should be evaluated to determine how it is used in your environment and whether it should be removed from day-to-day usage.

To remove access to the above cmdlets, follow steps 1-7 from the “Removing Access to Destructive Cmdlets” section.

Requesting Elevation

Over time, administrators will require access to restricted cmdlets to perform a necessary operation (e.g., disabling mailboxes, removing unnecessary transport rules, etc.). There are many ways you could go about this. For example, you could simply build RBAC roles for each individual cmdlet (and/or property) that you restrict; when elevation is required, you add the administrator to the appropriate role group, granting them access, and then remove the administrator when the task is complete. Or you could develop a process and workflow that includes the following:

1. A means by which an administrator may submit a request for elevated access. The request needs to include specifics like the cmdlets being requested, the targeted servers/users/etc., and the length of that time elevated access is required.
2. The request can either be implicitly approved based on the requested action, or it can require human approval.
3. All actions must be logged once elevated access has been granted.
4. Elevated access must be removed once the time period has expired (either based on the request or based on a default time period for access elevations) or the task has been completed.

How is this addressed in Office 365?

Exchange Online implements a variety of mechanisms to prevent rogue administrators from accessing or destroying data.

Perry Clarke and Vivek Sharma recently discussed Lockbox, a mechanism we use to enforce no standing access, in the article From Inside the Cloud: Who has access to your data within Office 365?

In particular, Exchange Online personnel do not have persistent access to the service or servers; instead, administrators (who have undergone background checks) have to request specific access (to servers, cmdlets, etc.) and can only perform the requested tasks during a specified timeframe. Additionally, for requests for elevation to a role with access to customer data, approval must be performed by another human being and the ability to approve this type of request is restricted to a smaller set of more senior personnel.

We also use other mechanisms to protect the service and customer data. For example, Bitlocker is used to encrypt all disks that contain customer data. When the disks are end-of-life they are shredded, thereby ensuring the data cannot be accessed.

Conclusion

While this article covers the basics, there are many other mechanisms you can implement in your environment to reduce the surface attack area within your messaging environment. For more information about security mechanisms protecting Exchange Online that can be used in on-premises deployments, see the MEC session Exchange Online service security investments: you CAN and SHOULD do this at home.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Microsoft periodically refreshes certificates in Office 365 as part of our effort to maintain a highly available and secure environment. On September 23, 2014, we are making a certificate change on our Microsoft Federation Gateway that could affect some customers as detailed in knowledge base article 2928514. The good news is, you can easily avoid any disruption.

Who is affected?

This certificate change can affect any customer that is using the Microsoft Federation Gateway. If you are in a hybrid configuration orif you are sharing free/busy information between two different on-premises organizations using the Microsoft Federation Gateway as a trust broker, you need to take action.

When will the change occur?

The change is scheduled to occur on September 23, 2014. You must take action before then to avoid any disruption.

What type of issues will you face if no action is taken?

If you don't take action, you won't be able to use services that rely on the Microsoft Federation Gateway. For example:

• A cloud user won't be able to see free/busy information for an on-premises user and vice versa.
• MailTips will not work in a Hybrid configuration.
• Cross-premises free/busy will stop working between organizations that have organization relationships in place.

What action should you take?

If you’re using Exchange Server 2013 SP1 or later no action is required. This is a common task in Exchange 2013 SP1, it happens automatically. Installing the latest version of Exchange Server 2013 will make this an automated task for you.

Update: if you are running Windows Server 2008 with Exchange 2013, the automatic update feature will not work (it will only work with Windows Server 2012). Therefore, you should instead follow the below instructions to update your metadata.

If you are not running Exchange 2013 SP1 or later, you can create a scheduled task to keep your Federation Trust up-to-date. You can use the following command on your Exchange Server to create a scheduled task to run the update process periodically. This is how we recommend you keep your Federation Trust constantly updated. This will prevent you from being negatively affected by future metadata changes.

Schtasks /create /sc Daily /tn FedRefresh /tr "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -command Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.E2010;$fedTrust = Get-FederationTrust;Set-FederationTrust -Identity $fedTrust.Name -RefreshMetadata" /ru System

If you prefer to not use a scheduled task, you can manually run the command at any time to refresh the metadata. If you choose a manual option, it is still best practice to update Federation information at least monthly.

Get-Federationtrust | Set-FederationTrust –RefreshMetadata

Jim Lucey

Yesterday, I, along with the rest of the Microsoft Exchange community, was shocked and saddened to learn of the untimely death of a colleague and friend, Andrew Ehrensing.

For those that never met Andrew, he was truly one of a kind. With his smile, laughter, and genuine good nature and charm, you were disarmed and put at ease. Everyone that met him became friends with Andrew instantly, and boy could he make you laugh with his stories.

Andrew spent his Microsoft career within Microsoft Consulting Services, working on many of the most challenging Exchange and Lync on-premises projects we could throw at him. Recently, he worked with several customers on the transition to Office 365. He worked tirelessly to meet the expectations of our customers and always over-delivered.

Andrew never shied away from passing on his wisdom, either. He taught during the Certified Master program, delivered many solid presentations at conferences like TechEd and MEC, and always made himself available to help out a friend or colleague with a challenging issue.

He approached everything with a passionate zeal, whether it be with work or in his personal life. He always strived for honesty and for doing right by his family and customers. If he didn’t agree with an approach the company or his friends were taking, he would not only tell us, but provide us the necessary evidence to see the error in our ways and wholeheartedly guide us toward the right path.

This is a terrible loss and our hearts, thoughts, and prayers go out to his wife, children, extended family, and friends.

Andrew will be forever remembered in the annals of Exchange history and in our hearts. If your life happened to be touched by Andrew, please share your anecdotes.  We will collect them and share them with the family.

Rest in peace, Andrew. We miss you.

Note: Some of the documentation referenced may not be fully available at the time of publishing of this post.

Exchange Server 2013 Cumulative Update 6 (CU6) was released today and provides several important updates for modern Public Folders. This blog post introduces you to the updates delivered in CU6 and discusses our on-going investments in public folders.

10x Increase in Public Folder Limits

CU6 delivers the first round of investments we have made to scale up the limits for Public Folders in Exchange Server 2013. CU6 raises the folder count limit to 100,000 folders. This is a 10x increase over the prior limit as defined in the Exchange Server 2013 limits for public folders. This enables you to migrate and deploy larger Public Folder hierarchies on premises with Exchange Server 2013. Customers can immediately take advantage of this new scale by deploying CU6.

In addition to the increased folder scale capabilities CU6 delivers improvements for concurrent access of Public Folders by reducing lock contention in store for hierarchy sync and content mailbox access.

As you scale the number of public folders in Exchange you might need to keep track of the number of folders that have been created. Exchange PowerShell provides an easy way to see the current public folder count in Exchange Server 2013. Using the Get-PublicFolder and Measure-Object cmdlets you can readily get a current count of your public folders created in Exchange 2013.

Get-PublicFolder –Recurse –ResultSize Unlimited | Measure-Object
Count    : 40051
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

Mail-Enabled Public Folder Permission Changes

This is an important change for customers already using Public Folders in Exchange Server 2013. Prior to CU6 unauthorized senders were able to send messages to mail-enabled Public Folders which means external users could send email to mail-enabled Public Folders regardless of permissions. With CU6, administrators must grant Anonymous users Create Items permissions in the mail-enabled Public Folder to allow external users the ability to send email to the mail-enabled Public Folder. Refer to the CU6 release notes Public Folders section for guidance on updating your configuration.

Automatic Public Folder mailbox readiness management after migration

An additional change delivered in CU6 for Public Folders helps improve the administrator experience post migration. All PF mailboxes serve hierarchy by default in Exchange Server 2013. We have introduced new logic to check if the hierarchy is fully synced to a mailbox after migration. If it is, then the mailbox is automatically made available to serve public folder hierarchy connection else we wait for full sync to complete. This eases work for admin to manually manage readiness of a mailbox after migration completes. Admins can still turn hierarchy serving off and on (default = on) as they please. Refer to the Public Folder article for specific attributes to control hierarchy sync.

Public Folder Deployment Guidance

The increased scale capabilities for public folders in CU6 enables more advanced configurations to begin migrating to modern Public Folders. To meet the needs of these large scale migrations the team has created deployment guidance to assist customers migrating larger scale public folder hierarchies. This deployment guidance will become available in the next few weeks. We will update this post with a link once it is available.

What’s Next

This is the first round of public folder scale improvements we are working to deliver as we shared in the prior Exchange team blog post. Scale improvements are targeted to increase again in a future update. Scale improvements will remain our top priority for Public Folder updates. Other updates such as OWA support for calendar and contacts and Public Folder reporting tools are expected to follow after delivering further scale updates.

Brian Shiers
Technical Product Manager

Frequently asked questions

Q: Is there a limit for the number of sub-folders within a single public folder?
A: The recommended maximum number of sub-folders is 1000. This is the level that has been validated and is the same limit used in Exchange Online.

Q: Is there a limit for the folder depth of the hierarchy?
A: The recommended maximum depth of the hierarchy is 300 folder levels. This is the level that has been validated and is the same limit used in Exchange Online.

Q: Does the increase in folder count change the number of public folder mailboxes or quota for public folders?
A: The number of public folder mailboxes and the total public folder quota remain unchanged. These and other limits are documented in Public Folder Limits article.

Note: We have learned that customers using Exchange Server 2013 and Exchange Server 2007 co-existence can experience an issue causing Exchange Server 2013 CU6 databases to failover. Please refer to KB2997209 for the specific scenario impacted.

The Exchange team is announcing today the availability of our most recent quarterly servicing update to Exchange Server 2013. Exchange Server 2013 Cumulative Update 6 and updated UM Language Packs are now available on the Microsoft Download Center. CU6 represents the continuation of our Exchange 2013 servicing and builds upon Exchange 2013 CU5. The release includes fixes for customer reported issues, minor product enhancements and previously released security bulletins. A complete list of customer reported issues resolved in Exchange 2013 CU6 can be found in KB 2961810. Customers running any previous release of Exchange 2013 can move directly to CU6 today. Customers deploying Exchange 2013 for the first time may skip previous releases and start their deployment with CU6 as well.

We would like to call your attention to a couple of items in particular about the CU6 release:

• As discussed at MEC 2014 and other forums, CU6 includes significant improvements in Public Folder scalability. More details about this in Public Folder Updates in Exchange 2013 CU6: Improving Scale and More.
• CU6 includes a fix for the HCW issue discussed in KB 2988229. A reminder for those customers who installed the Interim Update which resolved this issue: it's NOT necessary to uninstall the Interim Update prior to installing CU6.

For the latest information and product announcements about Exchange 2013, please read What's New in Exchange 2013, Release Notes and Exchange 2013 documentation on TechNet.

CU6 includes Exchange-related updates to Active Directory schema and configuration. For information on extending schema and configuring Active Directory, please review Prepare Active Directory and domains in Exchange 2013 documentation.

Reminder:  Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to maintain currency on Cumulative Update releases.

Note: Documentation may not be fully available at the time this post was published.

The Exchange Team

The Exchange team is announcing today the availability of Update Rollup 7 for Exchange Server 2010 Service Pack 3. Update Rollup 7 is the latest rollup of customer fixes available for Exchange Server 2010 Service Pack 3. The release contains fixes for customer reported issues and previously released security bulletins. Update Rollup 7 is not considered a security release as it contains no new previously unreleased security bulletins. A complete list of issues resolved in Exchange Server 2010 Service Pack 3 Update Rollup 7 may be found in KB2961522. Customers running any Service Pack 3 Update Rollup for Exchange Server 2010 can move to Update Rollup 7 directly.

The release is now available on the Microsoft Download Center. Update Rollup7 will be available on Microsoft Update in September.

Note: The KB article may not be fully available at the time this post was published.

The Exchange Team

The Exchange team is announcing today the availability of Update Rollup 14 for Exchange Server 2007 Service Pack 3. This latest rollup supports recent DST updates. The rollup contains all previously released security bulletins and fixes and updates for Exchange Server 2007 Service Pack 3 as well. This is not a security release, but customers are encouraged to deploy these updates to their environment once proper validation has been completed. More information on this rollup is available in KB2936861.

Note: The KB article may not be fully available at the time this post was published.

The Exchange Team

Update: On August 25, 2014, the pelnet.ps1 script was updated to fix a minor bug.

EHLO Exchange community,

It seems that PelNet has been well received and I’ve been receiving requests to add much wanted functionality to PelNet. So this article is a quick update on some of the cool new features that administrators can use to help troubleshoot and validate mail flow.

The new features added in this release:

1. Ability to test against multiple recipients – this is useful if you want to test to multiple external domains without having to run the tool again.
2. Optimized remote execution against transport servers for better performance across a large amount of servers.
3. The ability to validate if TLS negotiation is working. This is one of the most useful feature additions.

The above features gave birth to two new parameters validateTLS and CertThumbPrintOverride.

Let’s recap the parameters with the new ones introduced.

• AddressSpace: Which AddressSpace should the script look for in the Send Connectors?
• sendConnector: Specify if you want the scope to be a single Send Connector.
• SourceTransportServers: Accepts comma separated list of transport servers to test from.
• smartHost: The smarthost you want to test against. Accepts comma separated list value. (when validating TLS be sure to use FQDN of remote host – certificate validation will fail if IP is used)
• mailSubmissionTest: Use this switch if you want the script to submit the mail to the mailbox. If you omit the parameter the script will skip the DATA portion of the SMTP verb.
• From: From address (postmaster@contoso.com)
• Rcpt: Recipient Addresses –accepts comma separated list of addresses (testmailbox@fabrikam.com,testmailbox@wingtiptoys.com)
• LogFolderPath: Log file and report location, default will be current path if not specified.
• Port: Default is 25, but you can specify a custom port if you need to.
• validateTLS: This switch will enable TLS validation – this changes the SMTP verb array being used to include the STARTTLS verb (and some other more complicated stuff).
• CertThumbPrintOverride: This allows the operator to override the logic used to determine the SMTP certificate assigned to the transport servers.

  This can also be used to test TLS to a specific host before assigning the certificate to the SMTP service in Exchange, i.e. pre-validations prior to production change. The certificate needs to be in the local machine certificate store.

  It’s important to note that the code logic uses best effort to determine the SMTP certificate assigned. Using the CertThumbPrintOverride parameter allows you to override this easily.

Script Execution Examples

Show the full help with examples

Get-help .\pelnet.ps1 -full

To test mail flow and validate TLS to a smarthost against all the transport servers on port 25 to multiple recipients. (Will not submit the message for delivery)

.\PelNet.ps1 -From postmaster@adatum.com -Rcpt user1@contoso.com,user2@fabrikam.com,user3@wingtiptoys.com -smarthost webmail.contoso.com -validateTLS

To test mail flow and validate TLS to a smarthost against all the transport servers on port 25 to multiple recipients. (Submits the message for delivery and override the certificate to use)

.\PelNet.ps1 -From postmaster@adatum.com -Rcpt user1@contoso.com,user2@fabrikam.com,user3@wingtiptoys.com -smarthost webmail.contoso.com –validateTLS –mailsubmissiontest –certThumbprintOverride 1A13124HJG1234K12JHG312J123D

To test mail flow and validate TLS to EOP from your hybrid servers on port 25 to multiple recipients (also submit the mail to EOP).

.\PelNet.ps1 -From postmaster@adatum.com -Rcpt user1@contoso.com,user2@fabrikam.com,user3@wingtiptoys.com -smarthost adatum-mail-onmicrosoft-com.mail.protection.outlook.com –validateTLS –sourceTransportServers E15HYBRID01,E15HYBRID02 -mailsubmissiontest

The TLS validation logic will authenticate against the remote server with the certificate assigned to SMTP or the certificate that matches the thumbprint used in the override parameter. If the remote host is configured with Opportunistic TLS and the handshake fails the session will fall back to unencrypted SMTP.

The console output won’t show the verb’s being sent as the code is invoking on multiple servers concurrently, but the final output table and output file will be exactly as previously described in PelNet 1.0.

From the below output:

STARTTLS verb being sent with server responding with 2.0.0 SMTP Server Ready and subsequent SSL Stream is established by authenticating against target host using certificate that matches thumbprint provided (or dynamically found using best effort).

Verbs being sent over SSL stream and successful recipient lookup.

The following is an example of a certificate validation issue on one server:

Some of the most common certificate validation errors are:

• Certificate revocation list not found.
• The remote hostname does not match the name on the certificate.
• Certificate is expired.
• The root certificate is not installed on the sending server, i.e. the server does not trust the remote certificate it received.

The above validation error was quickly fixed by installing the root certificate from the Contoso environment on the EX14-02 server.

Until next time,

Michael Hall
Service Engineer
Office 365

When customers receive an email with a suspected virus, they often ask “What do I do now?”

This blog post helps answer that question and guides you through our recommended process. This is intended for customers using Office 365 or Exchange Online Protection with on-premises Exchange servers.

First, it is important to understand the difference between an infected and uninfected email. Any email that has an attachment containing a script or malicious executable is considered ‘a virus’ for our purposes. This does not include subscription-based messages with links to malicious sites. Those messages would be considered spam and not viruses, and a different approach is used for spam messages (see this and this).

To deal with an email virus, here are some quick actions that you can perform:

1. Start at the filtering layer. We recommend using EOP, as it is the default option for Office 365 users. However, if you are using a third-party filtering mechanism, you will need to contact your vendor to investigate further. If the email virus has gone through Exchange Online Protection (EOP), or if header information is missing, then proceed to the next step.

2. Create a Transport Rule to block the message. Note that Office 365 Small Business and Small Business Premium customers will not have this feature access as mentioned here. See here also for information about transport and inbox rules limits. If you are an EOP customer, you can perform these steps as mentioned in Microsoft Knowledge Base article 2959596:

• Navigate to Mail Flow in the Exchange Admin Center.
• Click + to create a new rule.
• Click More Options.

Under Apply this rule if, choose any attachment has executable content. At this point you can also choose an action under Do the following. We recommended choosing Block the message…

Make sure no other Transport rules exist that would override this rule. See Manage Transport Rules for more information.

3. Submit the email virus sample immediately to Microsoft Malware Protection Center (MMPC) for further analysis. In order to receive analysis updates, please sign into the MMPC Web site, or enter a valid email address. We recommend you to use your Microsoft account email address.

4. Once you have logged in, select O365 and Exchange Online Protection. Follow the instructions outlined on the MMPC to understand if you need to compress the email virus sample before uploading it to the site. Once you have completed the procedure, make note of the final MMPC ID that will be sent to you from the MMPC Submission Support Team.

If you are dealing with an email virus that has a sender of administrator@domain.com or fax@domain.com with domain.com being same as your Office 365 domain, we also recommend blocking the sending server’s IP address and enabling the SPF hard fail in addition to the steps mentioned above. Also, see Best Practices for Configuring EOP.

If you continue receiving infected messages or attachments, then you should copy the message headers from the email virus, and contact Microsoft Customer Service and Support for further assistance. Be sure to have your MMPC ID handy, as well.

Irol Pinto
Technical Advisor, Microsoft Corporation

In the last related blog postwe gave some introduction about Exchange Online Protection (EOP), what needs to be done when EOP is not working as desired and spam email troubleshooting process and classification. In this blog we will be moving further and discussing some more advanced option to stop spam emails.

1. IP Block list

The “IP block list” option enables us to block email messages that came from a specific mail server (specific IP).

EOP - using the the IP Block list

• Login to Office 365 portal, Exchange admin center
• On the left-side menu bar, choose the Protection menu
• On the top menu options, choose the connection filter menu
• Choose the Default connection filter policy
• In the window that appears, choose the option: connection filtering menu.
• In the section: IP block list, Choose the plus icon to add the IP address of the Mail server that sent the spam

Additional reading

• Configure the Connection Filter Policy

2. International spam

The “International spam” is an interesting option that enables us to block or identify mail as “spam” based on the classification of Geographical location or Language.

Note: We need to be cautious when using this option because we can very easily get into the scenario in which legitimate mail is identified as “bad\spam” mail and be blocked.

Using the International spam option

• Login to Office 365 portal, Exchange admin center.
• On the left side menus, choose the protection menu
• On the top menu options, choose the content filter menu
• Choose the Default connection filter policy
• In the window that appears choose the option: international spam menu.

We can use one (or both) of the following options:

Blocking mail written in the specific language

• Choose Filter email messages written in the following languages
• Click on the Plus icon and choose the specific languages that you want to block

Blocking mail by Geographical location

• Choose Filter email messages sent from the following countries or regions
• Click on the Plus icon and choose the specific regions that you want to block

3. Content filter advanced options

Before we begin with instruction of how to use EOP advanced option for spam mail, let’s explore additional classifications of spam mail types and the tools we can use. Using a high level classification, we can define 3 “families” of spam mail types:

• Advertisement mail - negative effect of such mail could be considered as “annoying." No real damage is caused to users besides the fact that the user is troubled by the content of the mail (suggestions to buy different medications, enlarge specific body parts and so on). This type of spam mail is automatically blocked (most of the time) by the Office 365 mail gateways. In case that some Advertisement spam mail manages to “sneak in" we can use a solution such as “rules” for blocking this type of spam mail. 
• Mail with malicious content - this type of spam mail is closer to the definition of “virus” because, the target of the spammer is to cause the destination recipient to click or accept some suggestion that could lead the user to many kinds of attacks such as fraud, phishing and so on.
• “Other spam mail” - in this group, we have other spam mail types that don’t belong to the former families. As an example, we can mention spam mail described as NDR backscatter.

Content Filter - Advanced options

The “Advanced options” section under the Content Filter section enables us to “harden” the default spam policy that is implemented by the Office 365 mail security gateways. To avoid incorrectly marking legitimate messages as spam, we can use the “Test mode” (we can describe this as a “Learning mode”). This mode enables us to use the “additional security filter” and decide what will happen when a specific mail item is recognized as spam by the security filter without actuallyperforming any action. We can choose to block\delete the mail item or just report the mail item (Test mode).

Using Content Filter - Advanced options

• Login to Office 365 portal, Exchange admin center.
• On the left side menus, choose the protection menu
• On the top menu options, choose the content filter menu
• Choose the Default connection filter policy
• In the window that appears choose the option: advanced options menu.

As you can see there are many possible options that we can select. The options are divided into 2 categories: Increase spam Score and, Mark as spam.

To be able to demonstrate options available in the Content Filter - Advanced options let describe two scenarios:

• Scenario 1: Blocking spam mail with malicious content
• Scenario 2: Blocking spam mail classified as NDR backscatter

Scenario 1: Blocking spam mail with malicious content

Over the last month, users were complaining about spam mail that contains malicious content. When users open the mail item, they are automatically redirected to a web site, and once there are invited to download an executable file. To be able to block this spam mail item, we would activate three additional filters: mark as spam if the mail item is or contains:

Empty messages

JavaScript or VBScript in HTML

Frame or IFrame tags in HTML

By default, each of the security filter status is: Off. When we click on the “option arrow," we can see that we can choose the options: “Off," “On” or “Test." In case that we choose the option “On," each mail that contains content that is not allowed by one of the security filters that was selected (such as JavaScript or VBScript in HTML) will be marked as spam.

In case that we just want to test the “new security filter” we can choose the option “Test." In the following screenshot, we can see that we can choose one of the following three options:

• None
• Add the default test X-header text
• Send a BCC message to this address  (Note: This address should have a separate mailbox that is just for testing the security filters.)

Scenario 2: Blocking spam mail classified as NDR backscatter

NDR backscatter is a special kind of spam because the “mechanism” that’s used by the spammer is different from the “Standard spam mail." NDR backscatter is when spammer forges the user’s email address and sends email on their behalf to other recipients. If the “destination mail system” recognizes the mail as a spam or if the mail is sent to non-existing users, the “destination mail system” creates an NDR message that is sent to the organization recipient (the user whose email address was used by the spammer).

Generally speaking, Office 365 security gateway servers are configured to block this kind of spam mails, but in case that the spam mail manages to “sneak” through, we can add the following filter using the Content Filter - Advanced options.

Using Content Filter - Advanced options - NDR backscatter

• Login to Office 365 portal, Exchange admin center.
• On the left side menus, choose the protection menu
• On the top menu options, choose the content filter menu
• Choose the Default connection filter policy
• In the window that appears choose the option: advanced option menu.
• Choose the option: NDR backscatter, and turn on the security filter

That is all for this time. Until we meet again,

Eyal Doron
Tech Lead | Office 365 | Israel

Probes are one of the three critical parts of the Managed Availability framework (monitors and responders are the other two). As I wrote previously, monitors are the central components, and you can query monitors to find an up-to-the-minute view of your users’ experience. Probes are how monitors obtain accurate information about that experience.

There are three major categories of probes: recurrent probes, notifications, and checks.

Recurrent Probes

The most common probes are recurrent probes. Each probe runs every few minutes and checks some aspect of service health. They may transmit an e-mail to a monitoring mailbox using Exchange ActiveSync, connect to an RPC endpoint, or establish CAS-to-Mailbox server connectivity. All of these probes are defined in the Microsoft.Exchange.ActiveMonitoring\ProbeDefinition event log channel each time the Exchange Health Manager service is started. The most interesting properties for these events are:

• Name: The name of the Probe. This will begin with the SampleMask of the Probe’s Monitor.
• TypeName: The code object type of the probe that contains the probe’s logic.
• ServiceName: The name of the Health Set for this Probe.
• TargetResource: The object this Probe is validating. This is appended to the Name of the Probe when it is executed to become a Probe Result ResultName
• RecurrenceIntervalSeconds: How often this Probe executes.
• TimeoutSeconds: How long this Probe should wait before failing.

On a typical Exchange 2013 multi-role server, there are hundreds of these probes defined. Many probes are per-database, so this number will increase quickly as you add databases. In most cases, the logic in these probes is defined in code, and not directly discoverable. However, there are two probe types that are common enough to describe in detail, based on the TypeName of the probe:

• Microsoft.Exchange.Monitoring.ActiveMonitoring.ServiceStatus.Probes.GenericServiceProbe: Determines whether the service specified by TargetResource is running.
• Microsoft.Exchange.Monitoring.ActiveMonitoring.ServiceStatus.Probes.EventLogProbe: Logs an error result if the event specified by ExtensionAttributes.RedEventIds has occurred in the ExtensionAttributes.LogName. Success results are logged if the ExtensionAttributes.GreenEventIds is logged. These probes will not work if you override them to watch for a different event.

The basics of a recurrent probe are as follows: start every RecurrenceIntervalSeconds and check (or probe) some aspect of component health. If the component is healthy, the probe passes and writes an informational event to the Microsoft.Exchange.ActiveMonitoring\ProbeResult channel with a ResultType of 3. If the check fails or times out, the probe fails and writes an error event to the same channel. A ResultType of 4 means the check failed and a ResultType of 1 means that it timed out. Many probes will re-run if they timeout, up to the MaxRetryAttempts property.

The ProbeResult channel gets very busy with hundreds of probes running every few minutes and logging an event, so there can be a real impact on the performance of your Exchange server if you perform expensive queries against this event channel in a production environment.

Notifications

Notifications are probes that are not run by the health manager framework, but by some other service on the server. These services perform their own monitoring, and then feed data into the Managed Availability framework by directly writing probe results. You will not see these probes in the ProbeDefinition channel, as this channel only describes probes that are run within the Managed Availability framework.

For example, the ServerOneCopyMonitor Monitor is triggered by Probe results written by the MSExchangeDagMgmt service. This service performs its own monitoring, determines whether there is a problem, and logs a probe result. Most Notification probes have the capability to log both a red event that turns the Monitor Unhealthy and a green event that make the Monitor healthy once more.

Checks

Checks are probes that only log events when a performance counter passes above or below a defined threshold. They are really a special type of Notification probe, as there is a service monitoring the performance counters on the server and logging events to the ProbeResult channel when the configured threshold is met.

To find the counter and threshold that is considered unhealthy, you can look at Monitor Definitions with a Type property of:

· Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor or

· Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor

This means that the probe the Monitor watches is a Check probe.

How this works with Monitors

From the Monitor’s perspective, all three probe types are the same as they each log to the ProbeResult channel. Every Monitor has a SampleMask property in its definition. As the Monitor executes, it looks for events in the ProbeResult channel that have a ResultName that matches the Monitor’s SampleMask. These events could be from recurrent probes, notifications, or checks. If the Monitor’s thresholds are reached or exceeded, it becomes Unhealthy.

It is worth noting that a single probe failure does not necessarily indicate that something is wrong with the server. It is the design of Monitors to correctly identify when there is a real problem that needs fixing versus a transient issue that resolves itself or was anomalous. This is why many Monitors have thresholds of multiple probe failures before becoming Unhealthy. Even many of these problems can be fixed automatically by Responders, so the best place to look for problems that require manual intervention is in the Microsoft.Exchange.ManagedAvailability\Monitoring crimson channel. These events sometimes also include the most recent probe error message (if the developers of that Health Set view it as relevant when they get paged with that event’s text in Office 365).

There are more details on how Monitors work, and how they can be overridden to use different thresholds in the Managed Availability Monitors article.

Abram Jackson
Program Manager, Exchange Server

Update 8/26/14: changed the resolution to include the release of Exchange 2013 Cumulative Update 6 (CU6).

An important update is now available to resolve issues customers are currently experiencing when using the Hybrid Configuration Wizard (HCW) to create a new or manage an existing hybrid deployment with Microsoft Exchange Server 2013.

If you currently have an Exchange 2013-based hybrid deployment configured, you will not notice any issues unless you rerun the HCW as part of updating or managing your existing hybrid features. If you need to reconfigure your hybrid deployment, you should instll Exchange Server 2013 (Cumulative Update 6) to correct this issue with the HCW.

For Exchange 2013 organizations creating new or managing an existing hybrid configuration with the HCW, the following HCW error message indicates you are experiencing the issue this update addresses:

Subtask CheckPrereqs execution failed: Check Tenant Prerequisites Deserialization fails due to one SerializationException: Microsoft.Exchange.Compliance.Serialization.Formatters.BlockedTypeException: The type to be (de)serialized is not allowed: Microsoft.Exchange.Data.Directory.DirectoryBackendType

If you experience this issue, please install Exchange 2013 Cumulative Update 6 (CU6).

Brian Shiers
Technical Product Manager

FAQ

Q: I’ve already configured a hybrid deployment with Exchange Server 2013 and I don’t need to make any changes to my hybrid configuration or features, do I need to apply this (interim) update?

A: No, you can wait for the fix to be delivered in the next Exchange Server 2013 update as long as you don’t have the need to run the Hybrid Configuration Wizard. EDIT: CU6 is now released and available.

Q. I may need to make updates to my Exchange 2013-based hybrid deployment before the next Exchange Server 2013 update, what are my options?

A. If you need to update your hybrid deployment features, install Exchange Server 2013 Cumulative Update 6 (CU6). Attempting to manually configure a new or update an existing hybrid deployment without HCW can result in unsupported hybrid deployment states.

Q: Are customers who use Exchange Server 2010 impacted by this update?

A: No, this only applies to customers using Exchange Server 2013 to configure a hybrid deployment with Office 365.

Q: If we apply the update specific for SP1 or CU5 do I have to do anything special to update to CU6 or later in the future?

A: The interim update does NOT need to be uninstalled. We allow later CU’s to install over Interim Updates and Security Updates directly as of CU3.

I wanted to write a series of blog posts talking about email spam in Office 365. While majority of spam mail is blocked by the Office 365 mail security gateways, there are no perfect systems that will block 100% of spam all the time, some can still get through. In case that we do experience spam mail, we can use several tools and configuration options that are available for us in Office 365 to deal with it and improve effectiveness.

In this series, we will quickly review different types of spam mail. Then we will present different tools that we can use for fighting spam mail in an Office 365 environment and try to “match” the “spam tool” for the task based on the type of the spam.

Also please note that while we are approaching this from Office 365 viewpoint, many of the procedures listed here apply to both on-premises and hybrid deployments.

Introduction

One of the advantages of using Office 365 is that transparently, behind the scenes, we implement EOP – Exchange Online Protection (the former mail security infrastructure was implemented by FOPE services).

The Exchange Online Protection infrastructure serves as mail gateways, which are responsible for the “Hygiene” of incoming and outgoing mail flow. The purpose of this mail gateway’s is to filter any malware, virus or spam that might be included in the mail flow that comes from external sources to Office 365 recipients (incoming mail flow) and also mail that is sent from Office 365 recipients to external sources. A bit over-simplified but think of it like this:

What should I do when EOP is not working as desired?

EOP aims to provide the best possible protection, but from time to time Office 365 subscribers can experience spam mail that gets into their mailbox.

Before going further into this, let’s not forget that there is no “perfect solution” that will block 100% of spam mail because “spam solutions\gateways”, will always need to face issues of:

• False Positive - a scenario in which the defending systems recognize legitimate mail is bad\spam mail and blocks the mail. 
• False Negative - a scenario in which the defending system doesn’t recognize bad\spam mail and the mail reaches recipients mailbox.

Certainly any hygiene solution, even a cloud-based one, will have times when a few messages originating from a creative spammer sneak through before it is recognized as a threat. The advantage that a cloud-based solution offers is that it is set up to recognize those threats quickly, partially due to the quantity of email that it processes.

Additionally, different users will always have slightly different expectations. It is therefore challenging to have a default configuration setting that is perfect for different business customers, each with unique requirements. One person’s spam email can be another person’s legitimate business email. EOP defaults tend to be slightly less strict rather than risk a false positive. If these defaults are not adequate for your organization, EOP offers great flexibility in allowing customization of anti-spam settings.

This series of blog posts will help you understand what to do in either situation.

Spam mail - Troubleshooting process and classification

To create a clear path of the troubleshooting process, we will need to implement the workflow similar to the one in the following diagram:

Step 1 - Get information about the character of the spam mail.

The most basic step is to get essential information about the spam message. Determine if the mail message is truly a spam message and if so, try to recognize the type of spam. Based on this information, choose the right “tools” for mitigating it (we will cover more of those in future posts).

Questions to answer

Here is a list of questions that could help gather required information:

• Q: Is the mail considered as spam mail or just standard advertisement mail from a well-known\familiar company?
• Q: Is the spam mail sent from a specific sender email address?
• Q: Is the spam mail sent from a specific domain?
• Q: Does the spam mail include specific keywords in the mail subject\body?
• Q: Does the spam mail include specific URLs in the mail body that redirect the recipient to another location?
• Q: Does the spam mail include characters of non-English language?
• Q: Is the spam mail from a specific geographical location?
• Q: Is the spam mail directed to a specific user or distribution list in the organization?

General characteristics:

• Q: Is the spam mail sent on a specific schedule (specific hour or date)?
• Q: What is the percentage of organization users who get the spam mail?
• Q: What is the “amount” of the spam mail (single mail item, tens or hundreds of spam mails)?
• Q: How long has the spam mail been received (days/hours)?
• Q: When was the last spam mail received?

Step 2 – Report\Block spam mail

When we deal with spam mail, we need to try to block the spam mail by using the available option from the “Server side” (Exchange online and EOP) and the “Client side” (Outlook). The process of blocking the spam mail could be implemented as a combined operation of using tools for filtering spam mail and other tools for reporting (sending a sample of the spam mail) to the Microsoft team that manages the EOP infrastructure.

Dealing with spam mail - Client side

1. Microsoft Junk E-mail Reporting Add-in

The Microsoft Junk E-mail Reporting Add-in, is a very useful Outlook add-in that enables each of the users to report the offending message to Microsoft.

By selecting the mail item and then choosing the option of “Report Junk," the mail item will automatically be sent to the Microsoft mail security team for further analysis and investigation to help to improve the effectiveness of our junk e-mail filtering technologies.

Using the Microsoft Junk E-mail Reporting Add-in

• Download and Install the Microsoft Junk E-mail Reporting Add-in.
• Report email as spam

In Outlook 2010\2013, the Microsoft Junk E-mail Reporting Add-in is implemented by additional menu option named: Report junkthat is added to the “Junk” section to be able to report an email as spam. To “mark” mail item as Junk use the following procedure: 

• Choose the mail items you would like to report
• On the Home Tab choose the small black arrow of the Junk option.
• Choose the option Report Junk

A warning message appears and informs the user that the mail item will be reported as spam. Choose the “Yes” option.

When we choose the “yes” option, the following events will occur:

• The mail items that were reported as spam, will be sent to the Junk Email folder.
• A copy of mail items will be sent to abuse@messaging.microsoft.com as attachments, as can be seen in the sent items folder
• An acknowledgement email will be sent back to the recipient.

In Outlook 2007, the option to “report junk” will be added on the top menu option.

2. Outlook Junk option - block sender

Another option that is available for us from “client side” is the Outlook junk component and the option of “block sender” (Add a sender to the Blocked Senders list).

This option is most suitable in a scenario that the spam mail is delivered from a specific recipient email address. In reality, many times the “spammers” mange to send the spam mail by using a different source recipient email address, so the option to “block sender” will not help us in such scenarios.

Add a sender to the Blocked Senders list

In case that you want to block the sender who sends spam mail, we can use the junk menu for blocking this recipient.

• Choose the required mail items,
• In the Home Tab chooses the small black arrow of the Junk option.
• Choose the option Block sender

Additional reading:

• How to obtain the latest Outlook Junk E-mail Filter update
• Overview of the Junk Email Filter

3. Unsubscribe from a mailing list

In case that the user reports “spam mail” and when checking the mail item, we see that the sender is not considered as “spammer” (mail is just a standard advertising email that is sent to a distribution list that the user is on), most of the time the mail will include an option that enables the user to unsubscribe from the mailing list.  So, before we start to use the “heavy artillery," please check if the option of “unsubscribe” exists and unsubscribe from the mailing list.

4. Educate users: How to avoid spam

Educating users to avoid spam belongs to a “proactive” section in which we are trying to avoid a scenario that could lead to spam mail. 

By providing our users instructions and guidance about behavior they should avoid, we can prevent or significantly reduce in advance the occurrence of “spam events."

You can read more information about this subject by using the following link:

10 tips on how to help reduce spam

That is all for today – part 2 (starting to talk about server side solutions) to follow soon!

Eyal Doron
Tech Lead | Office 365 | Israel

Quick note to let you know we've announced a new unified technology event for enterprises. If you've attended Microsoft Exchange Conference (MEC), SharePoint Conference, Lync Conference or Project Conference, this event is for you! Head over to Office Blogs for more.

Bharat Suneja