Quantcast
Channel: You Had Me At EHLO…
Viewing all 172 articles
Browse latest View live

Early look: Exchange 2010 perf counters and thresholds to watch

$
0
0

Seeing that many will be finding a copy of Exchange 2010 under the tree soon (...right?), we wanted to let you know that we have been working to create the performance counter guidance for Exchange 2010 as we have for Exchange 2007 (see Monitoring Without System Center Operations Manager).

We are planning to release the official Exchange 2010 version of such document within a month or two. But - for those of you that just can't wait, and will be / are installing Exchange 2010 now - you can find a preview of our perf counter guidance in the following Excel spreadsheet found here.

We do not expect many changes to this between now and official release, but if you have any kind of feedback on it - we'd love to hear it!

- Erin Bookey


Call Answering Rules (Part 2): Call Answering Conditions

$
0
0

In Exchange 2010, users can easily create call answering rules to have a call answered based on the specified conditions. Users can create rules to answer calls from specified callers or Contacts in a certain way, handle calls differently based on their availability (Free/Busy status) or time of day. The call answering rule will only be triggered when all the associated conditions are met. In this post, I will cover:

  • The different classes of conditions supported in UM 2010
  • How does UM go about evaluating a given set of call answering rules

This article assumes that you have read my previous post Call Answering Rules (Part I) - Creating your first Call Answering Rule.

The Call Answering Rule form

The diagram below shows you the Call Answering Rule form. In particular:

  • Condition(s) which have already been added to the rule is located on the left (in green). You can remove them by clicking on the symbol beside the condition.
  • Condition(s) which you can further add to this rule is located on the right (in red). To start adding new condition, simplify click on the condition desired.

Figure 1: The call answering rule form

Different classes of conditions

