MS Exchange Feeds

In Exchange 2010, you can place a mailbox on retention hold or legal hold. Both holds serve a different purpose. It's important to understand the functionality provided by both.

Retention Hold: As the Messaging Records Management page in the EMC suggests (see Figure 1), retention hold is used to halt retention policy, which means the Managed Folder Assistant (MFA) does not move or delete items from the mailbox. It's typically used when a user may not have mailbox access for an extended duration, for example, when the user's on vacation. You can also use retention hold during the initial phase of MRM deployment and remove it as users become more comfortable with MRM functionality.

Should users access their mailbox when it’s on retention hold, they may notice that items aren’t being deleted or moved to archive. Mailbox size increases as more email accumulates and you may need to raise the user's mailbox quotas to ensure mail flow to and from the mailbox isn’t interrupted.

The mailbox owner or any user (or process) with mailbox access can delete messages when the mailbox is on retention hold. Deleted messages are not treated any differently when a mailbox is on retention hold. Deleted items are retained until the deleted item retention period (14 days by default) and then deleted permanently. See the Retention Hold section in Understanding Retention Tags and Retention Policies for more details.

When placing a mailbox on retention hold, you can specify a start date and an end date. This allows you to configure retention hold in advance, and have it end at a predetermined date. Takeaway: retention hold is for planned activity, suspends move or delete actions taken by the MFA. If you haven't deployed either MRM feature (Retention Tags or Managed Folders), retention hold is unnecessary.

Note: When you archive-enable a mailbox, the Default Archive and Retention Policy is automatically applied to the mailbox if it doesn't have a retention policy.

Litigation Hold: Litigation hold, also known as legal hold, is used to preserve mailbox items for discovery before and during legal proceedings, investigations or similar events. The goal is to preserve mailbox items from inadvertent or purposeful modification or deletion by the mailbox owner or any user with mailbox access, and also automated deletion by processes such as the MFA. Unlike retention hold, you can’t configure litigation hold to start and end at a specified date – it’s either enabled or not. Until the hold is removed, deleted items are not purged from the mailbox database. If mailbox items are modified, a copy of the original item is also retained. These are returned in Discovery searches performed when the mailbox is on litigation hold. See Understanding Litigation Hold for more details.

When you place a mailbox on litigation hold, Exchange also populates the LitigationHoldDate and the LitigationHoldOwner properties, which can be useful for tracking purposes. Note that an administrator can modify the LitigationHoldDate and LitigationHoldOwner properties. Admin audit logging is the best place if you're looking for reliable audit trail of admin actions.

Tip: You can run a litigation hold report from the Exchange Control Panel by going to Roles & Auditing > Auditing > Run a litigation hold report....

Mailbox quotas for mailboxes on hold

Both types of hold will result in more data being stored in a mailbox. Understandably, both may require some adjustments to storage quotas. Mailboxes on retention hold may require higher mailbox quotas because the MFA doesn’t delete items or move them to the user’s archive mailbox.

Mailboxes on litigation hold don’t require a higher mailbox quota because the user and MFA continue to delete messages, which are then retained in the Recoverable Items\Purges folder until the hold is removed. In Exchange 2010, Recoverable Items does not count towards the mailbox storage quota because it has its own quota. For details, see Understanding Recoverable Items.

At 20 GB and 30 GB, the Recoverable Items Warning Quota and Recoverable Items Quota are set to fairly high defaults. Depending on how long a mailbox user is on litigation hold and the volume of email the mailbox receives, the Recoverable Items folder may reach its quota limits. It’s recommended that you monitor the size of Recoverable Items folder for mailboxes on litigation hold.

To check Recoverable Items folder size for all mailboxes on litigation hold:

Get-Mailbox -ResultSize Unlimited -Filter {LitigationHoldEnabled -eq $true} | Get-MailboxFolderStatistics –FolderScope RecoverableItems | Format-Table Identity,FolderAndSubfolderSize -Auto

If the Recoverable Items folder is close to its quota limits, you can raise the Recoverable Items Quota for the mailbox – the simple solution and also the recommended one. Alternatively, you can use Search-Mailbox to extract messages from the folder and store them in another mailbox. See Clean Up The Recoverable Items Folder for the step-by-step procedure.

This command sets the Recoverable Items Warning Quota and Recoverable Items Quota for a mailbox to 40 GB and 50 GB:

Set-Mailbox “Mailbox User” –RecoverableItemsWarningQuota 40GB –RecoverableItemsQuota 50GB

Note: A user’s archive mailbox also has a Recoverable Items folder. Although the same RecoverableItemsWarningQuota and RecoverableItemsQuota apply to the primary and archive mailbox, they're not combined but calculated separately (i.e., 30 GB for the primary mailbox and 30 GB for the archive, if enabled).

Informing the user about litigation hold or retention hold

When you place a mailbox on litigation hold or retention hold in Exchange 2010, you can populate the comment field using the EMC or the Set-Mailbox cmdlet. The comment shows up in the Backstage area in Outlook 2010 and can be used to inform the user about either hold. You can also include a URL to internal hold policies or other documentation.

When you place a mailbox on litigation hold, Exchange alerts you that it may take up to 60 minutes for the change to be processed.

Although litigation hold is processed by Exchange in that period, the litigation hold comment does not show up in Outlook 2010 until the MFA has processed the mailbox. Depending on the assistant’s work cycle, it may take as long as 1 day (the default work cycle configuration on Exchange 2010) for the comment to be displayed in Outlook. To make the comment show up sooner, you can manually kick off the assistant against a mailbox.

Start-ManagedFolderAssistant “Mailbox User”

To have the assistant process multiple mailboxes, you’ll need to pipe output from the Get-Mailbox cmdlet, which can use recipient filters to filter mailboxes, or use distribution group membership.

Additionally, LitigationHoldEnabled, LitigationHoldDate and LitigationHoldOwner are filterable properties in Exchange 2010. This means you can filter Get-Mailbox output using these properties and start the MFA against all mailboxes you’ve placed on litigation hold on a certain date.

This command retrieves all mailboxes places on litigation hold by Paul Singh after 8/14/2010.

Get-Mailbox –Filter {LitigationHoldEnabled –eq $true –and LitigationHoldDate –gt “8/14/2010” –and LitigationHoldOwner “Paul Singh”} | ft Name,Litigation*

Once you’ve examined the list of mailboxes returned by the above command, you can start the MFA to process them.

Get-Mailbox –Filter {LitigationHoldEnabled –eq $true –and LitigationHoldDate –gt “8/14/2010” –and LitigationHoldOwner “Paul Singh”} | Start-ManagedFolderAssistant

After the Managed Folder Assistant has processed a mailbox, the hold comment is displayed in Outlook 2010. The user is not required to restart Outlook.

Exchange 2010 has a number of features to help you meet your organization's compliance goals. For more details, see Messaging Policy and Compliance in Exchange 2010 documentation.

Bharat Suneja

In Exchange 2010, you can use Retention Policies to manage message retention. Retention Policies consist of delete tags, i.e. retention tags with either Delete and Allow Recovery or Permanently Delete actions, or archive tags, i.e. retention tags with the Move To Archive action, which move items to the user's archive mailbox.

Depending on how they're applied to mailbox items, retention tags are categorized as the following three types:

1. Default Policy Tags (DPTs), which apply to untagged items in the mailbox – untagged items being items that don't have a retention tag applied directly or by inheritance from parent folder. You can create three types of DPTs: an archive DPT, a delete DPT and a DPT for voicemail messages.
2. Retention Policy Tags (RPTs), which are retention tags with a delete action, created for default folders such as Inbox and Deleted Items. Not all default folders are supported. You can find a table showing the default folders supported for RPTs in Understanding Retention Tags and Retention Policies. Notably, Calendar, Tasks and Contacts folders aren't supported.
3. Personal Tags, which are retention tags that users can apply to items and folders in Outlook 2010 and Outlook Web App. Personal tags can either be delete tags or archive tags. They're surfaced in Outlook 2010 and OWA as Retention policies and Archive policies.

To deploy retention tags, you add them to a retention policy and apply the policy to mailbox users.

In Exchange 2010 SP1, we added support for the Notes folder. In Exchange 2010 RTM, items in the Notes folder aren't processed. After you upgrade to SP1, if the user's retention policy doesn't have a RPT for the Notes folder, the DPT from the user's policy will apply to items in that folder.

In existing deployments, your users may not be used to their notes being moved or deleted.

To prevent the DPT from being applied to a default folder, you can create a disabled RPT for that folder (or disable any existing RPT for that folder). The Managed Folder Assistant, a mailbox assistant that processes mailbox items and applies retention policies, does not apply the retention action of a disabled tag. Since the item/folder still has a tag, it's not considered untagged and the DPT isn't applied to it.

Note: You can create a disabled RPT for any supported default folder.

Why are items in the Notes folder still archived?

If you create a disabled RPT for the Notes folder, you'll see items in that folder are not deleted, but they do continue to be moved to the archive! Why does this happen? How do you prevent it?

It's important to understand that:

• A retention policy can have a DPT to archive items and a DPT to delete items. Both apply to untagged items.
• The move and delete actions are exclusive of each other. Mailbox folders and messages can have both types of tags applied - an archive tag and a delete tag. It's not an either/or proposition.
• If you create a disabled RPT for the Notes folder to not delete items, the archive DPT for the mailbox would still apply and move items.
• When it comes to archiving, there's only one archive policy that administrators can enforce – the DPT with 'Move to archive' action. You can't create a RPT with the 'Move to archive' action. This rules out using the disabled RPT approach to prevent items from being moved.
• Users can apply a personal tag to a folder or messages to move items sooner or later than the default archive policy for that mailbox.

How do you prevent items in a default folder from being archived?

There's no admin-controlled way of doing this, short of removing the archive DPT from a retention policy. However, removing the archive DPT would result in messages not moving to archive automatically unless the user applies a personal tag to messages or folders.

The workaround is to have users apply the Personal never move to archive personal tag (displayed as Never under Archive Policy in Outlook/OWA) to a default folder. The tag is included in the Default Archive and Retention Policy created by Exchange Setup. You can also add this tag to any Retention Policies you create.

Note: You can't use Outlook 2010 to apply an archive policy to the Notes default folder or individual notes items. Users wanting to apply an archive policy to the folder must use OWA.

Bharat Suneja

Starting with Exchange 2007, installation of the current version of Office Filter Packs is a prerequisite. For Exchange 2007 and Exchange 2010 RTM, the pre-req was 2007 Office System Converter: Microsoft Filter Pack. In Exchange 2010 SP1, this was updated to Office 2010 Filter Packs. The filters are used by Exchange Search to index email attachments on Mailbox servers and by the transport rules agent to scan attachments on transport servers. The filters are also important for discovery searches in Exchange 2010 – Multi-Mailbox Search uses content indexes generated by Exchange Search.

In Exchange 2010 RTM and Exchange 2007, you need to register the IFilters with Exchange Search (for Exchange 2007, see 'KB 944516 How to register Filter Pack IFilters with Exchange Server 2007'). In Exchange 2010 SP1, IFilters included in the Office 2010 Filter Pack are automatically registered by Exchange Setup. You must register any third-party filters you install.

An updated filter pack, Service Pack 1 for Microsoft Office Filter Pack 2010 (KB2460041) 64-bit Edition is now available on Download Center. The Filter Pack has been tested with Exchange 2010 and Exchange 2007. The updated filter pack doesn’t have any fixes or updates that impact Exchange scenarios or functionality. If you have the RTM version of Office 2010 filter packs installed, you can update it but it’s not required. For new installs, we recommend going with the current versions.

Note: The SP1 package updates the RTM version of Office 2010 Filter Packs.

Bharat Suneja

The Exchange Sustained Engineering team recently made the decision to recall the June 22, 2011 release of Exchange 2010 SP1 Rollup 4. This was not an action we took lightly and we understand how disruptive this was to customers. We would like to provide you with some details that will give you a deeper understanding of what actually happened and, more importantly, what improvements we are making to prevent this in the future.

• Q: What actually triggered the recall?
  

  A: While fixing a bug that prevented deleted public folders from being recovered, we exposed an untested set of conditions with the Outlook client. When moving or copying a folder, Outlook passes a flag on a remote procedure call that instructs the Information Store to open deleted items which haven’t been purged. Our fix inadvertently caused the RPC to skip all content that wasn’t marked for deletion because we were not expecting this flag on the call from Outlook on the copy and move operations.

• Q: Why didn’t you test this scenario?
  

  A: The short answer is we thought we did. We didn’t realize we missed a key interaction between Exchange and Outlook. The Exchange team has well over 100,000 automated tests that we use to validate our product before we ship it. With the richness and number of scenarios and behaviors that Exchange supports, automated testing is the only scalable solution. We execute these tests in varying scenarios and conditions repeatedly before we release the software to our customers. We also supplement these tests with manual validation where necessary. The downside of our tests is that they primarily exercise the interfaces we expose and are designed around our specifications. They do test positive and negative conditions to catch unexpected behavior and we did execute numerous folder copy and move tests against the modified code which all passed. What we did not realize is that our tests were not emulating the procedure call as executed by Outlook.

• Q: Exchange has been around a while, why did this happen now?
  

  A: In Exchange 2010 we introduced a feature called RPC Client Access. This functionality is responsible for serving as the MAPI endpoint for Outlook clients. It allowed us to abstract client connections away from the Information Store (on Mailbox servers) and cause all Outlook clients to connect to the RPC Client Access service.

  As part of our investigation, we discovered that there was some specific code added to the Exchange 2003 Information Store to handle the procedure call from Outlook using the extra flag. This code was also carried forward into Exchange 2007. But when the Exchange team added the RPC Client Access service to Exchange 2010, that code was not incorporated into the RPC Client Access service because it was mistakenly believed to be legacy Outlook behavior that was no longer required. That, unfortunately, turned out not to be the case. The fact that we were not allowing a deleted public folder to be recovered was masking this new bug completely.

• Q: Are there other similar issues lurking in RPC Client Access?
  

  A: We do not believe so. The RPC Client Access functionality has been well-tested at scale and proven to be reliable for the millions of mailboxes hosted in on-premises deployment and in our own Office 365 and Live@EDU services.

• Q: What are you doing to prevent similar things from happening in the future?
  

  A: We have conducted a top-to-bottom review of the process we use to triage, develop and validate changes for Rollups and Service Packs and are making several improvements. We have changed the way we evaluate a customer requested fix to ensure that we more accurately identify the risk and usage scenarios that must be validated for a given fix. Recognizing the diversity of clients used to connect to Exchange, we are increasing our client driven test coverage to broaden the usage patterns validated prior to release. Most notably, we are working even closer with our counterparts in Outlook to use their automated test coverage against each of our releases as well. We are also looking to increase coverage for other clients as well.

Kevin Allison
General Manager
Exchange Customer Experience

Earlier today the Exchange CXP team released an updated version of Update Rollup 4 for Exchange Server 2010 SP1 to the Download Center. This updated release is being made available after a complete review and revalidation of the list of fixes included in the previously released version of Rollup 4 dated June 22, 2011.

The review completed by the Exchange CXP team determined that the issue identified in 'KB 2581545: The copy or move operation on a folder that contains subfolders does not work as expected after you install Update Rollup 4 for Exchange Server 2010 SP1 dated June 22, 2011’ introduced a serious regression in the original release of Rollup 4. As a result, a new version of Rollup 4 dated July 23, 2011 has been tested and released with the change that caused the regression removed. The re-release of Rollup 4 is tracked by 'KB 2579150: Description of Update Rollup 4 for Exchange Server 2010 Service Pack 1'.

The updated Rollup 4 is being released to allow customers to install the list of fixes previously committed to on the normal rollup schedule using normal rollup installation routines without the need for further action. The re-released version of Rollup 4 is functionally equivalent to the combination of the original Rollup 4 release and (the interim updatein) KB 2581545. Here are answers to some install questions:

• Customers who have installed KB 2509910 (Rollup 4, dated June 22, 2011) and KB2581545 (fix for Rollup 4 regression) do not need to install KB 2579150 (re-released Rollup 4) but may do so if they choose to.
• Customers who have already installed KB 2581545 and want to update their systems to the updated Rollup 4 should first uninstall KB 2581545 (or any interim updates) prior to installing the new rollup.
• You do not need to uninstall original RU4 (KB 2509910) to install the re-released RU4 package (KB2579150).
• The re-release of Rollup 4 does not change the release plans for Update Rollup 5 for Exchange Server 2010 Service Pack 1. Rollup 5 is currently scheduled to release in August 2011.

Some of the above KnowledgeBase articles are not replicated/live at the time of writing this post. Please check back later in the day if you can't reach them.

General Notes

Note for Exchange 2010 Customers using the Arabic and Hebrew language version: We introduced two new languages with the release of Service Pack 1, Arabic and Hebrew. At present we are working through the process of modifying our installers to incorporate these two languages. Customers running either of the two language versions affected are advised to download and install the English language version of the rollup which contains all of the same fixes.

Note for Forefront users: For those of you running Forefront Security for Exchange, be sure you perform these important steps from the command line in the Forefront directory before and after this rollup's installation process. Without these steps, Exchange services for Information Store and Transport will not start after you apply this update. Before installing the update, disable ForeFront by using this command: fscutility /disable. After installing the update, re-enable ForeFront by running fscutility /enable.

Brent Alinger

UPDATE 8/2/2011: The survey is now closed; thank you for taking the time to share your feedback with us!

As we have done few times already, we wanted to reach out to you again to help us think about where we should be taking Exchange in the future.

This time, the focus is Exchange Certificate Management. Both Exchange 2007 and 2010 have GUI elements / wizards that were created to help you manage Exchange certificates. To help identify the improvements needed in the area, we created a short anonymous survey that we are asking you to fill out. It will take ~10 minutes tops and will give you an opportunity to give the Exchange Management team direct feedback on Certificate Management, your likes / dislikes, as well as functionality you feel might be missing.

You can find the survey here (link removed).

We really value your time and feedback provided; thank you!

- Nino Bilic

Every day we talk to customers, partners, consultants, analysts, administrators and a lot of great people like you. You have shared with us your ideas, opinions, favorite features, memories and recommendations. We love hearing from you so we wanted to help share your voice with the rest of the Exchange community - what better way to do this than with some videos? We're introducing a new series: Exchange Ideas.

In this video series, we'll cover different topics and questions discussed by our community, including Exchange team members. We're kicking it off with Exchange Faves, in which we asked folks about features and technology areas in Exchange that were their favorites. A great deal of people were incredibly passionate about Mailbox Resiliency so we made it our first Exchange Faves topic. Check out the video - you might be in it!

Stay tuned for more Exchange Ideas videos. We've been capturing footage of a lot of community members at different events and will continue to film people so please participate when you see me around with a camera - we're thrilled to hear from you!

Ann Vu

Have you been wondering what the aka.ms URLs we've been posting on Twitter and elsewhere are all about? They come from a Microsoft URL-shortening service. Not only does it allow us to shorten URLs to the minimum characters possible, it also creates vanity URLs that are easier to remember! Note, although it's not a public service (short URL creation is internal), but once they're created, these short URLs are available externally.

A common way to find content is by using Bing, The Decision Engine (<shameless plug!> We love what our friends at Bing are doing!) or other search engines.

For example, to search Exchange cmdlets like New-RetentionPolicyTag, you would either enter the cmdlet name or keywords in a search engine (or the search box in your browser, or the address bar in the browser – now that most browsers are getting rid of the search box as well). If you wanted to get more targeted search results, for example from a particular web site like microsoft.com, you’d type site:microsoft.com in that search box.

Tip: Want to search only topics in the Exchange TechNet Library? Add site:technet.microsoft.com/en-us/library to your search. For example:
Exchange 2010 Personal Archives site:technet.microsoft.com/en-us/library

Once you find the content you're looking for, and want to come back to the page again, you create a bookmark or favorite in your browser. This works for many of us, although if you have too many bookmarks or use different computers or browsers, more effort is required to keep them organized. Utilities and web services are available to help you manage bookmarks.

Exchange Short URLs

With the new vanity URLs, you can reach the topics directly – without having to use a bookmark, without using a search engine, and without having to remember and type a super-long URL. Of course, it can't be very efficient if you had to remember all the short URLs! We've tried to make these intuitive and close to what you may use as a search term in many cases.

Here are examples of short URLs:

Frequently Used Exchange Sites/URLs

• You Had Me At EHLO… (this blog) > aka.ms/ehlo
• Exchange 2010 documentation > aka.ms/ex2010docs
• Exchange 2007 documentation > aka.ms/ex2007docs
• Exchange2003 documentation > aka.ms/ex2003docs
• Exchange Server Licensing > aka.ms/exchangelicense
• Exchange Deployment Assistant (EDA) > aka.ms/exdeploy
• Microsoft Remote Connectivity Analyzer > aka.ms/exrca (also at exrca.com)
• Sender ID Framework SPF Record Wizard > aka.ms/senderidwizard
• Exchange Server Tools > aka.ms/exchangetoolsdocs
• Exchange 2010 SP1 > aka.ms/ex2010sp1
• Latest Rollup Update for Exchange 2010 SP1 > aka.ms/ex2010sp1update
• Exchange 2010 Visio Stencil > aka.ms/ex2010visiostencil
• Exchange Wiki Portal > aka.ms/exwiki
• Exchange 2010 Wiki > aka.ms/ex2010wiki
• Exchange 2007 Wiki > aka.ms/ex2007wiki
• Exchange 2003 Wiki > aka.ms/ex2003wiki

Exchange Cmdlet Help

PowerShell cmdlet names are formatted as verb-noun combinations separated by a dash (-). The verb part is generally: Get to retrieve an object, New to create an object, Set to modify an object and Remove to remove an object. Some other verbs (not an extensive list): Enable, Disable, Test, Import, Export, Clear, Suspend, Resume, Connect, Disconnect, Restore, Move, Update, Mount, Dismount and Search. The noun part is the object you're trying to retrieve (Get), create (New), modify (Set), remove or test – for example, Mailbox, MailboxDatabase, MailContact, MailUser, PublicFolder, ExchangeCertificate, RetentionPolicyTag, etc.

The cmdlet help topics contain the same help content you'd see in the Shell on your Exchange server (or remote Shell session from an admin workstation). These topics are under Exchange 2010 Cmdlets – every single Exchange 2010 cmdlet you can use.

Here are some examples of short URLs to get to cmdlet topics. I'm not listing all of them here, but once you get the hang of it, you'll be able to figure these out.

• Mailbox Get-Mailbox > aka.ms/getm | New-Mailbox > aka.ms/newm | Set-Mailbox > aka.ms/setm | Remove-Mailbox > aka.ms/removem
• MailContact Get-MailContact > aka.ms/getmc | New-MailContact > aka.ms/newmc | Set-MailContact > aka.ms/setmc | Remove-MailContact > aka.ms/removemc
• DistributionGroup Get-DistributionGroup > aka.ms/getdg | New-DistributionGroup > aka.ms/newdg | Set-DistributionGroup > aka.ms/setdg | Remove-DistributionGroup > aka.ms/removedg | Get-DistributionGroupMember > aka.ms/getdgm | Add-DistributionGroupMember > aka.ms/adddgm | Remove-DistributionGroupMember > aka.ms/removedgm | Update-DistributionGroupMember > aka.ms/updatedgm
• ExchangeCertificate Get-ExchangeCertificate > aka.ms/getec | New-ExchangeCertificate > aka.ms/newec | Enable-ExchangeCertificate > aka.ms/enableec | Export-ExchangeCertificate > aka.ms/exportec | Import-ExchangeCertificate > aka.ms/importec | Remove-ExchangeCertificate > aka.ms/removeec

• As you may have noticed, the format used is Verb + Initials of each word in noun. For example: Get-Mailbox is getm, Get-DistributionGroup is getdg.
• In the rare cases where the short URL for a cmdlet is already taken, a numeric suffix is added, starting with number 2. For example, Get-MailboxStatistics is getms2 because getms is used for Get-MailboxServer.
• Some cmdlets also have multiple short urls. For example, for Get-Mailbox you can also use getmb.

Tip Exchange cmdlet help topics list all parameters for a cmdlet, including the parameter type, and whether it's a required or an optional parameter. To get a list of all parameters for a cmdlet from the shell, use the following command:
(Get-Command <cmdlet>).Parameters

Exchange Help Topics

Exchange help topics are separated into conceptual topics and procedures. Conceptual topics generally start with the word Understanding, followed by the feature you're trying to understand. For example, Understanding Multi-Mailbox Search. These are located under top level nodes, generally the server role (Transport, Mailbox) or feature area (High Availability and Site Resilience, Messaging Policy and Compliance, Security, etc.).

I've listed short URLs to a few topics. The http:// prefix has been removed because most browsers add it automatically. I've also removed the domain and forward slash (aka.ms/) so only the keyword or tag (the part after the /) is listed here. Think of it as the Exchange Short URLs Tag Cloud. (When using one of these, you'll need to prefix it with aka.ms/.)

Hover over the links to find out the topic title these lead to!

Once again, more short URLs are being added, particularly for cmdlet help, so the above is not a complete list but it should give you a fair idea. Next time you want to go to an Exchange doc, try the short URL first and see if what you've remembered (or come up with) matches what we've used! If they're not the same, let us know and if the keyword isn't already taken we'll add the shortcut.

Note: Unlike the FWLink links we use to direct you to pages external to Exchange documentation, including to many downloads on the Download Center, the aka.ms short URLs are unmanaged. FWLink links are maintained and updated by the content team - if the target web page is permanently moved or removed, we'll update them. We wouldn't recommend using the aka.ms short URLs to link from your web site, blog or other content. They're convenient for locating content quickly and posting on social networking sites.

Let us know what you think about these short URLs, and if they do help you get to Exchange content faster!

This post and the tag cloud will be updated as we add more short URLs. To come back to this blog post and check out the "short url tag cloud", all you need to remember is aka.ms/exchangeurls (or just aka.ms/exurls).

Bharat Suneja

We are excited to announce that the Remote Connectivity Analyzer tool has been updated! In addition to the standard set of connectivity tests, we’ve added an Office 365 tab and a Single Sign-On test. The new Single Sign-On test will validate users' ability to log on to Office 365 with their on-premises credentials. It also validates some basic Active Directory Federated Services (ADFS) configurations.

Here's an overview and video demo.

In addition to the new tests, you will see the same great tests that were always available.

The Remote Connectivity Analyzer is available at https://www.TestExchangeConnectivity.com/.

Tip: you can also get here by going to exrca.com. Same site… just fewer characters to type.

We’re always excited to hear from you - please send us your feedback to ExRCAFB address.

Remote Connectivity Analyzer Release Notes (Also available here)

Version 1.3 (June 2011)

Known Issues

• A couple of the tests allow you to "Ignore trusts for SSL". Checking this option only tells the tool to not fail if the certificate you are using is not in the list of Trusted Root Certificates – for example, if you were using a certificate from your own Windows CA. This option does not allow the test to be completed over a non-SSL connection. If you do not have a certificate and want to test whether Exchange ActiveSync works over port 80 - this tool cannot perform this validation. We will not be able to add this feature in the future.

  Note: Due to limitations in the RPC API, we are currently unable to ignore the trust requirement for SSL for the RPC over HTTP / Outlook Anywhere tests. We are looking into alternatives for future releases.

• Copy to clipboard doesn't work in Firefox by default (You have to enable it)
• Some localized strings are in English if they were modified during this update. These strings will be localized in the future.
• While performing tests, the stage of testing will no longer update while the test is being performed. This is a necessary change for the moment due to some underlying changes to the Remote Connectivity Analyzer code. Your full test results will be available once the test is complete.

New / Modified Features

• Microsoft Exchange Remote Connectivity analyzer is now the Microsoft Remote Connectivity Analyzer. The future direction for this tool is to incorporate more products as we have done with Office 365. Thus dropping "Exchange" from the name made sense. There are still lots of strings where you'll see ExRCA or Exchange; we're cleaning these up in a future release.
• Tabbed user-interface to support multiple products and Office 365.
• Office 365 Single sign-on validation. This test allows you to validate identity federated scenarios with Office 365. Specifically, this new test targets the "Basic Authentication" federated scenario where a client sends credentials to Office 365 which in turn validates them against the on-premises ADFS server.
• Fixed an issue where ExRCA wouldn't validate certain top-level domains such as .travel and .museum.
• Added code so if the Enter key is pressed in the wizard, the default action is "next" instead of "previous". Previously, this didn't work for browsers other than IE.
• Better cross-browser support, fully supporting IE8-IE9 standards mode as well as other major browsers.

Nicole Allen

In Exchange 2010, the generating server for your Offline Address Books (OAB) can change, under certain conditions, without any admin intervention. The process described here happens only on Exchange 2010.

An Offline Address Book (OAB) is a collection of address lists downloaded by Microsoft Outlook so users can access recipient information and select/resolve recipients when composing messages offline or in Cached Exchange Mode. Offline address book generation (OABGen) is the process by which Exchange creates and updates the OAB. OAB generation occurs during the scheduled time – daily between 5:00-5:15 AM by default. You can customize the schedule and specify the originating Mailbox server for each OAB. The originating Exchange server generates new OAB files, compresses the files and then places them on a local share for web distribution. See Understanding Offline Address Books for more details.

Orphaned OAB Recovery is part of OAB maintenance; the goal is to recover orphaned offline address books. Orphaned is defined as "at least 25 hours overdue for an update". This is calculated based on the LastTouchedTime and Schedule properties of the OAB.

A single Exchange 2010 Mailbox server is selected in the organization to perform the Orphaned OAB Recovery task, and all Exchange 2010 Mailbox servers know the selected server using the same algorithm:

1. List all the mailbox databases in the org
2. Sort the list:
   1. First by server version
   2. Then lexically by objectGuid
3. The owning server of the first database in the list is the "selected server"

All Exchange 2010 mailbox servers will log event ID 2001 in the Application event log, indicating that evaluation of OAB recovery has taken place:

Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2001
Task Category: Orphaned OAB Recovery
Level: Information
Description:
The server responsible for performing the OAB recovery scan is <server>.

Event ID 2002 is logged on all Exchange 2010 Mailbox servers that are not selected to do OAB recovery:

Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2002
Task Category: Orphaned OAB Recovery
Level: Information
Description:
Because this server is not the one responsible for performing the OAB recovery scan, the task is exiting.

Events 2003 and 2004 are loggedOn the Exchange 2010 Mailbox server that is selected to perform OAB recovery:

• Log Name: Application
  Source: MSExchange OAB Maintenance
  Event ID: 2003
  Task Category: Orphaned OAB Recovery
  Level: Information
  Description:
  Orphaned OAB recovery scan has begun.

• Log Name: Application
  Source: MSExchange OAB Maintenance
  Event ID: 2004
  Task Category: Orphaned OAB Recovery
  Level: Information
  Description:
  Orphaned OAB recovery scan has been completed.

Event ID 2005 is generated on selected server if no orphaned offline address books are detected:

Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2005
Task Category: Orphaned OAB Recovery
Level: Information
Description:
No orphaned offline address books were found.

Event ID 2006 is generated on the selected Mailbox server when an orphaned OAB has been detected:

Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2006
Task Category: Orphaned OAB Recovery
Level: Warning
Description:
<number of orphaned OAB detected> orphaned offline address books were found. The OAB Maintenance Servicelet will attempt to move these offline address books to functioning servers.

Then Recover Orphaned OAB Process is executed on the selected server and event ID 2007 is logged for each orphaned OAB detected:

Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2007
Task Category: Orphaned OAB Recovery
Level: Information
Description:
The offline address book \Default Offline Address Book was successfully moved to server <MBX server>.

Tracking Offline Address Book Moves

To move the orphaned OAB to the selected Mailbox server, the process executes a Move-OfflineAddressBook command for each orphaned OAB using the system account [NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost)"].

Note: You can also use the cmdlet to manually move the OAB generation process to another Mailbox server.

This command searches the admin audit log for all such moves between 1/5/2011 and 5/5/2011:

Search-AdminAuditLog -StartDate 01/05/2011 -EndDate 05/05/2011 -Cmdlets Move-OfflineAddressBook

RunspaceId : 34b7d8a3-5c29-4b94-9d9a-143b84a02416
ObjectModified : \ Default Offline Address Book
CmdletName : Move-OfflineAddressBook
CmdletParameters : {Identity, DomainController}
ModifiedProperties : {Server, LastTouchedTime}
Caller : NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost)
Succeeded : True
Error : None
RunDate : 23/04/2011 13:21:00
OriginatingServer : (14.xx.xxxx.xx)
Identity : RgAAAAB7eTSlvjteQbvq59MpPJ50BwBXybVCyQZoTb5TtcDmP1TaAAAAA4udAABXybVCyQZoTb5TtcDmP1TaAAAIOUcPAAAJ
IsValid : True

Caller is "NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost)"

Summary

In Exchange 2010, the Offline Address Book generating server can be changed with no admin action if specific OAB is deemed orphaned. Event ID 2006 [MSExchange OAB Maintenance] needs to be monitored.

Event ID 2007 [Source: MSExchange OAB Maintenance] will give us the information about what has changed as part of this process.

You can find the OAB recovery server by using the following steps:

1. Restart “Microsoft Exchange Service Host” service on one of mailbox servers
2. Check event ID 2001 logged by MSExchange OAB Maintenance in the Application event log:

   Log Name: Application
   Source: MSExchange OAB Maintenance
   Event ID: 2001
   Task Category: Orphaned OAB Recovery
   Level: Information
   Description:
   The server responsible for performing the OAB recovery scan is <server>.

Pierre Touratier

Update 7/14/11: When contacting Microsoft Customer Support to obtain the Interim Update, you can reference KB 2581545 (please note that the article will be available at a later date on support.microsoft.com).
7/27/2011: Exchange 2010 SP1 RU4 has been re-released. See Announcing the re-release of Exchange 2010 SP1 Rollup 4. We also provide more details on what actually happened and what improvements we're making to prevent this in the future, in An Update on Exchange Server 2010 SP1 Rollup Update 4.

We have discovered an issue impacting some customers who have installed Exchange 2010 SP1 RU4 into their Exchange environment and as a result have removed SP1 RU4 from Download Center and recommend customers do not proceed with any planned deployments of SP1 RU4.

A small number of customers have reported when the Outlook client is used to move or copy a folder that subfolders and content for the moved folder are deleted. After investigation we have determined that the folder and item contents do not appear in the destination folder as expected but may be recovered from the Recoverable Items folder (what was previously known as Dumpster in older versions of Exchange) from the original folder. This behavior occurs due to a customer requested change in SP1 RU4 which allowed deleted Public Folders to be recovered. Outlook and Exchange are not correctly processing the folder move and copy operations causing the folder contents to appear to be deleted. OWA and Exchange Web Services clients are not affected by this change and process the folder move or copy actions correctly.

We will be providing a fix in Exchange 2010 SP1 RU5, scheduled for release in August, which prevents the content loss in the target location during the move/copy process. In addition, we are also working with the Outlook development team to examine their code for proper behavior and identify if a fix is necessary from the client. If you have already deployed SP1 RU4, we recommend obtaining an Interim Update that resolves this issue.

If you are a customer seeing this issue or would like to receive the Interim Update, please contact Microsoft Customer Support.  When contacting Microsoft Customer Support, you can reference KB 2581545 (please note that this article will be available at a later date on support.microsoft.com).  When installing the Interim Update, you need to install this on all Client Access and Mailbox servers that have SP1 RU4 installed.

We are commencing an internal review of our processes to determine how we can best prevent issues such as this one arising in future.

Once again, on behalf of the Exchange Product Group, I want to thank you for the patience you continue to show us while we work through these issues. We deeply regret the impact that this issue has had on you, our customers, and as always, we continue to identify ways to better serve your needs through our regular servicing releases.

Kevin Allison
General Manager, Exchange Customer Experience

Last year when we released Exchange 2010 SP1, we posted about the change expired password feature in Outlook Web App and how you can enable it by creating the ChangeExpiredPasswordEnabled registry entry. See So you want to change your expired passwords in OWA... for details.

Since then you've sent us many requests for supporting the use of User Principal Name (UPN) format in the same feature. Previously only domain\username format was supported when entering domain credentials.

We passed on that feedback to Exchange PMs and we're glad to let you know that the support for UPN credentials is now available in Exchange 2010 SP1 RU3-V3, which was released recently.

Note: At the time of this writing, Update Rollup 4 is the latest rollup available for Exchange 2010 SP1.

References:

• Configuring the Change Password Feature in Outlook Web App
• 2464564 - You cannot change the password of a UPN formatted user name in OWA when you enable Exchange Server 2010 SP1 Password Reset Tool

M. Amir Haque

You may have noticed a change in the behavior of the Safe Senders list within Outlook starting in Exchange 2010. Users can no longer add accepted domains to Outlook’s Safe Senders list.

This was done as an anti-spam deterrent as we have all seen cases where Joe The Spammer spoofs the mail from your own domain. Adding your own domain to the Safe Senders list would bypass all Outlook client-side anti-spam checks, dumping that message from the Nigerian prince (spoofed using your own domain) into your users’ Inboxes. Not so good unless you were really waiting for that business opportunity.

A valid SPF record and our anti-spam agents (specifically the SenderID agent) would go a long way to block these types of spam. However, many customers out there have not exactly jumped on the SPF bandwagon.

You can learn more about SenderID filtering in Sender ID and Understanding Sender ID. Use the Sender ID Framework SPF Record Wizard to create an SPF record for your domain.

With Exchange 2010, you CAN still add individual email addresses from your own accepted domains to the Safe Senders list - you just can’t add the entire domain, as shown in the screenshot above.

What happens if you DO decide to add the whole domain?

If you try to do this for a user via the Shell, you will get the very helpful error below:

We tell you exactly why we are throwing an error.

How about when a user does this via Outlook? First, Outlook lets the user add a domain.

However after a few minutes the entry will magically disappear.

Allowing app servers to send as your own domain

Many customers have various applications that submit mail anonymously to Exchange where the messages come from email addresses from your accepted domains.

Some of you have apps submitting from so many accepted domain addresses that it wouldn’t be feasible (let alone fun) attempting to add all of these addresses individually to the safe senders list in Outlook to ensure these messages do not end up in junk mail.

Now that we can’t add the whole domain, what are our options?

• We know that adding all the addresses manually is an available albeit painful option
• A second option is to disable Outlook’s client side filtering (yeah... not a good idea, so do not seriously consider it. Spam checks out the window!)
• A third and best option is to install the anti-spam agents on your relay hub(s) and add the IPs of your app servers to the IP Allow list of the connection filtering agent as documented here.

When the sending SMTP host’s IP address is on the IP Allow List in Exchange, it bypasses all anti-spam checks (except sender/recipient filtering) and the Content Filter agent stamps an SCL of -1 on the message which Outlook will honor.

X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-Antispam-Report: IPOnAllowList
X-MS-Exchange-Organization-SCL: -1

So, go ahead and run the Install-AntispamAgents.ps1 from the Scripts folder on your Hub Transport server, and then add IP addresses or subnets of our application servers to the IP Allow List.

If using the Shell, use this command to add an IP address to the IP Allow List:

Add-IPAllowListEntry –IPAddress 192.168.10.120

What Not To Do: Using Externally Secured Authentication

Now I know what you’re thinking: Why don’t we just add Externally Secured Authentication as an authentication type on a Receive Connector, scope the connector’s remote IP range to the sending application servers and call it a day?

Well, not so fast... you see, while Externally Secured gives the sending IP the ms-Exch-Bypass-Anti-Spam extended right, this only circumvents the Exchange Anti-Spam checks, not Outlook’s. And it is Outlook that’s moving the message into junk mail in this case.

Also note that Externally Secured does not stamp any SCL X-headers on the message as an SCL of -1 would’ve bypassed Outlook’s checks. The only header this authentication type creates is the one below:

X-MS-Exchange-Organization-AuthAs: Internal

If you're still confused about Exchange and Outlook anti-spam checks, take a look at Exchange anti-spam myths revealed.

Big thanks to Tak Chow for tech reviewing this post.

Tom Kern

Earlier today the Exchange CXP team released Update Rollup 4 for Exchange Server 2007 SP3 to the Download Center.

This update contains a number of customer-reported and internally found issues since the release of RU3. For a list of changes included in this rollup, see KBA 2509911 Description of Update Rollup 4 for Exchange Server 2007 Service Pack 3. We'd like to specifically call out the following fixes which are included in this release:

• 2531208 You cannot synchronize a folder hierarchy by using Outlook for Mac 2011 in an Exchange Server 2007 SP3 environment
• 2528437 EWS applications cannot connect to Exchange Server 2007 servers after you make changes on accepted domains
• 2521063 You are incorrectly displayed as a meeting organizer after you synchronize the meeting by using your mobile device in an Exchange Server 2007 environment

Update Rollup 5 for Exchange Server 2007 Service Pack 3 is currently scheduled to release in August 2011.

Kevin Bellinger

As we like to say here on EHLO, we’re always listening for feedback on what we're doing well and what we could be doing better for you. As more and more of you evaluate and deploy the email archiving, retention and discovery capabilities of Exchange Server 2010 and Exchange Online, we understand that Personal Folders (.pst files) remain a challenge for you. You have told us that having the ability to search your network to discover and then import .pst files across your environment is critical, and that you need an admin-driven and straightforward tool for doing these things.

We're excited to announce that later this year we'll be adding a new tool to our already rich portfolio of planning and deployment tools. This new tool, PST Capture, will be downloadable and free, and will enable you to discover .pst files on your network and then import them into both Exchange Online (in Office 365) and Exchange Server 2010 on-premises. PST Capture will be available later this year. It doesn’t replace the New-MailboxImportRequest cmdlet that exists already for importing known .pst files into Exchange Server, but instead works in parallel to enable you to embark on a systematic search and destroy mission to rid yourself of the dreaded .pst scourge <*pirate growl*>.

We'll make more details available as we approach the release of the tool, but given the high demand for this capability, we wanted to let you know that we are working on this for you.

As always, keep the feedback coming!

Ankur Kothari
Exchange Team

Have you missed Geeking out with Perry Clarke? Well he's back with another blog post and Geek Out with Perry episode where we chat about availability for Exchange Online in the Office 365 service.

Perry shares some insights on the framework that the team uses when designing reliability and availability as well as discusses with me how the team evolved their thinking as we transitioned from mainly creating Exchange as on-premises software to delivering Exchange as service.

I thought that this was an awesome topic but I'll leave it up to you to watch and give us feedback. We'll have more Geek Out with Perry videos coming soon as well some videos that feature you, our Exchange community!

Ann Vu

Update 7/2/11: The installation steps have been modified to make it clear the script must be executed on the Mailbox server using elevated credentials.

With Exchange 2010 Service Pack 1, you may find that performing a search via Outlook Web App (OWA) results in an error message, “The action couldn’t be completed.  Try again later.” Additionally, Outlook clients operating in Online Mode can no longer search for attachments or embedded emails. 

When this issue occurs, you will see the following events in the application log:

Log Name: Application
Source: MSExchangeIS Mailbox Store
Event ID: 9877
Task Category: Content Indexing
Level: Error
Description:
Content Indexing function 'CISearch::EcGetRowsetAndAccessor' received an unusual and unexpected error code from MSSearch. Mailbox Database: <Database Name> Error Code: 0x80043629

Log Name: Application
Source: MSExchangeIS Mailbox Store
Event ID: 9842
Task Category: Content Indexing
Level: Error
Description:
Function CISearch::EcGetRowsetAndAccessor detected that content indexing was disabled for database '<Database Name>' because of error '0x80041820' from MSSearch.

When you check the CatalogData folder in the same subfolder as the database, you may see that the content indexing files (.CI files) are not growing. If you perform a ResetSearchIndex.ps1 on the index, you may see that the total size of the CatalogData folder only grows to a few KB or a few MB and either no .CI files are generated or only a few .CI files are generated and are only a few KB each.

What causes this issue?

This problem typically is a result of installing or upgrading a multi-role server (a server that has the Mailbox, Client Access, and Hub Transport roles installed) to SP1 and then removing the Hub Transport and Client Access roles, thereby leaving the server with only the Mailbox role installed. 

There is a symbolic link for each language referenced in the registry,  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex\Language.  The symbolic links (ActiveX CLSID of the class used) allow for word breaking and stemming  for the locale corresponding to the language.

During the Exchange 2010 Service Pack 1 uninstall process for the Hub Transport role, setup removes the symbolic links, regardless of the fact that the Mailbox role is still present.  The removal of the symbolic links causes the generation of content indexing files to fail.

How do we resolve this issue?

You will need to execute a script on the affected Mailbox servers that reinstalls the symbolic links:

1. Download the script Repair-ExchangeSearchSymlinks.ps1 from the Script Center.
2. Copy the Repair-ExchangeSearchSymlinks.ps1 script to the Scripts directory on the Mailbox server (default installation is C:\Program Files\Microsoft\Exchange Server\v14\Scripts).
3. On the afflicted Mailbox server, open the Exchange Management Shell by right-clicking the shortcut and selecting “Run as Administrator”.
4. Within the Exchange Management Shell, navigate to the Exchange Scripts directory.
5. Within the Exchange Management Shell, run the following script:

   .\Repair-ExchangeSearchSymlinks.ps1

6. Within the Exchange Management Shell, run the following script (without the symbols [] and substitute the database name(s) for any databases you wish to reset:

   .\ResetSearchIndex.ps1 [-force] <dbname> [<dbname>]...

7. You will receive an Event ID 109 when the rebuilding of the index starts for each database and an Event ID 110 for each database when the index rebuild has completed.
8. After receiving Event ID 110 for each database, test to make sure search functions correctly with both OWA and Outlook operating in Online Mode.

Bob Want

Organizations often need to share availability (aka Free/Busy) information with other Exchange organizations. Depending on the version of Exchange Server you're on, there are different ways to do this. Let's take a look at three common scenarios and go through the exact steps required in order to achieve sharing of availability information between two on-premises Exchange organizations.

Scenarios:

1. Scenario 1: Both organizations running Exchange 2010 SP1
2. Scenario 2: One (or both) organizations running a mix of both Exchange 2007 and Exchange 2010 SP1
3. Scenario 3: One (or both) organizations running a mix of Exchange 2003, Exchange 2007 and Exchange 2010 SP1

This summary table outlines the requirements in order to facilitate Availability lookups between two organizations:

*refer to “Option A” and Option B” which are discussed later in this post

Scenario 1: Both organizations are running Exchange 2010 Sp1

This is the simplest scenario. Users in both organizations are on Exchange 2010, both organizations can use Federated Delegation and do not require any additional steps.

1. Both organizations must first set up a Federation Trust. The steps to create a Federation trust are documented in Create a Federation Trust. The Federation Trust should be in place and working for both organizations before the organization relationship is set up.
2. Register the DNS TXT records for the federated domain namespace and all other domains you wish to add to the federation trust. The account namespace (this is the federated delegation organization identifier or OrgID) identifies your organization to the Microsoft Federation Gateway. You must use a domain other than your primary SMTP domain (used to receive inbound email) for the account namespace, as documented in Configure Federated Delegation. The current recommendation is to use exchangedelegation.domain.com as the account namespace.
3. Ensure that the autodiscover web service is configured and working for your domain namespace. Although it's possible to manually configure the organization relationship, we recommended that you use autodiscover.
4. Create an organization relationship with the remote organization. The steps to create an organization relationship are documented in Create an Organization Relationship.

Note: Directory synchronization is not required in order to do cross-org availability in Exchange 2010 SP1, except if you have users on Outlook 2007/2003. However, if you choose to configure directory synchronization, it'll not impact the ability to perform availability lookups.

Scenario 2: One or both organizations are running Exchange 2010 SP1 and Exchange 2007

Steps 1-4 in this scenario are the same as Scenario 1. However, with Exchange 2007 in the mix, directory synchronization is requiredbetween the two organizations. You must also create an availability address space for the remote organization. This allows Exchange 2007 users in both organizations to benefit from Exchange 2010's support for federation.

5. For Exchange 2007 to query availability cross org, directory synchronization must be performed for all users for which Free/Busy needs to be shared. This can be performed either manually (create Exchange contacts or Mail-enabled users one at a time), or via an automated process (MIIS, ILM, FIM, other 3rd party dirsync tool, etc.).

   Dirsync is required in this case because Exchange 2007 requires (and expects) a local object when the availability request is performed. If no local Exchange object is present, the availability request will fail.

6. Create a new availability address space for the remote organization that directs availability request from 2007 users to the 2010 Sp1 server. The syntax for creating the availability address space is included below.

   Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl https://Exchange2010SP1CAS.InternalDomain.com/ews/exchange.asmx -ForestName Fabrikam.com -UseServiceAccount $True

   With this setting, when an Exchange 2007 user requests availability information for a user from the remote org, the request will be proxied through the Exchange 2010 Sp1 server, which then will utilize the Federation Trust and Organization Relationship to send the availability request to the remote forest availability endpoint.

   
   Figure 1: Exchange 2007 user requests availability for a user in remote organization
   1. Step 1. Exchange 2007 user requests availability from user in Org B. Exchange 2007 proxies the request to the Exchange 2010 SP1 server.
   2. Step 2 and 3. Exchange 2010 detects it is for a remote org, and detects there's an Organization Relationship. Exchange then validates the Federation Trust.
   3. Step 4. Exchange 2010 then sends a request to the Availability service endpoint for Org B.
   4. Step 5. The Availability service in Org B generates a respond and sends back to the Exchange 2010 SP1 CAS server in Org A.
   5. Step 6. The availability response is returned to Exchange 2007, which then returns the response to the client.

Scenario 3: One or both organizations are running Exchange 2003, Exchange 2007 and Exchange 2010 SP1

Steps 1-4 in this scenario are the same as Scenario 1. Steps 5-6 in this scenario are the same as Scenario 2. Additionally, since you have Exchange 2003 in the topology, you must choose one of the two options described below in Option A and Option B.

With either option, there are considerations that must be made. Please reference the known issues section at the end of this post to better understand these considerations. With both options, it's assumed that you have performed all previous steps outlined in Scenario 1 and Scenario 2.

Option A:

1. Ensure that there is an Exchange 2010 Sp1 Mailbox server that hosts a Public Folder database.
2. Move ALL replicas of Free/Busy public folders to the Exchange 2010 Sp1 Public Folder server, and remove ALL replicas from either 2003 or 2007. This will allow Exchange 2010 SP1 to respond to all Public Folder free/busy requests.

   As the Public Folder free/busy query comes in, the Microsoft Exchange RPC Client Access Service on the Mailbox server (utilized for Public Folder connections) will intercept the public folder query, and route the request to the Availability service, which will then process the request as outlined in previous scenarios

3. If the remote organization that you need to look up Free/Busy for contains Exchange 2003 users, you must manually populate the targetSharingEPR property on the Organization Relationship (reference Issue #4 at the end of this document). This is done via the Exchange Management Shell by running this command:

   Set-organizationrelationship –identity “Org Relationship name” –TargetSharingEPR https://outlook.contoso.com/ews/exchange.asmx/wssecurity

   Note: the actual URL that you use will differ from the example above. You can determine the URL by checking the ExternalURL property for your Web Services virtual directory. This can be obtained by running Get-WebServicesVirtualDirectory –server 2010cas.contoso.com | fl name, *url*

   
   Figure 2: Exchange 2003 user requests availability information for user in remote org (Option A)
   1. Step 1. Exchange 2003 user requests availability from user in Org B. Since the mailbox is on an Exchange 2003 server, the client will only perform a free/busy query to Public Folders. This is done by looking up the LegacyExchangeDN attribute on the mail-enabled object for the remote user. From the LegacyExchangeDN, the client determines the Administrative Group in which the object was created and then knows which Free/Busy public folder to look in. Outlook first performs a query to the default Public Folder database for its mailbox store (which will typically be the Exchange 2003 Public Folder store).

      For example, Joe User's LegacyExchangeDN is LegacyExchangeDN=/o=First Organization/ou=Exchange 2003 Admin Group/cn=Recipients/cn=Joe User. The first part of the LegacyExchangeDN, /o=First Organization/ou=Exchange 2003 Admin Group is used to determine which Free/Busy public folder to look in. The second part of the LegacyExchangeDN, cn=Joe User, is used to look for the existence of a public folder message within that Free/Busy folder.

   2. Step 2. The Exchange 2003 Public Folder database will issue a referral to the client to the Exchange 2010 SP1 Public Folder database, which is where the only replica of that Free/Busy public folder resides.
   3. Step 3. Outlook queries the Exchange 2010 SP1 Public Folder for Free/Busy. Microsoft Exchange RPC Client Access Service running on the Mailbox server intercepts the Free/Busy request and routes it to the Availability service.
   4. Step 4 and 5. Exchange 2010 detects it is for a remote org, and detects there is an Organization Relationship. Exchange then validates the Federation Trust.
   5. Step 6. Exchange 2010 then sends a request to the Availability service endpoint for Org B.
   6. Step 7. The Availability service in Org B generates a response and sends it back to the Exchange 2010 SP1 CAS server in Org A.
   7. Step 8. Microsoft Exchange RPC Client Access Service translates the availability response into a Public Folder free/busy response, and returns the information to the Outlook client. In addition, the availability response is placed into the Free/Busy Public Folder and cached for 15 minutes. If additional availability queries are performed for that remote user within that 15 minute period, they will be returned from the cache.

Option B

1. Ensure that there's an Exchange 2010 SP1 Mailbox server that hosts a Public Folder database.
2. If not already present, create the Free/Busy system folder called External (FYDIBOHF25SPDLT) and ensure that the only replica of this Free/Busy Folder is on the Exchange 2010 SP1 server.

   Note:This External free busy folder will only be created on a new Exchange 2010 SP1 install when the option to create the public folders is selected during setup. The option is only presented if it's the first server installed in the organization. If a public folder database was not created during setup, you'll need to manually create this folder. The process to create this External folder is simple.

   1. Connect to the on-premise Exchange 2010 SP1 Public Folder server (this has to be done from the Public Folder server)
   2. Open Windows PowerShell
   3. Type " Add-PsSnapin Microsoft.Exchange.Management.Powershell.Setup"
   4. Then Type " Install-FreeBusyFolder"

   This will create the new Schedule Plus free busy folder called "External (FYDIBOHF25SPDLT)".

3. Modify the LegacyExchangeDN on all mail-enabled objects that reference the remote organization and change the OU value to External (FYDIBOHF25SPDLT). As the Public Folder free/busy query comes in, the Microsoft Exchange RPC Client Access Service on the Mailbox server (utilized for Public Folder connections) will intercept the public folder query and route the request to the Availability service, which will then process the request as outlined in previous scenarios.
4. If the remote organization that you need to look up Free/Busy for contains Exchange 2003 users, you must manually populate the TargetSharingEPR property on the Organization Relationship (reference Issue #4 at the end of this document). This command populates the TargetSharingEPRproperty:

   Set-OrganizationRelationship –Identity “Org Relationship name” –TargetSharingEPR https://outlook.contoso.com/ews/exchange.asmx/wssecurity

   Note: the actual URL that you use will differ from the example above. You can determine the URL by checking the ExternalURL property for your Web Services virtual directory. You can obtain it by running Get-WebServicesVirtualDirectory –Server 2010cas.contoso.com | fl Name, *url*

Figure 3: Exchange 2003 user requests availability information for user in remote org (Option B)

1. Step 1. Exchange 2003 user requests availability from user in Org B. Since the requesting client mailbox is on an Exchange 2003 server, the client will only perform a free/busy query to Public Folders. This is done by looking up the LegacyExchangeDNattribute on the mail-enabled object for the remote user. From the LegacyExchangeDN, the client determines which Administrative Group the object was created in, and then knows which Free/Busy public folder to look in. Outlook first performs a query to the default Public Folder database for its mailbox store (which will typically be the Exchange 2003 Public Folder store).

   For example: LegacyExchangeDN=/o=First Organization/ou= External (FYDIBOHF25SPDLT)/cn=Recipients/cn=Joe User. The first part of the LegacyExchangeDN, /o=First Organization/ou= External (FYDIBOHF25SPDLT)/is used to determine which Free/Busy public folder to look in. The second part of the LegacyExchangeDN, cn=Joe User, is used to look for the existence of a public folder message within that Free/Busy folder.

2. Step 2. Since the mail-enabled user has had the legacyExchangeDN modified, and the only replica of the External free/busy folder is on Exchange 2010, the Exchange 2003 Public Folder database will issue a referral to the client to the Exchange 2010 SP1 Public Folder database, which is where the only replica of that Free/Busy public folder resides.
3. Step 3. Outlook queries the Exchange 2010 SP1 Public Folder for Free/Busy. Microsoft Exchange RPC Client Access Service running on the Mailbox role intercepts the Free/Busy request and routes it to Availability.
4. Step 4 and 5. Exchange 2010 detects it is for a remote org, and detects there is an Organization Relationship. Exchange then validates the Federation Trust.
5. Step 6. Exchange 2010 then sends a request to the Availability service endpoint for Org B.
6. Step 7. The response is generated by the Availability service in Org B and sent back to the Exchange 2010 SP1 CAS server in Org A.
7. Step 8. Microsoft Exchange RPC Client Access Service translates the availability response into a Public Folder free/busy response, and returns the information to the Outlook client. In addition, the availability response is placed into the Free/Busy Public Folder and cached for 15 minutes. If additional availability queries are performed for that remote user within that 15 minute period, they will be returned from the cache.

Known Issues/Concerns

Issue #1 - OWA 2003

When Exchange 2003 users use OWA to schedule a meeting, they will look at “Availability” tab in the form, which will request free/busy from public folders via DAV. A free/busy request for DAV looks like this:

http://ExchangeServer/public/?Cmd=freebusy&
start=2009-10-28T00:00:00-07:00&
end=2009-10-29T00:00:00-07:00&
interval=30&
mbxguid=ea14502f-44cc-41ae-9f1d-df519a16ad20&
u=SMTP:mary@Contoso&
u=SMTP:joe@Contoso.com

Note: The above text is actually a single line string, it was broken down into multiple lines for easy reading.

DAV can only retrieve free/busy for users in the local public folder database. When OWA loads pages and scripts in the browser, it passes the URL to the public folder corresponding to the user mailbox. If the is no local replica for the folder corresponding to the first user provided in u= entry in the URL, DAV will do HTTP redirect (status 302) for the entire request to a public server that has that replica. Note this implementation assumes that free/busy for all other users provided in the request can also be found in the same server. The implication is that free/busy folders for different administrative groups must have replicas in all public folder databases. In our case, some or all free/busy folders will only have replicas on Exchange 2010, however Exchange 2010 does not support the DAV protocol, so OWA redirects to 2010 will simply fail.

With Option A, this will cause ALL OWA Free/Busy requests (both internal and external) to fail, as the Exchange 2003 server will not have replicas of any Free/Busy public folders.

With Option B, if the free/busy request is for a local mailbox user, the request will succeed. If the request is for a user from the remote org, the request will fail.

Issue #2 - Internal Free/Busy for Exchange 2003

Option A for Exchange 2003 requires that the only replicas for all free/busy folders must reside on Exchange 2010 SP1 servers. In environments where Exchange 2003 Public Folder databases are located in multiple physical sites, if Exchange 2010 Sp1 Public Folder databases are not located in the same physical sites, this may lead to issues with excessive latency and possible performance issues as internal free/busy queries may have to traverse WAN links.

Issue #3 - Queries for Exchange 2007 users cross-org fail

By default, Exchange 2007 allows availability queries for 42 days of information. Exchange 2010 bumped up that limit to 62 days. When Exchange 2010 performs the request for a user on Exchange 2007 in the remote organization, the request may fail because Exchange 2010 is requesting 62 days of information, which exceeds the default limit of 42 imposed by Exchange 2007.

To address this issue, you can adjust the maximumQueryIntervalDays value in the EWS web.config (located in the \Program Files\Microsoft\Exchange Server\ClientAccess\ExchWeb\ews\ folder) on the Exchange 2007 servers. Add the value under the AppSettings section.

This example configures the availability service on Exchange 2007 server to provide availability information for 62 days.

<appSettings>
    <add key="maximumQueryIntervalDays" value="62" />
</appSettings>

Note: The maximumQueryIntervalDays value is not present by default. If this value is not present, Exchange uses the default interval of 42 days.

After you do this, you will want to do an IISReset on the Exchange 2007 CAS servers to make sure the new setting takes effect, as this value is only read on startup.

Issue #4 - Queries for Exchange 2003 users cross-org fail

By default, an Exchange 2010 CAS performing a cross-org free/busy lookup will query the autodiscover service for the user you're attempting to view Free/Busy for. If the target user is an Exchange 2003 user, autodiscover will fail because Exchange 2003 users are not autodiscover-enabled. This issue is scheduled to be fixed in Exchange 2010 SP1 Update Rollup 4. To work around this issue, manually set the targetSharingEPR on the Organization Relationship for the remote organization with Exchange 2003.

Example:

Set-OrganizationRelationship –identity -targetSharingEPR https://mail.contoso.com/ews/exchange.asmx/WSSecurity

Update: The issue has been fixed in Exchange 2010 SP1 Update Rollup 4. See KB 2506820. The free/busy information does not display of a user whose mailbox is located on an Exchange Server 2003 server.

An additional issue with queries for remote Exchange 2003 users is that the remote organization will return the Free/Busy response in the format of a MergedOnly string. Exchange 2010 cannot convert this string to store the result in public folders, so no information is returned to the Outlook client.  A fix is available for this issue. See KB 2567863 Free/Busy information may not be returned when a Cross-Org query is performed from a legacy Exchange user.

Issue #5 - Federating with another Organization that has both on-premises and cloud users

If you federate with another organization that subscribes to a cloud service such as Office 365 or BPOS, availability lookups for remote users that have been moved to the cloud will fail. The reason is that your organization relationship is with the on-premises Organization. That on-premises org has a completely separate Organization Relationship with O365/BPOS. When an availability call is made from a separate org via an Organization Relationship, it'll be made to the on-premises org, where a mail-enabled user or contact will be found. There's no functionality to proxy the availability call through the Organization Relationship from the on-premises Org to the cloud, so this call will fail.

Ben Winzenz

Update 7/13/2011: Exchange 2010 SP1 RU4 has been removed. See Exchange 2010 SP1 RU4 Removed from Download Center for details.

Earlier today the Exchange CXP team released Update Rollup 4 for Exchange Server 2010 SP1to the Download Center.

This update contains a number of customer-reported and internally found issues since the release of RU1. See 'KB 2509910: Description of Update Rollup 4 for Exchange Server 2010 Service Pack 1' for more details. In particular we would like to specifically call out the following fixes which are included in this release:

• 2519359Unable to Create a 'Reply With' Rule on Public Folders Even With Owner and Send As Permissions
• 2394554Generating DSN fails if original mail uses non-support encoding charset.
• 2490134 Outlook 2007 does not deliver "Delayed Delivery" Messages against an Exchange 2010 Server in Online mode with any additional Transport loaded in the Outlook Profile

Some of the above KnowledgeBase articles are not replicated/live at the time of writing this post. Please check back later in the day if you can't reach them.

Update Rollup 5 for Exchange Server 2010 Service Pack 1 is currently scheduled to release in August 2011.

General Notes

Note for Exchange 2010 Customers using the Arabic and Hebrew language version: We introduced two new languages with the release of Service Pack 1, Arabic and Hebrew. At present we are working through the process of modifying our installers to incorporate these two languages. Customers running either of the two language versions affected are advised to download and install the English language version of the rollup which contains all of the same fixes.

Note for Forefront users: For those of you running Forefront Security for Exchange, be sure you perform these important steps from the command line in the Forefront directory before and after this rollup's installation process. Without these steps, Exchange services for Information Store and Transport will not start after you apply this update. Before installing the update, disable ForeFront by using this command: fscutility /disable. After installing the update, re-enable ForeFront by running fscutility /enable.

Kevin Bellinger

Struggling to find an overview of what the latest EAS features are? Planning your migration from Exchange 2003 and looking for a basic introduction to Database Availability Groups (DAGs)? These videos are for you!

The Microsoft Exchange team has produced a new portfolio of videos designed to give customers a fundamental technical education on Exchange Server 2010. There are currently seven videos in the series covering the following topics:

1. Archiving and Discovery
2. Mailbox Resiliency
3. Management
4. Mobility
5. Outlook and Exchange
6. Outlook Web App
7. Unified Messaging

The objective of the video series is to provide an introductory curriculum for IT professionals to learn more about the benefits of Exchange Server 2010. While TechNet provides great technical documentation at a more granular level, this video series should help bridge the gap for those who are new to Exchange 2010 and still trying to learn about the technical fundamentals of the product.

Each video runs 20-30 minutes long and includes an overview of the workload as well as a technical demonstration of 3-4 core scenarios related to that workload. The “Exchange Server 2010 Technical Video Series” is hosted by Ann Vu and presented by subject matter experts from the Microsoft Exchange team. You can find these videos on the front page of Exchange Server TechCenter on TechNet.

Please help us evangelize these videos to anyone who wants to learn more about Exchange Server 2010 and let us know your thoughts. As always, your feedback is extremely valuable to us. Many thanks in advance!

Steven Chew
Technical Product Manager

In case you did not try this yet (or you read our blog through RSS reader only) - that orange "Wiki" link on the navigation bar on top of our blog pages takes you to our TechNet Wiki landing page here:
http://social.technet.microsoft.com/wiki/contents/articles/wiki-exchange-server-portal.aspx

• Exchange Server and Update Rollups Builds Numbers
• Exchange Schema Versions – Common Questions & Answers
• Exchange ActiveSync Considerations When Using Windows Phone 7 Clients
• Exchange ActiveSync Client Comparison Table (also check out Comparison of Exchange ActiveSync Clients on Wikipedia.org)
• Configuring Static RPC Ports on an Exchange 2010 Client Access Server

Of course, since this is content generated by the community (including Microsoft employees), you can sign in to create more articles on the wiki or update the existing ones. Have fun exploring!

Nino Bilic

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

We're happy to announce that we've enhanced Exchange Server Deployment Assistant to include support for configuring rich coexistence (also known as “hybrid deployment”) for organizations interested in maintaining some users on-premises with Exchange 2010 and some users hosted in the cloud by Microsoft Office 365 for enterprises. This scenario is in addition to the existing support for configuring rich coexistence between on-premises Exchange 2003 and Exchange 2007 organizations and Office 365.

The new coexistence information for the Exchange 2010 environment is only available in English at this time and requires that your existing Exchange 2010 servers are updated to Exchange Server 2010 Service Pack 1 (SP1).

Rich coexistence (“hybrid deployment”) offers organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the cloud. It provides the seamless look and feel of a single Exchange organization between an on-premises organization and a cloud-based organization. In addition, coexistence can serve as an intermediate step to moving completely to a cloud-based Exchange organization. This approach is different than the simple Exchange migration (aka cutover migration) and staged Exchange migration options currently offered by Office 365 outlined in Email Migration Overview in Exchange Online help.

If you're not already familiar with the Exchange Deployment Assistant, it allows you to create Exchange Server 2010 on-premises configuration and deployment instructions that are customized to your environment. It asks you a small set of simple questions and it provides a checklist with instructions that are designed to deploy or configure Exchange 2010 based on your answers. In addition to the online checklist, you can even print a PDF of your checklist.

Figure 1: The Exchange Server Deployment Assistant (ExDeploy) is a web-based tool that helps you upgrade to Exchange 2010 on-premises, deploy a hybrid on-premises and Exchange Online organization or migrate to Exchange Online

Your feedback is very important for the continued improvement of this tool. We would love your feedback on this new scenario and any other area of the Deployment Assistant. Feel free to either post comments on this blog post, provide feedback in the Office 365 community migration and coexistence forum, or send an email to edafdbk@microsoft.com via the 'Feedback' link located in the header of every page of the Deployment Assistant. Thanks!

The Exchange Team

We’ve released the latest version of the Mailbox Role Requirements Calculator which corrects (among other things) the OS locale issue many of you stumbled upon with the first release of the database copy distribution function. 

You can download the new version of the calculator and let us know what you think. Alternatively, you can check out what else has changed by reviewing the Updates Tracking page.

Ross Smith IV

Note 6/3/2011: we have now fixed the survey link; sorry for the disruption, you can now take the survey.

We wanted to reach out to you again to help us think and plan about evolution of Exchange in the future.

This time, we wanted to get a better understanding on how you use Exchange management tools to manage your server or organization-level objects. Those would, generally speaking, be objects that are not recipient objects (so not management of mailboxes, groups etc. but rather server or org configuration.)

We have created a ~15 minute anonymous survey that will give you the opportunity to tell us which of those scenarios are most important for you, what is most valuable to expose in GUI and if there are improvements that you feel we should make based on what you use today.

You can find the survey here.

We absolutely value your feedback and will go through this carefully. Thank you for your time!

- Nino Bilic