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

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

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

Creating a Default Call Answering Rule

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

Figure 1: Call Answering Rule Control

Anatomy of a Call Answering Rule

Each Call Answering Rule comprises two key aspects:

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

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

Figure 2: Call Answering Rule Form

Conditions

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

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

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

Actions

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

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

Adding a Find-Me action

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

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

Figure 3: Find-Me Dialog

Adding a Call Transfer option

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

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

Figure 4: Call Transfer Dialog

Adding Voice Mail action

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

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

Saving the rule and trying it out

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

Optional: Record a customized greeting

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

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

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

-Chun Yong Chua

Share this post :

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

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

Figure 1. Exchange UM voice mail in the Inbox

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

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

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

Figure 2. Voice Mail Preview (sample message)

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

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

- Michael Wilson

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

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

Figure 1: Example of Exchange 2010 UM fax message.

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

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

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

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

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

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

- Katarzyna Puchala

References:

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

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

John Robinson

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

The survey can be found here.

Thank you for your time!

- Brendan Reeves
(User Experience Researcher)

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

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.

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:
  • Check the event log on the mailbox server
    • Increase the UM MWI event logging level on the Mailbox server
  • Identify the UM IP Gateway and UM server
  • On the UM server look for a SIP OPTIONS failure
  • Increase the UM MWI event logging level on the UM server
  • Check connectivity between the UM server and the UM IP Gateway.
• New Unified Messaging server event ID for SIP OPTION failures
• Summary of settings to validate
• Useful links

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.

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

• Understanding Message Waiting Indicator -An in-depth description of the MWI.
• Configure the TCP Listening Port on a UM IP Gateway -Settings to use TLS (Transport Layer Security) with gateways.
• Error and Event Reference for Unified Messaging Servers -UM events and their description text.
• Understanding Unified Messaging IP Gateways -Description of IP Gateways and objects.
• An IP gateway or IP PBX didn't respond to a SIP OPTIONS request from the Unified Messaging server -Description of the event ID 1400 for the System Center Operations Manager Exchange Server 2010 Management Pack.
• MSExchange Unified Messaging 1400 -Description of the event ID 1400.

Jon Ernast

Update 12/13/2016: Please see the December 2016 Quarterly Exchange Updates blog post for updates on this subject.

We wanted to raise your attention to an issue that some customers have reported running Exchange Server 2016 on Windows Server 2016. Crashes of the IIS (W3WP.exe) process have been reported causing instability of Exchange Server on Windows Server 2016. The Exchange team has worked with the Windows team to isolate the source of the problem. An update for Windows Server 2016 will be made available to resolve this issue. Microsoft recommends that customers delay deploying Exchange Server on Windows Server 2016 until this update is made available. For the latest guidance on known issues, please consult the Windows Server release notes on TechNet.

When there are updates on this, we will update this blog post.

The Exchange Team

Multi-Factor Authentication (MFA), which includes Two-factor authentication (2FA), in Exchange Server and Office 365, is designed to protect against account and email compromise.

Microsoft has evaluated recent reports of a potential bypass of 2FA. We have determined that the technique described is not a vulnerability and the potential bypass does not exist on properly configured systems.

The reported technique does not pose a risk to Exchange Server or Office 365:

• In Exchange Server, authentication configuration settings for client endpoints are not shared across protocols.  Supported authentication mechanisms are configured independently on a per protocol endpoint basis.  Multi-Factor Authentication in Exchange Server can be enabled in multiple ways, including OAuth.  Before implementing MFA with Exchange Server it is important that all client protocol touchpoints are identified and configured correctly.
• In Office 365, when Azure MFA is enabled within a tenant, it is applied to all supported client protocol endpoints. Exchange Web Services (EWS) is an Office 365 client endpoint which is enabled. Outlook on the Web (OWA) and Outlook client access are also enabled in Office 365. Office 365 users may experience a small delay in activation of MFA on all protocols due to propagation of configuration settings and credential cache expiration.

Additional information on enabling OAuth in Office 365 and Exchange Server can be found on Office.com and MSDN.

The Exchange Team

If you are using Public Folders (legacy or Modern) and would like to migrate some of them to Office 365 Groups, we are working on a solution for that. We are starting with the migration of Calendar folders and will move on to other types as we complete work on calendars. We would like to have customers who would like to try this migration to provide feedback. Please email us with below information if interested. You can also send us your information if you would like to try migrating other types of public folders (other than Calendar) as we extend the support to those folder types.

Drop us an email at: pftogroupmigration@service.microsoft.com

• Customer name:
• Tenant domain name in Exchange Online:
• Location of public folders; on-premises or Exchange Online:
• If on-premises, Exchange version of public folder servers:
• Public folder types to migrate (Mail, Calendar, Task, Contact):
• Expected month/year of migration:

Your organization might need to join our TAP program (depending on public folder location) – and if so, we will share those details with you after reviewing the above.

Public Folder Migration team

We are in the process of rolling out a new migration experience that will greatly simplify your journey to Office 365 and Exchange Online.

This new experience will help any customer running at least one Exchange 2010, 2013 and/or 2016 server on-premises to migrate to the cloud seamlessly. When you initiate the migration, we evaluate what you have configured already in Exchange Online and we walk you through the Hybrid Configuration Wizard to evaluate the on-premises environment. Once all the information on your current state is collected, we ask a couple of questions about your desired state (things like how fast you want to move to Exchange Online and whether you require advanced features). The hybrid wizard then walks you through the configuration needed to migrate your users to Exchange Online.

Based on your current configuration and the options selected while running the hybrid wizard, you will be taken down one of the following paths.

• Full Hybrid: This is a common configuration for customers that are larger in size and will take some time to migrate or customers that will not be able to move all their mailboxes to Exchange Online in the short to medium term. This is the most complex option to configure, but will give you enhanced features like cross-premises free/busy and enhanced mail flow options. For more on Full Hybrid you can go here.
• Minimal Hybrid: This is a recently introduced option that was added to the Hybrid Configuration Wizard in June. It allows you to configure your environment to support hybrid migrations and recipient administration without the need for the additional overhead of configuring free/busy and other enhanced features of full hybrid. Often this is used for customers that want to move all their mailboxes to Exchange Online over the course of a couple of months or less, but want to keep directory synchronization in place. For more information on Minimal Hybrid please go here.
• Express Migration: The newest option we have added is the Express Migration. This is the path in the Hybrid Configuration Wizard that will benefit smaller customers or a customer that truly wants to move to Exchange Online over the course of a couple of weeks or less. If you have a need to keep directory synchronization in place, then this is not the option for you. This option will configure your users and walk you through the new migration experience to get the mailboxes to Exchange Online with minimal disruption for your users.

More About Express Migration

In the past, an administrator of the small to medium business had to choose to either take the complex configuration route of hybrid or the complex user experience of a cutover or staged migration. Now you can get a greatly simplified Express Migration experience.

With the Express Migration option, you will get a onetime directory synchronization of your users along with the Minimal Hybrid configuration to allow you to perform the migrations. After that initial synchronization of user accounts, directory synchronization will be automatically disabled in both Office 365 and on-premises. This will give small and medium customers that would have previously perform a cutover migration the ability to get the benefits of the hybrid migration without the overhead.

The following are the benefits of performing an Express Migration over a more traditional cutover migration:

• Usernames and passwords will sync from on-premises
• Users will not have to recreate Outlook profiles
• Mail flow will continue to work between users before, during, and after the migration
• There is essentially no down time for users during the migration

How to initiate the migration

All the migration approaches discussed in this article (Full, Minimal, and Express) can be initiated from one interface now. We will guide you to the proper option as we go.

One of key components in this new experience is the migration pane. This is a new pane we have created in the Office 365 Admin Portal that will match the modern look and feel of the rest of the portal. However, it is not just the look and feel that is revamped, we also have a lot of intelligence built in. For instance, when you enter the migration pane we will detect if you have executed the Hybrid Configuration Wizard, already synchronized your users, and whether there is a migration endpoint already created. Depending on what is already in place we can take you toward the proper migration approach.

To get to the new migration experience you will have to expand the “Users” section in the portal (Http://portal.office.com) and then select the “Data Migration” option. Once there, select the Exchange email source to initiate the experience. This is a page where we list various sources from where you can migrate. In this case, you would select the Exchange option.

Once the source is selected we perform a quick check of the tenant to see if you have executed the Hybrid Configuration Wizard. If you have not yet executed it, that means we know you have not prepared your on-premises environment for migration. Therefore, we will take you through downloading and running the hybrid wizard.

When in the hybrid wizard you will see a welcome screen, just select next on that:

You will then see the Server detection screen, again just select next since the correct server should be detected. By default, we will try to connect to the Exchange server running the latest version.

Provide your credentials for both Exchange on-premises and Exchange Online.

Select the appropriate migration option. For this example, we are demonstrating Express Migration so we will select the Minimal Hybrid option.

Select update, which will perform all the configurations needed to allow you to start moving mailboxes at a later step.

Next up: Provisioning users

If you have not synchronized your users already at this point you will see an option to perform a onetime sync of your users or to install AAD Connect separately. As mentioned, if you plan on moving all of your mailboxes to Exchange Online and do not have the need to keep directory synchronization around, then select the one-time sync option. Selecting this option is what we consider an “Express Migration”. If you need directory synchronization for any reason, then you need to install and setup AAD Connect separately.

Note: if you did select the one-time sync and later decided that you do need to have directory synchronization, you can setup AAD Connect to perform directory synchronization.

If you did not select Minimal Hybrid as an option in the wizard, then you will not be given the one-time directory synchronization option. The reason you would not get it if you opted for Full Hybrid is because that deployment scenario requires the advanced coexistence features and directory synchronization.

Once the option for “Synchronize my users and passwords one time” is selected, the hybrid wizard displays a progress bar. The wizard is waiting for the AAD Connect to be configured and for the initial set of users to synchronize.

To complete the hybrid configuration setup, you will need to configure AAD Connect. In almost all cases the default options in AAD Connect are the best options.

Once completed you will see the ending page for the hybrid application that will allow you to give feedback. Once closed you will be taken to the user list page to start moving mailboxes.

On the user list page you will have the option to select the users you want to migrate. Under the hood this is using MRS to migrate the users just like a hybrid migration. You can use this new pane to migrate mailboxes, regardless of the hybrid deployment option chosen. The experience is as simple as selecting the users and clicking start migration. At that time, we will perform a lookup to see if the prerequisites are in place. If anything is missing, we will walk you through taking care of the missing prerequisite.

Limitations

There are some limitations with the new Migration pane that need to be called out. We are working to overcome these limitations in the future:

• Only one migration endpoint is supported: If there is more than one endpoint we will choose the one created by the Hybrid wizard or by the new Migration experience.
• Only one batch can be started at a time: we do not yet support multiple batches with this migration pane. This means that you need to wait for the previous migration to finish before you can start another migration. We know multiple batch support is important for medium and larger customers, we have this as a top priority.
• We do require you license users separately: we require that all users being migrated through this experience be licensed before the migration begins (except for shared mailbox object type), this is not an automatic process so you need to license users before migrating.

Conclusion

These updates will make the Exchange Online onboarding experience more seamless for many Exchange customers. We have created and are continuing to improve the Migration pane to meet the needs of our customers. While running through the experience if you have any feedback please use the provided feedback button that are available throughout the experience.

Office 365 On-boarding Team

Introduction

Since the release of Microsoft Exchange Server 2013, we have heard questions regarding the sizing and deployment of modern public folders. It is important to plan migrations for public folders so the client experience with their use is good. In this blog post, we will discuss some of best practices and recommendations regarding modern public folder deployment as well as discuss various related concepts. We will assume that you are already familiar with basic modern public folders concepts so we will not go there (but might link to relevant articles).

There is a lot here as we are going through several examples. Use it as a reference!

How clients connect to the public folder hierarchy mailbox

When the user launches the Outlook desktop client on Windows or Mac, client contacts the Autodiscover service to determine connection settings for the user’s primary mailbox and their archive mailbox if they have one. During the initial response, the Autodiscover service may indicate there are public folders available in the environment by including an XML element named <PublicFolderInformation>. This element will contain the SMTP address of a public folder mailbox within the environment. An additional Autodiscover request will be made to request connection settings for the SMTP address of the public folder mailbox.

To provide a value for this element during the initial request/response interaction, the Autodiscover service calls a function named GetPublicFolderRecipient. This function gathers information for the available public folder mailboxes in the environment available for serving hierarchy connections.

In most cases the GetPublicFolderRecipient function will (randomly) pick a public folder mailbox from the available list to be handed over to the Autodiscover Service, which in turn gets returned to the client.

Another possibility is that the user’s mailbox has a static DefaultPublicFolderMailbox assigned. When a mailbox has a default public folder mailbox assigned, the client will always attempt to connect to this public folder mailbox for hierarchy connections. If that public folder mailbox is not available for some reason, the client will fail to reach the public folder infrastructure and will not fall back to a random public folder mailbox. Something to keep in mind!

Note: In the case of Outlook on the web (we’ll call it OWA for short) clients accessing public folders, public folder mailbox access does not rely on the Autodiscover service even though the same selection process logic is used. In other words, OWA uses similar functionality that the Get-Mailbox cmdlet uses to get list of available public folder mailboxes the user can utilize. Even if Autodiscover is offline for some reason in the environment, you may see users successfully accessing public folders via OWA, but not Outlook clients.

When are new mailboxes eligible for this process?

By default, all public folder mailboxes deployed in the environment can serve hierarchy connections to the clients. However, immediately after creation a new public folder mailbox will not be used by Autodiscover. This is due to the newly created public folder mailbox has not yet completed an initial full hierarchy sync from the primary hierarchy public folder mailbox. This logic is automatically calculated and is reflected in the parameter IsHierarchyReady. By default, the value will be set to $False. If this value remains $False, the GetPublicFolderRecipient function will not return that public folder mailbox to the Autodiscover Service as it is assumed to contain an incomplete copy of the hierarchy (a user connecting to it would not have a complete view of the public folder infrastructure). Once the value of the newly created public folder mailbox’s IsHierarchyReady has changed to $True, the Autodiscover service will be able to hand it out to clients.

Under normal conditions this initial full hierarchy sync should start automatically within 24 hours of the public folder mailbox being created. You may also invoke the hierarchy sync manually if you so choose by using the below command:

Update-PublicFolderMailbox -Identity “Public folder mailbox name” -SuppressStatus -Fullsync -InvokeSynchronizer

The time it takes for the fully hierarchy replication to complete depends on several factors such as (but not limited to) network speed, number of public folders, geographical location of PF mailboxes, and connection load on the primary hierarchy mailbox.

The initial hierarchy sync happens using a pull operation model. The secondary public folder mailboxes will poll the primary hierarchy public folder mailbox to fetch the hierarchy information. Once the initial FullSync is complete, the value of IsHierarchyReady will change to True automatically and the public folder mailbox will be available to serve the hierarchy information to requesting clients.

To confirm, the following command can be run:

Get-Mailbox -PublicFolder | fl name,ishierarchyready

Note: While IsHierarchyReady value can be manually forced to True using PowerShell, this is not supported. Doing this can cause the public folder mailboxes to serve incomplete hierarchy to clients. The recommendation is wait for the initial sync to complete or manually invoke the hierarchy sync to get the hierarchy replicated to the new public folder mailboxes.

Once the initial hierarchy sync is complete for the public folder mailbox, the next hierarchy sync hereon will happen using the push model, where the primary hierarchy mailbox will push the changes to the secondary hierarchy public folder mailbox every 10 minutes.

Another setting an administrator has at their disposal is the attribute IsExcludedFromServingHierarchy. This attribute can be set to $False (default) or $True using the Set-Mailbox cmdlet and will prevent this mailbox from being used by Autodiscover or OWA to serve hierarchy connections to clients. Even after IsHierarchyReady becomes automatically set to $True the public folder mailbox will be excluded from Autodiscover and OWA hierarchy usage if IsExcludedFromServingHierarchy is set to $True. This option is useful when you want a public folder mailbox utilized only for content of public folders and can be set immediately after the public folder mailbox is created.

Note: If DefaultPublicFolderMailbox is populated on a user mailbox it will override the $True value of IsExcludedFromServingHierarchy (on the mailbox they are connecting) and will allow that user to connect to the public folder mailbox specified in DefaultPublicFolderMailbox for hierarchy. We will discuss this later in the post.

Scenario 1: What happens when default public folder mailbox value has not been set on the user mailbox?

Let’s say we have 50 public folder mailboxes in their default state, all of which have sync’d hierarchy, and there are 20,000 users who try to access public folders. The Autodiscover service will provide a random public folder mailbox to each user to service hierarchy requests.

The specific public folder mailbox being returned to the client can change randomly, or if Outlook is closed and reopened, based on what GetPublicFolderRecipient function returns to Autodiscover which in turn returns the data to the client.

On the client side, public folder mailboxes being accessed will appear under the connection status in Outlook, as shown below:

The first public folder GUID value in here is a random primary public folder hierarchy mailbox. The remaining public folders GUIDs are populated and returned when user tries to access individual public folders which reside within those public folder mailboxes.

Scenario 2: Restricting clients to contact a specific public folder mailbox for hierarchy.

It is possible to override the behavior of random selection of default public folder hierarchy mailbox.

First, you need to confirm that the public folder mailbox has IsHierarchyReady populated with value of $True which confirms that it has completed its initial full hierarchy sync with the primary public folder mailbox.

Run the command:

Get-Mailbox -PublicFolder “Public Folder mailbox name” | FL Name,ExchangeGuid,*Hierarchy*

Once the above is confirmed, the next step is to assign the desired public folder mailbox as the DefaultPublicFolderMailbox on the user mailbox. In our example this would be accomplished by running the below command:

Set-Mailbox “user mailbox identiy” -DefaultPublicFolderMailbox “PF-MBX-002” -Verbose

Now, when the client opens Outlook, Autodiscover provides the DefaultPublicFolderMailbox’s SMTP address in the <PublicFolderInformation> XML element and the client then performs a second Autodiscover request to learn how to connect to this public folder mailbox.

When we check the Outlook connection status, it will list the assigned public folder mailbox.

Scenario 3: Setting the default public folder mailboxes close to the user’s location for better client experience

Our customers deal with communication links that may be highly latent and expectedly inoperable for periods of time. For demonstration purposes let’s consider our favorite company called Contoso which has the following configuration:

Three company sites are listed below:

• Hyderabad: India with 23,000 mailboxes. Local servers have 10Gbps LAN connectivity and there are three public folder mailboxes in this site.
• Adelaide: Australia with 5,000 mailboxes. Local servers have 10Gbps LAN connectivity and there is one public folder mailbox in this site.
• A cruise ship with 500 mailboxes for employees on-board. Local server has 1Gbps LAN connectivity and there is one public folder mailbox per ship.

To maintain communications with their ships at sea, Contoso has established a 384Kbps satellite link to each ship and has also installed a dish at their Hyderabad site. All network routes to/from ships are routed via Hyderabad’s own satellite link.

Contoso has also purchased 1Gbps of bandwidth on a submarine cable link to Australia. All WAN routes to/from Australia site traverse this link.

Challenges with the above deployment

If we were to simply deploy modern public folders with all the default values, we could see some interesting things happen. For example, all users could be offered any of the five public folder mailboxes for hierarchy regardless of their location.

The worst-case scenario here would be a ship based user trying to access PFMBX-AUS-001 for hierarchy information or an Adelaide based user trying to access PFMBX-SHIP-001 for hierarchy information. In either of those scenarios we see client traffic traversing round-trip not only along the longest network path, but also the one with the least bandwidth and most latency. In this extreme example, you would more than likely have clients calling the help desk reporting the Outlook RPC popup after they attempted to expand the public folder tree.

Considering the above problems, we recommend administrators with similar decentralized and complex network topologies consider configuring user mailboxes to access public folder mailboxes located within local or geographically closer sites as their default public folder mailbox.

What would work better?

In an environment like the one in the example, it may make sense to set IsExcludedFromServingHierarchy to $True for the public folder mailboxes on all cruise ships and Australia. This will remove them from being returned as valid public folder hierarchy endpoints for Autodiscover and OWA, leaving only the three well-connected Hyderabad based public folder mailboxes setup for automatic discovery.

Additionally, the DefaultPublicFolderMailbox attribute at the mailbox level should be utilized for employees based on the cruise ship or the Australia continent to ensure they always attempt to connect to a public folder mailbox that makes sense based on their geolocation. One caveat here is if a user from the Australia office were to visit the cruise ship (for work purposes sadly and not fun in the sun!), their client would continue to connect back to Australia for their PF hierarchy connection. In addition, the Hyderabad office with 23,000 mailboxes would need to monitor user concurrency to determine if they need additional public folder mailboxes or not over time to stay within supported user concurrency limits.

Things to remember and plan during the deployment:

1. Understand the company topology completely before making any decision to deploy public folders for offices located in different geographical locations. Correct deployment of public folders using the recommended approach will make life easier for administrators and end users.
2. Make use of the attribute IsExcludedFromServinginHierarchy by setting it to $True when it makes sense to exclude public folder mailboxes from being discovered by Autodiscover for providing hierarchy information to clients and avoid any unwanted connections.
3. The DefaultPublicFolderMailbox attribute at the mailbox level should be considered when you need to ensure the users in less-connected sites must connect to public folder mailboxes close to their geographical location for hierarchy information. Misconfiguration can lead to serious issues such as latency in accessing public folder information and poor end user experience.
4. No more than 2000 active connections being made to the same public folder mailbox at any point of time are currently supported. This will require advanced planning, to ensure that the public folders being heavily used by the clients are being distributed across the public folder mailboxes, which are in turn close to the user’s geographical site for better access and experience if necessary.
5. You can add one or more additional Hierarchy Only Secondary Public Folder Mailboxes (HOSPFM) and Content Only Secondary Public Folder Mailboxes (COSPFM) depending upon the geographical location and identification of commonly used public folder mailboxes by the end users for better end user experience. Yeah, we like our acronyms. Yup, we just made that up.

What are those (HOSPFM) and (COSPFM), and why do we require them?

• Hierarchy Only Secondary Public Folder Mailbox (HOSPFM): does not contain public folder content and only serves hierarchy. IsExcludedFromServingHierarchy is set to False
• Content Only Secondary Public Folder Mailbox (COSPFM): has public folder content in it but is excluded from serving hierarchy. IsExcludedFromServingHierarchy is set to True

There are 2 type of connections being made to the public folder mailbox, when it is accessed.

1. Hierarchy connection
2. Content connection

Public folder mailbox connections (both hierarchy and content) should not exceed 2000 to remain within the support boundaries. Given this requirement, you should plan to have enough public folder mailboxes serve hierarchy and/or content so that you maintain a level of less than 2000 active and simultaneous client connections per secondary public folder mailbox.

The primary public folder mailbox must be excluded from providing hierarchy to clients (IsExcludedFromServingHierarchy parameter set to True). This allows the primary public folder mailbox to spend its time maintaining the hierarchy and dealing with hierarchy replication tasks. Overloading this public folder mailbox with client connections can in turn lead to performance and reliability issues with your PF hierarchy.

How to move the public folder data close to the user’s geographical location

Consider another company also called Contoso, which has many offices around the world and modern public folders have been deployed in the environment. Sarah is a user whose mailbox is in a datacenter which is in India and she frequently works with public folders. There is another large group of users who also frequently work with the same set of public folders, but they are in a different geographical location, in Australia.

The public folders being accessed are in the India site, close to Sara’s geographical location, so she has a better experience when accessing public folders.

In contrast, when Australia users try to connect to public folder mailboxes, the local hierarchy public folder mailbox in their datacenter will provide the content location for required public folders. Users will initiate a connection to the actual public folder located in India holding the content for the public folder. Since the actual folder content is in different geographical location, the connection request may be not as performant for the Australian group of users, resulting in user frustration.

This deployment is not recommended. The focus should be on identifying the most frequently used public folders by a common set of users, and moving the public folders with that content closer to users’ location. In this scenario, the content should be moved closer to the larger group of users in Australia.

Note: Moving public folders only moves the physical contents of the public folder; it doesn’t change the logical hierarchy, or layout of folders in the folder tree.

To move the public folder content, run the command:

New-PublicFolderMoveRequest -Folders “\path of the public folder to be moved” -TargetMailbox “target public folder mailbox name”

Note: To verify that the PublicFolderMoveRequest is complete, the command Get-PublicFolderMoveRequest can be run.

Like mailbox move requests, completed public folder move request must be removed before any other public folder can be moved to another public folder mailbox. To do this, run the command Remove-PublicFolderMoveRequest. If any other public folder move request is initiated without removing the old request, it will error out like this:

To remove the existing PublicFolderMoveRequest, run the command:

Get-PublicFolderMoveRequest | Remove-PublicFolderMoveRequest

Note: If a parent public folder and its subfolders need to be moved to another public folder mailbox, this can be done using Move-PublicFolderBranch.ps1 script, located in \scripts folder.

For more details, see: Move a public folder to a different public folder mailbox

Once the public folder content has been moved to a different public folder mailbox, users in Australia site accessing the public folder will be updated by the local public folder mailbox hierarchy connection to the folder’s new content location and connect to the local public folder mailbox. To continue with our example, Sarah will continue to connect to local public folder mailbox for hierarchy (which has been set by the administrator), but will then get her content from the Australia datacenter. Even though the experience may not be as great for that one user, Sarah can add frequently used public folders to Favorites using Outlook client or OWA to help with latency issues.

Looking at the above example, it becomes very important to determine network latency and bandwidth before you start deployment of public folder mailboxes in geographically dispersed environment to avoid any latency issues when accessed by end users. In such situations, the recommendation will be to use tools like Netmon which can help in determining the connections happening to public folder mailboxes. There is a great tool written by Mark Russinovich called Psping, which can be helpful in determining the round-trip latency. Based on the results customers can decide whether the current network is suitable for their environment or if there are any changes that needs to be done.

Summary: deployment considerations

Considerations when deploying public folder mailboxes in the organization, to ensure they are protected and readily available to the clients:

• Public folder mailboxes, both hierarchy and content, should be protected by placing them in databases protected by multiple copies in a Database Availability Group. By doing this, mailboxes will remain protected in case of any outage and be available to end users.
• There should be no public folders hosted within the primary public folder mailbox. This way we dedicate the primary public folder mailbox to specifically focus on its job of replicating hierarchy changes to other public folder mailboxes.
• You should exclude the primary public folder mailbox from serving hierarchy to clients. This is done by setting the IsExcludedFromServingHierachy to $True.
• The recommendation is to activate database copies hosting public folder mailboxes on mailbox servers which are geographically located close to the client location.
• The general recommendation is having one public folder hierarchy mailbox for every 2000 users accessing public folders. Additional hierarchy only public folder mailboxes can always be created to divide the connection load among users to ensure that the 2000 connection limit is not reached.
• Plan and create more secondary hierarchy public folder mailboxes and content mailboxes to ensure there are fewer than 2000 active and concurrent connections to public folders and that they are close to the users geographical location to ensure there are no latency issues and users have good experience.
• Since Exchange Server 2016 CU3 has released, you can make use of up to 1,000 public folder mailboxes. Of the 1,000 public folder mailboxes, 100 of them can be used for hierarchy (or 99 once you exclude the primary PF) and the remaining 900 can be used for content storage.

Post summary

In the above post, we have provided information on how public folder mailboxes are accessed, and the importance of correctly deploying them in a geographically dispersed environment. In upcoming posts, we will discuss topics related to public folder logging analysis, management and quota related information

We would like to say thanks to Public Folders Feature Crew team for their valuable inputs while this blog post was being written.

Special Thanks to Ross Smith IV, Nasir Ali, Scott Oseychik for reviewing this content and validating the guidance mentioned in the blog post and Charlotte Raymundo, Nino Bilic for helping us to get this blog post ready!

Siddhesh Dalvi and Brian Day

Today we are announcing the latest set of Cumulative Updates for Exchange Server 2016 and Exchange Server 2013. These releases include fixes to customer reported issues and updated functionality. Exchange Server 2016 Cumulative Update 4 and Exchange Server 2013 Cumulative Update 15 are available on the Microsoft Download Center. Update Rollup 22 for Exchange Server 2007 Service Pack 3 and Update Rollup 16 for Exchange Server 2010 Service Pack 3 are also available.

A new Outlook on the web compose experience

Exchange Server 2016 Cumulative Update 4 includes a refresh to the compose experience. The body of the message is now “framed” and formatting controls have been moved to the bottom of the view. This mirrors the current experience in Office 365.

Support for .Net 4.6.2

Exchange Server 2013 and Exchange Server 2016 now fully support .Net 4.6.2 on all supported operating systems. Customers who have already updated their Exchange servers to .Net 4.6.1 can proceed with the upgrade to 4.6.2 before or after installing the cumulative updates released today. Customers who are still running .Net 4.5.2 are advised to deploy Cumulative Update 4 or Cumulative Update 15 prior to upgrading to .Net 4.6.2.

The upgrade to .Net 4.6.2, while strongly encouraged, is optional with these releases. As previously disclosed, the cumulative updates released in our March 2017 quarterly updates will require .Net 4.6.2.

Change to Pre-Requisites installed by Setup

Since Exchange Server 2013, the Windows feature Media Foundation has appeared as a pre-requisite in our setup checks on Windows Server 2012 and later. However, if you chose to allow Exchange setup to install the required OS Components, Desktop Experience has been installed on all supported operating systems. Desktop Experience is required on Windows Server 2008R2. The Desktop Experience feature includes additional components which are not necessary for Exchange Server and require frequent patching. Windows Server 2012 and later modified feature definitions to include Media Foundation. Exchange Setup in Exchange Server 2016 Cumulative Update 4 and Exchange Server 2013 Cumulative Update 15 has been updated to install Media Foundation instead of Desktop Experience on Windows Server 2012 and later. This change will only apply to newly installed servers. Applying either cumulative update will not change the existing configuration of the server. If desired, an administrator can add Media Foundation and remove Desktop Experience from the list of installed Windows features on Windows Server 2012 and later.

Update on Windows Server 2016 support

The Windows team has released KB3206632. This update addresses the issue where IIS would crash after a DAG is formed and the server is subsequently restarted. This update is now required on all servers running Exchange Server 2016 on Windows Server 2016. Setup will not proceed unless the KB is installed.

Latest time zone updates

All of the packages released today include support for time zone updates published by Microsoft through October 2016.

Important Public Folder fix included in these releases

Exchange Server 2013 Cumulative Update 14 and Exchange Server Cumulative Update 3 introduced an issue where new posts to a public folder may not have been indexed if there was an active public folder migration (KB3202691). This issue is now resolved. To ensure all public folders are indexed appropriately, all public folder mailboxes should be moved to a new database after applying the appropriate cumulative update released today.

Release Details

KB articles which contain greater depth on what each release includes are available as follows:

• Exchange Server 2016 Cumulative Update 4 (KB3177106), Download, UM Lang Packs
• Exchange Server 2013 Cumulative Update 15 (KB3197044), Download, UM Lang Packs
• Exchange Server 2010 Service Pack 3 Update Rollup 16 (KB3184730), Download
• Exchange Server 2007 Service Pack 3 Update Rollup 22 (KB3184712), Download

Exchange Server 2016 Cumulative Update 4 does not include new updates to Active Directory Schema. If upgrading from an older Cumulative Update or installing a new server, Active Directory updates may still be required. These updates will apply automatically during setup if user permissions and AD requirements are met. If the Exchange Administrator lacks permissions to update Active Directory Schema, a Schema Admin needs to execute SETUP /PrepareSchema prior to the first Exchange server installation or upgrade. The Exchange Administrator should also execute SETUP /PrepareAD to ensure RBAC roles are updated correctly.

Exchange Server 2013 Cumulative Update 15 does not include updates to Active Directory, but may add additional RBAC definitions to your existing configuration. PrepareAD should be executed prior to upgrading any servers to Cumulative Update 15. PrepareAD will run automatically during the first server upgrade if Setup detects this is required and the logged on user has sufficient permission.

Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

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

For the latest information on Exchange Server and product announcements please see What’s New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

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

The Exchange Team

Many organizations have been using certificate based authentication for Exchange Online while the feature was in preview. Today, we are excited to announce that the feature is generally available in Office 365 Enterprise, Business, Education, and Government plans. For more details, please reference our preview post which has been modified to reflect this announcement. As always, we look forward to hearing your suggestions and feedback!

Tyler Lenig
Program Manager
Office 365

We are interested in working with Exchange 2016 customers or partners to help us validate Exchange hybrid scenarios using Microsoft Graph. This will be a self-paced development project where your developers will scope and get technical help to unblock Graph API issues from the product team. In order to participate, you will need to join the Exchange TAP program. Here is a mini FAQ about this program:

What are the technical requirements?
To develop and validate an Exchange hybrid solution, you will need to have Exchange 2016 CU3 or later deployed with your on-premises Active Directory synced with Azure AD. To learn more about the hybrid deployment: https://channel9.msdn.com/Events/Ignite/2016/BRK3045

How many developers will I need?
Expect to have 1 maybe 2 developers to scope and develop a Microsoft Graph solution.

Do I need to have an existing Exchange Web Services solution?
It would be a nice-to-have but we do not require it. We’re more interested in finding customers who want to support hybrid Exchange 2016 deployments and validating the benefits that the Microsoft Graph provides.

What is the timeframe for this?
We are planning to start this project in January 2017 and look to finish before the summer of 2017.

Do we have to travel to Redmond?
No. The tech is already in Preview and available to use from any dev laptop with internet access.

Why are you offering this?
We find collaborating directly with our customers and partners help us to make improvements to the Microsoft Graph to support deeper and broader customer needs. We hope to add what we learn to our product roadmap.

If you are interested in applying for this program, then please send an email to exchangehybridgraph@service.microsoft.com and include the following information:

1. Who will be the primary lead for this project?
   • Company:
   • First, Last Name:
   • Business Title:
   • Work e-mail:
   • Work phone:
2. Is your company enrolled in the Exchange TAP?
3. What hybrid scenario do you envision working on?
4. Describe how you would like to technically solve it?
5. Have you or your team tried to solve this hybrid scenario using Exchange Web Services? How did it go?
6. Have you or your team programmatically used the Microsoft Graph? Please describe a project if you have built one.
7. Please tell us about your development team that will work on this project.

Cheers!

Microsoft Outlook Team

Greetings Exchange Community!

Today, I am pleased to announce the release of a major update to the Exchange Generate Message Profile script. This release primarily focuses on two enhancements.

The first enhancement is the script will now use multiple “threads” (currently in the form of PowerShell jobs with Runspaces under consideration for a future version) to collect data from multiple servers simultaneously. This should significantly speed up data collection in environments with a large number of servers in a site. A few notes on this:

1. Each thread creates its own fully RBAC compliant connection to a local Exchange server (defaulting to itself). Because each session is using the RBAC compliant IIS based PowerShell proxy, the CPU utilization of the server running the script is not only increased by the multiple threads that are spawned, but also by the IIS service that they are each are connected to.
2. When run on a full Exchange Server, the script defaults to using the number of threads equal to approximately ¼ of the CPU cores on the server. This helps ensure that by default the script does not use more than ~50% CPU resources on the server running the script, as it accounts for the CPU load of the threads (1/4 = 25%) and the load they place (another 25%) on the IIS service.
3. When run on an system with just the Exchange Management tools loaded, the script default to using the number of threads equal to approximately ½ of the CPU cores of the system.
4. The script will gracefully shut down any background jobs still running if CTRL-C is used to stop the script.

The second enhancement is regarding the script’s behavior of skipping the creation of a message profile for a site when a single server in it is unavailable or has data collection issues. This is still the default behavior of the script, but this behavior can now be overridden by specifying the minimum percentage of servers in a site that must be online and return data for a message profile to still be generated for that site. It is highly recommended to leave this at the default setting, but this requested feature will allow the script to provide even a slightly skewed message profile versus nothing when a small percentage of servers were unresponsive or have data collection issues.

For a complete list of all enhancements and bug fixes please review the Version History on the TechNet Gallery posting.

As always I welcome feedback through the TechNet Gallery posting.

Dan Sheehan
Senior Premier Field Engineer

Today, we released an updated version of the Exchange Server Role Requirements Calculator.

This release focuses on bug fixes with the DAG auto-calculation functionality that was introduced in 8.3, as well as, support for ReplayLagMaxDelay.

In addition to allowing you to configure the ReplayLagMaxDelay value (default is 24 hours), the calculator has also been updated to ensure that the SafetyNetThreshold is configured to a value that is equal to or greater than the sum of ReplayLagTime+ReplayLagMaxDelay.

For all the other improvements and bug fixes, please review the Release Notes, or download the update directly.

As always we welcome feedback and please report any issues you may encounter while using the calculator by emailing strgcalc AT microsoft DOT com.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience