Programming4us
         
 
 
Applications Server

Exchange Server 2010 : Designing and Implementing Message Classifications (part 2)

12/1/2010 9:13:31 AM

1. Dependencies of Message Classification

Active Directory and the messaging client used are the main dependencies of message classification in Exchange Server 2010; we'll go over each of these in turn in the following sections.

1. Active Directory Configuration Container

As with all Exchange Server 2010 configurations, message classifications are stored in Active Directory; in particular, in the Configuration container in the path Configuration/Services/Microsoft Exchange/<Organization>/Transport Settings/Message Classifications/<Locale>. The classifications can be verified using ADSI Edit (ADSIEdit.msc), as shown in Figure 4.

Figure 4. Message classifications in Active Directory

1.2. Messaging Client

The other primary dependency for Exchange Server 2010 message classifications is the messaging client. As stated earlier, classifications are set by the message sender on outgoing messages in Outlook 2007, Outlook 2010, and Exchange Server 2010 Outlook Web App and are viewable by recipients only in those same clients.

2. Creating Message Classifications in Exchange Server 2010

New-MessageClassification -Name Privacy -DisplayName "Privacy Act" -SenderDescription
"This message contains personal information as described by the Privacy Act"
-RecipientDescription "This message contains private information of clients as defined
in the Privacy Act"


The common parameters used when creating new or configuring existing classifications are listed in Table 2.

Table 2. Message Classification Common Parameters
CLASSIFICATION PARAMETERPARAMETER DESCRIPTION
DisplayNameThis parameter specifies the display name for the message classification. This display name is shown in Outlook 2007, Outlook 2010, and Outlook Web App; it is used to select the appropriate message classification before a message is sent. The DisplayName parameter must be 64 characters or fewer.
SenderDescriptionProvides an explanation to the sender what the message classification is intended to achieve. This is used by Outlook and Outlook Web App users to assist in selecting the appropriate message classification before sending a message. The SenderDescription parameter must be 1,024 characters or fewer.
RecipientDescriptionDisplays text to the recipient explaining what the message classification is intended to achieve. This is seen by Outlook and Outlook Web App users when a message with this classification is received. The RecipientDescription parameter must be 1,024 characters or fewer. If this parameter is not configured, the text set for SenderDescription is used.
LocaleThis parameter allows you to localize the message classification for different languages when a culture code is specified. You also must also specify the Identity parameter of the existing message classification when you create a new locale-specific version. Values for the Locale parameter are the string names listed in the Culture Name column in the Microsoft .NET Class Library class reference that is available at http://go.microsoft.com/fwlink/?LinkId=67222.
RetainClassificationEnabledSpecifies whether the message classification should persist with the message if the message is forwarded or replied to; the default value for this parameter is true.

2.1. Creating Localized Message Classifications

Localized versions of an existing message classification can also be created for accommodating multilingual organizations. Exchange Server 2010 determines the language of the recipient by examining the recipient's mailbox when a message is classified and sent. If a message classification in the corresponding language is found in Active Directory, the message has that classification attached to it by Exchange Server 2010. If there is no exact language match, Exchange examines the recipient mailbox's locale property to determine the locale of the recipient. In the event of no match for the specific locale of the recipient, Exchange Server 2010 looks for a version that is culture-neutral, such as es for es-MX, (Spanish-Mexico) or fr for fr-CA (French-Canada). Finally, the default message classification is used if no language-specific or culture-neutral match is found, regardless of its locale.

Localized message classifications are created with the New-MessageClassification cmdlet, using the Identity parameter to identify the existing classification and the Locale parameter to indicate the locale of the new classification. For example, to create a Spanish version of a message classification named Privacy, you would use the following cmdlet:

New-MessageClassification Privacy -Locale es-ES -DisplayName "España Example"
-SenderDescription "Este es el texto de la descripción"

3. Configuring Message Classifications for Outlook 2007 and Outlook 2010

After your message classifications have been created and configured, a few more steps are required to allow Outlook 2007 and Outlook 2010 users to be able to set message classifications. You must export the classifications from Active Directory to an XML file, and make this file accessible to the Outlook 2007 and Outlook 2010 clients. This is accomplished with the Exchange Server 2010 EMS script named Export-OutlookClassification.ps1; this script is located in the <install_drive>:\Program Files\Microsoft\Exchange Server\Scripts directory on the server running Exchange Server 2010.

After the classification XML file is exported, Outlook 2007 and 2010 clients not only require access to the file, but also require message classification to be enabled. This is done through the registry by creating the three values shown in the following example:

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

You must change the above registry key to [HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Policy] for Outlook 2010 clients. This Policy key is not present by default in Outlook 2007 or Outlook 2010, so it must be created. Table 3 outlines the registry values configured as well as the purpose of each.

