Policies in Exchange are designed to enable flexible administration of large numbers of Exchange objects. A policy is a collection of configuration settings that can be applied to one or more Exchange objects of the same class. This blog post gives an overview of Exchange 2007 policies: E-mail Address Policy (EAP), Exchange ActiveSync mailbox policy, Unified Messaging (UM) mailbox policy, and managed folder mailbox policy. Policies available in Exchange 2003 that are removed or changed in Exchange 2007 are also covered.

E-mail Address Policy (EAP)

EAP defines the proxy addresses that are stamped onto recipient objects. In Exchange 2007, every EAP must link to an existing accepted domain object. This is required so that e-mails sent to e-mail addresses defined by the EAP can be routed by Exchange 2007 transport servers. The relationship between EAP and accepted domains in Exchange 2007 and is covered in my recent post Recipient Policies and Accepted Domains.

Manage E-mail Address Policies

In the Exchange Management Console, the E-mail Address Policies tab of the Hub Transport node under the Organization Configuration work center is the place to create and configure e-mail address policies. If multiple policies apply to the same recipients, the policy with the highest priority (the lower the priority number, the higher the priority) takes precedence over any matching policies with a lower priority.

The PowerShell tasks used to manage e-mail address policies are <verb>-EmailAddressPolicy.

How EAP Enforces E-mail Address for Associated Recipients

The E-Mail Addresses property page of a recipient in the console allows management of recipient e-mail addresses. You can select whether to automatically update the e-mail address for this recipient based on e-mail address policies by checking or/unchecking the "Automatically update ..." checkbox at the bottom of this property page.

If a recipient is configured to automatically update the e-mail addresses based on e-mail address policy, all primary e-mail addresses (default reply addresses) of e-mail address types will always be set from the e-mail address policy. If you try to edit the primary address to a different e-mail address, it will always revert to the one specified by the e-mail address policy. Which policies applying to a recipient are up to the filtering rules of the policies.

The PowerShell command line to configure a mailbox to automatically update the e-mail addresses based on EAP is:

Set-Mailbox <mailboxid> -EmailAddressPolicyEnabled:$True

The command line to configure automatic update of e-mail addresses based on EAP for another type of recipient is similar.

Removal of Recipient Update Services (RUS)

In Exchange 2003, RUS is used to update e-mail addresses for recipients. This service processes e-mail address policy in an asynchronous way, which can be unreliable and unpredictable. Exchange 2007 doesn't rely on RUS to update e-mail addresses any more, instead it uses a predictable, synchronous e-mail provisioning process. Once an e-mail address policy is changed, the e-mail addresses for all associated recipients are updated synchronously.

See Evan's Top Exchange 2003 Recipient Problems and how they're fixed in Exchange 2007 and Goodbye RUS posts for a more detailed cover of removal of RUS in Exchange 2007.

Exchange ActiveSync mailbox policy

With Exchange 2007, you'll be able to create multiple Exchange ActiveSync (EAS) mailbox policies to have more control for mobile deployments. Exchange 2003 SP2 first introduced EAS policies; however Exchange 2003 can only create only a single global policy which applies to all users not specifically excluded. Exchange 2007 EAS policies are per-user policies, so you can create as many policies as needed to meet your company's security requirements.

Manage EAS Policies

In the console, the Exchange ActiveSync Mailbox Policies tab of the Client Access node under the Organization Configuration work center is the place to create and configure EAS policies.

The PowerShell tasks for managing EAS policies are <verb>-ActiveSyncMailboxPolicy.

Apply an EAS policy to a Mailbox

Each mailbox can have zero or one ActiveSync mailbox policy applied. Below is the console GUI to associate an ActiveSync mailbox policy to a mailbox.

An example PowerShell command line to assign an EAS policy to a mailbox is:

Set-CASMailbox <mailboxid> -ActiveSyncMailboxPolicy (Get-ActiveSyncMailboxPolicy "Corporate Mobile Policy").Identity

Unified Messaging (UM) mailbox policy

UM is a brand new feature introduced in Exchange 2007. UM mailbox policies are required when you enable users for Unified Messaging, as these policies control the association between UM mailbox and UM dial plan. You can also use UM mailbox policy to apply a common set of policies or security settings (such as PIN policies, dialing restrictions, etc) to a collection of UM-enabled mailboxes.

Manage UM policies

In the console, the UM Mailbox Policies tab of the Unified Messaging node under the Organization Configuration work center is the place to create and configure UM mailbox policies.

The PowerShell tasks for managing UM policies are <verb>-UMMailboxPolicy.

Apply an UM policy To a Mailbox

When you enable a mailbox for UM through the Enable Unified Messaging wizard, a UM policy is required. Below is the console GUI to associate a UM mailbox policy to a mailbox.

The PowerShell command line to assign a UM mailbox to a mailbox is:

Enable-UMMailbox <mailboxid> -UMMailboxPolicy "dp1 Default Policy" -Extensions 12345

Or if the mailbox is already UM-enabled:

Set-UMMailbox <mailboxid> -UMMailboxPolicy "dp1 Default Policy"

Managed folder mailbox policy

Managed folder mailbox policies are used for messaging records management (MRM), a.k.a e-mail lifecycle (ELC), in Exchange 2007. Managed folder mailbox policies collect managed folders into logical groupings. When a managed folder mailbox policy is applied to a mailbox, the managed folders and their settings linked to the mailbox policy are applied to the mailbox in a single step.

A blog post Records Management in Exchange Server 2007 and Outlook 2007 in 5 Easy Steps covered specifically how Exchange 2007 can help with MRM.

Manage Managed Folder Mailbox Policies

In the console, the Managed Folder Mailbox Policies tab of the Mailbox node under the Organization Configuration work center is the place to create and configure managed folder mailbox policies.

The PowerShell tasks for managing managed folder mailbox policies are <verb>-ManagedFolderMailboxPolicy.

The PowerShell command line to assign a managed folder mailbox policy to a mailbox is:

Set-Mailbox <mailboxid> -ManagedFolderMailboxPolicy "Inbox folder policy"

Policies in Exchange 2003 That Are Removed or Changed

System Policy

This has been removed. Refer to an earlier post Gone but not forgotten for a more detailed explanation.

Mailbox Manager Recipient Policy

This has been removed. The mailbox manager recipient policy is one kind of recipient policies in Exchange 2003, which is gone in Exchange 2007. This concept is replaced by managed default/custom folder, managed content settings and managed folder mailbox policy concepts in Exchange 2007, which is covered in the previous managed folder mailbox policy section of this post.

E-mail Address Recipient Policy

Changed. E-mail address recipient policy in Exchange 2003 has been separated into EAP and Accepted Domain concepts in Exchange 2007 which was covered in the E-mail Address Policy (EAP) section of this post.

- Jared (Ji-Chao) Zhang 

There are 2 ways that Exchange Server 2007 UM is integrated with your OOF.  The first is from the telephone using Outlook Voice Access (OVA) and the 2^nd is from the desktop using Outlook or Outlook Web Access (OWA):

1. By using logging into OVA, you can change your telephone greeting to an Out-of-office greeting and you can also turn on your E-mail out-of-office auto-replies if you forgot to do this in Outlook or OWA.

• To do this, log into Outlook Voice Access and Say "Personal Options" at the main menu, and then Press 1 to turn on telephone OOF greeting.  Follow the prompts to record your telephone OOF greeting, then you will be offered option of pressing "1" to also turn on your Email OOF auto-replies.  UM will put standard text in your out-of-office auto-reply message that indicates you are out of the office.
• Similarly, you can turn off your telephone out-of-office greeting and email auto-replies using the same menu options.

2. By using Outlook or OWA, you can change the telephone greeting played to callers when you are out of office.

• To do this in Outlook, go to Tools > Options > Voicemail.  Click on the "Out of Office voice mail greeting" radio box under "Choose the greeting to play to callers."

• If you want to listen to the greeting or change it, click on the "Call" button and enter a phone number for the system to call you.  When you pick up the phone, you will hear the existing greeting and can record a new one.
• To restore the greeting to your normal greeting, click on the "Voice mail greeting" radio button instead.
• To do this in OWA, go to Options > Voicemail.  Click on the "Play Out of Office voice mail greeting to callers" radio button (please click on the following thumbnail to see the full screenshot):

• If you want to listen to the Out-of-office greeting or change it, click on the "Call the Play on Phone Number to Play or Record a Greeting..." link and wait for the system to call you on the Play on Phone number above.  When you pick up the phone, you will hear the existing greeting and can record a new one.
• To restore the greeting to your normal greeting, click on the "Play voice mail greeting to callers" radio button instead.

- David Fong

NOTE: This article has also been published in the official Exchange 2007 documentation. We recommend that you check the documentation for the most up-to-date version. Please see the following links:

• Planning Processor Configurations -http://technet.microsoft.com/en-us/library/aa998874.aspx
• Planning Memory Configurations -http://technet.microsoft.com/en-us/library/bb738124.aspx 
• Planning Server Role Ratios -http://technet.microsoft.com/en-us/library/bb738159.aspx

Introduction

When selecting hardware for your Exchange servers, there are many things that you must consider. Two of the most critical resources are processor and memory.

This article, an update to an article original posted on 3/13/2006 as well as updated article posted on 11/27/2006, provides processor & memory guidelines for minimum, recommended and maximum recommended configurations. There are several factors that go in to choosing the right hardware for an Exchange 2007 deployment. This article provides rule of thumb guidance on the primary factors which determine the proper memory and processor configuration for a given Exchange 2007 role. In separate articles we will cover other critical pieces to Exchange 2007 sizing such as storage and network hardware. Additional guidance will be provided as available throughout the Exchange Server 2007 development process.

Exchange 2007 server hardware requirements are different than previous versions of Exchange (2003)

The primary hardware difference between Exchange 2003 and Exchange 2007 is the move from a 32-bit platform (Exchange 2003) to a 64-bit platform (Exchange 2007). Exchange 2007 will only be supported in production environments when it is running on an x64 edition of Windows Server 2003 (Note: The Exchange 2007 Admin only installation is supported for production when using both the x64 and x86 versions of the software running on their respective processor platforms). The change from a 32-bit platform to a 64-bit platform requires a new approach to choosing server hardware for Exchange; especially processor and memory:

Processor types supported by Exchange 2007

Exchange 2007 is only supported in production when the following are true:

• Running the x64 version of Exchange 2007
• Running on Windows 2003 x64 Editions
• Running on x64 compatible processors

The following processors support x64 versions of Windows 2003, thereby supporting Exchange 2007 deployments:

• AMD Opteron
• Intel Xeon processor with Intel® EM64T

Each of these vendors also ship x64-capable desktop processors which can also run x64 versions of Windows 2003 (e.g. AMD Athlon64 and Intel Pentium D with EM64T) but for the sake of simplicity, this article will concentrate on processors designed for server deployments.

It's important to note that the Intel Itanium (IA64) processor will not work with Windows 2003 x64 Editions, and thus it will not work for Exchange 2007 deployments. Exchange 2007 is designed to run only on x64 capable processors such as those listed above; Exchange 2007 will not run on Itanium based systems.

Regardless of which server processor you select, it is necessary to have the server product pass the Designed for Windows test suite to ensure Microsoft support. Servers listed on the Windows Server Catalog meet these criteria. If your server is not listed, check with your vendor to see if either the "Designed for Windows" logo testing is in progress or the server has passed the testing and is pending a website update.

Multi-core processor considerations for Exchange 2007

Exchange 2007 benefits significantly when running on multi-core processors. The performance benefit for Exchange from dual-core technology depends upon the specific processor utilized. The findings from Exchange 2003 dual-core testing have been summarized in Microsoft Knowledge Base article 827281, CPU and memory scalability for Exchange Server 2003 and for Exchange 2000 Server.

Multi-core processors are an attractive option for Exchange 2007 servers based on price and performance. Please ask your server vendor about dual-core benefits for Exchange, specific to a given hardware architecture.

Hardware specific memory considerations for Exchange 2007

Exchange 2007 enables much better memory utilization than Exchange 2003 due to its 64-bit architecture. Because of the virtual address space limitations of a 32-bit platform, Exchange 2003 is limited to using 4 GB or less of physical memory. In contrast, customers running Exchange 2007 on Windows 2003 x64 Editions can efficiently utilize upwards of 32 GB of memory (Mailbox role). Note: 32 GB is not a physical limitation, rather the most cost-efficient current maximum memory configuration. Depending upon the number of memory slots in a server, this cost-efficient maximum memory configuration could be even less than 32GB (e.g. 16GB). This change needs to be factored in when choosing server hardware. The following factors should be considered:

• Server Maximum Memory Configuration - Different server architectures have different memory limits. We recommend that you check the following technical specifications of the server to determine the criteria that affect the maximum memory configuration to ensure that the appropriate amount of RAM can be installed in to an Exchange 2007 server economically:
  • Memory Speed - Some server architectures require slower memory to scale up the memory to ten's of gigabytes in a given server (e.g., maximum server memory is limited to 16GB with PC3200 or 32GB using PC2700). You should check with the manufacturer to make sure that the memory configuration target for Exchange 2007 is compatible in terms of speed.
  • Memory Module Size - What is the largest memory module size the server will support? Generally, the larger the memory module, the more expensive it is; 2x1GB DDR SDRAM memory modules generally cost much less than 1x2GB DDR SDRAM memory modules. When planning for an Exchange 2007 server, make sure the maximum memory module size allows you to meet your target memory requirements.
  • Total Number of Memory Slots - How many memory modules will a given server support? The total number of slots multiplied by the maximum memory module size will provide the maximum memory configuration for the server. Also, keep in mind that memory modules must sometimes be installed in pairs.

Applying the processor and memory configuration factors to specific Exchange 2007 server roles

The following chart can be used to assist in purchasing server hardware destined to be used for Exchange 2007 server roles. The goal of this chart is to provide minimum, recommended and recommended maximum configurations.

Minimum: The minimum processor/memory configuration suitable for specific Exchange 2007 server roles (also defined in System Requirements). Minimum hardware requirements must be met to receive Microsoft Product Support Services.

Recommended: This is the recommended processor/memory configuration for specific Exchange 2007 server roles. Recommended can be defined as "the best configuration based on price and performance." The recommended configuration also provides a balance between processor and memory capacity. The goal is to match the memory configuration to the processor configuration so the system will effectively utilize the processors without becoming bottlenecked on memory and vice versa.

Maximum: This is the maximum recommended processor/memory configuration for specific Exchange 2007 server roles. Maximum is defined as "the upper bound of viable processor/memory configurations for Exchange 2007 based on price and performance." Maximum is a guideline and not a "support criteria" and does not take in to account the resource requirements of 3^rd party applications. The recommended maximum may change over time based on price changes and technology advancements.

Processor Configuration Table for Exchange 2007

** Processor Core recommendations are based on the following processor revision: AMD Option 275 2.2GHZ dual-core

• www.spec.org ratings may be used to rationalize unlike processors/server configurations.

Edge Transport Role

Edge transport is extremely efficient in design and thus requires moderate processing power. Also, fault tolerant Edge Transport deployments will utilize multiple servers to provide redundancy. The Recommended configuration on 2 x Processor Cores takes this fault tolerant deployment consideration in to account. Large enterprises, with a large volume of inbound/outbound SMTP traffic will be able to utilize 4 x Processor Core servers to reduce aggregate Edge Transport server count. Processor utilization is based on several factors such as: message rate, average message size, number of agents enabled, anti-virus configuration, 3^rd party applications etc.

Hub Transport Role

The recommended configuration for Hub Transport is 4 x Processor Cores in deployments where Hub Transport is deployed along with several Mailbox servers and thousands of mailboxes. 8 x Processor Core servers can be efficiently utilized when message hygiene is configured on the Hub server (A/V, Anti-Spam). 1-2 x Processor Core configurations can be considered for deployments where there are not enough mailboxes (message traffic) to utilize a 4 x Processor Core configuration. Processor utilization is based on several factors such as: message rate, average message size, number of agents enabled, Forefront Mailbox Virus Scanning configuration, 3^rd party applications etc.

Client Access Server Role (CAS)

Exchange 2007 architecture has moved significant client specific functions from the Microsoft Exchange Store to the Client Access Server. Messages are now converted on the CAS server when accessed with non-MAPI clients (e.g. POP3/IMAP4). Also, Outlook Web Access rendering is now performed on the CAS server as opposed to the Mailbox Store in previous versions of Exchange. These architectural changes allow CAS to offload significant processing from the Mailbox role and to allow it to effectively utilize 4 x Processor Cores. Similar to Hub Transport, servers with 1-2 x Processor Cores can be utilized for CAS in deployments where there are not enough mailboxes/non-MAPI client traffic to utilize 4 x Processor Core servers.

Unified Messaging Role (UM)

The recommended configuration for the Unified Messaging role is 4 x Processor Cores. Multiple Cores are well utilized on the UM server for several architectural functions such as Voicemail WAV to WMA conversions. Similar to previous roles, 1-2 x Processor Core configurations may be utilized when the mailbox count/UM utilization does not necessitate 4 x Processor Core configurations.

Mailbox Role

The recommended configuration for the Mailbox role is based predominantly on mailbox count and user profile. A 4 x Processor Core server provides a good balance between price and performance and should be able to host several thousand mailboxes. Rule of thumb sizing for the Mailbox server role requires an understanding of the average client user profile. This profile can be collected using the Microsoft Exchange Server Profile Analyzer or with 3^rd Party tools/applications. The following table lists generic/common Outlook knowledge worker profiles:

There are several factors that go in to doing Mailbox server sizing for Exchange 2007 which are above and beyond the user type listed above. These include Exchange 2007 features such as Local Continuous Replication (LCR), Forefront Mailbox Virus Scanning, 3^rd Party applications, 3^rd Party mobile devices, and Microsoft Outlook client version/mode (Online vs Cached Exchange Mode etc.). Rule of thumb sizing used primarily for budgeting purposes can be accomplished by calculating that 1000 Averageprofile mailboxes will require 1 x Processor Cores. E.g. A 4000 Mailbox server with an Average usage profile can be estimated to require 4 x Processor Cores. A Heavy usage profile will effectively double the required processor cycles (or halve the number of users per processor core;500 Mailboxes/Processor Core). On the other hand, a 2000 Mailbox server with an Average profile can be estimated to require a 2 x Processor Core server. The maximum number of processor cores the Exchange 2007 Mailbox role will efficiently utilize is eight. Deploying Exchange 2007 Mailbox on servers with greater than eight cores will not provide significant scalability improvements.

*** Concurrency: Concurrency is defined as the percentage of the total number of users on a server that are connected and using the server at a given peak period of time. Concurrency is difficult to measure since users may use multiple clients/devices and different versions of Outlook have various connection counts to the server. For a fully utilized server, concurrency is generally in the 75-80% range. The guidance in this article assumes this average concurrency profile.

Sizing additional processing capacity for Local Continuous Replication (LCR)

Local Continuous Replication (LCR) has all of the Exchange 2007 Mailbox role services as well as the Exchange 2007 Replication Service running on the same server. On an LCR Mailbox server, there is additional processing overhead generated from the Replication Service copying and playing in logs to the target database copy. This additional processing cost is roughly 20% and should be factored in when sizing LCR Mailbox servers.

Multi-Role (Mailbox, Hub, CAS)

The Multi-Role configuration has similar guidance and limitations as the Mailbox role. To accommodate CAS and Hub Transport utilization on a single server with the mailbox, reduce the 1000 Mailboxes/core calculation based on the Average client profile by 20% (800 Mailboxes/core) when performing rule of thumb sizing for Multi-Role servers. The maximum recommended processor core configuration is listed at 4 for the Multi-Role configuration to indirectly provide guidance on the maximum number of users recommended to be hosted in this scenario. Neither Clustered Continuous Replication (CCR) nor Single Copy Cluster (SCC) support hosting the Hub nor CAS server so a Multi-Role server has to be non-clustered by definition. It is a good idea to cluster Mailbox servers that host thousands of user to ensure patch management and server failures do not have a significant impact on up time. The more users hosted on a Mailbox server the more user "pain" is caused by server downtime. For this reason, the recommended maximum processor core configuration for the Multi-Role server is listed at 4. While the this configuration will perform well up to 8 processor cores, it is not recommended due to the availability concerns outlined above.

Memory Configuration Table for Exchange 2007

Once the number of processor cores have been estimated to be required per server role are understood; baseline memory recommendations can be applied. The following table illustrates the Minimum, Recommended and Maximum memory configurations for Exchange 2007 server roles.

Edge/Hub Transport Roles

The Edge and Hub Transport roles do not require substantial quantities of memory to perform well in optimal conditions. Generally, 1GB of RAM per processor core (2GB minimum total) is sufficient to handle all but the most demanding loads/scenarios. There is one significant memory factor that should be taken in to account for large deployments:

Large Queue Scenarios: Exchange 2007 Edge/Hub Transport servers are designed to handle scenarios where extremely large queues build up (e.g. 1 million messages in a single server queue). Edge/Hub Transport servers hold the queued message recipient information in memory to optimize the SMTP send and message retry operations. When sizing Edge/Hub Transport servers for large queue scenarios, use the following table to estimate the memory requirements:

The recommended maximum memory configuration of 16GB is based on the Edge/Hub Transport servers handling 1 million messages with an average number of recipients each. Most deployments will be optimally configured with the "Recommended" memory configuration of 1GB per processor core (2GB minimum total).

Client Access Server Role (CAS)

In general, memory utilization on Client Access servers has a linear relationship with the number of client connections and the transaction rate. Based on the current recommendations for processor and memory configurations, a Client Access server will be balanced in terms of memory and processor utilization, and it will become processor bound at approximately the same time it becomes memory bound.

Mailbox Role

The memory configuration process for the Mailbox role is more involved than the other roles since the optimal memory configuration depends upon the mailbox count and the client profile (similar to estimating processor core requirements). Memory sizing for the Mailbox role is critical to reducing the I/O requirements of the server. The more memory you add to the Mailbox server, the less I/O will be generated by the Exchange databases. There is a point of diminishing returns; in which adding additional memory to the server may not be justified based on price/performance. Memory guidance outlined here takes this point of diminishing returns in to account based on current memory prices and performance metrics. Also, defining the memory configuration of the Exchange 2007 Mailbox server is required prior to defining the storage requirements/configuration. The following table can be used to assist in estimating the memory requirements of a given mailbox server with a given number of hosted mailboxes with a given profile type (taken from previous profile table).

Recommended Maximum Memory Configuration for Mailbox

Recent x64 based servers have the ability to scale up their memory configuration to 64GB and beyond. There are several reasons why Microsoft does not recommend maximum memory configurations for Mailbox that go beyond 32GB.

Cost: Based on current memory prices (specifically 4GB DIMMs), it is cost prohibitive to expand the physical memory capacity of a server beyond 32GB. Generally, the cost of physical RAM is linear up to 32GB; beyond this the cost trend is exponential. Beyond 32GB, for many configurations, it is less expensive to add disk drives as opposed to memory.

Non-Transactional I/O: The Mailbox server utilizes additional physical RAM by caching more data and thus reducing the database I/O footprint for transactional I/O (I/O that is generated by send/receive/client processing of email). There are several sources of non-transactional I/O generated on the Mailbox server. These include Online Maintenance (e.g. Online Defrag), Offline Maintenance (e.g. offline defrag, database repair operations), Backup/Restore operations, Mailbox Management Processes (e.g. Messaging Records Management (MRM)), All of these operations require database I/O to properly maintain and recover the server. Although Exchange 2007 has reduced transactional I/O significantly; adequate storage performance is still required for proper maintenance of the Mailbox server. For this reason, there is a point of diminishing returns when adding memory to the server. In general, the purpose of adding memory to the Exchange Mailbox server is to reduce the storage requirements (specifically performance) and thus storage cost. Due to non-transactional I/O requirements; the storage requirements of the system may not be significantly reduced by adding server memory beyond 32GB.

Cold State Operation: Cold state is defined as the state of the Mailbox server immediately following a server reboot or store.exe process restart. The Database Cache, which is used to cache database read/write operations, is small in size (or "cold") during this period so it has a significantly diminished ability to reduce read I/O operations. As the Mailbox server processes messages, the Database Cache Size grows which increases the effectiveness of the cache and subsequently reduces the I/O footprint of the server. The larger the physical memory size of the server the longer it takes the Database Cache size to reach its optimal size. If the storage is designed/sized for a server with a large amount of physical RAM (>32GB), and the I/O profile of the users assumes an optimal Database cache state (large/warm cache); then the client experience may be compromised due to insufficient disk performance during these "cold state" periods. Similar to the Non-Transactional I/O case; the storage subsystem requirement may be the same for a server that has been populated with 32GB of RAM as a server that has been populated with greater than 32GB of RAM.

While the Exchange 2007 Mailbox role will utilize memory greater than 32GB, for the reasons outlined above; 32GB is the maximum recommended memory config and is considered the point of diminishing returns in terms of both cost and performance.

Required Minimum Memory Configuration for Mailbox based on the number of Storage Groups

The maximum number of Storage Groups configurable in Exchange 2007 has been increased to 50 in the Enterprise Edition (up from 4 with Exchange 2003). This increase provides much greater flexibility in server/storage architecture, but the increase has a significant effect on the memory utilization of the Exchange 2007 Mailbox server so Storage Group count is now a factor in minimum memory configuration for Mailbox and Multi-Role servers. Increasing the number of Storage Groups primarily effects the Database Cache utilization of ESE (Extensible Storage Engine). The ESE Database Cache is used for both read and write activity. Due to the way Checkpointing works, adding a Storage Group effectively increases the amount of the Database Cache used for write activity. This has a positive impact of reducing database write I/O; but if too many Storage Groups are configured on a server with insufficient physical memory, the effectiveness of the database read cache may be reduced which may have an overall negative effect on the performance of the server. For this reason, minimum hardware requirements for Mailbox and Multi-Role uses the following table to provide specific minimum memory requirements based on Storage Group count configured on a per server basis.

*** This table includes the 2GB minimum memory requirement. Mailbox and Multi-Role Server configurations must meet the requirements outlined in the above table to receive Microsoft support.

The minimum physical memory requirements based on SG count closely match our recommendations on memory sizing based on mailbox count and profile (detailed above).

Example 1: A 4000 user Mailbox server with a heavy user profile would calculate out to 22GB of RAM (2048MB+ (4000*5MB)). Based on the above support requirements, the administrator will have the flexibility to use up to 44 Storage Groups. Additional RAM would be required to deploy greater than 44 Storage Groups based on the above supportability requirements.

Example 2: A 1000 user Mailbox server with a light user profile would calculate out to 4GB of RAM (2048MB+(1000*2MB)). Based on the above support requirements the administrator will have the flexibility to use up to 8 Storage Groups. Additional RAM would be required to deploy greater than 8 Storage Groups based on the above supportability requirements.

Memory Recommendations for Local Continuous Replication (LCR)

Local Continuous Replication (LCR) has all of the Exchange 2007 Mailbox role services as well as the Exchange 2007 Replication Service running on the same server. The Exchange 2007 Replication Service will work well on a LCR server based on the provided memory guidance but to ensure that the ESE Database Cache maintains optimal efficiency under LCR, it is recommended to provision an additional 1GB of physical RAM to Exchange Mailbox and Multi-Role servers (above and beyond the memory guidance listed above).

Multi-Role (Mailbox, Hub, CAS)

Guidance and limitations similar to the Mailbox server role apply to multiple server role configurations. To accommodate the Client Access and Hub Transport server roles on the same server as the Mailbox server role, the recommended base memory configuration is 8 GB. Memory guidance based on mailbox count and profile is the same as the Mailbox server role. The recommended maximum amount of memory is 32 GB.

Neither cluster continuous replication (CCR) nor single copy cluster (SCC) supports hosting the Hub Transport or Client Access server roles in a failover cluster. A multiple role server is non-clustered by definition. It is a good idea to cluster Mailbox servers that host thousands of mailboxes to ensure that server maintenance or failures do not have a significant impact on uptime or availability.

The minimum memory requirements based on the number of storage groups listed in the preceding table apply to multiple role server configurations, including configurations that contain the Mailbox server role.

Server Role "Rule of Thumb" Ratio Recommendations

Once optimal server role processor/memory configurations have been finalized, the next logical sizing task is to make a rough prediction of how many server roles of each type are required for your deployment. As with any sizing exercise, every environment is different; so these recommendations should be considered starting points that can then be tailored to specific environments. The recommendations are also based off of Microsoft's own Exchange 2007 deployment with the following characteristics:

The recommended "Rule of thumb" ratio for each role is based on processor cores (like our other guidance in this document), since it is common for roles to have vastly difference processor core counts. Also, the Mailbox server role is the basis for the process core ratios. Hub and CAS roles relate back the Mailbox role with regard to the rule of thumb recommendation.

These recommendations have the following caveats:

General:

• Ratio is a "rule of thumb" and may not be valid for every topology (not a support requirement or hard and fast rule).
• Ratios can change dramatically based on user profiles. E.g. A profile that creates correspondingly more load against the Mailbox role than the Hub role will increase the Mailbox:Hub ratio; and vice versa.
• This guidance follows Microsoft's internal Exchange deployment for Mailbox servers which is based on the ~500 "Heavy" users per processor core.
• Ratio assumes Mailbox role servers are +60% processor utilized during peak period with corresponding processor utilization on Hub or CAS.
• Processors used on Mailbox role and Hub/CAS roles are of same type and speed.
  • www.spec.org ratings may be used to rationalize unlike processors/server configurations.
• A minimum of two Hub and two CAS servers should be deployed for redundancy to ensure uninterrupted service in case of planned or unplanned server downtime.
• The Exchange 2007 Management Pack for MOM 2005 SP1 combined with the Performance Troubleshooter, built in to the Exchange 2007 Management Console; can be used to determine when/if a given deployment requires additional Hub, Edge, CAS or Mailbox server roles based on performance. This method can be used to fine tune the server role ratios for a specific deployment.

Hub:

• Hub ratio rule of thumb where A/V is enabled assumes Forefront A/V with five engines scanning.

CAS:

• CAS ratio rule of thumb assumes SSL is enabled for all appropriate access protocols.

It is not possible to provide Edge and UM ratios since their utilization are not directly tied to the Mailbox server role. UM server sizing is covered in Determining the Number of Users an Exchange 2007 Unified Messaging Server Can Support. Edge server sizing is covered next.

Edge Server Sizing

Determining Edge server count is based off the following key factors during peak period:

• Connections/sec
• Messages/sec
• Avg. Message Size

Sizing is based on the number of connections/messages processed with Avg. message size being a secondary factor. Since every SMTP connection does not translate in to an SMTP message and every message initially accepted does not make it passed IMF/Anti-Virus scanning; it is very difficult to provide a simple sizing methodology based on message rate. Edge utilization will depend on several factors that are very specific per individual deployment. The following table can be used, however, to get an understanding of Edge's performance characteristics based on Microsoft's own internal Exchange 2007 deployment:

** Based on a 2 socket, dual-core AMD Opteron 275 2.2 GHz based server.

• A minimum of two Edge servers should be deployed for redundancy to ensure uninterrupted service in case of planned or unplanned server downtime.

In the above example, a significant percentage of the server processing can be associated with the overhead of analyzing connections and scanning accepted messages. For this reason, it is not possible to provide a sizing metric based solely on the number of messages sent/received per second since blocking spam/viruses is a significant processor utilization function of the Edge role.

Summary

With effective planning and an understanding of the basic processor and memory requirements for specific Exchange 2007 server roles, a balanced/cost effective topology can be easily attained.

- Matt Gossage

Share this post :

What is a Dialing Rule

Dialing rules are created to modify a phone number before sending it to the PBX for outbound calls. Dialing rules serve two purposes:

1. Specify the numbers that can be dialed as outbound calls internal or external. Administrators specify the number format that can be dialed and any number that do not fall into any specified dialing rule are rejected. Dialing rules act a "white-list" for outbound calls.

2. Modify the number before sending it out to the PBX. Dialing rules will strip numbers from, or add numbers to telephone numbers. Often times this is done to add the 'Trunk Access Code' to external numbers. This is also done to add or remove 'in country' code for long distance or local numbers.

A caller can make outbound calls from the UM server in the following manner:

● Play on phone feature

● Call someone from directory search (accessed from Pilot Number or 'Contact Someone' menu option)

● Call someone from auto attendant directory search

● Call someone from personal contact

The number format for the phone number will not be the same for all of these scenarios. Dialing rules can be used to modify the user's input to a format that meets telephone system requirement.

Dialing Group

Dial group is a collection of one or more dialing rules. Dial groups allow administrators to organize similar rules into one group. The 'name field for each dialing rule actually specifies the name of the 'dialing group' that the rule belongs to. Multiple rules can have same name, which makes them part of the same dialing group. For example, lets say we created one dialing rule named 'local' for area code '704', and another one, also named 'local' for area code '980'. Both these dialing rules will belong to the same dialing group called 'local'.

Unified Messaging server has 2 kinds of dialing groups – 'In country or region' for calls within the country or region and 'International' for international calls.

Syntax for creating Dialing Rule

Dialing rule consists of 4 fields – name, number mask, dialed number, and comment. The 'comment' field is optional. The 'name' is the name of the dialing group. The 'number mask' is the number that the user dials and the 'dialed number' is the number that is sent by the UM server to the VOIP Gateway or IP-PBX. Following are the syntax to create dialing rules:

1. For each rule, specify a name, 'number mask', and 'dialed number'. Wild cards can be used for 'number mask' and 'dialed number'.

2. Wild card 'x' can be used to designate any number between 0-9. The number of 'x' should match the number of digits of the phone number. For example, when creating a rule for all the numbers in the 425 area code you can write 425xxxxxxx to indicate that it is a 10 digit number.

3. Wild card '*' can be used to designate any number or numbers. When this wild card is used it does not have to be matched with the number of digits. For example, to include all the numbers within area code 425, the format 425* can be used.

4. When two rules have same specification but one uses "x" as a wild card and the other one uses "*" as a wild card, the one with "x" will take precedence. For example, the rule with '425xxxxxxx' will take precedence over the rule with '425*'.

Dial Group and Dialing Rules in Unified Messaging

For Exchange 2007 unified messaging, dialing rules are configured within the dial plan scope. Each dial plan has 2 parameters called 'ConfiguredInCountryorRegionGroups' and 'ConfiguredInternationalGroups'. These parameters act as a repository for dialing rules for 'in country' and 'international' calls respectively. After configuring the dialing rules in these parameters, they can be applied within the scope of UM Mailbox Policy object, or UM Auto Attendant object or the Dial Plan object.

In the following example, we are typing in management shell command to query all the configured rules within the dial plan 'CorpDialPlan'.

PS] C :\> (get-umdialplan corpdialplan).configuredInCountryorRegionGroups

In this example, there are three dial groups – 'local' and 'low-rate' and 'long-distance'. The fields 'NumberMask' and 'DialedNumber' comprise the actual dialing rule. The dial group 'local' has two rules, the first rule, removes the 'in-country' prefix '1' from all numbers that start with area code '704'. The purpose of this dialing rule is to make sure all numbers with area code '704' are treated as local calls. The other rule works the same way for area code 980.

Creating Dialing Rules

Prior to setting the rules on outbound calls, you have to create the rules and load them in the dial plan. Within the dial plan there are 2 parameters called 'ConfiguredInCountryorRegionGroups' and 'ConfiguredInternationalGroups'. These parameters act as a repository for all the dialing rules. After storing the dialing rules in these parameters, you can apply them on a UM object such as Dial Plan, UM Mailbox Policy or Auto Attendant through the 'AllowedInCountryorRegionGroups' and 'AllowedInternationGroups' parameter. When setting values for these two parameters only refer the dialing groups by name.

Example:

Set-UMDialPlan CorpDialPlan –AllowedInCountryorRegionGroups low-rate

Lets take a look at the rules in table 1, there are 3 rules or entries, for dialing groups 'low-rate'. When you apply the 'low-rate' dial group, all three rules within this group will be used for outbound dialing when 'low-rate' is applied.

Steps to set Outbound Dialing Rules

There are two steps involved in setting the dialing rules:

1. First step is to load dialing rules in the dial plan. You can use the Exchange Management Console to create and store the rules. You can also create a CSV file with all the rules and then load them to the dial plan object using Exchange Management Shell Command.

2. Second step, is to apply one or more rules to a UM object. Rules can be applied to dial plan, or UM Mailbox Policy, or Auto Attendant object. UM Mailbox Policy and Auto Attendant have to be linked to the dial plan where you stored the rules. The rules are referred by the 'dialing group' name as the values for the 'AllowedInCountryorRegionGroups', or 'AllowedInternationalGroups' parameter.

Step 1: Storing the rules in Dial Plan Object

In this step you will store all the dialing rules in the dial plan. They will be stored in the 'ConfiguredInCountryorRegionGroups' parameter for the 'in country' dialing rules and 'ConfiguredInternationalGroups' parameter for international dialing rules.

Using Exchange Management Console

Following are the steps to load dialing rules using Exchange Management Console:

1. Open the properties of the 'Dial Plan' object and go to the 'Dialing Rule Groups' tab (figure 2).

2. Click on the 'Add' button and a new window 'Dialing Rule Entry' will pop-up (Figure 3).

3. Add the name of the 'dialing group', 'number mask' and 'dialed number' for a dialing rule. The 'comments' field is optional.

4. If you are adding a rule to an existing dialing group then first select the dialing group from the 'name' drop down list and then add rest of the fields.

Dialing Rule Groups tab in Dial Plan properties

Dialing Rule Entry Page

Using Exchange Management Shell

You can use the 'set' command to load the rules in the 'ConfiguredInCountryorRegionGroups' parameter. If you have a large number of rules you may want to import the rules from a CSV file.

Loading Rules using 'set' command

You can load each rule individually using the 'set' command –

Set-UMDialPlan "DialPlanID" –ConfiguredInCountryorRegionGroups "Local,91704*,9704*,local calls"

After running this command the 'ConfiguredInCountryorRegionsGroups' attribute will have one entry.

Following set of commands can be used for adding a new rule to these parameters -

$DialGroup= (get-UMDialPlan "DialPlanID").ConfiguredInCountryorRegionGroups

$DialGroup.add("local,91980*,9980*,local calls")

Set-UMDialPlan "DialPlanID" –ConfiguredInCountryorRegionGroups $DialGroup

After running this command the 'ConfiguredInCountryorRegionGroups' attribute for dial plan 'DialPlanID' will have following two entries:

Name,NumberMask,DialedNumber,Comment

Local,91704*,9704*,Local calls

Local,91980*,9980*,Local calls

Importing rules from CSV file

You will create the rules in a CSV file based on the instruction in the following section and then import the CSV file within the dial plan. Following is the command:

Set-UMDialPlan "DialPlanID" –ConfiguredInCountryorRegionGroups $(IMPORT-CSV c:\dialrules\incountry.csv)

In this example the data in the incountry.csv file will populate the 'ConfiguredInCountryorRegionGroup' parameter of Dial Plan in the AD.

In order to retrieve all the data from the 'ConfiguredInCountryorRegionGroup' attribute, use the get command and export the data in csv file:

(Get-UMDialPlan –id "DialPlanID").ConfiguredInCountryorRegionGroups | EXPORT-CSV C:\incountry.csv

Create CSV File

You need to create a file with all the dialing rules in correct format before loading it on dial plan. Following are the guidelines in creating the CSV file –

• First line of the csv file must include the names of the field – name, numberMask, DialedNumber, comment. The field names are separated by comma and there should not be any space between them.
• Each line in the CSV file represents one entry. Each entry will have four fields which are separated by 'comma', these fields are - Name, Number Mask, dialed number and comment. The comment field is optional.
• There should not be any space between the text entry and the comma for next field.
• Do not put any blank lines in between the fields or the rows.
• Do not have any blank lines at the beginning or end of the CSV file.

Following is an example of 'in country' dialing rules CSV file:

Name,NumberMask,DialedNumber,Comment

Low-rate,91425xxxxxxx,9xxxxxxx,Local call

Low-rate,9425xxxxxxx,9xxxxxxx,Local call

Low-rate,9xxxxxxx,9xxxxxxx,Local call

Any,91*,91*,Open access to in-country numbers

Long-distance,91408*,91408*,long distance

Following is an example of 'international' dialing rules CSV file:

Name,NumberMask,DialedNumber,Comment

International, 901144*, 901144*, international call

International, 901133*, 901133*, international call

Step 2: Applying Dialing Rules to UM Objects

After loading the rules in the dial plan repository object you need to apply the rules to make them effective. You can apply the rule in the following UM objects:

Dial Plan

In the previous step you have uploaded the rules to the dial plan. The rules have populated 'ConfiguredInCountryorRegionGroups' and/or 'ConfiguredInternationalGroups' attributes of the dial plan. Each rule belongs to a dial group and when you apply the settings, you can specify the rule only by the name of the dial group.

You can apply the dialing rule at 'Dial Plan' level by using Exchange Management shell commands, this feature is not available EMC. After you have loaded the rules in the dial plan you can run the following command to apply the rules at dial plan level:

Set-UMDialPlan "MyDialPlan" –AllowedInCountryorRegionGroups "low-rate","local"

After running this command, all the rules within these two dialing groups will be set as the "allowed groups" within the dial plan.

UM Mailbox Policy

When you configure restriction on UM Mailbox Policy, the rule applies to all the users within the policy.

You can use the following command to set the rule for a policy:

Set-UMMailboxPolicy MyUMPolicy –AllowedInCountryorRegionGroups "Low-Rate"

If you want to allow multiple groups then you have to include them all in the command, the 'set' command does not append entries, it only replaces it.

Example:

Set-UMMailboxPolicy MyUMPolicy –AllowedInCountryorRegionGroups "low-Rate","long-distance"

You can also use the Exchange Management shell to set the restrictions.

Adding Dialing Rules to a UM Mailbox Policy:

Follow these steps:

1. Open the properties page of the UM Mailbox Policy

2. Go to the tab 'Dialing Restrictions'

3. Click the 'Add' Button to add the allowed groups

Auto Attendant

You can set restrictions on "in country" or 'International" dialing groups for any auto Attendant. These rules will take into affect when an anonymous caller calls the Auto Attendant pilot number. You have to specify the name of the 'dial group' that is configured on the dial plan. For Example, if you created an Auto Attendant called 'CorpAA' which is linked to 'CorpDialPlan' then you can specify the groups that are already configured on the dial plan 'CorpDialPlan'. In the following example there is a 'dialing group' called "low-rate" configured in the dial plan that 'CorpAA' is linked to. You have to apply the rule using the following Exchange Management shell command:

Set-UMAutoAttendant CorpAA –AllowedInCountryorRegionGroups "low-rate"

Similarly, for international groups you can run the following command:

Set-UMAutoAttendant CorpAA –allowedInternationalGroups "call-Japan"

When the command executes it will set the values for AllowedInCountryorRegionGroups for the Auto Attendant to all the entries for "low-rate" dialing group.

Order of the Rules

Order or priority of the rules will determine how they are going to be applied. All the dialing rules are stored as dialing groups in the 'AllowedInCountryorRegionGroups' parameter and they are referred by the dialing groups. The order is determined in 2 cycles. The rules are sorted out first from most specific to least specific and then they are applied from top to bottom. Following is the detailed information:

1. The rules sorted out from 'ConfiguredInCoutryGroups' repository field of Dial Plan, based on the ones that are mentioned in the 'AllowedInCountryorRegionGroups' field. For example,

PS] C:\> (get-umdialplan corpdialplan).ConfiguredInCountryorRegionGroups

PS] C:\> (get-umdialplan corpdialplan).AllowedInCountryorRegionGroups

Low-rate

In this example, for the 'ConfiguredInCountryorRegionGroups' we have three dialing groups – 'local', 'low-rate', 'long-distance' and in the 'AllowedInCountryorRegionGroups' you have one entry – 'low-rate'. First, all the rules for dialing group 'low-rate' are sorted out.

2. After gathering the rules in step 1, the rules are sorted so that the number mask is from most specific to the least specific. For example if you have following 3 rules:

Name,NumberMask,DialedNumber,Comment

Low-rate,9425xxxxxxx,9xxxxxxx,Local call

Low-ratel,91425xxxxxxx,9xxxxxxx,Local call

Low-rate,9xxxxxxx,9xxxxxxx,Local call

After sorting it will look like:

Name,NumberMask,DialedNumber,Comment

Low-rate,91425xxxxxxx,9xxxxxxx,Local call

Low-rate,9425xxxxxxx,9xxxxxxx,Local call

Low-rate,9xxxxxxx,9xxxxxxx,Local call

3. After sorting in step 2, the rules are applied from top to the bottom of the list to the number that is entered by the user and apply the one that is the first match. So for the example, in step 2, if a user enters '94253334444' as a 'Play on Phone' number, the second rule from the list will be applied and the number that will be sent out by UM server to the PBX is '93334444'.

Context of Rule Application

From the above discussion, dialing rules can be set at dial plan level, or Auto Attendant level or UM Mailbox Policy level. Following table illustrates how they are applied –

- Seema Rahman

Unified Messaging provides the functionality of having voice mail, email and fax to a single location that is the user's mailbox. In Exchange 2007 Unified Messaging the fax feature is limited to inbound fax only. Which means that, an external or internal caller can call to the UM server and leave a fax message for a user with Exchange 2007 mailbox. A user can receive fax in their mailbox the following manner:

1. A user can have a specific extension for fax. Their mailbox will have a corresponding secondary UM extension (eum type proxy address) which is dedicated to fax.
2. Users have a single number for both Voice mail and Fax. The caller can send faxes to the voice mail extension. Should users pick up the phone, they can either transfer the call to their own extension, or hang up to let the fax machine resend.
3. Users can have a shared mailbox dedicated to fax messages. The fax message in this case has to be manually forwarded to its destination or via custom application.

Protocol for Fax

UM supports T.38 protocol for fax media. The signaling information is sent by the VOIP endpoints (gateway or IP-PBX) as SIP over TCP. UM relies on the VOIP endpoints to detect the fax tone and take appropriate action in handling the media.

Configuring the Fax Feature in UM

The default configuration on Unified Messaging is already set for receiving fax. Which means the dial plan, the user and the UM server are all by default, Fax enabled.

A UM enabled user account has a parameter called 'FaxEnabled' which determines whether the user is enabled for fax or not. If this attribute is 'not set' then the user defaults to the settings of the dial plan.

The command for enabling fax for a dial plan:

Set-UMDialPlan –identity MyDialPlan –FaxEnabled $true

When you enable a dial plan for Fax all the users within that dial plan are enabled for fax unless user level attribute for fax is set to 'false'.

The duration of the fax call is impacted by the parameter 'MaxCallDuration' parameter of the dial plan. It is set to 30 minutes by default.

You can also configure fax on the UM mailbox level. You have to set the UM mailbox attribute 'FaxEnabled' to 'true' to enable the user to receive fax. After the user is fax enabled you can add a new proxy address of 'eum' type as an alternate number for fax or you can use the same number for voicemail and fax messages.

The command for enabling fax for a user:

Set-UMMailbox –identity UMUser1 –FaxEnabled $true

If the dial plan is configured for fax but a user's 'faxEnabled' attribute set to 'false', the user will not receive fax messages.

Configure Fax Attributes for a UM Server

This section explains how to use the Exchange Management Console and the Exchange Management Shell to configure the number of concurrent fax connections that are accepted by a Microsoft Exchange Server 2007 Unified Messaging (UM) server. The range of concurrent fax calls is 0 to 200, and the default value is 100.

You need to have exchange organization administrator permission to perform this operation.

Using Exchange Management Console

Following is the step by step procedure:

1. In the console root of the Exchange Management Console, expand the Server Configuration node, and then click the Unified Messaging node.
2. In the result pane, click to select the UM server you want to configure.
3. In the action pane, click Properties.
4. On the UM Server Configuration tab, under the Maximum concurrent fax calls section, in the data field, type the maximum number of concurrent fax calls.
5. Click OK.

Using Exchange Management Shell

Following is the command:

Set-UMServer -Identity UMServerName -MaxFaxCallsAllowed 100

Configure Fax attribute for UM Mailbox Policy

You can configure couple of settings in the UM Mailbox Policy to customize the fax that the user's receive.

Adding Fax ID

You can add fax identifier for all incoming Fax by editing the UM Mailbox Policy. The parameter is 'faxId'. By default the value is set to 'Microsoft Exchange'

Following is the command:

Set-UMMailboxPolicy –identity MyUMPolicy –FaxId "Fax Service"

Adding a default message

You can add a default message for all incoming Fax by editing the UM Mailbox Policy. This message is added within the body of the email message that has the fax message. The parameter is 'faxMessageText'

Following is the command:

Set-UMMailboxPolicy –identity MyUMPolicy –FaxMessageText "This Fax is received by UM Server."

Fax Call Flow to UM server

The fax call flow to UM server is very similar to the voice mail call flow. For details go to:

http://technet.microsoft.com/en-us/library/bb123887.aspx

Fax Message in the client

Fax message will arrive as email message with fax message as an (tif) attachment. After receiving the fax message from the gateway, UM server will treat the message the same way as with voice mail message. The message will look like the following screen shots in the client machine, Outlook or OWA client:

- Seema Rahman

The Unified Messaging component of Exchange 2007 SP1 is the designed to be the voice mail solution for Office Communications Server 2007 (OCS). What it means is that anyone can dial an Office Communications Server user and leave a voice mail which will then be delivered to that user's Outlook inbox. The integration of Office Communication Server 2007 and Exchange 2007 Unified Messaging will take users closer to the vision Microsoft has for Unified Communications.

http://www.microsoft.com/presspass/exec/jeff/06-26-06UnifiedCommunications.mspx

For an enterprise with Office Communications Server 2007, the integration of Unified Messaging (hence Exchange 2007) will give enterprise users the added benefit of having e-mail, voice mail, and fax messages consolidated in their inbox. Moreover, certain voice mail features can now be accessed using Office Communicator clients. The Unified Messaging role must be deployed with Exchange 2007 service pack 1 to support this integration.

In an integrated environment when a call to a person is not answered (busy, ring no answer, or diverted to voice mail) it gets routed to the Unified Messaging server (UM). The front end server role of OCS (or the Director) is responsible for processing and routing the call to the UM server.

Clients for OCS can be one of the following:

• Office Communicator (OC)
• OC qualified IP phone device

These clients are also known as Unified Communications Clients or UC Clients. Any user in Active Directory (AD) will have to be enabled and configured for voice capability to talk to the OCS server. The same client will also have to be enabled for Unified Messaging to divert their missed call to the UM server.

Common Scenarios

Following are some of the common scenarios where a call will route through OCS as well as UM. In each of these scenarios the users are enabled for Office Communications as well as Unified Messaging.

Divert to Voice Mail

User A calls User B, who does not answer. The call is then diverted to the UM server by OCS. Exchange UM plays a greeting previously recorded by User B, after which User A records a message. User B receives the voice mail message in their e-mail inbox with contextual information (additional contact information, phone numbers, title) provided in the body of the voice mail message. Callers can are identified through Active Directory or from User B's personal address book in Outlook. Finally, Outlook and Outlook Web Access both display this message along with an embedded player to play the voice message.

Subscriber Access

User A logs on using Office Communicator and selects the option to call voice mail. Since the user is already authenticated through Office Communicator, UM will not require the user to enter their PIN. Exchange UM will play the prompts for voice mail, e-mail, and calendar in Outlook Voice Access, all of which is pulled from User A's mailbox. User A selects to listen to their voice mail.

Auto-Attendant

User A does not know User B's direct line or extension, so User A calls the public access number for User B's organization. User B is connected to the Exchange UM Automated Attendant, which offers various options, including a corporate directory. User A says User B's name verbally, which is recognized by the Automated Attendant and User A's call is transferred to User B's extension in the organization.

Better Together

Integration of OCS and UM gives users a seamless experience to communicate across their entire organization. A UC client has the option to do instant messaging, audio-video conversations, conferencing, and access to all UM functionality from their UC client.

The following are some of the key features of this experience:

• Provides a single authentication method – A user who has logged into Office Communicator does not need to enter their PIN when they check their voice mail from the Office Communicator interface.
• Maintain subject name and priority - An OC user can add subject and priority when making a call. If the call gets diverted to UM, the subject is added to the subject line of the message containing the voice mail or the missed call notification. Additionally, the priority of the original call is maintained by UM in the auto-generated notification for missed calls or new voice mails.
• Integrated missed call notifications - When a call is missed by the receiving party, UM will generate an e-mail notification for the missed call and place it in the inbox for the receiving party.
• Both missed calls and voice mails show the name and contact information for the calling party user. This information is retrieved through Active Directory or from the called party user's personal contact list.
• Traversing the firewall - Media streams can be traversed through the corporate firewall securely without complicated configurations.
• High fidelity voice quality - UM now supports high fidelity codecs for voice mail recording and play back.

E.164 Number Format

The format of the telephone number associated with the UC-enabled user is E.164 (example: +19805551234). Therefore, if a user enters a number that is in different format (example: extension 1234) it has to be manipulated into the E.164 format. OCS will take this number and search the corporate directory to find the user who has a matching number and then voice mail will be routed to the correct user. OCS uses normalization rules to translate these number formats and uses an internal translation service to perform canonicalization transformation. Stay tuned for future blog post on this topic.

A Simple Scenario

In this scenario User A makes a call to user B using Office Communicator. User B does not answer and the call is forwarded to voice mail. User A hears the mailbox greeting and leaves a voice mail for User B.

Call Flow

The following is the call flow for the above scenario:

1. When User A makes a call to User B, the request is first sent to the OCS front end server as a SIP INVITE. OCS will first try to find the target user (User B) in AD and determine whether User B is OC-enabled. If the user is OC-enabled, the call will be forwarded to the registered SIP endpoint for User B. OCS will send the request as a SIP INVITE.
2. If User B does not answer the call, a response message will be sent back to OCS server indicating that User B did not answer the call.
3. OCS will query AD to find out if User B is UM-enabled, and if so, will extract out information such as their proxy address, dial plan name, and the UM server(s) assigned to the dial plan. OCS will use its routing logic to determine the appropriate UM server to route the call to.
4. A new INVITE request will be sent to the UM server by the OCS server. In this new INVTIE request, User B's SIP address will be added as a diversion header indicating that this is a voice mail call for User B.
5. A new session will be created between OCS and UM. OCS will exchange media information with UM and indicate that the RTP end point is the IP address of User A. After media negotiation is done, UM will establish a RTP session with User A and play prompts for leaving a voice mail. User A will directly communicate with UM and leave a voice mail for User B.
6. The remainder of the communication remains the same for any Exchange 2007 environment. After the voice mail is received by UM, it will be handed it off to a hub-transport server which will in turn route the voice mail to the user's mailbox on the appropriate mailbox server.

Conclusion

This blog post is a high level introduction to Exchange UM and OCS 2007 integration. It does not cover calls routed to and from the PSTN via OCS, which is also supported in UM-OCS scenarios. Office Communications Server 2007 deployment scenarios can expand cross-forest and resource forest and Exchange 2007 Unified Messaging is supported in complex deployment scenarios as well. For deployment scenarios and more information refer to the Office Communications Server 2007 documentation:

http://technet.microsoft.com/en-us/library/bb676082.aspx

- Seema Rahman

I have learned (via William) that there is a limited time offer of a free Exchange Server 2007 Unified Messaging course that you can take online if interested.

From the course page:

Title: Clinic 5091: Introduction to Microsoft Exchange Server 2007 Unified Messaging
Course Type: Self-paced Course
Available Offline: Yes
Estimated Time of Completion: 2 Hours
Language: English

Description:
In this online clinic, you are introduced to the new Unified Messaging features and functionalities in Exchange Server 2007. In addition, you learn how telephony and Unified Messaging can be integrated in Exchange Server 2007. This online clinic is composed of a rich multimedia experience. It is intended for IT Professionals who are interested in telephony or Unified Messaging.

At this time I do not know how long this will be available for free but I figured some of you might like it!

- Nino Bilic

Microsoft IT has published a white paper about their rollout of Exchange Server 2007 Unified Messaging (UM).  This is a good resource for those who enjoy technical detail and are curious about real-world UM implementations!

Using Exchange Server 2007 for Unified Messaging and Fax

What is the best way to implement the Unified Messaging (UM) features of Microsoft Exchange Server 2007?  Discover how Microsoft IT uses Unified Messaging to integrate voice messaging with an internal e-mail messaging environment. In this white paper, we detail the technical implementation and deployment strategy for rolling out Exchange 2007 Unified Messaging features in the Microsoft enterprise messaging environment. Learn what UM features and functions are deployed at Microsoft, why UM is a compelling service to offer Microsoft employees, and the design issues to consider when planning to integrate Exchange Server 2007 with an existing PBX infrastructure in your own organization.

Please note that the following is also available as part of this release:

• Technical Case Study
• PowerPoint Presentation
• IT Pro Webcast

- Nino Bilic

Via the Office Communications Server blog:

Join Bill Gates and Jeff Raikes as they kickoff the worldwide Unified Communications Launch 2007 in San Francisco on October 16, 2007.  This free, day-long event includes a keynote with demos, a series of technical sessions, the Unified Communications Starter Kit (kit includes a FREE copy of the full version of Office Communications Server Standard Edition and Office Communicator 2007, a value of over $500) and a partner pavilion.  See how Microsoft solutions will help streamline communications between people and organization regardless of medium, platform, device or location.

Click here to register and use the following registration code: UCLTBL18

- Kevin Engman

Today Bill Gates and Jeff Raikes (my boss) launched Office Communications Server 2007 (OCS), and announced that Exchange Server 2007 SP1 will be available in the 4th quarter of this year. Here is a long list of enhancements within SP1 – but given the occasion today with OCS, I figure it's worth digging into the "better together" story between Exchange 2007 and OCS a bit here.

Exchange 2007's advanced unified messaging capabilities are a viable replacement for your existing voice mail system today. It's been great to see so many customers realizing this benefit this year. The Tracy Unified School District in northern California went from a traditional voice mail system to Exchange Unified Messaging for e-mail and voice mail.  This move initially saved them $168,000 in licensing costs and will continue to save them $126,000 annually in maintenance, support, and licensing.

OCS can be added to these Exchange 2007 deployments to offer a "unified communications" experience, integrating presence, IM, email, voice, and video. For example, OCS lights up Outlook with rich presence and click-to-communicate features, and pulls from your Outlook calendar to inform your presence status.

With Exchange 2007 SP1, you can now retrieve voice mail messages from Communicator 2007 (the preferred client for OCS) with a single click. Also, certain OCS- and Communicator-qualified devices will be able to work with Exchange 2007 for additional functionality, like a new "message waiting" indicator that lets you know when you have a voice mail.

To me, this kind of integration highlights why our software-centric approach to Unified Communications is so compelling. Gartner would seem to agree. Check it out.

Magic Quadrant for Unified Communications, 2007 (Gartner, August 20, 2007): This Gartner Magic Quadrant by Bern Elliot evaluates leading vendors in the unified communications market. Gartner positions Microsoft in the Leaders quadrant. According to Gartner, "The Leaders quadrant contains vendors selling comprehensive and integrated UC solutions that directly, or with well-defined partnerships, address the full range of market needs."

SP1 will be available very soon, and as always, I look forward to your feedback.

- Terry (terry.myerson AT microsoft DOT com)
General Manager, Microsoft Exchange

Share this post :

Join Microsoft at INTERACT2008 - an exclusive event for key community influencers in the unified communications space. This event provides a unique opportunity for you to develop deep technical knowledge on Microsoft's unified communications products, build powerful new connections with leading professionals in the industry and gain insights into the future of converging technologies.

This exclusive invitation-only event is aimed at technology professionals who are evaluating, deploying and supporting unified communications in enterprise organizations. INTERACT2008 will provide one-on-one interaction with the technology leaders and developers for Microsoft® Office Communications Server 2007 and Microsoft Office Communicator, Microsoft Exchange Server 2007 SP1, Microsoft RoundTable^TM, Microsoft Office Live Meeting and Exchange Hosted Services.

This three-day event includes:

• More than 40 technical presentations including:
  • Planning Voice Architecture and Deployment in OCS 2007
  • Sourcing, Deploying and Managing Your UC Devices
  • Microsoft Unified Communications for Developers: Building Communications into Your Applications
  • Migration, Co-existence, and Deployment Strategies with Exchange Unified Messaging
  • Automating Exchange Server 2007 Deployments Using PowerShell
  • Additions to Exchange Hosted Services Directory Synchronization and Reporting Tools
• Hands-on labs to help you learn to deploy UC technologies end-to-end
• Chat sessions with INTERACT2008 presenters
• Birds of a feather sessions to connect on key unified communications topics
• Partner Expo hall to interact with and learn about third-party UC solutions

Don't miss this opportunity to get connected to a world of expert information and pioneering best practices, and to prepare for the future of unified communications.

Event agenda and registration can be found here:

https://www.interact08.com

Sign up today and save $200 on the price of the conference!

- Nino Bilic

Before you can install Exchange Server 2007 SP1 on a Windows Server 2008 there are varying prerequisites that need to be installed, depending on the Exchange 2007 Server role you plan on installing. Details on how to install those prerequisites manually can be found in the Exchange 2007 SP1 documentation:

How to Install Exchange 2007 SP1 Prerequisites on Windows Server 2008 or Windows Vista

In this blog post, we wanted to share a set of XML files that you can use to simplify the process of installing those prerequisites. Please see the attached ZIP file near the end of this post.

The following XML files are available:

Exchange-Base.xml - this will install the prerequisites that are common for majority of Exchange server roles. Note: To complete the installation, a reboot will be necessary. The reboot must be done before proceeding with the remaining Operating System prerequisites that are detailed below. If the AD management tools are not installed prior to installation of IIS 7 components, there are potential issues with IIS 7 configuration that can crop up as a result, hence the recommendation for a reboot.

Exchange-MBX.xml - this will install the rest of prerequisites that the Mailbox Server role requires.

Exchange-CAS.xml - this will install the rest of prerequisites that the Client Access Server role requires

Exchange-Edge.xml - this will install the rest of prerequisites that the Edge role requires.

Exchange-UM.xml - this will install the rest of prerequisites that the Unified Messaging role requires.

Exchange-ClusMBX.xml - this will install the rest of prerequisites that a clustered Mailbox Server role requires. When compared to the previously mentioned Exchange-MBX.XML, this XML file also installs Failover Clustering.

The Hub Transport Server Role requires no further Operating System prerequisites, other than what is already specified in Exchange-Base.xml.

To run those XML files and install the OS prerequisites you need, you should run the following from the CMD line:

ServerManagerCmd -ip <path>\<Exchange-role>.XML

So to put this into real life - if you wanted to install let's say the Mailbox server role, you would first run the Exchange-Base.xml followed by Exchange-MBX.xml.

Using those XML you can also test if correct Operating System prerequisites have already been installed. For example, let say I thought I had installed the clustered Mailbox Server prerequisites. I could run the following to verify:

ServerManagerCmd -w -ip <path>\exchange-clusmbx.xml

Note: Running in 'WhatIf' Mode.
Skipping [Web Server (IIS)] Web Server (IIS) because it is already installed on this computer.
Skipping [Web Server (IIS)] Basic Authentication because it is already installed on this computer.
Skipping [Web Server (IIS)] Windows Authentication because it is already installed on this computer.
Skipping [Web Server (IIS)] ISAPI Extensions because it is already installed on this computer.
Skipping [Web Server (IIS)] IIS 6 Metabase Compatibility because it is already installed on this computer.
Skipping [Web Server (IIS)] IIS 6 Management Console because it is already installed on this computer.
Specified for installation: [Failover Clustering]

This server may need to be restarted after the installation completes.

The above tells us that all the Operating System prerequisites have been installed, except for Failover Clustering. The remaining will be skipped, since they were installed sometime in the past. It does no harm to re-run the <Exchange-Role>.xml file if some of the prerequisites have already been installed, they will simply be skipped.

You can also quickly verify the OS components that have been installed by running:

ServerManagerCmd -q

Finally, you can download the XML files from here.

- Matt Richoux, Roman Maddox

I learned that there is a new UC user group being formed in Pacific Northwest area: Pacific Northwest Unified Communications User Group (PNWUCUG). Now, say that acronym 3 times fast! :)

Anyway, the group's site can be found here: http://www.ucdoers.org/. The inaugural meeting is on Wednesday, May 28, from 4:00PM to 8:00PM. From the site, here is what the group will do:

Our goal is to sponsor a variety of events and activities throughout the Pacific Northwest region, bringing you and your peers together with a variety of speakers and UC experts. For this first event, we're pleased to announce:

• Terry Myerson, Corporate Vice President of Exchange at Microsoft
• Eric Swift, Senior Director of Product Management for the Unified Communications Group at Microsoft
• Devin Ganger, Messaging Architect and Microsoft Exchange MVP at 3Sharp
• Martin Tuip, Business Development Manager and Microsoft Exchange MVP at Mimosa Systems

All of the information on how and where to go as well as how to connect using Microsoft Office LiveMeeting can be found here. Who said Wednesdays have to be boring?

- Nino Bilic

Introduction

We have been working on a problem that surfaced with the release of Exchange 2007 Rollup 5. A number of customers reported that some of their Exchange 2007 managed services did not start automatically after Rollup application, however they would start manually. In most of these cases the computer in question was not connected to the Internet. Investigation showed that the problem was the timing of the Windows Service Control Manager (SCM) and validation of all of the certificates associated with a service within the SCM timeout. In the case of computers that were connected to the Internet, the problem seemed to be network latency, as the problem in those cases can happen only intermittently.

Why this happens

To sum it up: the problem did not manifest itself until Exchange 2007 managed binaries were signed with two certificates (because the original one was expiring). For Exchange 2007 RTM this occurred when RU5 was released. Because now .Net Framework Common Language Runtime (CLR) attempted to validate two certificates by connecting to http://crl.microsoft.com, the process took longer, to the point where SCM timeout would pass and services would fail to start up automatically. In environments with limited or no Internet connectivity, this might fail every time. In other cases, this might fail intermittently based on current network state and load.

Workarounds

KB article 944752 Exchange 2007 managed code services do not start after you install an update rollup for Exchange 2007 is being revised to only contain the recommended workaround, which is to modify the services configuration files. The modification will to prevent the CLR from going onto the Internet in the first place. This is accomplished by adding a section to the managed executable configuration file as outlined in Bypassing the Authenticode Signature Check on Startup (MSDN .NET Security Blog, Shawn Farkas).

Security concerns

The first question that people usually ask about is if making the modification to .config files compromises server security.

In case of Exchange Server 2007, this is not relaxing security at all.  From a security point of view, what it's doing is saying "assume that the Authenticode signature is invalid."

Let's say that you have these three assemblies:

• An assembly without an Authenticode signature.
• One with an invalid Authenticode signature
• One with a valid signature that has this option set in the Configuration file

All three behave exactly the same.  The CLR will load them, and not give Publisher evidence to the assembly.  Since the assembly doesn't get the Publisher evidence, any trust decisions that were being made based upon the validity of the signature will no longer apply - so if the assembly is only trusted due to its signature it will lose its trust status due to the config switch.  Exchange 2007 assemblies however, do not use this mechanism as the only one to determine if the assembly should be run or not, so disabling it does not compromise Exchange.

To make this .config file modification

The resolution to this problem involves editing the configuration files associated with the Exchange Services to use a switch which was added to CLR 2.0 SP1 (which is by default present in .NET framework V3.5.) You can update .NET Framework 2.0 or 3.0 by installing the fix from http://support.microsoft.com/kb/942027/. That hotfix contains the fix outlined in http://support.microsoft.com/default.aspx/kb/936707.

Before continuing with this procedure, save a copy of your existing configuration files to a safe location. In the event of an error in the configuration file, the applicable service will fail to start.
Create configuration files for all managed code Exchange 2007 services to resolve this issue.Please note that we do not suggest going to create/modify the .config files unless your server is actually impacted by this problem.

To create an application configuration file that contains this configuration setting, follow these steps:

1. Create a file, and then name the file the <ApplicationName>.exe.config file.
2. In a text editor, open the file that you created in step 1.
3. Add the following code to the file:

<configuration>
  <runtime>
          <generatePublisherEvidence enabled="false"/>
  </runtime>
</configuration>

4. Save the changes to the file to the applicable directory (see below for a list of files and locations - the .config files should be saved into the same folder where the affected executable is).

If the configuration file already exists for a specific service, just add the "<generatePublisherEvidence enabled="false"/>" line to the runtime options section in the file.

Exchange 2007 Services/Apps which come with a .config file that might need to be updated:

Bin\EdgeTransport.exe
Bin\ExBPA.exe
Bin\ExBPACmd.exe
Bin\ExTRA.exe
Bin\Microsoft.Exchange.Cluster.ReplayService.exe
Bin\Microsoft.Exchange.EdgeSyncSvc.exe
Bin\Microsoft.Exchange.Monitoring.exe
Bin\Microsoft.Exchange.Search.ExSearch.exe
Bin\Microsoft.Exchange.ServiceHost.exe
Bin\MSExchangeMailboxAssistants.exe
Bin\MSExchangeMailSubmission.exe
Bin\MSExchangeTransportLogSearch.exe
ClientAccess\PopImap\Microsoft.Exchange.Imap4.Exe
ClientAccess\PopImap\Microsoft.Exchange.Pop3.Exe

Exchange 2007 Services for which you need to create a new .config file (unless it was already created for another reason):

Bin\Microsoft.Exchange.AntispamUpdateSvc.exe
Bin\MsExchangeFDS.exe
Bin\MSExchangeTransport.exe

Troubleshooting

If a service fails to start after modifying or creating the config files, the most likely reason is an XML syntax error or an incorrect value. In both of these cases the service will fail to start and you'll get an error similar to this example from the Exchange 2007 Edge Transport Service:

Event Type:      Error
Event Source:    MSExchangeTransport
Event Category:  Process
Event ID:        14004
Description:
The worker process has failed to load application configuration file: System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize ---> System.Configuration.ConfigurationErrorsException: The 'generatePublisherEvidence' start tag on line 4 does not match the end tag of 'runtime'. Line 5, position 6. (C:\Program Files\Microsoft\Exchange Server\Bin\edgetransport.exe.config line 5) ---> System.Xml.XmlException: The 'generatePublisherEvidence' start tag on line 4 does not match the end tag of 'runtime'. Line 5, position 6.
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.ThrowTagMismatch(NodeData startTag)
   at System.Xml.XmlTextReaderImpl.ParseEndElement()
   at System.Xml.XmlTextReaderImpl.ParseElementContent()
   at System.Xml.XmlTextReaderImpl.Skip()
   at System.Configuration.XmlUtil.StrictSkipToNextElement(ExceptionAction action)
   at System.Configuration.BaseConfigurationRecord.ScanSectionsRecursive(XmlUtil xmlUtil, String parentConfigKey, Boolean inLocation, String locationSubPath, OverrideModeSetting overrideMode, Boolean skipInChildApps)
   at System.Configuration.BaseConfigurationRecord.ScanSections(XmlUtil xmlUtil)
   at System.Configuration.BaseConfigurationRecord.InitConfigFromFile()
   --- End of inner exception stack trace ---
   at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
   at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors)
   at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey)
   --- End of inner exception stack trace ---
   at System.Configuration.ConfigurationManager.GetSection(String sectionName)
   at System.Configuration.ConfigurationManager.get_AppSettings()
   at Microsoft.Exchange.Transport.TransportAppConfig.GetConfigBool(String label, Boolean defaultValue)
   at Microsoft.Exchange.Transport.TransportAppConfig.ResourceManagerConfig.Load()
   at Microsoft.Exchange.Transport.TransportAppConfig.Load()
   at Microsoft.Exchange.Transport.Main.Program.Run(String[] args)

Additional information

We're continuing to investigate this problem and will provide more information as it becomes available.

- Ed Beck, Nino Bilic

Share this post :

Exchange 2007 was the first release of Exchange to include Unified Messaging (UM) and this was the first time many of our customers started considering replacing their existing voice mail systems with UM. As with any new technology, many have sent in questions or concerns regarding the legal implications of UM, and how to control the voice mail messages once they're inside Exchange.

If you aren't familiar with Exchange UM and the benefits it provides to both end-users and IT professions, please check out more information here: http://www.microsoft.com/exchange/evaluation/unifiedmessaging/default.mspx .

However, some companies have been hesitant to store voice mail and e-mail in the same system, fearing that it will create increased legal risk by making voice mails more "discoverable" or somehow less manageable. We got this initial feedback during our TAP and beta trials of Exchange, so we worked with the law firm of Covington & Burling LLP. They studied this problem and created a white paper to summarize their findings.

If you read through the white paper, you'll notice two things. First, the white paper concludes ".that no aspect of Exchange alters, by increasing or decreasing, the record retention obligations of these organizations in the U.S. or E.U. ." That is, if a company is obligated to retain voice mail messages, it doesn't matter if they're stored in Exchange 2007 UM or somewhere else - they still need to be retained. Likewise, if voice mail messages have been deleted in the normal course of business prior to an obligation to retain them, the fact they were in Exchange 2007 UM doesn't create a new obligation to retain where no obligation existed before.

Secondly, the white paper notes that Exchange 2007 Unified Messaging offers significant advantages for a company that may need to retain and produce voice mails. Features that were considered especially helpful included being able to visit a single system to access, query, and produce both voice mail and e-mail; and having a single repository (rather than multiple repositories) to apply retention policies.

The complete white paper is available here if you're interested: http://www.microsoft.com/exchange/evaluation/unifiedmessaging/dataretentionwp.mspx

There are additional benefits that Exchange 2007 Unified Messaging provides for companies seeking to reduce cost and increase flexibility in addressing e-discovery requirements. They fall into two categories:

1. Ensuring that voice mails are not retained beyond policy during the normal course of business.
2. Being able to quickly and easily retain voice mails to meet preservation obligations in the face of impending litigation.

For a good overview of our compliance features if you're not already familiar with them, check out the Exchanger Server 2007 Compliance Tour here: http://www.microsoft.com/exchange/evaluation/compliance/compliance-tour.mspx

Ensuring that voice mails are not retained beyond policy during the normal course of business:

To meet this first category of requirements, you can implement a transport rule and modify some settings to easily control how you retain voice mail.

1. Use a Managed Default Folders setting to automatically expire voice mails after X days. Also note that these policies can be applied differently at the user- or group-level, as well as for the entire organization.
2. Use Transport Rules to prevent voice mail being from being forwarded outside the organization, based on attributes Exchange automatically adds to a voice mail message:

1. Use Journaling settings to ensure that voice mail is not journaled to any external system. Additionally, in case you didn't know, Exchange does not journal voice mail by default. To change this setting or verify your existing settings, an administrators can use Set-TransportConfig or Get-TransportConfig cmdlets described here: http://technet.microsoft.com/en-us/library/bb201690(EXCHG.80).aspx
2. Use Exchange ActiveSync settings to prevent voice mails from being forwarded to Mobile devices. This policy is somewhat draconian, as it prevents all attachments from being forwarded to mobile devices, not just .wma files.
3. Customize the voice mail message template to remind users of the company policy about voice mail retention. Administrators can create a message of up to 512 characters that appears on every voice mail message using Set-UMMailboxpolicy -VoiceMailText, described here: http://technet.microsoft.com/en-us/library/bb124903(EXCHG.80).aspx

Ensuring that voicemails are retained to meet preservation obligations in the face of impending litigation:

Once you have Exchange retaining voice mail to be consistent with organizational policies, you may need to change that based on impending litigation.

1. Instantly implement a retention hold on an effected user's mailbox, using either the Set-Mailbox cmdlet or the EMC. The retention hold can be indefinite, or have a set start and end date. This command can also be combined with the Get-Mailbox cmdlet, allowing you to easily select an OU, etc.
2. Easily transcribe voice mails, by providing a text field right next to the "play" controls on the voice mail message where the end user can make notes. These transcribed notes are searchable with Exchange's full-text search engine, allowing the message to be quickly retrieved later.
3. Assist users in the process of identifying relevant information by providing a litigation-specific Managed Custom Folder. This could automatically create a folder in the end user's Mailbox, with a name like "Contoso Litigation" and a descriptive label, such as "Please store any and all email, voice mail, and faxes related to Contoso Litigation in this folder"
4. Easily export voice mails to another mailbox for review using the Export-Mailbox cmdlet with the -Subject "Voice Mail" parameter. This allows Exchange administrators to create separate accounts for the purpose of reviewing voice mails, while leaving the original messages in place.

In Summary: Exchange 2007 Unified Messaging does not change a company's obligation to retain voice mail. However, by using Exchange UM, organizations will find it easier to control voice mail. It will also be easier to implement a retention policy that applies to e-mail, voice mail, and fax messages. Should it become necessary to prepare for litigation, Exchange 2007 Unified Messaging reduces the cost of accessing, querying, and producing voice mail.

- Chris Chalmers
  TECHNOLOGY SPECIALIST

Share this post :

One of the core functionalities provided by Exchange UM is call answering, i.e., to answer phone calls and record voice mails on your behalf. With the introduction of Call Answering Rules in Exchange UM 2010, you can dictate how incoming phone calls should be handled, thus enriching the call answering experience of your callers. In this article, we walk through the steps of creating a simple "default" call answering rule - one that is applied to all inbound phone calls.

I don't have any Call Answering Rule. So what?

Out-of-the-box, there are no Call Answering Rules created for you. All your callers will get the same default, call answering experience provided by UM 2007, i.e., callers will be prompted to leave you a voice message. Users who are satisfied with the default experience can continue to retain the same experience without the need to create any rule.

Creating a Default Call Answering Rule

As illustrated in Figure 1, the control for managing Call Answering Rules is located under ECP > Phone > Voice Mail tab. To create a new call answering rule, click on "New Rule".

Figure 1: Call Answering Rule Control

Anatomy of a Call Answering Rule

Each Call Answering Rule comprises two key aspects:

• Conditions - what criteria must be met before the rule can be applied to an inbound call.
• Actions - what options should be presented to the caller when all the conditions are met. These actions will be read to the caller over the phone and users can then pick an action using the phone keypad.

Figure 2 shows the form for creating a Call Answering Rule, which is divided into two columns. The right column displays the list of available conditions and actions you can use to build the rule. The left column displays the list of conditions and actions which have been added to the rule.

Figure 2: Call Answering Rule Form

Conditions

There are 4 classes of conditions supported by Call Answering Rules, including:

• Caller ID
• Time-of-the-day
• Free/busy status
• Automatic email reply is enabled/disabled

By using a combination of these conditions, you can create multiple Call Answering Rules and have them triggered for different phone calls. To create a default rule that will be applied to every call, you create a rule does not contain any condition. Since we are not adding any condition, I will not delve further into these conditions but leave them to my follow-up article.

Actions

There are 3 kinds of actions supported by Call Answering Rules, including:

• Find-Me
• Call Transfer
• Leave a voice mail

Adding a Find-Me action

When a caller selects Find-Me action, UM will attempt to locate you on up to 2 different phone numbers, and then connect you to the caller. To add a Find-Me option, click on "Find me at the following numbers". In the Find-Me dialog and with reference to my example in Figure 3 :

• You can optionally specify a context that will be read to the user. In my example, I have entered "important matters" to inform my callers that they should only select this action if they have important things to discuss.
• You need to associate the Find-Me action with a number on the keypad. This is the key which the caller has to press to select this action. In my example, I have also specified "1" as the DTMF key to be used.
• You also need to specify 1 to 2 phone numbers to be dialed. If 2 numbers are specified, they will be dialed in a sequential fashion, i.e., one after the other. Each phone number has an associated duration. This indicates how long UM should try dialing the phone number before moving on to the next number or revert back to the options menu.
• Click on Apply to add the Find-Me option and close the dialog.

Figure 3: Find-Me Dialog

Adding a Call Transfer option

By configuring a Call Transfer action, you provide callers with the option to be transferred to someone else. To add a Call Transfer option, click on "Transfer the caller to..." link. In the Call Transfer dialog and with reference to my example in Figure 4.

• You can optionally specify a context that will be read to the caller as part of this option. In my example, I have entered "Unified Messaging" to inform my callers that they can choose this option if they have questions around "Unified Messaging."
• You need to associate the Find-Me action with a number on the keypad. I have specified "2" as the DTMF key to be used for this option.
• You need to specify a transfer target for this option. This can be in the form of a phone number, or you can select an AD contact for the call transfer. When specifying the AD contact, UM will attempt to transfer the call to the UM extension of the AD contact. If the AD contact is not UM-enabled, the AD business phone number field will be used. In my example, I have selected my manager "Michael Wilson" as the transfer target.
• Click on Apply to add the Call Transfer option and close the dialog.

Figure 4: Call Transfer Dialog

Adding Voice Mail action

By default, the Voice Mail option is automatically added to each Call Answering Rule. If you do not wish to offer this option, you can remove it by clicking:

To add the option back, simply click "Leave a Voice Message."

Saving the rule and trying it out

Prior to saying the rule, you need to give a meaningful name to the rule you've created. After which, you click on the SAVE button to create the rule. Next, you should test to see if the call answering rule is working as desired by trying to call your UM-enabled phone extension and wait for the call to be answered by UM.

Optional: Record a customized greeting

You can record a custom greeting for each rule. By default, UM will generate a default greeting based on the actions you have configured. To record a custom greeting, you can click on:

in the Call Answering Rule form and UM will call you up to record a greeting.

Note: In your recording, you should include any actions you have configured on the rule itself. UM will not list the actions if a custom greeting is present.

-Chun Yong Chua

Share this post :

Voice Mail Preview will literally transform the way that you look at voice messages in Exchange.

Exchange Unified Messaging (UM) makes it easy to manage your voice messages by delivering them in your Inbox. You can then use many types of Exchange mail client software to review your voice mail. Microsoft Outlook, Outlook Web Access (OWA), Outlook Mobile (and other clients connected via Exchange ActiveSync) and, of course Outlook Voice Access (the speech access interface in Exchange UM) are examples of the ways that you can now retrieve voice mail.

Figure 1. Exchange UM voice mail in the Inbox

If you're using a visual mail client such as Outlook to review your voice mail, it's great to see at a glance the message details (date/time, length) and the number or name of the sender. In Outlook and OWA, you can even add your own text in an Audio Notes field. This permits you to annotate the message so that you can see what it's about, should you return to it later. You can also search for the message by one or more words in the note, as you're used to doing for e-mail.

People who have used the Audio Notes feature since Exchange 2007 have surely sometimes wished that the annotations could be generated automatically.

In Exchange 2010, the Voice Mail Preview feature will do this, and more. By the time that a voice message arrives in your Inbox, UM can insert a Preview. This is machine-generated text that is derived from the voice recording. You can usually gain a good sense of the recorded content by looking at the Preview. Text in the Preview is indexed, so you can search for voice messages without Audio Notes. You can add additional information or make corrections through the Audio Notes field, if required.

Figure 2. Voice Mail Preview (sample message)

Figure 2 shows an example of an actual voice message with a Preview, which I received recently. Some of the text in the figure has been obscured to protect the identity of the caller. In this case, the caller was a telemarketer and I was able to glance at the message (which arrived while I was in a meeting and unable to play the audio) and decide that it was (how shall I put this?) not at all urgent.

In later articles in this series, I'll look at Voice Mail Preview in more detail, describing additional capabilities, how it works, and some limitations.

- Michael Wilson

If you are using Exchange 2007 UM to receive faxes, you should know about the changes we have made to the inbound faxing capabilities in Exchange 2010 UM. After working with our customers and partners, we determined that it was best for specialized partners with deep fax expertise to provide the comprehensive fax capability for Exchange Server 2010. We have therefore established partnerships with several fax vendors to ensure a seamless fax experience for customers who are new to Unified Messaging as well as those upgrading from Exchange Server 2007.

Exchange 2010 no longer creates fax messages itself but instead forwards the inbound fax calls to a dedicated partner fax solution. The partner fax solution establishes the fax call with the remote endpoint and receives the fax media on behalf of the UM-enabled user. It then sends an SMTP message, which contains the fax as a TIFF attachment, to the recipient's mailbox. The Exchange 2010 UM server ensures that the fax message is formatted just like the fax messages coming from Exchange 2007 UM server (Figure 1). 

Figure 1: Example of Exchange 2010 UM fax message.

To allow users to receive faxes via Exchange 2010 UM, customers must install and configure or sign up for service with one of the UM-certified partner fax solutions. At the time of writing, fax partner testing and certification is in progress. The list of compatible, UM-certified fax partners will be made available on our website when Exchange 2010 is launched.

The new fax capabilities in Exchange 2010 RTM are controlled by the following attributes:

• FaxEnabled on UMDialPlan objects
• AllowFax and FaxServerURI on UMMailboxPolicy objects
• FaxEnabled on UMMailbox objects

By default, when the user is first UM-enabled, the UMDialPlan.FaxEnabled and UMMailbox.FaxEnabled are set to true, whereas UMMailboxPolicy.AllowFax is set to false. In order to enable a UM user for fax, all three of these attributes must be set to true and UMMailboxPolicy.FaxServerURI must point to a valid partner fax solution endpoint. Whenever UMMailboxPolicy.AllowFax is set to true, FaxServerURI must be provided to indicate to the UM server where to redirect the fax calls. FaxServerURI must have the following form: sip::;, where "fax server URI" is either an FQDN or an IP address of the partner fax solution; "port" is the port on which the fax server listens for incoming fax calls and "transport" is the transport protocol over which the fax calls are made (udp, tcp or tls). For example, you might configure fax as follows:

[PS] D:\>Set-UMMailboxPolicy MyPolicy -AllowFax $true -FaxServerURI "sip:faxserver.abc.com:5060;transport=tcp"

You may be wondering how to secure communication with the partner fax solution. Partner fax messages must be authenticated; any unauthenticated message claiming to have come from a fax partner will not be processed by the UM server but instead will be delivered as a regular email. For authenticating the connection from the partner you can use mutual TLS, sender ID validation [1, 2], or establish trust via a dedicated receive connector. A receive connector should be sufficient for authenticating the partner fax solutions deployed in the enterprise together with the UM server. The receive connector will ensure that the Exchange server treats all traffic coming from the partner fax solution as authenticated. The connector should be deployed on the Hub Transport server used by the partner fax solution to submit SMTP fax messages and should have the following property values:

- Katarzyna Puchala

References:

[1] Fighting SPAM and Phishing with Sender ID. Internet Resource. Last Accessed 7/21/09. http://technet.microsoft.com/en-us/magazine/2006.12.sidf.aspx?pr=blog

[2] Sender ID. Internet Resource. Last Accessed 7/21/09. http://technet.microsoft.com/en-us/library/aa996295.aspx

John Robinson

We are interested in hearing feedback on your experience deploying and/or managing Unified Messaging in Exchange. We are conducting research to understand users' pain points and frustrations around deployment and management of unified messaging. Please take 5-10 minutes to answer the survey questions. This type of feedback directly impacts product decisions and we would appreciate your valuable feedback.

The survey can be found here.

Thank you for your time!

- Brendan Reeves
(User Experience Researcher)