Managing Compliance in Microsoft Exchange Server 2010

Message classifications

Microsoft introduced message classifications in Exchange 2007 in an attempt to allow users to apply business-specific labels to messages. The labels are stored as properties of the messages and can be acted on by transport rules. Users can also react to the classifications when they see them on messages through Outlook or Outlook Web App. For example, if a message is labeled “Super Critical,” a user might be less likely to delete it and more likely to quickly respond to the request that the message contains.

The problems with message classifications are threefold. First, you rely on senders to apply classifications and receivers to respond appropriately to the classifications when messages arrive. Second, there’s no automated method to distribute and publish message classification data to clients such as the approach used by Outlook protection rules, so you have to make an arrangement to distribute the necessary classification information to Outlook clients. By comparison, Outlook Web App picks up classifications direct from the server. Third, only Outlook 2007 and Outlook 2010 clients and Outlook Web App support classifications. Any other client simply ignores their presence.

Even with the acknowledged limitations, there are customers who find message classifications a very useful and worthwhile facility. The characteristics of these customers usually include the following:

• A requirement to classify messages in terms of their sensitivity, content, or intended audience that is well understood by the user population.

• A well-structured classification scheme for information that makes sense to users and the business. Ideally, email shares the same classification scheme as applied to documents and other information. Multiple classification schemes invariably cause confusion and result in a lesser degree of compliance by users.

• The ability to deploy updates to Outlook clients in a reliable manner.

• A population of Outlook 2007 and Outlook 2010 clients.

Typical classifications include labels such as Personal, Secret, Business Critical, Audit Retention, and so on. The diversity of businesses is reflected in the diversity of classifications that are created and applied to material. However, within an individual company, it is a good idea to keep the number of classifications to a minimum to avoid user confusion and to encourage compliance.

Creating a message classification

You can’t create a new message classification using EMC or ECP. All manipulation of message classifications is performed through EMS. Before creating any message classifications, it’s worthwhile to sit down and chart out the various classifications that you think are needed by the business. Too many classifications are likely to confuse users if they don’t know which classification to apply in a given circumstance, whereas too few might not achieve the granularity of classification required by the business. Each classification therefore should be justified by business logic and its application should be easily explainable to a user. In other words, the use and purpose of every message classification must be blindingly obvious if it is to succeed.

Let’s assume that we have done the necessary due diligence and have decided to create a new message classification called “Top Secret.” We can do this with the New-MessageClassification cmdlet:

New-MessageClassification -Name 'Top Secret' -DisplayName 'Top Secret: Eyes Only'
-SenderDescription 'This message contains Top Secret information that must not be
shared outside the company' -RecipientDescription 'This message contains Top Secret
information that must not be shared outside the company: Do not forward!'

Table 15-10 explains the parameters that you can use with the New-MessageClassification cmdlet and their meaning.

Table 15-10. Parameters used with the New-MessageClassification cmdlet

Our new classification is now registered in Active Directory and is replicated throughout the forest. Users will be able to use the new classification the next time they connect to Exchange. We can retrieve the details of the classification with the Get-MessageClassification cmdlet. For example:

Get-MessageClassification -Identity 'Top Secret'

ClassificationID            : 7387906a-20fe-49e9-bedf-6a637f104b93
DisplayName                 : Top Secret: Eyes Only
DisplayPrecedence           : Medium
Identity                    : Default\Top Secret
IsDefault                   : True
Locale                      :
RecipientDescription        : This message contains Top Secret information that must not be
shared outside the company: Do Not forward!
RetainClassificationEnabled : True
SenderDescription           : This message contains Top Secret information that must not be
shared outside the company
UserDisplayEnabled          : True
Version                     : 0

Localized message classifications

The message classification that we just created will work for all languages, but let’s assume that we have to support a group of French users. We can create a separate message classification for French that includes translated or localized text that Exchange will provide to clients connected to mailboxes that have French listed as a supported language. When we create the French version of the “Top Secret” message classification, we identify it as a localized version by including the locale parameter. For example:

New-MessageClassification -Name 'Top Secret' -DisplayName 'Top Secret: Eyes Only'
-SenderDescription "Ce message contientl'informationextrêmementsecrète qui ne doit
pas êtrepartagée en dehors de la compagnie"
-RecipientDescription"Ce message contient l'information extrêmement secrète qui ne
doit pas être partagée en dehors de la compagnie : N'expédiez pas !" -Locale 'fr-FR'

If you use the Get-MessageClassification cmdlet to list the message classifications known to Exchange after creating the localized version, you won’t see the localized version listed because the cmdlet only returns classifications for the default language. To retrieve details of a localized classification, you have to pass its identifier. For example, in this instance we need:

Get-MessageClassification -Identity 'fr-FR\Top Secret'

Client access to message classifications

Because Outlook Web App reads in message classification data each time it creates a new session, assuming that Active Directory replication is working smoothly, new or updated message classifications are available to Outlook Web App clients the next time that they connect to a server. The situation is less satisfactory for Outlook because you have to instruct Outlook to read in classification data from a location with registry keys. Because of the difficulty of distribution of updates to all clients in a reliable and robust manner, it is bad news for administrators any time that you have to customize Outlook through registry keys.

Access to message classifications from Outlook Web App is very straightforward. When you create a new message, you can click the Restriction icon (envelope overlaid with a red Access Denied sign) to see the set of classifications available within the organization. The top screen shown in Figure 15-38 shows four available classifications. The No Restriction classification is the default value that Exchange applies to message if the user doesn’t select an explicit classification. The Do Not Forward classification is in fact the default AD RMS template. We discuss AD RMS in detail very soon.

Figure 15-38 Using message classifications with Outlook Web App.

The important point that comes through here is that if you use AD RMS and message classifications, you have to make sure that you use a naming convention that clearly identifies message classifications and templates to users. The problem here is that we have an AD RMS template called “Top Secret – Eyes Only” and a message classification called “Top Secret: Eyes Only”. The poor users won’t know what to choose without clear direction and some help through the naming convention. Let’s assume that this is a very clever user, so he knows that the “Top Secret: Eyes Only” classification is the one he wants. When you select a classification, Exchange displays the text defined in the classification’s SenderDescription property. The bottom screen in Figure 15-38 shows how the text for the message classification is displayed. Much the same happens when the message is delivered except that the text is taken from the RecipientDescription property (Figure 15-39).

Figure 15-39 Recipient text displayed by Outlook Web App for a message classification.

Making message classifications available to Outlook 2007 and Outlook 2010 clients is a multistage process. You have to do the following:

1. Export the message classifications from Active Directory to an XML file. Exchange provides the Export-OutlookClassification.ps1 script for this purpose. Run the script to output the XML file as follows:

   Export-OutlookClassification.ps1 > c:\Temp\Classifications.XML

2. The XML file contains information about the message classifications that are currently known to Exchange and establishes the set of classifications that are available to Outlook. It must be regenerated each time you make changes to classifications or add or delete classifications. The XML content for a classification looks like this:

   <Classification>
   <Name>Top Secret: Eyes Only</Name>
   <Description>This message contains Top Secret information that must not be
   shared outside the company</Description>
   <Guid>7387906a-20fe-49e9-bedf-6a637f104b93</Guid>
   <AutoClassifyReplies />
   </Classification>

3. Each Outlook client must be separately enabled to use message classifications. This is done by updating the system registry to instruct Outlook to enable classifications and where to find the XML file that describes the available classifications. A suitable registry update file for Outlook 2010 is shown here. Change “14.0” to “12.0” in the first line to create an update file for Outlook 2007 clients. The three values instruct Outlook where to find the XML file, enable message classifications, and assert that the classifications placed on messages are trusted by the Exchange organization. Exchange 2003 supports a different form of message classification so you should set this registry value to 0 (zero) for users who still have their mailboxes on an Exchange 2003 server.

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

4. The next time Outlook starts it discovers that classifications are enabled and attempts to read in the XML file. If the XML file is unavailable for some reason (for example, the server that hosts the share is offline or Outlook is working offline and can’t contact the server), Outlook won’t be able to add classifications to messages. If you want classifications to be available all the time, you can either distribute the XML file to every PC so that it is available locally or you can put it in a network share and use the Windows offline files feature to synchronize the file so that it is in the local files cache and therefore available even when offline.

All of the steps just described are reasonably straightforward to accomplish on a single computer. Things get messy when you have to ensure that every computer in a large organization has access to the XML file and receives updates after they are made available in a reasonably guaranteed manner. Once this is done, probably through a mixture of group policies and offline file synchronization, you are ready to use message classifications with Outlook clients.

See Chapter 16, “Rules and Journals”, for an example of how to use the Top Secret message classification in a transport rule that stops messages marked with this classification from going outside the organization.