There are 4 different classes of conditions supported by UM 2010, namely:

  • Caller identity
  • Time-of-the-day
  • Calendar free/busy status
  • When my automated email reply is turned on
  1. Caller Identity

    Users can use different call answering rules for different callers. For example, if you receive a call from an important customer's phone number, you can answer it differently. To answer calls based on caller identity, users can add a caller-ID condition to a call answering rule such that the rule will only be triggered if the calling party matches one of those specified. To configure this condition:
    1. Click on "If the caller is." condition to bring up the following UI control.

      Figure 2: Call answering rule based on caller
    2. Specify 1 or more phone numbers, pick Contacts from the GAL or your Contacts folder, or specify the entire Contacts folder.
    3. Click on "Apply" to close the UI control.
  2. Time of Day

    Users can add a time-of-the-day condition to a call answering rule such that the rule will only be triggered if the time of the call matches the time period specified. For example, during working hours, calls can be answered using the "Follow-Me" action, or routed straight to voicemail during after-hours. To configure this condition:

    1. Click on If it is during this period. condition to bring up the following UI control:

      Figure 3: Call answering rule based on time of day
    2. Specify a period, either working hours, non-working hours or custom hours.
    3. Click on Apply to close the UI control.
  3. Calendar Free/Busy status

    Users can specify a condition for a call answering rule based on their availability (calendar Free/Busy status). To do so:

    1. Click on If my schedule shows that my status is. condition to bring up the following UI control:

      Figure 4: Call answering rule based on Free/Busy Status
    2. Pick one or more Free/Busy status which you want this rule to fire. In the example provided, I have specified that the call answering rule to be triggered if my calendar shows that I am either Busy or Away.
    3. Click on Apply to close the UI control.
  4. When my automated email reply is turned on

    Users can specify that a call answering rule only be fired when their automatic email reply is turned on. To do so, simply click on "If Automatic Replies are turned on" condition.

      Call Answering Rules and conditions

      It is possible to associate the same call answering rule with multiple conditions. All the conditions must be met in order for the call answering rule to be trigger. You can also create call answering rules without specifying any condition. When such a rule is encountered, it will be triggered as though all its conditions are met.

      Multiple Call Answering Rules

      You can create one or more call answering rules. You can also associate each call answering rule with one or more conditions. The diagram below illustrates an example with 3 call answering rules configured. You can enable/disable or reorder the rules.


      Figure 5: Multiple call answering rules

      As illustrated in the flow diagram below, for each call answering call received:

      • No call answering rules configured: If you do not have any call answering rules configured, UM will offer the caller to leave a voice message.
      • One or more call answering rules configured: If there are one or more call answering rules configured, UM will evaluate these rules in a top-down fashion. The first rule, whose conditions are met, will be fired.
      • After evaluating all the rules, if UM is unable to find a rule whose conditions are met, UM will offer the caller to leave a voice message.

      Figure 6: How UM call answering rules are evaluated

      Call answering rules are an Exchange 2010 feature, and only available to UM-enabled users with a mailbox on an Exchange 2010 Mailbox server.

      -Chun Yong Chua

      Understanding Remote Mailbox Move and Unified Messaging

      $
      0
      0

      Remote mailbox move (a.k.a. cross-forest mailbox move) refers to the process of migrating an Exchange mailbox from one Active Directory forest to another. Exchange 2010 supports remote mailbox moves via the MoveRequest cmdlets. Here are some of the considerations for performing remote mailbox moves on mailboxes which are enabled for Unified Messaging (UM). This article assumes that readers are familiar with Unified Messaging and how remote mailbox move operates in general.

      So... why do you care?

      Prior to Exchange 2010 SP1, if you want to perform remote mailbox move on a UM-enabled mailbox, you need to do the following:

      1. Prior to the move, UM-disable the mailbox in the source forest
      2. Execute move request on the mailbox
      3. After the move completes, UM-enable the mailbox in the target forest

      In addition, you need to update the telephony configuration for the corresponding phone set so that all phone calls for the mailbox owner are correctly covered by the telephony system to the UM servers in the target forest.

      This process poses several pain points, most importantly:

      • Admin hassle - The admin having to manually disable and re-enable the mailbox for UM every time a UM-enabled mailbox is moved.
      • User hassle - Voice Mail stops working for the user whose mailbox is being moved for the entire duration of the move process since the mailbox is UM-disabled. This is problematic for users with large mailboxes where the move process can take a long time to complete.

      In Exchange 2010 SP1, we've extended the MoveRequest cmdlets to alleviate these pain points by removing the need for an admin to UM-disable/re-enable the mailbox and reduce voice mail downtime.

      How it works

      For this to work correctly, you need to "map" the UMMailboxPolicy objects in the source forest to the UMMailboxPolicy objects in the target forest. This is achieved by stamping the name of the UMMailboxPolicy object in the source forest on the SourceForestPolicyNames attribute on the UMMailboxPolicy object in the target forest. Here's an example to explain what I mean:

      1. Suppose you have some mailboxes which are UM-enabled in the source forest and are associated with UMMailboxPolicy object (Policy S). You would like these mailboxes to be UM-enabled and associated with UMMailboxPolicy object (Policy T) in the target forest after the move completes.
      2. Prior to executing the New-MoveRequest on these mailboxes, you need to stamp the name of Policy A on Policy B's SourceForestPolicyNames attribute by running the following Exchange cmdlet in the target forest:

        Set-UMMailboxPolicy -identity "Policy B" -SourceForestPolicyNames "Policy A"

      3. Once the mapping is created, you can start moving the mailboxes by executing the New-MoveRequest cmdlet without having to UM-disable the mailbox first. While the move is in progress, UM continues to operate for these mailboxes in the source forest since the mailboxes are still UM-enabled. As the move request completes for a particular mailbox, the following happens:
        • In the target forest:
          1. Upon detecting that the mailbox is UM-enabled, the migration process obtains the name of the UMMailboxPolicy object which the mailbox is associated with in the source forest. It then looks for a corresponding UMMailboxPolicy object in the target forest whose SourceForestPolicyNames attribute contains this name.
          2. The migration process also figures out what UM extensions are currently assigned to the mailbox in the source forest. Using these extensions and the UMMailboxPolicy object found earlier, the migration then UM-enables the mailbox in the target forest.
          3. The migration process also copies over information about the user's UM PIN into the target forest, ensuring the user's existing UM PIN is preserved during migration.
          4. A UM welcome message is then sent to the user, showing the access telephone number for the UMDialPlan in the target forest. Access telephone number is what users dial on their phone to get to Outlook Voice Access.
        • In the source forest:
          1. As part of move request, the Active Directory mailbox object is updated into a Mail-Enabled User (MEU) object. All UM configuration on the MEU object is automatically removed.

      Once the migration process completes, voice mail outage begins. This is because your telephony system is still sending calls to the UM servers in the source forest. Voice Mail outage continues until the telephony configuration for the corresponding phone set is updated to cover calls to the UM servers in the target forest.

      Further reducing voice mail downtime

      If you want to reduce the amount of downtime even further, this is what you can do:

      1. Make sure the name of the UMMailboxPolicy object in the source forest is correctly stamped on the SourceForestPolicyNames attribute of the UMMailboxPolicy object in the target forest.
      2. Execute New-MoveRequest with SuspendWhenReadyToComplete parameter set to $true. This ensures that the New-MoveRequest pauses right before finalization occurs.
      3. As you resume the move request by running Resume-MoveRequest, you also update your PBX configuration.

      As the mailbox move finalizes, the mailbox in the source forest is deleted and the mailbox in the target forest becomes functional. If you update your telephony configuration as the mailbox move finalizes, you can reduce the window of voice mail outage. Note that this method can be cumbersome since it requires precise coordination between your Exchange admin and your telephony admin.

      SourceForestPolicyNames Attribute

      The SourceForestPolicyNames attribute on the UMMailboxPolicy object is part of Exchange 2010 SP1 schema. It bears the following characteristics:

      1. Multi-valued - This means that you can have multiple UMMailboxPolicy objects in the source forest mapped to a single UMMailboxPolicy object in the target forest.
      2. Unique - No two UMMailboxPolicy objects in the same forest can have the same value stamped in their SourceForestPolicyNames attribute. This prevents you from stamping the name of a single UMMailboxPolicy object in the source forest on multiple UMMailboxPolicy objects in the target forest. This is needed to avoid any ambiguity when the migration process looks for a matching policy object in the target forest.
      3. By default, when you create a new UMMailboxPolicy object using Exchange 2010 SP1 cmdlets or admin console, its SourceForestPolicyNames attribute is automatically populated with its own name. An easy way to handle remote mailbox moves is to create UMMailboxPolicy objects in both source and target forests with the same name, thereby avoiding the need to manually configure the SourceForestPolicyNames attribute.

      Other considerations

      1. If the mailbox is UM-enabled in the source forest but you don't want the mailbox to be UM-enabled in the target forest, you should UM-disable the mailbox prior to the move. Conversely, if the mailbox isn't UM-enabled in the source forest but you want to UM-enable the mailbox in the target forest, you should UM-enable the mailbox in the target forest after the move. Doing so helps to reduce complexity in managing the move request since you don't have to take UM configuration into account.
      2. When you first execute New-MoveRequest, the migration process will perform a series of UM-specific validation up front if mailbox is UM-enabled, including looking for a matching UMMailboxPolicy object in the target forest as well as validating that the UM extensions assigned to the mailbox are unique in the target forest. If the validation fails, New-MoveRequest will return an error immediately.
      3. Under rare circumstances, the UM-specific validation may succeed up front when New-MoveRequest cmdlet is executed but the migration process fails to UM-enable the mailbox as the mailbox move finalizes. When this occurs, the mailbox move will complete with warning and the mailbox will not be UM-enabled in the target forest. You will need to manually UM-enable the mailbox in the target forest. The corresponding warning message, which can be obtained through Get-MoveRequestStatistics cmdlet, looks like this:

        Warning: User 'John Doe' can't be enabled for Unified Messaging in the target forest for the following reason: Extension 12345 is already assigned to another user on dialplan DP1 or an equivalent dial plan. Please fix the problem and enable the user for Unified Messaging manually.

        An example of how this can happen is that the UM extension assigned to the mailbox was available in the target forest when the UM-specific validation occurred but is no longer so right when the move finalizes.

      4. A UM-enabled mailbox may be assigned extensions from multiple UMDialPlan objects in the source forest. Only extensions from the primary UMDialPlan will be used to UM-enable the mailbox in the target forest. Extensions from secondary UMDialPlan(s) will not be preserved.

      Chun Yong Chua

      Exchange 2010 Diagnostics: The Unified Messaging Troubleshooting Tool

      $
      0
      0

      The Unified Messaging Troubleshooting Tool is a diagnostics cmdlet which every administrator should run whenever someone desperately (or not) comes to them and says "Help! My voicemail isn't working!". The tool executes a set of tests and outputs the possible root causes for any detected issues and the possible solution for those. Simple, fast and efficient, just the kind of tool you need in your daily IT adventures.

      Since we released the tool a while back, I've been receiving requests to post about it here on EHLO. As more and more organizations are starting to move away from the typical enterprise deployment model to a completely online world in Office 365, I thought this would be the right time to attend such requests.

      So, have you been using the tool? If not, here's something to get you started!

      Configuring the Windows PowerShell default execution policy on Windows 7

      If you are running the tool in Windows 7, by default it won't be given permission to execute Powershell scripts. This is due to the default execution policy granted by Windows PowerShell which is set to Restricted, so the moment you double click on the shortcut for the tool on your desktop, you get a nasty error message:

      Microsoft.Exchange.UM.TroubleshootingTool.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about signing" for more details.

      To bypass this, execute the following steps on your box:

      1. Start a new Powershell window as Administrator(run as Administrator)
      2. Run the following command: Set-ExecutionPolicy RemoteSigned

      This will grant Windows Powershell permissions to execute all scripts and configuration files, as long as they're signed by a trusted publisher. Because the troubleshooting tool is a signed Powershell script, it'll be granted the permissions to execute.

      Running the tool

      You are now ready to run the tool. Double click on the UM Troubleshooting tool shortcut on your desktop and type Test-ExchangeUmCallFlow

      PS C:\>Test-ExchangeUMCallFlowCmdlet Test-ExchangeUMCallFlow at command pipeline position 1
      Supply values for the following parameters:
      Mode:

      The troubleshooting tool supports two operating modes:

      • Gateway: Emulates a call, as if it was coming from a SIP Gateway.
      • SIPClient: Emulates a call, as if it was coming from a Lync server.

      Say you're running the tool to verify Bob's TelEx extension (x12345). When prompted about the execution mode, you should go ahead and confidently type Gateway.

      PS C:\>Test-ExchangeUMCallFlowCmdlet Test-ExchangeUMCallFlow at command pipeline position 1
      Supply values for the following parameters:
      Mode: Gateway
      NextHop:

      The troubleshooting tool will now prompt you for the NextHop. This should be the IP address or FQDN that the tool must connect to. Your NextHop will vary, depending on whether you're running the tool to verify the UM configuration of a mailbox in Office365 or a mailbox hosted in your on-premises Exchange organization.

      If you're verifying a mailbox hosted in the cloud, you should enter the FQDN of the SBC device, which will in turn forward the call to one of our UM servers.

      If you're running the tool against an on-premises mailbox, you should enter the FQDN of your Unified Messaging server.

      PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1
      Supply values for the following parameters:
      Mode: Gateway
      NextHop: Umserver.constoso.com
      Diversion:

      The last information required is the diversion header to be used. It can be as simple as just the extension number to be verified, or a (somewhat) complex History-Info header, as those might also be used by SIP devices interested in preserving the information on how a call originated.

      Here's an example of a very complex History-Info in case you'd like to try it out:

      History-Info:<sip:12345@contoso.com;user=phone?Reason=SIP%3Because%3D487%3Btext%3DTimeout>;index=1,<sip:7890@contoso.com;user=phone?Reason=SIP&m#62;;index=1.1

      So go ahead and enter the last parameter required:

      PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1
      Supply values for the following parameters:
      Mode: Gateway
      NextHop: Umserver.constoso.com
      Diversion: 12345

      That's it! The tool will then execute a set of tests and output any issues detected.

      PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1
      Supply values for the following parameters:
      Mode: Gateway
      NextHop: Umserver.constoso.com
      Diversion: 12345
       
      The diagnostic test identified a problem.
       

      Task : Resolving "UmServer.contoso.com" to an IP address
      Status : Failed
      Reason : It is not possible to resolve "UmServer.constoso.com" from this machine. Details: No such host is known
      Solution : Confirm that the server name "UmServer.contoso.com" is correct and that it can be accessed from this computer.
       
       
      Traces for this diagnostic test can be found at 'C:\Users\Administrator\AppData\Roaming\Microsoft Exchange 2010 UM Troubleshooting Tool'.

      By the way, did you notice the last lines outputted by the tool? Here is what is says:

      Traces for this diagnostic test can be found at 'C:\Users\Administrator\AppData\Roaming\Microsoft Exchange 2010 UM Troubleshooting Tool'

      In addition to the information returned by the tool, a set of very, very important traces are automatically generated by the tool:

      • UMTool_Collaboration: RTC stack traces
      • UMTool_DiagnosticLog: Lists the tests executed by the tool and their results
      • UMTool_S4: S4 stack traces
      • UMTool_SIPMessageLogs: The full SIP traces for the test call executed

      The UM team would love to hear stories where the Unified Messaging Troubleshooting tool saved your day! We'd love as well to hear any other asks you might have. Let us know by posting your comments on this blog.

      Bernardo Sana

      Troubleshooting the Messaging Waiting Indicator status in Exchange 2010 Unified Messaging server

      $
      0
      0

      Message Waiting Indicator on an IP phone

      There are a number of ways an end-user may learn that they have new voice mail, such as from client software like Microsoft Outlook, OWA, Lync, Communicator, or different types of indicators on IP, smart and traditional phones. The term Message Waiting Indicator (MWI) is usually applied to notifications delivered by the user’s phone using mechanisms such as a light on the phone, a special icon or highlighted notification or even a special dial tone. Exchange 2010 includes built-in support for MWI.

      For more details, see Understanding Message Waiting Indicator in Exchange 2010 documentation.

      Exchange 2010 Unified Messaging also includes a feature called Voice Mail Preview which uses automatic speech recognition (ASR) to add a text version of the voice mail that's delivered to the user's Inbox (along with the MP3 voice message). This allows users to read their voicemail messages. See Voice Mail Preview Advisor for Exchange 2010 for details.

      This article describes steps on how to use the event logs on Exchange 2010 Unified Messaging (UM) and Mailbox servers to troubleshoot MWI failures. Also included in this article are settings to validate MWI configuration on Exchange.

      Flow of MWI notifications on Exchange servers

      1. A voice message is left for a user and is stored in the user's Exchange mailbox on a Mailbox server.
      2. The Mailbox Assistant service on the Mailbox server checks the status of voice mails in the user’s mailbox.
      3. The Mailbox Assistant service makes an RPC connection to a Unified Messaging server associated with the user’s UM Dial Plan.
      4. The UM server sends a SIP NOTIFY message with the MWI state change to a UM IP Gateway associated with the user’s UM Dial Plan.

      The starting point of a MWI notification is after the voicemail has been placed in the end user’s mailbox. The focus of these troubleshooting steps are on the Exchange messaging side to diagnose MWI notification issues between a Mailbox server and a UM Server, and also between the UM server and a UM IP Gateway.

      Contents

      Troubleshooting Steps

      1. Check the event log on the mailbox server

        Confirming the Mailbox server is not logging MWI errors will help to isolate the problem to a later notification handling step. The first step in sending the MWI notification is the retrieval of the MWI state from the user’s mailbox on the mailbox database. Once the state of the MWI is known, the mailbox server must be able to make an RPC connection with the UM server to relay the MWI state information. Any of the following events, if found on the Mailbox server, would be the starting point for a deeper look at the Mailbox server. Also UM event logging can be increased on the mailbox server to confirm that the MWI notification was successfully sent to the UM server.

        1. On the Exchange 2010 Mailbox server, look for Event ID 1346 in the Application Event log. It indicates there may be an issue with the database or the database might be dismounted.

          Log Name: Application
          Event ID: 1346
          Source: MSExchange Unified Messaging
          Date: 4/15/2011 6:55:52 PM
          Task Category: MWI General
          Level: Warning
          Keywords: Classic
          User: N/A
          Computer: Ex2K10MailboxServer.Contoso.com
          Description: The Message Waiting Indicator Assistant was unable to query the mailbox database 'MailboxDB01#GUID'. The MWI assistant will try to query the mailbox database again in 720 minutes. If you continue to see this warning, there could be a problem with the mailbox database or the Mailbox server. Additional information: Microsoft.Mapi.MapiExceptionMdbOffline: MapiExceptionMdbOffline: Unable to get mailbox information. (hr=0x80004005, ec=1142) Diagnostic context: Lid: 20354

        2. Presence of Event ID 1345 on the Mailbox server indicates there may be a problem with the user’s mailbox. The ‘Additional information’ will contain MAPI error codes and additional information to diagnose the specific issue. Here's an example:

          Log Name: Application
          Source: MSExchange Unified Messaging
          Date: 4/15/2011 6:45:52 PM
          Event ID: 1345
          Task Category: MWI General
          Level: Warning
          Keywords: Classic
          User: N/A
          Computer: Ex2K10MailboxServer.Contoso.com
          Description: The Message Waiting Indicator Assistant was unable to obtain the MWI state for mailbox 'John Doe (#ExchangeGuid)' on database 'MailboxDB01#GUID'. You can safely ignore this warning if the mailbox is currently disconnected or inactive. Additional information: (Various MAPI error descriptions).

        3. Event ID 1360 on the Mailbox server indicates that there might be an RPC communication issue between the Mailbox server and the UM server. A communication issue between the mailbox and the UM server could be due to an issue on either server. For example:

          Log Name: Application
          Source: MSExchange Unified Messaging
          Date: 4/15/2011 7:05:52 PM
          Event ID: 1360
          Task Category: UMCore
          Level: Warning
          Keywords: Classic
          User: N/A
          Computer: Ex2K10MailboxServer.Contoso.com
          Description: The Message Waiting Indicator Assistant failed to deliver the MWI notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension '+15555555555'. Until this problem is corrected, the MWI state for this user may be out of sync. Additional information: Server Ex2K10UMServer failed with 1722 Error 0x6ba (The RPC server is unavailable) from SendMwiMessage

          Note: You may also see:
          There are no more targets available to send an MWI message for user John Doe.

        4. If the UM MWI event logging level is increased on the Mailbox server, the success event for the MWI notification is logged to the Application event log with ID: 1343, which indicates that the Mailbox server has successfully submitted a MWI notification to the UM server.

          This command shows the current logging level of MWI on the mailbox server:

          Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | FT -auto

          The output:

          Identity                                  EventLevel
          --------                                  ----------
          MSexchange Unified Messaging\MWI General   Lowest

          This command raises the MWI logging level to ‘Expert’ and you will start to see the MWI ‘Success’ events (Event ID: 1343) in the Application event log.

          [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | Set-EventLogLevel -Level:Expert

          You can use the Get-EventLogLevel cmdlet again to verify that the MWI logging level has been raised to Expert level. For more details about diagnostic logging levels in Exchange 2010, see Manage Diagnostic Logging Levels.

          The increase in logging show will show that mailbox server has successfully submitted the MWI notification to the UM server. For example:

          Log Name: Application
          Source: MSExchange Unified Messaging
          Date: 4/15/2011 7:15:26 PM
          Event ID: 1343
          Task Category: MWI General
          Level: Information
          Keywords: Classic
          User: N/A
          Computer: Ex2K10MailboxServer.Contoso.com
          Description: A Message Waiting Indicator (MWI) notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension 'johndoe@contoso.com' was succesfully sent to 'Ex2K10UMServer'.

      2. Identify the UM IP Gateway and UM server

        From the UM server: If you already know the UM server in use, then check the Application Event log for event 1344 identifying an MWI and the user affected. The PowerShell commands further below will help to validate Exchange configurations settings for the MWI.

        Log Name: Application
        Source: MSExchange Unified Messaging
        Date: 4/15/2011 6:30:52 PM
        Event ID: 1344
        Task Category: MWI General
        Level: Warning
        Keywords: Classic
        User: N/A
        Computer: Ex2K10UMServer.Contoso.com
        Description: The Unified Messaging server failed to deliver the MWI notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension 'johndoe@contoso.com'. Until this problem is corrected, the MWI state for this user may be out of sync. Additional information:
        An MWI message couldn't be delivered in the allocated time for user John Doe.
        Server MyIPGateway1 failed with 0 Unable to establish a connection.
        Server MyIPGateway2 failed with 0 Unable to establish a connection.

        The ‘MyIPGateway#’ indicates one or more Exchange UM IP Gateways objects associated with the dial plan for the user. The UM IP Gateway should also be checked to confirm that the MWI is enabled with the MessageWaitingIndicatorAllowed set to True. See further below for an example.

        From the recipient: If you have a specific user you are validating MWI functionality, the steps below are also useful to validate that each portion of the messaging configuration has MWI enabled for the user. The user must be UM enabled, and MWI must be enabled ‘True’ on the UM Mailbox Policy and the UM IP Gateway in Exchange, to be configured to deliver MWI notifications. Please be sure to check the health and status of the user’s mailbox server first.

        Identify the UM server and UM IP Gateways that the user would be associated with.

        1. First find the UM dial plan linked with the user. The recipients UM dial plan (and UM Mailbox Policy) can be found for a user with Get-UMMailbox. Get-Recipient will provide much of the same data. For example:

          Get-UMMailbox johndoe@contoso.com | select UMEnabled, UMDialPlan, UMMailboxPolicy, UMSMSNotificationOption | FL

          The output:

          UMEnabled : True
          UMDialPlan : MyUMDialPlan
          UMMailboxPolicy : MyUMMailboxPolicy
          UMSMSNotificationOption : VoiceMail


          Alternatively, using the Get-Recipient cmdlet retrieves the following data.

          [PS] C:\>Get-Recipient johndoe@contoso.com | select UMEnabled, UMMailboxPolicy, UMRecipientDialPlanId | FL

          UMEnabled : True
          UMMailboxPolicy : MyUMMailboxPolicy
          UMRecipientDialPlanId : MyUMDialPlan

        2. Next, let's look at the UM Mailbox Policy by using the Get-UMMailboxPolicy cmdlet and confirm that the policy is MWI enabled (AllowMessageWaitingIndicator is set to True).

          Get-UMMailboxPolicy -Identity MyUMMailboxPolicy | select AllowMessageWaitingIndicator, AllowSMSNotification | FL

          AllowMessageWaitingIndicator : True
          AllowSMSNotification : True

        3. The UM servers and IP Gateways associated with the recipient’s dial plan can be found with the Get-UMDialplan cmdlet. For example,

          Get-UMDialplan -Identity MyUMDialPlan | select UMServers, UMMailboxPolicies, UMIPGateway | FL

          UMServers : {Ex2K10UMServer, Ex2K10UMServer2}
          UMMailboxPolicies : {MyUMMailboxPolicy}
          UMIPGateway : {MyIPGateway1, MyIPGateway2}

        4. The UM IP Gateway in Exchange should also be confirmed that the MWI is enabled and set to ‘True.’

          Get-UMIPGateway -Identity MyIPGateway1 | FL MessageWaitingIndicatorAllowed

          MessageWaitingIndicatorAllowed : True

        5. On the UM servers listed in the dial plan look for Application event log ID 1344. This event will show the MWI failure for the user. This will also indicate which UM IP Gateways that may have a communications issue where the SIP Options fail.

      3. Look for a SIP OPTIONS failure on the Unified Messaging server

        Connection issues between the UM server and physical UM IP Gateway device, may appear as SIP OPTIONS failure events on the UM server. With the UM IP Gateway from either the dial plan or directly on the UM server, you can look for Application event log ID 1400 that indicates a SIP OPTIONS failure to the specific Gateway. For example:

        Log Name: Application
        Source: MSExchange Unified Messaging
        Date: 4/15/2011 6:31:28 PM
        Event ID: 1400
        Task Category: UMCore
        Level: Warning
        Keywords: Classic
        User: N/A
        Computer: Ex2K10UMServer.Contoso.com
        Description: The following UM IP gateways did not respond as expected to a SIP OPTIONS request.
        Transport = TLS, Address = MyIPGateway1.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection.
        Transport = TLS, Address = MyIPGateway2.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection.

        Note: The error text will be different depending on the type of failure; you may also see "This operation has timed out.", “Unknown error (0x80131500)”, or as shown “Unable to establish a connection.” The Port may be different from ‘5060’. If mutual TLS has been configured the port is use will be 5061.

      4. Increase the UM MWI event logging level on the UM server

        To get confirmation that the Exchange UM server successfully submitted the MWI notification to the Gateway device, you will need to increase the logging level for MWI on the UM server. You may see a new Application event ID: 1343. The ID: 1343 is a ‘success’ entry for having notified the Gateway device of the MWI state. If the Exchange UM server successfully submitted the notification, then the next step would be to check the Gateway device’s functionality with the Gateway’s downstream devices.

        Run the command below to view the current logging level of MWI on the UM server.

        [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | FT -auto

        Identity EventLevel
        -------- ----------
        MSexchange Unified Messaging\MWI General Lowest

        To increase the MWI logging level to see the MWI success events you can run the following command. This will set the logging level to ‘Expert’ and you will start to see the UM MWI ‘Success’ ID: 1343 events in the Application event log.

        [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | Set-EventLogLevel -Level:Expert

        You can now see that the MWI logging level has been increased.

        [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | FT -auto

        Identity EventLevel
        -------- ----------
        MSexchange Unified Messaging\MWI General Expert

        The increase in the UM server’s MWI logging level show will show that UM server has successfully submitted the MWI notification to the UM IP Gateway with the following event. The failure to notify end users would then be with the Gateway device or downstream functionality.

        For example,

        Log Name: Application
        Source: MSExchange Unified Messaging
        Date: 4/15/2011 7:15:45 PM
        Event ID: 1343
        Task Category: MWI General
        Level: Information
        Keywords: Classic
        User: N/A
        Computer: Ex2K10UMServer.Contoso.com
        Description: A Message Waiting Indicator (MWI) notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension 'johndoe@contoso.com' was succesfully sent to 'MyIPGateway1'.

      5. Check connectivity between the UM server and the UM IP Gateway

        There are a number of factors that impact communications between the UM server and the UM IP Gateway. If TLS (Transport Layer Security) is being used, certificates are a common item to check. When other functionality is working between the UM server and the Gateway, there could be an issue in how the SIP NOTIFY is being handled.

        Basic network checks to confirm TCP/IP connectivity.

        • If the UM Gateway listed is a FQDN, confirm that the correct IP address is resolved. Validate the address resolution across all DNS servers.
        • From the UM server use ‘Ping’ and ‘Tracert’ to confirm the routing path and IP connectivity.
        • To validate that the port is listening you can ‘Telnet’ to the port (5060/5061).

      New Unified Messaging server event ID for SIP OPTIONS failures

      The event ID for the SIP OPTIONS failure has changed between Exchange 2007 and Exchange 2010. Exchange 2010 logs event ID 1400 in the Application event log for SIP OPTIONS failures. The content of event ID 1400 is also different from the SIP OPTIONS failure event ID 1088 logged by Exchange 2007, which logged only one failure per event. Exchange 2010 lists multiple failures per event. The event ID1088 does not alert on the Exchange 2010 UM server.

      In Exchange 2007 the Application log event ID 1088 for SIP OPTIONS failure:

      Event Type: Warning
      Event Source: MSExchange Unified Messaging
      Event Category: UMService
      Event ID: 1088
      Date: 4/15/2011
      Time: 6:18:13 PM
      User: N/A
      Computer: Ex2K7UMServer
      Description: The IP gateway or IP-PBX "MyIPGateway1" did not respond to a SIP OPTIONS request from the Unified Messaging server. The error code that was returned is "0" and the error text is ":Unable to establish a connection.". Note: The error text will be different depending on the type of failure, you may also see ":This operation has timed out.".

      In Exchange 2010 the new Application log event ID 1400 for SIP OPTIONS failure, for example.

      Log Name: Application
      Source: MSExchange Unified Messaging
      Date: 4/15/2011 6:31:28 PM
      Event ID: 1400
      Task Category: UMCore
      Level: Warning
      Keywords: Classic
      User: N/A
      Computer: Ex2K10UMServer.Contoso.com
      Description: The following UM IP gateways did not respond as expected to a SIP OPTIONS request.
      Transport = TLS, Address = MyIPGateway1.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection.
      Transport = TLS, Address = MyIPGateway2.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection.

      Note: The error text may be different depending on the type of failure. You may also see:
      • "This operation has timed out."
      • “Unknown error (0x80131500)”
      • “Unable to establish a connection.”
      Additionally, the actual port used is displayed - it may be different from 5060. For example, if you've configured mutual TLS, TCP port 5061 is used.

      Summary of settings to validate

      • Confirm that a voicemail has been placed in the end user’s mailbox.
      • Confirm the user’s mailbox and mailbox database are online and responding.
      • Look for any MWI failure events on the mailbox server.
      • Increase the UM MWI event logging level on the mailbox server to view ‘success’ events.
      • Confirm the user is UM enabled (Get-Recipient) and note the mailbox policy and dial plan.
      • If the user receives an SMS text notification confirm that ‘UMSMSNotificationOption’ is set to a Voicemail option, and also that the UMMailboxPolicy setting ‘AllowSMSNotification’ is set to ‘True’.
      • Confirm that the UM Mailbox Policy is MWI enabled.
      • Find the UM server and UM IP Gateway being used from the UM Dial Plan.
      • Confirm that the UM IP Gateways is MWI enabled in Exchange.
      • Check the health of the UM server.
      • Look for SIP OPTIONS failures on the UM server.
      • Increase the UM MWI event logging level on the UM server to view ‘success’ events.
      • Examine network connectivity between the UM server and the UM IP Gateway.
      • Confirm the UM server is able to ping the UM IP Gateway and telnet to the port in use.
      • The commands Test-UMConnectivity and Test-ExchangeUMCallFlow may be useful in testing functionality between the UM server and the UM IP Gateway but don’t specifically test MWI notifications.

      These troubleshooting steps will help to eliminate any issues on the Exchange server side in passing MWI notifications to end users. With all MWI settings correctly configured, any Exchange side MWI failure should be able to be isolated by the errors in the Application event log. But this only validates the Exchange side of the MWI notifications, there could be an issue on the UM IP Gateway / SIP Peer side or how the SIP NOTIFY of the MWI notifications were handled between the UM server and the UM IP Gateway device. This article doesn’t go into the handling of the SIP NOTIFY between the UM server and a UM IP Gateway. For an in-depth description on the MWI SIP NOTIFY with the UM IP Gateway / SIP Peer, please see 'Understanding Message Waiting Indicator’.

      Useful links

      Jon Ernast

      • Exchange 2007 policies

        $
        0
        0

        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 

        OOF integration with Exchange Server 2007 Unified Messaging (UM)

        $
        0
        0

        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 2nd 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

        UPDATE 2: Exchange 2007 Processor and Memory Recommendations

        $
        0
        0

        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:

        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:

        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 3rd party applications. The recommended maximum may change over time based on price changes and technology advancements.

        Processor Configuration Table for Exchange 2007

         Role

        Minimum

        Recommended

        Maximum

        Edge Transport

        1 x Processor Core

        2 x Processor Cores

        4 x Processor Cores

        Hub Transport

        1 x Processor Core

        4 x Processor Cores

        8 x Processor Cores

        Client Access Server (CAS)

        1 x Processor Core

        4 x Processor Cores

        4 x Processor Cores

        Unified Messaging Server (UM)

        1 x Processor Core

        4 x Processor Cores

        4 x Processor Cores

        Mailbox Server

        1 x Processor Core

        4 x Processor Cores

        8 x Processor Cores

        Multi Role (Hub, CAS, UM, Mailbox)

        1 x Processor Core

        4 x Processor Cores

        4 x Processor Cores

        ** 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, 3rd 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, 3rd 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 3rd Party tools/applications. The following table lists generic/common Outlook knowledge worker profiles:

        User Type

        Send/Receive per day (~50kb Message size)

        Light

        5 sent/20 received

        Average

        10 sent/40 received

        Heavy

        20 sent/80 received

        Very Heavy

        30 sent/120 received

        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, 3rd Party applications, 3rd 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.

         Role

        Minimum

        Recommended

        Maximum

        Edge Transport

        2GB/Server

        1GB/Core

         (2GB minimum)

        16GB/Server

        Hub Transport

        2GB/Server

        1GB/Core

         (2GB minimum)

        16GB/Server

        Client Access Server (CAS)

        2GB/Server

        2GB/Core

         (2GB minimum)

        16GB/Server

        Unified Messaging Server (UM)

        2GB/Server

        1GB/Core

         (2GB minimum)

        4GB/Server

        Mailbox Server

        2GB/Server:

        Variable based on Storage Group Count.  See below

        2GB +2MB to 5MB/mailbox:

        Variable based on user profile, see Mailbox Memory Recommendation in table below

        32GB/Server

        Multi Role (Hub, CAS, UM, Mailbox)

        4 GB:

        also depends on number of storage groups (For information, see later in this topic.)

        8 GB plus from 2 MB to 5 MB per mailbox.

        This is variable based on user profile. For more details, see "Mailbox Server Role" later in this topic.

        32GB/Server

        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:

        Memory Factors/Queued Message

        Memory Consumed

        Per Message Overhead

        3KB

        Per Recipient Overhead

        1KB

        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).

        User Type

        Mailbox Memory Recommendation

        Light

        2GB + 2MB/Mailbox

        Average

        2GB + 3 ½MB/Mailbox

        Heavy

        2GB + 5MB/Mailbox

        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.

        Storage Group Count

        Minimum Required Physical Memory

        1-4

        2GB

        5-8

        4GB

        9-12

        6GB

        13-16

        8GB

        17-20

        10GB

        21-24

        12GB

        25-28

        14GB

        29-32

        16GB

        33-36

        18GB

        37-40

        20GB

        41-44

        22GB

        45-48

        24GB

        49-50

        26GB

        *** 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:

        User Profile

        Heavy->Very Heavy

        Primary Client  (Weekday working hours)

        Outlook 2003/2007 Cached Mode (MAPI/RPC)

        Primary After Hours/Weekend Clients

        Outlook 2003/2007 Cached Mode (RPC/HTTPS) & OWA

        Percentage of user base utilizing AirSync

        25%

        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.

        Role Ratio

        Processor Core Ratio Rule of Thumb

        Mailbox:Hub

        7:1 (no A/V on Hub)


        5:1 (with A/V on Hub)

        Mailbox:CAS

        4:1

        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:

        SMTP Connections/Sec

        55

        % Connections Accepted

        80%

        Avg. Recipients/Msg

        1.25

        Recipients Rejected/Sec

        3.5

        SMTP Messages IMF Scanned/Sec

        3.7

        % SMTP Messages passed IMF Scanning

        80%

        SMTP Messages A/V Scanned/Sec

        3

        Avg. Message Size

        70KB

        CPU Utilization

        20%**

        ** 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 :

        Creating Outbound Dialing Rules in Exchange Server 2007

        $
        0
        0

        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

        Name

        Number Mask

        Dialed Number

        Comment

        Low-rate

        91425xxxxxxx

        9xxxxxxx

        Low rate calls

        Low-rate

        9425xxxxxxx

        9xxxxxxx

        Low rate calls

        Low-rate

        9xxxxxxx

        9xxxxxxx

        Low rate calls

        Local

        91704*

        9704*

        Local calls

        Local

        91980*

        9980*

        Local Calls

        Long-distance

        9408*

        91408*

        Long distance calls

        Long-distance

        9512*

        91512*

        Long distance calls

        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

        Name

        NumberMask

        DialedNumber

        Comment

        local

        91405*

        9405*

        local call

        low-rate

        91425xxxxxxx

        9xxxxxxx

        low rate call

        low-rate

        9425xxxxxxx

        9xxxxxxx

        low rate call

        low-rate

        9xxxxxxx

        9xxxxxxx

        low rate call

        long-distance

        9409*

        91409*

        low rate call

        local

        91408*

        9408*

        local call

        local

        91425*

        9425*

        local call

        long-distance

        9609*

        91609*

        local call

        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 –

        Caller Type

        Scope

        Applied Restriction

        Subscriber Access

        Caller logged on to mailbox

        UM Mailbox Policy

        Anonymous Caller

        Called the main pilot number

        UM Dial Plan

        Anonymous Caller

        Called the Auto Attendant pilot number

        Auto Attendant

        Internal Caller

        Play on Phone

        UM Mailbox Policy (prior to build 8.0.650 it is Dial Plan)

        - Seema Rahman

        Fax in Exchange 2007 Unified Messaging

        $
        0
        0

        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

        Introducing Unified Messaging in Office Communications Server 2007 environment

        $
        0
        0

        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

        Free Exchange Server 2007 Unified Messaging course (for a limited time)

        $
        0
        0

        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 Showcase white paper on Exchange Server 2007 Unified Messaging

        $
        0
        0

        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:

        - Nino Bilic

        Unified Communications Launch 2007

        $
        0
        0

        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

        Thoughts on Unified Communications Launch Today

        $
        0
        0

        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 :

        INTERACT2008

        $
        0
        0

        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 RoundTableTM, 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

        Speeding up installation of Exchange Server 2007 SP1 Prerequisites on Windows Server 2008

        $
        0
        0

        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

        New Unified Communications (UC) user group covering Pacific Northwest and beyond

        $
        0
        0

        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

        Exchange 2007 managed services might time out during certificate revocation checks

        $
        0
        0

        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 :

        Voice Mail and Discoverability with Exchange 2007 Unified Messaging

        $
        0
        0

        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 :
        Viewing all 172 articles
        Browse latest View live


        <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>