Table 3. Registry Values for Outlook 2007 and Outlook 2010 Message Classifications
REGISTRY VALUEDESCRIPTION
AdminClassificationPathThis string value defines the location where the classification XML file is stored. This can be any location accessible to the Outlook 2007 client, including a network share.
EnableClassificationsTo enable message classification functionality for the specified user, set this DWORD value to 00000001. Message classification functionality is disabled by setting this value to 00000000.
TrustClassificationsTrustClassifications should only be enabled for Exchange Server 2010 users, and is enabled by setting this DWORD value to 00000001. Message classifications between users on Exchange Server 2003 are also supported by Outlook; because Exchange Server 2003 doesn't support or recognize message classifications, the content and validity of the message classifications is not guaranteed. In this case, disabling TrustClassifications prepends the text "The sender claims:" to the message classification. This prevents the recipients from assuming incorrectly that their organization has processed the classification. Disable TrustClassifications by setting this DWORD value to 00000000.


Note:

The message classification XML file exported from Active Directory must be distributed to Outlook 2007 and 2010 clients, and this presents some challenges about where to store the XML file so that it is accessible to these clients.

Storing the XML file in a local path on the client computer ensures that message classifications are available to the user when they are offline in cached mode; however, this means that the file needs to be distributed to and updated on all of the client computers—especially if classifications are modified or added/removed.

You can store the XML file on a network share so that it is maintained in only one location, but this presents challenges for those users working offline in cached mode—they will be unable to use the message classifications while working offline.

One solution to this challenge is to store the file on a network share and force that network share to be available offline for all connected users (using Windows offline files). This ensures that message classifications are available to end users at all times, while leaving only one file location to maintain. When offline users connect to the corporate network again, any changes made to the XML file will be updated in their offline files cache.


4. Assigning Message Classifications with Transport Rules

As we've seen, with Exchange Server 2010 and supported messaging clients you can provide end users with the ability to assign message classifications to messages before they are sent. In addition to this, you can automatically assign classifications to messages using transport rules run by the Hub Transport role based on criteria you specify. As with any transport rules, conditions are defined for the rule and then an action is set for the rule to take when the conditions are met; in this case, applying a message classification. As a case in point, you could configure a transport rule to check for messages that contain a text pattern matching a Social Security number, then apply a message classification named Privacy Act to ensure compliance with regulatory and company policies.

Besides assigning classifications with transport rules, transport rules can also be created that act on messages that have already been classified. One example is to prevent any messages classified Company Internal from leaving the organization; another example would be to apply IRM protection to messages classified Client-Attorney Privilege. What this all means is that even though message classifications are only visible in Outlook 2007, Outlook 2010, and Outlook Web App, your organization may still find them of value.

Other -----------------
- Exchange Server 2010 : Managing Public Folders
- Exchange Server 2010 : Managing Outlook Web App Themes
- Exchange Server 2010 : Managing Details Templates
- Exchange Server 2010 : Managing Address Lists
- Exchange Server 2010 : Managing Address Policies
- Exchange Server 2010 : Designing and Implementing AD RMS Integration (part 5) - Configuring AD RMS Super Users
- Exchange Server 2010 : Designing and Implementing AD RMS Integration (part 4)
- Exchange Server 2010 : Designing and Implementing AD RMS Integration (part 3) - Transport and Journal Report Decryption
- Exchange Server 2010 : Designing and Implementing AD RMS Integration (part 2) - AD RMS and Exchange Server 2010
- Exchange Server 2010 : Designing and Implementing AD RMS Integration (part 1) - Overview
- Exchange Server 2010 : Multi-Mailbox Search (part 2) - Performing a Multi-Mailbox Search
- Exchange Server 2010 : Multi-Mailbox Search (part 1) - Litigation Hold
- BizTalk Server 2009 : Consuming WCF services without orchestration
- BizTalk Server 2009 : Consuming WCF services from orchestrations
- BizTalk Server 2009 : Exposing WCF services from schemas
- Active Directory Domain Services 2008: Exclude an Attribute from Directory Service Auditing
- Active Directory Domain Services 2008: Configure Auditing on Object Security Access Control Lists
- Active Directory Domain Services 2008: Disable the Detailed Directory Service Replication Auditing Subcategory
- Active Directory Domain Services 2008: Enable the Detailed Directory Service Replication Auditing Subcategory
- Active Directory Domain Services 2008: Disable the Directory Service Replication Auditing Subcategory
 
 
Most View
- Developing an SEO-Friendly Website : Keyword Targeting (part 3)
- Exchange Server 2010 : Fundamentals and Components of Federated Delegation (part 4)
- iPad SDK : Displaying Multiple Videos
- Exchange Server 2010 : Managing Web and Mobile Access (part 1) - Enabling and Disabling Outlook Web App Features, Configuring Ports, IP Addresses, and Host Names Used by Web Sites
- Processing and Storing Data in SQL Server 2005 : Data Tracking Validation
- SharePoint 2010 : Installing Windows PowerShell
- Overview of Process Management in Microsoft Visio 2010 (part 2) - New process flow templates
- Windows 7 : Reviewing the Control Panel Icons
- iPad SDK : PDF Generation
- Exchange Server 2010 : Manage Outlook Client Access (part 2) - Configure Automatic Client Configuration & Configure Access for Third-Party Clients
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS