You Had Me At EHLO...

Exchange “How do I?” videos

Exchange — Wed, 08 Sep 2010 19:31:19 GMT

It has been a while since we mentioned the Exchange video series we have been creating. Seeing that we have been recording new ones over past months, I wanted to remind you of those as they can be an excellent resource to help you learn how to do something in Exchange.

The general “How do I?” videos page can be found here. In order to be notified of new videos that we create and post, you should subscribe to the video RSS feed here.

Here are some more recent additions to the video series:

There is definitely more. Enjoy!

- Nino Bilic

Exchange 2010 SP1 FAQ and Known Issues

Exchange — Wed, 01 Sep 2010 18:03:51 GMT

Last week we released Exchange Server 2010 Service Pack 1. It has received some great feedback and reviews from customers, experts, analysts, and the Exchange community.

The starting point for SP1 setup/upgrade should be the What's New in SP1, SP1 Release Notes, and Prerequisites docs. As with any new release, there are some frequently asked deployment questions, and known issues, or issues reported by some customers. You may not face these in your environment, but we're posting these here along with some workarounds so you're aware of them as you test and deploy SP1.

Upgrade order

The order of upgrade from Exchange 2010 RTM to SP1 hasn’t changed from what was done in Exchange 2007. Upgrade server roles in the following order:
1. Client Access server
2. Hub Transport server
3. Unified Messaging server
4. Mailbox server
The Edge Transport server role can be upgraded at any time; however, we recommend upgrading Edge Transport either before all other server roles have been upgraded or after all other server roles have been upgraded. For more details, see Upgrade from Exchange 2010 RTM to Exchange 2010 SP1 in the documenation.

SP1 Prerequisites

SP1 requires the installation of 4-5 hotfixes, depending on the operating system – Windows Server 2008, or Windows Server 2008 R2. To install the Exchange 2010 SP1 administration tools on Windows 7 and Windows Vista, you requires 2 hotfixes.

Note: Due to the shared code base for these updates, Windows Server 2008 and Windows Vista share the same updates. Similarly, Windows Server 2008 R2 and Windows 7 share the same updates. Make sure you select the x64 versions of each update to be installed on your Exchange 2010 servers.

Here’s a matrix of the updates required, including download locations and file names.

Hotfix	Download	Windows Server 2008	Windows Server 2008 R2	Windows 7 & Windows Vista
979744 A .NET Framework 2.0-based Multi-AppDomain application stops responding when you run the application	MSDN or Microsoft Connect	Windows6.0-KB979744-x64.msu (CBS: Vista/Win2K8)	Windows6.1-KB979744-x64.msu (CBS: Win7/Win2K8 R2)	N. A.
983440 An ASP.NET 2.0 hotfix rollup package is available for Windows 7 and for Windows Server 2008 R2	Request from CSS	Yes	Yes	N.A.
977624 AD RMS clients do not authenticate federated identity providers in Windows Server 2008 or in Windows Vista. Without this update, Active Directory Rights Management Services (AD RMS) features may stop working	Request from CSS using the “View and request hotfix downloads” link in the KBA \| US-English	Select the download for Windows Vista for the x64 platform.	N.A.	N.A.
979917 Two issues occur when you deploy an ASP.NET 2.0-based application on a server that is running IIS 7.0 or IIS 7.5 in Integrated mode	Request from CSS using the Hotfix Request Web Submission Form or by phone (no charge)	Yes	N. A.	N. A.
973136, FIX: ArgumentNullException exception error message when a .NET Framework 2.0 SP2-based application tries to process a response with zero-length content to an asynchronous ASP.NET Web service request: "Value cannot be null".	Microsoft Connect	Windows6.0-KB973136-x64.msu	N.A.	N. A.
977592 RPC over HTTP clients cannot connect to the Windows Server 2008 RPC over HTTP servers that have RPC load balancing enabled.	Request from CSS	Select the download for Windows Vista (x64)	N.A.	N. A.
979099 An update is available to remove the application manifest expiry feature from AD RMS clients.	Download Center	N. A.	Windows6.1-KB979099-x64.msu	N. A.
982867 WCF services that are hosted by computers together with a NLB fail in .NET Framework 3.5 SP1	MSDN	N. A.	Windows6.1-KB982867-v2-x64.msu (Win7)	X86: Windows6.1-KB982867-v2-x86.msu (Win7) x64: Windows6.1-KB982867-v2-x64.msu (Win7)
977020 FIX: An application that is based on the Microsoft .NET Framework 2.0 Service Pack 2 and that invokes a Web service call asynchronously throws an exception on a computer that is running Windows 7.	Microsoft Connect	N. A.	N. A.	x64: Windows6.1-KB977020-v2-x64.msu X86: Windows6.1-KB977020-v2-x86.msu

Some of the hotfixes would have been rolled up in a Windows update or service pack. Given that the Exchange team released SP1 earlier than what was planned and announced earlier, it did not align with some of the work with the Windows platform. As a result, some hotfixes are available from MSDN/Connect, and some require that you request them online using the links in the corresponding KBAs. The administrator experience when initially downloading these hotfixes may be a little odd. However, once you download the hotfixes, and receive two of the hotfixes from CSS, you can use the same for subsequent installs on other servers. In due course, all these updates may become available on the Download Center, and also through Windows Update.

These hotfixes have been tested extensively as part of Exchange 2010 SP1 deployments within Microsoft and by our TAP customers. They are fully supported by Microsoft.

Prerequisite download pages linked from SP1 Setup are unavailable

When installing Exchange Server 2010 SP1 the prereq check may turn up some required hotfixes to install. The message will include a link to click for help. Clicking this link redirects you to a page saying that the content does not exist.

We're working to update the linked content.

Meanwhile, please refer to the TechNet article Exchange 2010 Prerequisites to download and install the prerequisites required for your server version (the hotfixes are linked to in the above table, but you'll still need to install the usual prerequisites such as .Net Framework 3.5 SP1, Windows Remote Management (WinRM) 2.0, and the required OS components).
The Missing Exchange Management Shell Shortcut

Some customers have reported that after upgrading an Exchange Server 2010 server to Exchange 2010 SP1, the Exchange Management Shell shortcut is missing from program options. Additionally, the .ps1 script files associated with the EMS may also be missing.

We’re actively investigating this issue. Meanwhile, here’s a workaround:
1. Verify that the following files are present in the %ExchangeInstallPath%\bin directory:
  - - CommonConnectFunctions.ps1
  - - CommonConnectFunctions.strings.psd1
  - - Connect-ExchangeServer-help.xml
  - - ConnectFunctions.ps1
  - - ConnectFunctions.strings.psd1
  - - RemoteExchange.ps1
  - - RemoteExchange.strings.psd1
  NOTE: If these files are missing, you can copy the files from the Exchange Server 2010 Service Pack 1 installation media to the %ExchangeInstallPath%\bin directory. These files are present in the \setup\serverroles\common folder.
2. Click Start -> AdmiinistrativeTools ->, right-click Windows PowerShell Modules, select Send to -> Desktop (as shortcut)
3. Go to the Properties of the shortcut and on Target replace the path to C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". 'C:\Program Files\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"
  Note: if the Exchange installation folder or drive name is different than the default, you need to change the path accordingly.
Upgrading Edge Transport on Forefront Threat Management Gateway (TMG) and Forefront Protection for Exchange 2010

If you upgrade a server with the Edge Transport server role running with ForeFront Threat Management Gateway (TMG) and ForeFront Protection for Exchange (FPE) enabled for SMTP protection, the ForeFront TMG Managed Control Service may fail to start and E-mail policy configuration settings cannot be applied.

The TMG team is working on this issue. See Problems when installing Exchange 2010 Service Pack 1 on a TMG configured for Mail protection on the ForeFront TMG (ISA) Team Blog. Exchange 2010 SP1 Release Notes has been updated with the above information.
Static Address Book Service Port Configuration Changes

The location for setting the port the address book service should use has changed in SP1. In Exchange 2010 RTM you had to edit the Microsoft.exchange.addressbook.service.exe.config to configure the service port. In SP1 you must use the following registry key:
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters
Value name: RpcTcpPort
Type: REG_SZ (String)

When you apply SP1 to a machine where you had previously configured a static port by editing the Microsoft.exchange.addressbook.service.exe.config file, the upgrade process will not carry forward your static port assignments. Following a restart, the Address Book Service will revert to using a dynamic port instead of a static port specified in the config file. This may cause interruptions in service.

As with all upgrades where servers are in load balanced pools, we recommend you perform a rolling upgrade — removing servers from the pool, updating them and then moving the pool to the newly upgraded machines. Alternatively, we recommend that you upgrade an array of servers by draining connections from any one machine before you upgrade it.

There are times when these approaches may not be possible. You can maintain your static port configuration, and have it take effect the moment the address book service starts for the first time following the application of the service pack, by creating the registry key BEFORE you apply SP1 to your server. The registry key has no impact pre SP1, and so by configuring it before you apply the Service Pack you can avoid the need to make changes to set the port post install, and avoid any service interruptions.
iPhone, OWA Premium and POP3 & IMAP4 issues due to invalid accepted domain

After applying E2010 SP1:
1. iPhone users may not be able to view the content of incoming messages in their Inboxes, and when they try to open a message, they get an error saying:
  This message has not been downloaded from the server.
  Admins may see the following event logged in the Application Event Log on Exchange 2010 CAS Server:
  Watson report about to be sent for process id: 1234, with parameters: E12, c-RTL-AMD64, 14.01.0218.011, AirSync, MSExchange ActiveSync, Microsoft.Exchange.Data.Storage.InboundConversionOptions.CheckImceaDomain, UnexpectedCondition:ArgumentException, 4321, 14.01.0218.015.
2. OWA Premium users may not be able to reply or forward a message. They may see the following error in OWA:
  
  An unexpected error occurred and your request couldn't be handled. Exception type: System.ArgumentException, Exception message: imceaDomain must be a valid domain name.
3. POP3 & IMAP4 users may also not be able to retrieve incoming mail and Admins will see the following event logged in Event Log:
  
  ERR Server Unavailable. 21; RpcC=6; Excpt=imceaDomain must be a valid domain name.
Resolution

Please run the following command under Exchange Management Shell and verify that there is one domain marked as ‘Default’ and it's DomainName & Name values are valid domain names. We were able to reproduce the issue by setting a domain name with a space in it, like "aa bb"

Get-AcceptedDomain | fl

If you also have an invalid domain name there (for example, a domain name with a space in it), then removing the space and restarting the server will fix the EAS (iPhone), OWA, POP3 & IMAP4 issues as mentioned above.

Command to run under EMS would be:

Set-AcceptedDomain –Identity <value> -Name “ValidSMTPDomainName”

Thes examples update the Name parameter of the "My Company" and "ABC Local" accepted domains (the space is removed from both):

Set-AcceptedDomain –Identity “My Company” –Name “MyCompany.Com”
Set-AcceptedDomain –Identity “ABC Local” –Name “ABC.Local”
Error when adding or removing a mailbox database copy

If a server running Exchange 2010 RTM (or Exchange 2010 SP1 Beta) is upgraded to Exchange 2010 SP1, administrators may experience an error when using the Add-MailboxdDatabaseCopy or Remove-MailboxDatabaseCopy cmdlets to add or remove DAG members.

When you try to add a DAG member, you may see the following error:

Add-MailboxDatabaseCopy DAG-DB0 -MailboxServer DAG-2

The result:

WARNING: An unexpected error has occurred and a Watson dump is being generated: Registry key has subkeys and recursive removes are not supported by this method.

Registry key has subkeys and recursive removes are not supported by this method.
+ CategoryInfo : NotSpecified: (:) [Add-MailboxDatabaseCopy], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.Exchange.Management.SystemConfigurationTasks.
AddMailboxDatabaseCopy

The command is not successful in adding the copy or updating Active Directory to show the copy was added. This happens due to presence of the DumpsterInfo registry key.

Workaround: Delete the DumpsterInfo key, as shown below.
1. Identify the GUID of the database that is being added using this command:
  
  Get-MailboxDatabase DAG-DB0 | fl name,GUID
  
  The result:
  
  Name : DAG-DB0
  Guid : 8d3a9778-851c-40a4-91af-65a2c487b4cc
2. On the server specified in the add command, using the database GUID identified, remove the following registry key:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\Replay\State\<DB-GUID>\DumpsterInfo
  
  The GUID identified in this case is 8d3a9778-851c-40a4-91af-65a2c487b4cc. With this information you can now export and delete the DumpsterInfo key on the server where you are attempting to add the mailbox database copy. This can be easily done using the registry editor, but if you have more than a handful of DAG members, this is best automated using the Shell.
  
  This example removes the DumpsterInfo key from the 8d3a9778-851c-40a4-91af-65a2c487b4cc key:
  
  Remove-Item HKLM:\Software\Microsoft\ExchangeServer\Replay\State\8d3a9778-851c-40a4-91af-65a2c487b4cc\DumpsterInfo
  
  To automate this across all servers in your organization, use the DeleteDumpsterRegKey.ps1 script.
  
  File: deletedumpsterregkey_ps1.txt
  Description: The DeleteDumpsterRegkey.ps1 script can be used to delete the offending DumpsterInfo registry keys that can cause this problem on all mailbox servers in the organization. Rename the file to DeleteDumpsterRegkey.ps1 (remove the .txt extension).
  
  For more info, see Tim McMichael’s blog post Exchange 2010 SP1: Error when adding or removing a mailbox database copy.

Thanks to all the folks in CSS and Exchange teams who helped identify, validate and provide workarounds for some of the issues mentioned above, and to the Exchange community and MVPs for their feedback.

Bharat Suneja, Nino Bilic
M. Amir Haque, Greg Taylor,
& Tim McMichael

Updates:

9/7/2010: Updated list of files for the missing Exchange Management Shell shortcut issue

Exchange 2010 SP1 and Support for FIPS Compliant Algorithms

Exchange — Mon, 30 Aug 2010 11:50:00 GMT

When will Exchange Server 2010 support FIPS compliance?
Exchange Server 2010 SP1 provides for the ability to disable algorithms which are not FIPS 140-2 compliant. These algorithms are used for encryption, hashing, and signing within the Windows Server 2008 and Windows Server 2008 R2 operating systems that support Exchange Server 2010. When the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing setting is enabled in a Group Policy or Local Policy, it disables the use of non-FIPS compliant algorithms such as RC-4. In Exchange 2010 RTM, it caused certain functions to fail. The most notable issue was in Outlook Web App (OWA), as documented in Microsoft Knowledge Base Article KB977961, and in the web-based Exchange Control Panel (ECP).

What is FIPS?
Federal Information Processing Standards (FIPS) are standards utilized to define security and interoperability requirements for cryptographic algorithms that the US Government uses. The FIPS 140-2 publication and standard (Security Requirements for Cryptographic Modules - PDF) defines the cryptographic algorithms as well as standards for key generation and key management. There are several FIPS publications which define how to further secure information systems and provide a standard upon which systems can be evaluated.

For more information on how Microsoft products and libraries comply with FIPS 140, see FIPS 140 Evaluation.

The importance of FIPS compliance to specific customers
Within the United States our customers utilize several guidelines, checklists, and requirements for securing systems, all which call for this policy setting to be enabled on the application’s host operating system (OS). In addition we have customers that do business with the US Government or work in industries where there is significant government oversight.

This policy setting ensures that the host OS, Windows Server 2008 SP2 or greater and Windows Server 2008 R2 or greater, in this case, only utilizes cryptographic algorithms that have passed the Cryptographic Module Validation Program and have been certified by the National Institute for Standards and Technology. Try saying that really fast three times.

The Windows Server OS, specifically the Windows Cryptographic Service Provider (CSP) is responsible for leveraging FIPS compliant algorithms for cipher, hashing, signing and encryption and we don’t actually need to enable anything within Exchange Server 2010. Exchange 2010 does have to know how to process the information provided via the OS, OS components such as Internet Information Server (IIS), and the Windows CSP. Exchange 2010 was released without support for servers which had this setting enabled, but had support and testing aligned for release with Exchange 2010 SP1.

What happens when this policy setting is enabled?
In Exchange 2010 RTM, when the policy setting System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing is enabled on the Windows Server 2008 or Windows Server 2008 R2 OS, the Schannel Security Provider (SSP) disables Secure Sockets Layer (SSL) protocols which are not part of the FIPS 140 standard. When this policy setting is enabled only FIPS 140-2 approved cryptographic algorithms are utilized. Examples of FIPS 140-2 compliant algorithms are the Triple Data Encryption Standard (3DES) and Triple Data Encryption Algorithm (TDEA) cipher, Advanced Encryption Standard (AES) algorithm and the Secure Hashing Algorithm (SHA) for hashing. In addition only the Transport Layer Security for Secure Sockets Layer (TLS/SSL) protocols will be utilized.

For those of you who have enabled the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing setting on an Exchange 2010 server, you may have discovered two distinct issues. The first is that Outlook Web App on your Client Access Servers (CAS) appears to work but generates errors once the customer provides their username and password or smartcard PIN.

For those of us that have customers using Kerberos constrained delegation (KCD), OWA errors out with:
! An unexpected error occurred and your request couldn’t be handled

Expanding the Show Details link provides additional detail, specifically an exception message stating:
The type initializer for ‘Microsoft.Exchange.Data.Storage.GccUtils’ threw an exception

Additionally, an error event (Event ID 4999, Source: MSExchange Common) will be logged in the Application event log on the Exchange CAS.

The second issue is near-identical where the web-based ECP functionality, also provided by the CAS, will fail.

How will this be fixed?
In Exchange 2010 SP1, changes have been made to the code base, tested and verified, to support this setting. Exchange 2010 SP1 operates with support for FIPS 140-2 algorithms if the Windows Server 2008 SP2 and Windows Server 2008 R2 operating systems are configured to utilize the FIPS 140-2 algorithms for system cryptography.

My agency/organization/customer/co-worker asked about this support yesterday. When will Exchange Server 2010 SP1 be released?
Exchange 2010 SP1 has been released and can be downloaded here.

Thanks for your time and my customers and I look forward to it as well!

Bob Christian II

Effects of Throttling on Your Deployment in Exchange 2010 SP1

Exchange — Fri, 27 Aug 2010 21:52:00 GMT

Exchange 2010 features a new resource protection mechanism - user throttling. This feature is designed to limit the amount of resources a single user or application can take up on a CAS to prevent poorly written applications from causing denial of service (DoS) to the rest of the users. You can read about throttling in Understanding Client Throttling Policies. If any of the terminology in this post sounds unfamiliar, please refer to this documentation.

While Exchange 2010 RTM shipped with user throttling "off" by default (most limits were set to infinite), after more testing in Exchange 2010 SP1, we've come up with a tighter set of limits for the throttling policies, and have thus turned user throttling on by default.

We have also changed what happens when users exceed their budget in some cases. In Exchange 2010 RTM version, Exchange rejected any Exchange Web Service (EWS), Exchange ActiveSync (EAS) and Outlook Web App (OWA) requests made by users who exceeded their budget. We've improved on this idea in SP1 in the EWS and ActiveSync protocols, by instead delaying the call just enough for the budget to recharge back into the positive and then execute the request. This means that end users will generally see fewer errors from the ActiveSync client or EWS application. In some rare conditions, such as if the caller is exceeding max number of connections or subscriptions in EWS, we'll still reject the request.

The longest a single request can be delayed is a minute, but this would be an extreme case and one that would signify that something is out of place either on the server, or with the caller. Typically, users and applications will not encounter throttling (except maybe if the user is doing a sync of the whole mailbox). However, some resource-heavy applications may start to get throttled in SP1. If throttling does kick in, the delays will be short enough that users won't notice any effect. However, we've provided ways to gain an insight into what is the user's experience is like due to throttling.

There are two main ways to monitor throttling - by monitoring perf counters and by looking at IIS logs. First, SP1 offers the following useful perf counters (instance is per CAS process) to monitor throttling under the MSExchange Throttling category on a CAS:

Max Delay Per Minute - this value represents the longest amount of time in msec that anyone was delayed due to throttling in the past minute.
Max Effective Time In * - this set of counters say that if the throttling policy was set to the counter values, then all requests that have been encountered in the past minute would all go through unthrottled.
Users Delayed X Milliseconds - the number of users who saw delays greater than "X" (see Delay Time Threshold) milliseconds in the past minute.
Users X Times OverBudget - the number of users whose requests were rejected more than "X" times in the past minute (see OverBudgetThreshold).
OverBudgetThreshold - the "X" value for the "Users X Times OverBudget" counter.
Delay Time Threshold - the "X" value for the "Users Delayed X Milliseconds" counter.
Total Unique Budgets - number of unique budgets (ie callers/users) seen in the past minute
Unique Budgets OverBudget - number of unique budgets that went over budget in the past minute

The general rule is that if the "Unique Budgets OverBudget" counter is graphing a line that's close to the "Total Unique Budgets" line, then most of the users in your system are getting throttled. You can further refine that by checking how many users are seeing rejections vs how many are getting delayed by viewing the appropriate "Users X times ..." counter. Finally, you can see if and how much users are delayed by viewing the "Max Delay Per Minute" counter. Also, all of these counters are saved off to SCOM once every minute.

If you do determine that many of your users are getting throttled, you may further try to understand why by digging into IIS logs. As of SP1, only ActiveSync, OWA and EWS log throttling info to IIS. By searching IIS for users or the string "overbudget", you can view which requests they have been making and which have been going over budget. You can refer to Budget Snapshots in the IIS Logs for a breakdown of the different parts of the budget.

If you do determine that your users or applications are throttled too much by your standards and their scenarios are in fact legitimate, then you can tweak the throttling settings to reflect your environment's use by:

Turning throttling off
Running your regular traffic through Exchange
Watching what the "Max Effective Time In *" counters report over the course of a few days
Setting the throttling policies to that value. To do this, call Get-ThrottlingPolicy ?| { $_.IsDefault} | Set-ThrottlingPolicy <new param values>

Alternatively, if it is an EWS application using a service account that becomes throttled, and you determine that it is not resource intensive to the Exchange server, you should create a new, custom throttling policy for it. To do this:

Call New-ThrottlingPolicy and set the proper parameters (refer to Exchange documentation at the top of the document for explanation of the parameters)
Call Get-Mailbox <mailbox of service account that the app is using) | Set-Mailbox -ThrottlingPolicy:<your policy that you just created>

The changes will be picked up within 15 minutes, or immediately after you recycle the EWS app pool in IIS. Please note that custom policies are meant as one-off solutions when a few applications or users are getting throttled and the load they are putting on the system is actually legitimate. You shouldn't update everyone's link to a custom policy - if you need to change throttling settings for the majority of your users, edit the default policy. For more information on throttling please refer to the official documentation linked at the top of this article.

Andrew Salamatov

The Future of Exchange Starts Here: Exchange Server 2010 SP1 Is Now Available

Exchange — Wed, 25 Aug 2010 13:00:00 GMT

You have been eagerly waiting, and we have been working hard over the summer to deliver the latest Exchange Server 2010 enhancements as soon as possible. I am extremely happy to announce the availability of Exchange Server 2010 Service Pack 1, ready for download here.

We released the SP1 beta at Tech Ed North America in June. We also shared some of the SP1 enhancements in Yes Virginia, there is an Exchange Server 2010 SP1 back in April. Since then, almost 500,000 SP1 mailboxes have gone into production in Technology Adoption Program (TAP) customer environments.

Rather than recap all the SP1 features, I want to let a few of our Exchange TAP customers tell you what they loved.

Exchange has been the most resilient and trusted solution for enterprise Email for many years now and when Exchange 2010 originally RTM’ed, I thought, what else could be improved… But the Exchange product group and the TAP group members have done just that in Service Pack 1.

From improvements to manageability for both administrators and users to better control and resiliency within the SMTP stack, and fantastic improvements in Unified Messaging, the list of improvements and features in Service Pack 1 amazes even an old Exchange guy like me (who has worked on Exchange since early 4.0 days). Of all the improvements in SP1, my favorite so far is the Audit Logging improvements available in the Exchange Management Shell and the Exchange Control Panel.

All I can say is, “Great job Microsoft Exchange Product Group on another fantastic product!”

Gary Cooper, Horizons Consulting

Calendar publishing is awesome. When working with people outside our organization, instead of fumbling around in multiple emails or phone calls “Is Tuesday at 3 PM good? How about next Wednesday at 9:30?” I can just send them a link to my calendar. Now if more organizations would get to Exchange 2010 and federate their free\busy (including Microsoft)....

Joseph Nguyen, University of Oklahoma

One of the most common criticisms from our customers regarding Exchange and OWA had been its lack of cross-browser and open systems support. Although we saw major improvements in Exchange 2010, SP1 has built upon this and taken things to the next level. SP1’s OWA experience is now class-leading and the addition of open standards calendar sharing is a feature we’ve been asked for many times - and have now been able to deliver. With SP1, our users can choose to share their Calendar in HTML and iCal formats, enabling real time sharing with external colleagues or access to their calendar from platforms and clients without Exchange support.

In addition to the OWA improvements, we’ve been delighted with some of the other new features. On the client side features like auto mapping of shared mailboxes to user’s Outlook 2010 profiles will remove a support headache.

In the datacentre, the support for online archives on a separate database from the primary mailbox is the green light for archiving implementation. Finally the ability to import and export PSTs without needing Outlook installed are a welcome addition and will be particularly useful when we begin importing archive PSTs back into Exchange for online archiving.

Steve Goodman, Aston University

And a word from Dimension Data, one of Exchange’s Global Partners.

Exchange 2010 SP1 is a great example of how Microsoft is rapidly responding to customer and partner feedback. We believe these new enhancements to the archiving functionality, improved Outlook Web App experiences, and expanded mobility capabilities can only accelerate the already strong customer demand we’ve seen for upgrades. And, the continual innovation delivered by Microsoft Exchange enables our business to maintain strong relationships with our customers by always having the ability to offer them new, next generation scenarios to consider and deploy.

Peter Menadue, Group General Manager, Microsoft Solutions at Dimension Data

Once again, a huge thank you to all of our customers, TAP participants, and EHLO readers for downloading the SP1 Beta, and the constant stream of great feedback. We couldn’t have done it without you!

Kevin Allison
GM – Exchange Customer Experience

Exchange 2010 SP1: Database Integrity checking

Exchange — Mon, 23 Aug 2010 19:36:02 GMT

Since the earliest versions of Exchange Server, the Information Store Integrity Checker (ISInteg) has offered Exchange administrators a way to check mailbox and public folder database integrity. ISInteg checks and fixes Exchange database errors that may prevent the database from mounting, prevent the user from logging on or from receiving, opening or deleting email. Curious to know what changes are coming to ISInteg in Exchange 2010 SP1? Let's take a look.

In Exchange 2010 SP1, ISInteg is no longer a standalone program.

The functionality provided by the ISInteg tool has been rolled into two new Exchange Management Shell cmdlets:

New-MailboxRepairRequest
New-PublicFolderDatabaseRepairRequest

Note: Like other Shell cmdlets, these are subject to Role-Based Access Control (RBAC) scoping restrictions. For details, see Understanding Management Role Scopes.

Cool Features

These new ISInteg cmdlets come with some cool new functionality!

The cmdlets work with the database mounted. It's no longer required to unmount the database to perform an integrity check or fix database errors.
You can repair logical corruption at the mailbox level.
You can fix corrupt search folders.
You can fix the Provisional Fid.
You can fix Aggregate Counts.

ISInteg can now work at the database or mailbox level

How does it do that? Well, the new schema in Exchange 2010 effectively partitions the database by mailbox. So the top problems fixed by ISInteg are now mostly limited to the affected mailboxes only. Previous versions of ISInteg required the database to be offline while validation and fixing are in progress. In Exchange 2010 SP1, the ability to do these checks at the mailbox level removes the need to dismount the database. It is actually required to have ISInteg operate against an online database!

New-MailboxRepairRequest

The New-MailboxRepairRequest cmdlet detects and fixes the following types of mailbox corruptions:

Search folder corruptions (SearchFolder): Repair tasks now look for all folders named in ptagSearchBacklinks, ptagSearchFIDs, and ptagRecursiveSearchFIDs and verifies that each folder exists. If the folder no longer exists, then it will remove that folder from the list.
Aggregate counts on folders that aren't reflecting correct values (AggregateCounts): Repair tasks tally all messages in a folder and keep a running total of various counts and sizes. Once the iteration is complete, it will verify the computed counts against the persisted counts on the Folders table record for the folder. If there is a discrepancy, it will update the persisted counts to reflect the computed counts.
Views on folders that aren't returning correct contents (FolderView): Repair tasks will iterate over all views for a folder and for each one, bring the view fully up to date and then reconstruct a temp copy. If there is a discrepancy between the existing view and the contents of the temp table, it will delete the view so it can be rebuilt from scratch the next time it is requested.
Provisioned folders that are incorrectly pointing into unprovisioned parent folders (ProvisionedFolder): Repair tasks can fix Provisioned folders incorrectly pointing into unprovisioned parents or vice versa.

Syntax

New-MailboxRepairRequest -Mailbox <MailboxIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Archive <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

New-MailboxRepairRequest -Database <DatabaseIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

Parameters

Database, Mailbox and Archive: You can repair an entire mailbox database or a specified mailbox by specifying either the Database or the Mailbox parameter. You can't use both. To repair the archive mailbox for the specified user, use the Archive switch.

CorruptionType: (at least 1 required) you are already familiar with, we discussed them above:

SearchFolder
AggregateCounts
ProvisionedFolder
FolderView

You can run a repair task with multiple parameters if you separate them with a comma (as shown in the Examples section below).

DetectOnly: (Optional) The DetectOnly switch secifies that you want this command to report errors, but not fix them. You don't have to specify a value with this switch.

Other Optional Parameters: This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer and OutVariable. For more information, type "get-help about_commonparameters".

New-PublicFolderDatabaseRepairRequest

The New-PublicFolderDatabaseRepairRequest cmdlet detects and fixes Public Folder replication state problems.

Syntax

New-PublicFolderDatabaseRepairRequest -Database <DatabaseIdParameter> -CorruptionType <PublicFolderDatabaseCorruptionType[]> [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

Parameters

Database: (required) Specifies the Public Folder database on which you will run this command. You can use one of the following values:
- GUID of the database
- Database name
CorruptionType: (required) Pretty easy, there's only one value.
- ReplState
DetectOnly: (optional) Specifies that you want this command to report errors, but not fix them. You don't have to specify a value with this parameter.
Other Optional Parameters: This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer and OutVariable. For more information, type "get-help about_commonparameters".

Examples

New-MailboxRepairRequest -Mailbox administrator@contoso.com -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

New-MailboxRepairRequest -Mailbox administrator -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView -WhatIf

New-PublicFolderDatabaseRepairRequest -Database PFD01 -CorruptionType ReplState -DetectOnly

Some additional examples are provided in the cmdlet help. You can retrieve them using the following commands, or refer to New-MailboxRepairRequest and New-PublicFolderDatabaseRepairRequest cmdlet reference:

Get-help New-MailboxRepairRequest -examples
Get-help New-PublicFolderDatabaseRepairRequest -examples

I recommend that you get to know the cmdlets by using the cmdlet reference docs, or by using the following commands to retrieve detailed help from the shell:

Get-help New-MailboxRepairRequest -detailed (or -full)
Get-help New-PublicFolderDatabaseRepairRequest -detailed (or -full)

Event Reporting

After submitting the Mailbox or Public Folder repair request, you can monitor its progress with the Event Viewer. That's right, no more text logs to weed through. The events are logged under the MSExchangeIS Mailbox Store source.

The following event IDs will be logged for repair requests:

10047 A mailbox-level repair request started
10064 A Public Folder repair request started
10048 The repair request successfully completed.
10050 The mailbox repair request task skipped a mailbox .
10059 A database-level repair request started.
10062 Corruption was detected.

Figure 1: Mailbox or Public Folder database repair request events are logged in the Application event log

Note: the repair events will only show up on the mailbox server where the mailbox or Public Folder is located.

This is very important to remember. Just because you fired off a repair task on a mailbox server does not mean the events will show up on that server. The repair task will be run on the database where the mailbox itself is, and the events will be in the event log on that mailbox server and that server alone.

Things to remember:

Only 1 active repair task is permitted to be running per server if the active task is a database level repair.
Only 100 mailbox level active repair tasks are permitted to be running at once per server.
There is no -Server parameter to do all databases or mailboxes on a server.
The repair task dies on database dismount or store stop/crash.
The only way to stop a repair is to stop the store or dismount the database.
Mailbox access will be disrupted for the mailbox that is being repaired.
Repair for a mailbox will skip a mailbox if it has been quarantined.
Repair will cause a move-mailbox operation to be delayed until the repair is completed.

Steve Bryant

Geek Out with Perry on More Exchange Archiving and Storage

Exchange — Fri, 20 Aug 2010 15:08:35 GMT

We have received some great feedback and questions from last month's post on Perry Clarke's blog and Geek Out with Perry series of videos on e-mail archiving. This has been a hot and somewhat controversial topic that comes up often amongst our customers and partners so we wanted to share the latest edition of Geek out with Perry with you.

In this next installment, Perry addresses two main items: tiered storage as a method to help customers reduce costs and the use of stubbing in archives. Do these two approaches make sense for archives? Check out this new video and blog post to see what Perry thinks about these subjects and share your thoughts and questions with us.

- Ann Vu

Exchange Circular Logging and VSS Backups

Exchange — Wed, 18 Aug 2010 13:10:34 GMT

In discussions with some of our friends over in the DPM team (System Center Data Protection Manager), we’ve found that there is a rather high incidence of VSS errors in installations where DPM is being used to back up Exchange 2010. Turns out that in many instances, this is because of an incorrect configuration of circular logging on the mailbox databases being backed up, so we thought we would quickly discuss circular logging, what it is, and how it affects VSS backup scenarios.

Circular logging has been around for a long time in the Exchange world. I found KB147524, which references Exchange 4.0, and discusses circular logging. When you configure an Exchange database with circular logging turned on, Exchange doesn’t wait until a backup occurs to truncate transaction log files. Rather, as soon as the log files have been played forward into the database, Exchange is free to delete those transaction logs. In Exchange 2003 and before, this was always handled by the Information Store service.

With Exchange 2007 and later there is actually another form of circular logging, known as continuous replication circular logging (CRCL). There is a great discussion of this in the Continuous Replication Deep Dive white paper, so I’m not going to delve into the mechanics of how it works, other than to state that the system ensures that logs are not truncated on the source until all copies agree with the deletion.

Circular Logging is useful in a few scenarios:

Customers leverage circular logging on mailbox databases that do not contain any user data.
Customers leverage circular logging on mailbox databases within lab environments.
Customers leverage circular logging on mailbox databases in Exchange 2010 when they utilize the Exchange Native Data Protection built into the product because there is no traditional VSS backup solution used to manage the log file truncations.

Customers occasionally leverage circular logging on mailbox databases when performing mass mailbox moves to a single mailbox database target within a small period of time to minimize the capacity impacts that could cause an outage event on the target database. If you are deploying an Exchange solution that will continue to leverage a VSS backup infrastructure and enable circular logging it is imperative that you remember to disable circular logging prior to your next backup window, otherwise your next full or incremental backup will fail. For example, some VSS solutions perform incremental backups of Exchange data by capturing the transaction log files generated since the previous backup that managed/truncated the transaction logs (a full backup, or the previous incremental backup). If you have circular logging turned on, when the incremental backup is performed, the log files that are expected to be there since the previous backup are not there – they have been truncated – causing the backup to fail.

So, what are we saying here? We know that there are some valid and supported scenarios where circular logging is very useful. The idea here we want to reinforce is that when you are performing VSS backups that rely on the transaction logs, make sure that your normal run state is with circular logging turned off. If you have a reason to turn circular logging on when utilizing VSS incremental backups that rely on the transaction log files, remember to turn it back off as soon as reasonable, and understand that while circular logging is on that your incremental backups will fail to complete as expected!

-- Robert Gillies

White Paper: Understanding the Relative Costs of Client Access Server Workloads In Exchange Server 2010

Exchange — Mon, 16 Aug 2010 19:06:02 GMT

Just a quick heads-up that we have published a new Exchange 2010 whitepaper:

White Paper: Understanding the Relative Costs of Client Access Server Workloads In Exchange Server 2010
http://technet.microsoft.com/en-us/library/ff803560(EXCHG.141).aspx

Here is what it is about:

Estimating your Exchange Server 2010 Client Access server capacity needs is a critical setup task. The Client Access server is the entry point for all users. In addition, the Client Access server hosts important services used by the other Exchange server roles. This white paper presents an estimate of the relative CPU weights of the different protocols on the Client Access server that can be used to produce a more detailed estimate of hardware needs when you design a new Exchange 2010 deployment or expand an existing one. As part of the testing performed while researching this white paper, the effect of MailTips and the cost of NTML versus Basic authentication were also compared.

- Nino Bilic

Summer reading fun

Exchange — Thu, 12 Aug 2010 18:42:59 GMT

As many of you know I review Exchange books for fun (yea... an odd hobby of mine), and I always look forward to new Exchange books coming out. Today it is my pleasure to note that two of our very own TAPs (Siegfried Jagott and Joel Stidley) had a new book coming out that covers Exchange 2010 SP1! You can order it here. I can tell you it's a good read, having reviewed the book myself! But don't just take my word for it; Tony Redmond (also a noted Exchange author) also reviewed the book as well. And if that was not enough - many TAPs and others wrote interesting sidebars that added interesting short topics to the book. TAP names you can recognize like Gary Cooper, Henrik Walther and Brian Day. A host of internal Exchange folks as well - like Kristian Andaker, Ross Smith, Todd Luttinen, Ed Banti, Greg Taylor, Andrew Ehrensing, and many, many more (see the acknowledgment page for a complete list).

If you are wondering about what the "TAPs" are and want to get a little bit more about the people behind this book, here is an excerpt from the book Foreword that I wrote for it:

Microsoft's Technology Adoption Program is designed to validate new versions of Exchange by having customers test and run production deployments of pre-release builds of the next version of Exchange. This gives participants the opportunity to provide real-time design feedback to the Exchange product development team. Microsoft deployed the first production Exchange 2010 server on April 16, 2007 and on January of 2008 released bits to TAP customers and partners for review. Shortly thereafter, the authors and other customers were running Exchange 2010 in their production deployments. When Microsoft officially shipped Exchange 2010 on November 9th, 2009, TAPs had already deployed over 200,000 mailboxes into production! Through this preliminary process, the authors were there every step of the final design, gaining valuable experience with each TAP release for deployment. During this TAP deployment phase, all TAPS work together with Microsoft to find the best product and best ways to deploy. Here is what one TAP had to say on this process:

"We have learned a lot through this process and not only about Exchange 2010. By interacting with other TAP members and the product group on a daily basis we have been able to remove the blinders we sometimes wear from administering the same system day in and day out. This has allowed us to consider alternate approaches we could take to improve our system overall and to identify where some of our own shortcomings are. I've seen things posted I've never even thought of before and hope that our contributions have done the same..."

Individually and collectively the authors who wrote this book have been working with Exchange 2010 for as long as many senior developers at Microsoft. They have done an awesome job of providing readers with the ins and outs of the full range of features of Exchange 2010, which will help you get the most out of the product. Exchange administrators will find the experienced hands-on approach of this book invaluable in designing and deploying Exchange 2010. You wouldn't want a book that only skimmed and introduced new features. Fortunately for you, this book is based on the experience of years of successful deployments in complex environments and a teamwork approach to the final design process. Microsoft and TAPS have built a product that we are truly proud of, and this book brings you the right way to walk through it. This book definitely belongs on the shelf of every serious Exchange Administrator or IT Manager.

So, if you are looking for some good summer reading, look no further!

- David Espinoza

Exchange 2010 Cross-Forest Mailbox Moves

Exchange — Tue, 10 Aug 2010 19:50:37 GMT

EDIT 8/12/2010: Added a note about the necessity to manually enable MSProxy in remote forest.

We are seeing some trends where quite a few customers are migrating mailboxes to a new Exchange organization, in a different Active Directory (AD) forest. This blog post is aimed at helping to explain the fundamentals of what is required to move mailboxes across forests so that you can be prepared with the correct data, make better plans, and successfully perform a migration without encountering painful problems. The blog post doesn't cover how to setup and configure shared address space or Free/busy.

After reading this blog post, you should have better understanding of:

How to plan your migration by understanding your current forest configuration and your desired configuration.
Different ways for you to synchronize user data between different AD forests.
Networking and Administrator permissions required to perform a successful cross-forest mailbox move.

The trends we are seeing currently show that companies are having more trouble understanding the different scenarios than performing the migration. There are several scenarios here, and Microsoft has tools, documentation, and scripts to assist in each one of them.

There are many reasons companies choose to have multiple forests or maybe find themselves with multiple forests, requiring cross-forest moves of users and mailboxes. For instance:

Companies that merge, are bought out, or have absorbed another company in some manner.
Companies who want to start fresh and leave a lot of legacy issues behind.
Companies that have subsidiaries; segment their environment by Department, Geography, or for Security considerations.

The common Active Directory topologies that are supported in Exchange 2010 are as follows:

Single forest, single Active Directory site
Single forest, multiple Active Directory sites
Multiple forest, multiple Active Directory sites

Exchange deployment topologies vary due to organizational size and business complexity. Variations may include Single Forest, Resource Forest, Hybrid Forest, and Cross Forest topology. For purposes of discussion the following forest definitions will be used going forward:

Forest Name

Active Directory user object status

Mailbox Status

Exchange Forest

Enabled User Object

Mailbox Enabled

Account Forest

Enabled User Object

No mailbox enabled objects

Resource Forest

Disabled User Object (linked to a separate enabled user object in an Account Forest)

Mailbox Enabled

Hybrid Forest

Both
1.) AD Enabled Mailbox Enabled
2.) AD Disabled Mailbox Enabled

Both mailbox enabled and disabled objects

Most of the Cross-Org Move Mailbox scenarios are closely related to the Active Directory Forests involved in the migration. There are 3 major scenarios to be considered:

1. Move from Exchange Forest A to Exchange Forest B. This means that the user is a security principal in forest A and after he is moved to forest B, he is a security principal in forest B as well.

This may be a hybrid-forest scenario, typical during inter-forest migrations, because the user is security principal in both.
Hybrid is when there are both enabled and disabled users in the same forest.

2. Move from Account Forest to Exchange Resource Forest.

Company is splitting Exchange off to its own forest. Maybe due to outsourcing it, complex business organization, or desire to de-couple the Exchange org (e.g. messaging services) from the other infrastructure.

3. Move from Exchange Resource Forest to Account Forest. This is the reverse of #2.

Company is bringing Exchange back into the same forest for simplicity, to better integrate with OCS (though they are not required to be in the same forest), or collapsing/consolidating previously separate Exchange orgs into one user forest.

Cross-forest is when all users from the same organization are only contacts or mail enabled user objects in the other forest.

This is not referenced as a common scenario because it's usually in place between two separate legal entities and there would not be much movement (e.g. migrations) between them.

Active Directory Forest Configuration examples:

Below are some AD forest configuration examples. The forest scenarios don't necessarily imply there is a "move" or migration going on, some are long-term configurations.

Resource Forest

A Resource Forest scenario is a deployment that has at least one Exchange Resource Forest that hosts user mailboxes (but not active user accounts or enabled user accounts) and at least one other forest that hosts the AD user accounts. In other words, Exchange is installed into an AD forest which is separate from the "user account" AD forest.

A one-way forest trust where the resource forest trusts the account forest is created.
Each mailbox in the Exchange forest must have a corresponding user in the account forest, which is granted access to logon to the mailbox. This is referred to as a "Linked Mailbox".

The user objects in the Exchange forest are never logged onto by an end user and are disabled.

Hybrid Forest

Typically this scenario is maintained initially for co-existence while migrating and decommissioning a forest. It is different from a typical cross-forest scenario because there may be both enabled and disabled users in both forests for the same organization. In some cases, an organization may actually need to maintain the Hybrid Forest scenario over the long-term. While this is a supported scenario, it comes with additional complexity that must be addressed:

Mastering User and Exchange attributes occurs on both sides.
A tool such as Forefront Identity Manager (FIM), is needed to maintain consistent data on both sides, including the GAL.
Free/Busy and Public Folder access requires additional configuration, tools, and in some cases maintaining an Exchange 2007 server. (Please note that the IOREPL tool isn't currently supported with Exchange 2010 as a target server and in fact follows the Exchange 2003 Product support life cycle.)
Free/Busy, over the long-term will be best managed using the new Federation services (Microsoft Federation Gateway)

For more information refer to Understanding Federation

Cross-forest

Both forests contain mailboxes and user accounts and contacts. This type of configuration has user accounts always enabled and mailbox enabled, with a corresponding contact in the other forest. The following diagram depicts how different objects are represented in the corresponding forest:

For more information on forests related to Cross Org migrations, refer to http://msexchangeteam.com/archive/2006/11/02/430289.aspx

Three Migration paths you need to choose from:

Depending on the current topology you have employed, you may find yourself planning to move users into the new forest and then following with moving their mailboxes as well. There are essentially three ways of planning to move your resources:

A customized deployment in which you write ILM rules extension code to create the target Mail Enabled User (MEU). You should already have a custom ILM deployment for cross forest GALSync. Microsoft Identity Lifecycle Manager Service Pack 1 Feature Pack 1 (ILM 2007 SP1 FP1) GALSync Management Agent (MA) doesn't include several attributes now required in Exchange 2010, most importantly, msExchMailboxGUID. The out of the box GALSync MA cannot be used since it creates contact object instead of user object required for Online Mailbox Move. The ILM sample code demonstrates how to sync source mailbox as Mail Enabled Users (MEU).

Note: Customers using "out of the box" GALSync MA may probably not know how to customize ILM.

Use Prepare-MoveRequest.ps1 script to create the target MEU. It is important to note that the PrepareMoveRequest script works in conjunction with "out of the box" Exchange GALSync MA for ILM (or FIM). This means the script has built-in logic to convert target Mail Enabled Contact (MEC) created by ILM GALSync MA into the required MEU.
Use Prepare-MoveRequest.ps1 script and then use ADMT to migrate the other attributes on the user object.

Important Note: Our recommendation on working with ADMT is to rely on the PrepareMoveRequest script to create the local user object for mailbox move, and then use ADMT to migrate SIDHistory and password and merge this into the MEU created by PrepareMoveRequest.ps1 script.

The point of doing ILM or the script first is to ensure the MEUs are all created with the correct msExch* attributes. This also ensures the following benefits:

A correct GAL immediately for co-existence (short or long-term)
Permissions for delegates and mailbox access are preserved during the move using the msExchMailboxGUID attribute. Since this is populated on the target object with PrepareMoveRequest.ps1 the permissions will be maintained in the cross-forest move.

At this point it doesn't matter if ADMT is used to migrate/merge the user objects all at once or in "batches" of user objects. ADMT can be controlled better to ensure only merging of SIDhistory and certain other mandatory attributes if it's not already populated.
Running ADMT first, without ensuring exclusions on msExch* attributes, can cause corrupted objects which the script cannot correctly convert with the -UseLocalObject switch.
Important Note: When SP1 ships, we will support running ADMT first and then the PrepareMoveRequest script later.

ILM and PrepareMoveRequest Scenarios broken-down:

There are basically 5 steps involved with moving a mailbox across a forest in Exchange 2010. They are: Preparing Active Directory, Network Prerequisites, Administrator Permissions, Moving Mailboxes and Clean-up. Each of these steps is series of smaller steps that need to be taken in order to move a mailbox from one Exchange forest to and Exchange 2010 forest.

The first step in Cross Forest mailbox moves is preparing Active Directory. In the target forest a mail enabled user account must be created with certain attributes. The method used for creating the target account and setting the mandatory attributes is up to the organization administrator. ADMT and ILM can be used to synchronize/pull over the attributes from the source forest.

Exchange Provisioning using ILM 2007

If you deployed ILM for cross-forest global address list (GAL) synchronization, the recommended approach to creating the mail-enabled user is to use ILM 2007 Service Pack 1 (SP1) Feature Pack 1 (FP1) or Forefront Identity Manager 2010 (FIM) GALSync MA. We've created sample code that you can use to learn how to customize ILM to synchronize the source mailbox user and target mail user.

For more information, including how to download the sample code, refer to this link.

To deploy Exchange 2010 in a cross-forest topology, you must first install Exchange 2010 in the new forest. Then, provision the mail-enabled users representing the source mailboxes so that Exchange 2010 can move the mailbox and migrated users can see all addresses.

Deployment steps:

Deploy Exchange 2010 in a cross-forest topology with ILM 2007 FP1 SP1.
Import and install the ILM sample code from Prepare Mailboxes for Cross-Forest Moves Using Sample Code.

Note: The main purpose of the sample code is to encourage customers to customize, or add more functions to the sample code. The sample code is very basic and it only copies very basic attributes. Customers who rely on this sample code may find many attributes missing.

Configure the Mail-Enabled User provisioning Management Agents for each forest. This allows the mailboxes in the source forest to be created as MEU in the target forest and ensure a common GAL.
Create an SMTP Send connector in each forest and configure SMTP namespace sharing (http://technet.microsoft.com/en-us/library/bb676395.aspx).
In each forest, enable the Availability service so that users in each forest can view free/busy data about users in the other forest. For more information, see Managing the Availability Service.

Note: The Availability service is supported only for Outlook 2007 clients and newer. If Outlook 2003 clients still exist in one of the forests, the only solution will be to deploy Exchange 2007 first in the Exchange 2010 organization (because adding it late is not possible if Exchange 2010 is deployed first) and implement the IOREPL tool to replicate Free/Busy system public folders to the Exchange 2007 server. The Free/Busy system public folder replicas can then be replicated using PF replication to your Exchange 2010 server. IOREPL will not replicate a public/system folder directly to an Exchange 2010 server.

For more information review:

Exchange Provisioning using ILM 2007 and FIM 2010
http://technet.microsoft.com/en-us/magazine/ff472471.aspx

Prepare-MoveRequest.ps1

It may be difficult for some customers to synchronize the prerequisite attributes for performing mailbox moves without using ILM. You may have some other solution in place that does not synchronize the required attributes, and does not allow customization. Small companies may not have a solution at all and simply wish to transition users from an existing forest (that is set to be obsolete) to a new, clean Exchange 2010 forest.

To solve this problem, the PrepareMoveRequest script has been written to prepare the AD target object and synchronize the required attributes for cross-forest moves to work. The script creates the target MEU if necessary, or synchronizes an existing MEU when possible.

The PrepareMoveRequest script prepares Exchange 2003, Exchange 2007, and Exchange 2010 mailbox users for migration to an Exchange 2010 forest.

For more information about using the sample script, refer to the following link.

The PrepareMoveRequest script supports 2 scenarios:

Creating a brand new user in the local forest where the MBX will be moved to.
A local recipient, either a MEU or MEC already exists, created by an external agent such as ILM - If the local forest object is a mail contact, the script will convert the mail contact to a mail user while persisting the contact's existing exchange-related attributes. If the local forest object is a MEU, the script will reuse this mail user and stamp the essential attributes on the local mail user object. The administrator must specify the -UserLocalObject switch in order to tell the script to use this scenario.

Note: The scenario that the script doesn't support is that some external process created a local user object and relies on the script to copy all the attributes and links from the remote MBX to the local user. This is the ADMT scenario described after this scenario.

In order to run New-MoveRequest cmdlet to move a mailbox from an Exchange 2003/2007/2010 source forest to an Exchange2010 target forest, the target forest must contain a valid MEU account with the set of AD attributes described in this section. These attributes are synchronized by the PrepareMoveRequest script.

There are certain mandatory attributes that should be present on the target mail user for New-MoveRequest to run properly. These attributes are always set by the PrepareMoveRequest script, either as they are taken from the source MBX, or as determined by the script. The attributes are listed here http://technet.microsoft.com/en-us/library/ee861103.aspx.

Process Overview: Run PrepareMoveRequest script first and then ADMT

Prepare MEU

To create the target mail enabled user account in an Exchange 2010 forest from the source mailbox enabled account in the source Exchange forest, the PrepareMoveRequest script must be executed in the target Exchange 2010 forest. The script pulls the mailbox enabled account attributes from the source forest.

The script can be used to provision one target MEU account at a time, but can also take data that is passed by pipeline as input to provision MEUs in bulk.

Since PrepareMoveRequest script relies on Update-Recipient task that exists only in Exchange Management Shell, all the below commands need to be run in Exchange Management Shell. Running in PowerShell will only result in error.

Run the below commands in the target forest

$Local = Get-Credential

Input the target forest's Administrator Credentials in "Domain\User" and Password format.

Note: The account used should have permissions to call Update-Recipient which is available only to Exchange Enterprise Admin.

$Remote = Get-Credential

Input the Source forest's Administrator Credentials in "Domain\User" and Password format.

Note: Since the PrepareMoveRequest script will also update the source object's proxyAddresses to include the target object's legacyDN as X500 address, the account used to run this command should have Read and Write access for the source forest.

Run the PrepareMoveRequest script in the target forest

[PS] C:\>.\Prepare-MoveRequest.Ps1 -Identity "DN of a user from SourceForest" -RemoteForestDomainController "FQDN of Source DC" -RemoteForestCredential $Remote -LocalForestDomainController "FQDN of Target Forest DC" -LocalForestCredential $Local -TargetMailUserOU "Distinguished name of OU in TargetForest" -UseLocalObject

Note 1: You can use the -Verbose flag to check which attributes have been set if you want to get a detailed list of the attributes that were touched.

Note 2: You can use the -UseLocalObject parameter here.

If the local matching object is found, then the local object will be used.

Note: If the local matching object is found and UseLocalObject is not defined, the script will throw an error.

If the local object doesn't exist, even if UseLocalObject is specified, the script will still create a new one.

If you are sure that you didn't prepare local object before, you could remove this parameter to ensure accidental overriding.

In the target forest, we get a new disabled mail-enabled user AD object created with some of the following Exchange attributes:

legacyExchangeDN, mail, mailnickname, msExchmailboxGuid, proxyAddresses, X500, targetAddress, userAccountControl, userprincipalName

SIDHistory is empty. This is expected because Exchange doesn't migrate SIDs. At this point all of the required attributes to perform a mailbox move have been synced into the target forest.
Run ADMT in the target forest.

Note: Currently the Active Directory Migration Tool (ADMT) v3.1 is not supported on Windows 2008 R2 Servers. If you plan to use ADMT v3.1, it must be installed on Windows 2008 server.

Check the results in the target forest: The user should now have SIDHistory matching the objectSid of the source object (all other attributes are left untouched)

Gotchas running ADMT first and then PrepareMoveRequest script:

Currently, several customers are running ADMT first and then running the PrepareMoveRequest script. When a user is created via ADMT, the PrepareMoveRequest script doesn't work since there are no proxyAddresses for the script to match the source forest user with the target forest user.

The recommended approach is to copy at least 1 proxy address using ADMT. However, if you use the -UseLocalObject parameter, the script will only copy the 3 mandatory parameters (msExchMailboxGUID, msExchArchiveGUID, msExchArchiveName). This is not very useful. Customers can simply copy these 3 themselves.

Important Note: In SP1, we are adding the OverwriteLocalObject parameter. This is designed for the ADMT case. ADMT can copy the SIDhistory, password, and proxyAddresses, and the PrepareMoveRequest script can sync the other email attributes. In this case, it will copy attributes from source to target, so it's the opposite of UseLocalObject.

ADMT and Exchange Attributes

ADMT transfers Exchange attributes (e.g. homeMDB, homeMTA, showInAddressBook, msExch*) which make the target user look like a legacy mailbox in the target domain. This leaves the target account in an invalid state (e.g. homeMDB still points to the old forest) which is unexpected for the

PrepareMoveRequest.ps1 script. To prevent this, Exchange attributes are excluded from ADMT.

The PrepareMoveRequest.ps1 script can identify and match existing accounts in the target forest based on their SMTP address (proxyAddresses attribute).

Note: It can also do this based on the MasterAccountSid, but this is only populated for accounts in a resource forest scenario.

More precisely, the script will use the existing target accounts if the following are true:

The target account has a value in proxyAddresses which matches one of the proxyAddresses of the source account.
The target account is a mail enabled user i.e. you can retrieve it with the Get-Recipient command. For this to succeed, it needs to have mail attributes like 'mail', 'targetAddress' etc.
You need to specify the -UseLocalObject parameter in the script

If all these are true, the script will copy further attributes needed (especially msExchMailboxGUID) to the target account so that the move request can process the accounts.

By default, ADMT 3.1 does NOT migrate "mail", "msExchMailboxGuid" and "proxyAddresses" attributes because of security reasons. This is documented in the below article under "System attribute exclusion list"

Managing Users, Groups, and User Profiles
http://technet.microsoft.com/en-us/library/cc974331(WS.10).aspx

Important Note: When running ADMT second after ILM due to both forests having the same schema (attributes), unexpected Exchange attributes are brought over. This can cause issues. HomeMDB for example is brought over and causes the MEU to look like a legacy mailbox, and is unusable.

To resolve the problem of ADMT being run first, and leaving the user in an invalid state for the PrepareMoveRequest.ps1 script, you can create the following VB script/ADMT COM object model to exclude all Exchange attributes from being migrated by ADMT.

Set O = CreateObject("ADMT.Migration").
o.SystemPropertiesToExclude = " HomeMDB,HomeMTA,showInAddressBook,msExchHomeServerName, mail, proxyAddresses, msExch*"

This allows update-recipient to find the target object and match it with the source account and merge the two together. For more information, refer to the below article:

You will find that several custom attributes are missing when you use ADMT to migrate users between two forests

http://support.microsoft.com/kb/937537

Network Prerequisites

When mailboxes are moved from one Exchange 2010 forest to another Exchange 2010 forest, the process is handled through Exchange 2010 Client Access Servers using the MRSProxy service. The only port required to be open between the forests for MRSProxy to use HTTPS traffic is port 443. This works even if the source mailboxes are on 2003 or 2007 MBX servers as long as an Exchange 2010 CAS server exists in both organizations.

Note: The whole forest doesn't need to be Exchange 2010 in order to use the MRSProxy. If there is at least one Exchange 2010 CAS in the forest (with access to the Mailbox Servers and AD), it can be used as the MRS Proxy for moves from a mostly Exchange 2003 or Exchange 2007 forest. This can be called the "Remote" scenario (or the "MRSProxy" scenario). By default, MRSProxy is disabled. To start MRSProxy on the Client Access server in the remote forest, you must modify the Client Access server's Web.config file. For more information refer to http://technet.microsoft.com/en-us/library/ee732395.aspx. If CAS servers are behind the NLB, you should do this on all servers that can take the load.

If the mailbox is being moved from legacy Exchange forest then the mailbox replication service will need to have the same TCP ports open that is needed for a normal local mailbox move. Listed are the TCP ports that are needed for a local mailbox move. These ports will be needed to be open both ways for mailboxes to be moved.

Note: This is more of the "Remote Legacy" scenario, but it can be used between two Exchange 2010 forests as well as between one Exchange 2010 forest and one Exchange 2003/2007 forest.

Port

Protocol

808 (TCP)

Mailbox Replication Service uses to communicate

53 (TCP)

DNS

135 (TCP)

RPC End Point

389 (TCP)

LDAP

3268

LDAP

1024 > (TCP)

if mailbox store is not statically configured then 1024 higher ports need to be open

88 (TCP)

Kerberos

445 (TCP)

Microsoft-DS Service

443 (TCP)

Mailbox Replication Proxy service uses port 443 to communicate with other Exchange 2010 client access server via HTTPS.

Also it is necessary for servers in both forests to successfully perform name resolution using DNS.

For cross forest mailbox moves via the MRSProxy service, the source and target servers use certificates to encrypt the HTTPS traffic. The CAS Servers in the source and target forests must have installed a valid certificate that has been issued by a trusted certificate authority recognized by the server in the opposite forest.

Administrator Permissions

In order to move mailboxes across different Exchange forests the account used to initiate the move request in the target forest and the account used to access the mailbox and directory in the source forest must have the proper permissions. The permissions that are needed for the account in the source forest depend on the type of move.

Remote

The account must have the privileges made available by membership in the Recipient Administrators group.

Remote Legacy

The migration account must have the following permissions.

Exchange Server Administrators role
Exchange Recipient Administrators role

Destination Forest Permissions

In the target Exchange 2010 organization the account used to create and manage the move request must be a member of the Organization Management or Recipient Management role groups, or have the following RBAC roles assigned either directly or through group membership:

Move Mailboxes role
Mail Recipients role
Mail Recipient Creation role

Only the Move Mailbox role is required to have access to the New-MoveRequest command. However, the Mail Recipients and Mail Recipient Creation roles may also be required to creating and managing target accounts in preparation for mailbox moves.

Moving the mailbox

There are two methods to move a mailbox across forests using Exchange 2010. The method used depends on the type of cross forest move. Both Remote and Remote Legacy cross forest moves can be performed from the Exchange Management Shell, but only Remote moves can be performed from the Exchange Management Console.

Exchange Management Console

To create a new move request for a cross forest move using Exchange Management Console (EMC), the console must have a session open to both the target and source forests at the same time using the feature Add Exchange Forest. This makes it possible to maintain a connection to an Exchange 2010 server in the source forest, and an Exchange 2010 server in the target forest. With a connection to servers in both source and target organizations via the EMC, you will be able to identify a mailbox that is to be moved from the source forest, while initiating the move request on an Exchange 2010 server in the target forest.

To initiate a cross forest move with the Exchange Management Console, navigate to the Mailboxes folder in the Recipient Configuration node of the source forest, select the mailbox(es) to be moved, and then select New Remote Move Request. This starts the New Remote Move Request.

Exchange Management Shell

To initiate a cross forest mailbox move in the Exchange Management Shell a New-MoveRequest command must be issued with Remote* parameters. Move requests issued without Remote* parameters are local moves within the same Exchange forest.

The New-MoveRequest cmdlet requires certain attributes to be synchronized between the source MBX account and the target MEU account in order for the mailbox move to succeed. This is described in the previous steps.

In the target domain, perform the move request by running the below cmdlet

New-MoveRequest -Identity "Distinguished name of User in Target Forest" -RemoteLegacy -TargetDatabase "E2K10 Mailbox Database Name" -RemoteGlobalCatalog "FQDN of Source DC" -RemoteCredential $Remote -TargetDeliveryDomain "Target domain name"

After the move completes, the proxyAddresses and targetAddress attributes should have changed in the target forest. If the accounts are disabled in the target forest, enable it, set a password and log into OWA and test.

After Online Mailbox Move (OMM), the source object is changed from MBX to MEU and target object is changed from MEU to MBX

For more information on performing cross forest moves in Exchange 2010, refer to Managing Move Requests

Clean-up

When the MRS completes the moving of mailbox data from the source forest to the destination forest it mailbox enables the target user account. If the user account is disabled it leaves the account disabled. The MRS mailbox disables the source account, and converts it into a MEU account with a target address that refers to the primary SMTP address of the target mailbox account. The New-MoveRequest takes the TargetDeliveryDomain parameter. This is what determines which targetAddress to stamp. MRS checks the list of proxyAddresses for one (not necessarily the primary SMTP) that matches the FQDN specified in the TargetDeliveryDomain. The MRS will stamp this address as the targetAddress on the MEU. We moved away from using the primary SMTP address because there is a need to maintain the primary STMP when moving mailboxes cross-forest since this is part of a user's identity. When the primary SMTP address is the same on both forests, mail flow becomes more difficult.

If the source account is to be retired and removed from the source forest, the administrator must plan for this manual operation outside of the mailbox move operation.

What's coming in Exchange 2010 SP1

As mentioned earlier, SP1, will include the PrepareMoveRequest script as part of the install. Additionally, we are fixing a couple of issues with that script:

Requiring separate local and remote credentials to run the script.
LegacyExchangeDN not set on the new user object after converting local contact to local user.
When specifying TargetMailUserOU, we will only search OUs (instead of other object class).

Common Issues

The most common issues related to PrepareMoveRequest script are listed below. These are not relevant if you have deployed the customized ILM, or if you have already run PrepareMoveRequest.

Not able to match source forest user with target forest user. This is mainly due to the fact the script relies on proxyAddresses to match objects, so the target forest user needs to have at least 1 proxy address that matches the source
Inadequate AD permission to delete/add recipient objects. The script manipulates AD directly and invokes the Update-Recipient cmdlet at the end, so you need to have the appropriate permission to change AD and call Update-Recipient. Another thing you can check is whether the TargetMailUserOU is set correctly.
The current script does not have good support for users created by ADMT. The updated PrepareMoveRequest script in SP1 will support a new parameter "OverwriteLocalObject" for users created by ADMT and it will copy attributes from the source forest user to the target user.
"UseLocalObject" - This is the script logic where we assume ILM has already created the target forest MEC or MEU, and you want to keep the target forest attributes. So the script will convert the target forest MEU or MEC to the required MEU for MBX move.

Finally, a few words of thanks:

I had the privilege of working with several SMEs from the Product Group, Consulting, UE and Support who helped me visualize, plan, develop and complete this blog. I would like to call out Ian Liu (Program Manager) who was instrumental in sharing his vision and being accessible at all times while writing this blog. I also want to thank Daniel Talbot for his expertise on this subject and his many contributions to the blog. Other contributors that I'd like to express gratitude are Andrew Ehrensing and Huangjian Guo. Thanks to Ying Zhang, Ramon Infante, Jeff Kizner, Kweku Ako-Adjei , Ben Winzenz, Kristi Simmons, Bill Haenlin, Laura La Fleur, Nino Bilic, Jonathan Runyon and Ayla Kol for their review and feedback. Last but not the least, I'd like to thank William Rall for his innumerable thorough reviews and feedback that helped shape this blog.

- Nagesh Mahadev

What is Exchange 2010 automatic mailbox distribution?

Exchange — Mon, 09 Aug 2010 10:28:00 GMT

Have you ever wondered why, in Exchange 2010, you can create a new mailbox and you don't have to tell Exchange in what mailbox database it should be created? Or had an administrator in one department create a mailbox, and the mailbox is created in a database that their department isn't assigned? If you've answered 'yes' to either of those questions, you'll want to check out a new article that was just posted today.

Where Did That New Exchange 2010 Mailbox Go? introduces you to automatic mailbox distribution, which is a new feature added to Exchange 2010. The article talks about how automatic mailbox distribution works, steps you through the selection process, and shows you how you can control it using exclusions, Active Directory sites, and (in Exchange 2010 SP1) database scopes.

Take a look at the article and let us know what you think of this new feature.

David Strome

Understanding Remote Mailbox Move and Unified Messaging

Exchange — Thu, 05 Aug 2010 20:41:52 GMT

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

So... why do you care?

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

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

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

This process poses several pain points, most importantly:

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

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

How it works

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

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

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

Further reducing voice mail downtime

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

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

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

SourceForestPolicyNames Attribute

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

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

Other considerations

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

An example of how this can happen is that the UM extension assigned to the mailbox was available in the target forest when the UM-specific validation occurred but is no longer so right when the move finalizes.
A UM-enabled mailbox may be assigned extensions from multiple UMDialPlan objects in the source forest. Only extensions from the primary UMDialPlan will be used to UM-enable the mailbox in the target forest. Extensions from secondary UMDialPlan(s) will not be preserved.

Chun Yong Chua

Throttling Policy Associations in Exchange 2010 SP1

Exchange — Mon, 02 Aug 2010 15:24:48 GMT

Exchange 2010 SP1 introduces two new throttling cmdlets: get-ThrottlingPolicyAssociation and set-ThrottlingPolicyAssociation. In Exchange 2010 RTM, in order to determine which throttling policy was associated with a given user, you would use something like:

Get-Mailbox JohnDoe | fl ThrottlingPolicy

To assign a non-default throttling policy to a user you would call

set-Mailbox JohnDoe -ThrottlingPolicy Foo

One thing that should stand out with these two CMDlets is that policies could only be associated with mailbox accounts. Why would you ever want throttling policies associated with anything else? I'm glad you asked. There are at least two valid scenarios to consider:

Scenario 1 - A machine account: Let's say you write a web site that uses Exchange Impersonation to call into EWS and perform actions on behalf of a user that logged onto your web site. Further assuming that your web site is configured to run as Network Service, the EWS call will come from the *machine* account (such as MyDomain/MyMachine$). When such a call is encountered by EWS, it tries to determine which throttling policy to apply to the machine account. Given that set-Mailbox is not applicable to Active Directory Computer objects, and given that a computer is not *in* any of the organizations defined in the Active Directory, the throttling framework must use the fallback policy for the computer account. Given that the fallback policy is hardcoded within the Exchange binaries, you have no control over reducing or increasing its policy values.

Scenario 2 - A cross forest contact: In cross forest scenarios, you have the option of creating a linked mailbox in the Exchange forest or a linked contact. If an account from user forest A is given Exchange Impersonation rights and needs custom throttling values defined, your only option in Exchange 2010 RTM is to use a linked mailbox so that you can assign a non-default throttling policy using the set-Mailbox cmdlets. When a cross forest account calls into Exchange via EWS, the user is authenticated via the user forest (via the trust), but the Active Directory object that Exchange uses to gather "Exchange" information is contained in the Exchange forest. If that Exchange object is a linked contact, the throttling framework must use the fallback policy to throttle the call, which as mentioned above cannot be modified since it is hardcoded.

To cover these scenarios, we added the get/set-ThrottlingPolicyAssociation cmdlets which operate on "virtual" ThrottlingPolicyAssociation objects. By virtual, I mean that there is no ThrottlingPolicyAssociation class in the Active Directory schema. The association represents the link between some "account" and its throttling policy. And what is an "account"? Well, it could be a mailbox, a computer object or a contact.

So let's see how this works. I created a factious mailbox account for JohnDoe. Let's call get-ThrottlingPolicyAssociation on JohnDoe and see what happens.

[PS] D:\Windows\system32>get-throttlingPolicyAssociation JohnDoe
RunspaceId : b84e9a5e-b4c9-4e58-ad86-26d2fffd9b32
ObjectId : MyDomain/Users/JohnDoe
ThrottlingPolicyId :
Name : JohnDoe
IsValid : True
ExchangeVersion : 0.10 (14.0.100.0)
DistinguishedName : CN=JohnDoe,CN=Users,DC=MyDomain
Identity : MyDomain/Users/JohnDoe
Guid : 4f617494-2542-480d-9db1-2720ddf3c013
ObjectCategory : MyDomain/Configuration/Schema/Person
ObjectClass : {top, person, organizationalPerson, user}
WhenChanged : 7/26/2010 8:13:48 AM
WhenCreated : 7/26/2010 8:13:48 AM
WhenChangedUTC : 7/26/2010 3:13:48 PM
WhenCreatedUTC : 7/26/2010 3:13:48 PM
OrganizationId :
OriginatingServer : MyServer.MyDomain

The association is embodied in the ThrottlingPolicyId and Name properties (in red above). If you look closely at the other properties that were returned, they are all properties on the user object. In fact, all of that data is coming from the mailbox object and not from the throttling policy. Now, let's try a mail contact. This time, I will only ask for interesting properties to save on space.

[PS] D:\Windows\system32>get-throttlingPolicyAssociation MyContact | fl ThrottlingPolicyId, Name, DistinguishedName, Identity, ObjectCategory, ObjectClass
ThrottlingPolicyId :
Name : MyContact
DistinguishedName : CN=MyContact,CN=Users,DC=MyDomain
Identity : MyDomain/Users/MyContact
ObjectCategory : MyDomain/Configuration/Schema/Person
ObjectClass : {top, person, organizationalPerson, contact}

And of course, we can't forget about computers.

[PS] D:\Windows\system32>get-throttlingPolicyAssociation MyComputer | fl ThrottlingPolicyId, Name, DistinguishedName, Identity, ObjectCategory, ObjectClass
ThrottlingPolicyId :
Name : MyComputer
DistinguishedName : CN=MyComputer,OU=Domain Controllers,DC=MyDomain
Identity : MyDomain/Domain Controllers/MyComputer
ObjectCategory : MyDomain/Configuration/Schema/Computer
ObjectClass : {top, person, organizationalPerson, user, computer}

The magic comes from the fact that the throttling policy "stamp" is made available on users, contacts and computers via the mailRecipient auxiliary class in the Active Directory schema. The attribute was actually available in Exchange 2010 RTM on users, contacts and computers, but it was not "PowerShell" accessible until these new cmdlets were added. To change the throttling policy association for a user, contact or computer, simply call set-throttlingPolicyAssociation with the identity of the account to change and the throttling policy identity to associate it with:

set-throttlingPolicyAssociation JohnDoe -ThrottlingPolicy Foo

In fact, we can assign users, contacts and computers in one shot:

[PS] D:\Windows\system32>$identity = "JohnDoe", "MyContact", "MyMachine"
[PS] D:\Windows\system32>foreach ($id in $identity){set-throttlingPolicyAssociation $id -ThrottlingPolicy Foo}

And just to confirm that it did indeed work:

[PS] D:\Windows\system32>foreach ($id in $identity){get-throttlingPolicyAssociation $id | fl Name, ThrottlingPolicyId}
Name : JohnDoe
ThrottlingPolicyId : Foo
Name : MyContact
ThrottlingPolicyId : Foo
Name : MyMachine
ThrottlingPolicyId : Foo

You may be relieved to know that getting and setting the throttling policy for a mailbox still works through get/set-Mailbox. However, for new scripts moving forward, we suggest you use the new, shiny get/set-ThrottlingPolicyAssociation cmdlets.

One important thing to note is that you use the ThrottlingPolicy parameter in set-ThrottlingPolicyAssociation whereas the property that is returned in get-ThrottlingPolicyAssociation is called ThrottlingPolicyId. This difference continues to trip me up when using these cmdlets, so when you encounter this difference, know that you are in good company.

- David Sterling

Confused About Named Properties Quotas in Exchange 2003 and Exchange 2007? Join the Club!

Exchange — Thu, 29 Jul 2010 17:00:21 GMT

One of my favorite things about my job is that I get to learn new stuff everyday! It's like being in school all of the time! And yes, I was that person in class that always ruined the curve for everyone else.

If you have been using either Exchange 2003 or Exchange 2007 for any length of time, you may have experienced the dreaded Named Properties Depletion warning in your Application Event log. If you haven't, they look like this:

Named Properties Warning for Mailbox Databases:

Event ID: 9666
Type: Warning
Category: General
Source: msgidNamedPropsQuotaWarning
Description: The number of named properties created for database "<database name>" is close to quota limit. Current number of named properties: <number of named properties>. Quota limit for named properties: <configured quota>. User attempting to create the named property: <user name>. Named property GUID: <GUID of named property>. Named property name/id: <name of named property>.

Note: Event ID 9666 can refer to Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI) creation of named properties. For a more in-depth explanation of the difference between Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI), please see Jason Nelson's blog about Named Properties, X-Headers, and You (http://msexchangeteam.com/archive/2009/04/06/451003.aspx)

Even worse is getting the error events.

Named Properties Error for Mailbox Databases:

Event ID: 9667
Type: Error
Category: General
Source: msgidNamedPropsQuotaError
Description: Failed to create a new named property for database "<database name>" because the number of named properties reached the quota limit (<configured quota>). User attempting to create the named property: <user name>. Named property GUID: <GUID of named property>. Named property name/id: <name of named property>.

Note: Event ID 9667 can refer to Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI) creation of named properties. For a more in-depth explanation of the difference between Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI), please see Jason Nelson's blog about Named Properties, X-Headers, and You (http://msexchangeteam.com/archive/2009/04/06/451003.aspx)

By the time the error is recorded, you are probably getting calls from your end users wanting to know why they can't send or receive mail. I am not going to explain the history and impact of Named Properties since Jason Nelson wrote several excellent blogs on this (which I use all the time). Check them out here:

Named Properties, X-Headers, and You
http://msexchangeteam.com/archive/2009/04/06/451003.aspx
Named Properties, Round 2: What lies Ahead
http://msexchangeteam.com/archive/2009/06/12/451596.aspx
Service Pack 2 Preview: Get-NamedProperty
http://msexchangeteam.com/archive/2009/08/06/451948.aspx
Understanding how Outlook, CDO, MAPI, and Providers work together
http://msexchangeteam.com/archive/2005/04/08/403512.aspx

Now to clear up the biggest misconception about setting quota limits for named properties for an Exchange 2003 or Exchange 2007 databases:

Setting the quota limits does not increase the number of named properties that can be created in an Exchange 2003 or Exchange 2007 database.
The number of named properties that can be created in an Exchange 2003 or Exchange 2007 database is a limitation of the size of the data type.
Setting the quota limits for named properties for an Exchange 2003 or Exchange 2007 database increases the threshold of when you are going to get the warning and error messages in the Application Event log.

Please read the above again; it's kind of important.

For Exchange 2003 and 2007, the maximum number of named properties that can ever be created is 32,767 per database.

There is not a way to ever increase the number of named properties that can be created in Exchange 2003 or Exchange 2007 database is a limitation of the size of the data type.

It took me several readings of all KB and TechNet articles before I picked up on that. So if you didn't get it, please do not feel bad. I spent a lot of time with one of our Senior Escalation Engineers trying to understand it. Right before I wore out their last nerve, a light bulb went on over my head and I finally understood it. Now I explain it to my colleagues and customers, my cat Spike and strangers at the gas station.

And now for something completely different or a little more in-depth view of NamedProps:

The way this really works is that we have a table in the database called NamedProps. Every Named Property that gets added to the database gets its own row in this table. The limit on the NamedProps table is a limit on the number of rows in the table, which are 32,767.

The quotas, of course, are set much lower than that, so that you have some warning before you run out of rows. It doesn't matter if the user is authenticated or not - they all go into the same NamedProps table. So you could have 32k created all by authenticated users, or 32k all created by unauthenticated users, or 10k created by unauthenticated and 22k by authenticated, or whatever... it doesn't matter who created them, the bottom line is that the maximum is 32k rows in that table.

Once your table passes 8k rows (by default), we stop allowing new named props from unauthenticated clients. It's entirely possible that those 8k rows were all created by authenticated clients, but it doesn't matter. We continue allowing new names from auth clients until we hit 16k, and then we deny them as well. This is assuming the quotas are at the default of 8k/16k.

Below is a table with the named properties quota limits:

Exchange Version

Maximum size of the data type

Default Quota

Default Warning Issued

Default Error Issued

2003 Mailbox Store

Authenticated Users & Non-Authenticated Users 32,767

Authenticated Users: 16,384

Non-Authenticated Users: 8,192

Authenticated Users:

16,364

Non-Authenticated Users: 8,172

Authenticated Users:

16,384

Non-Authenticated Users: 8,192

2007 Mailbox Store

Authenticated Users & Non-Authenticated Users 32,767

Authenticated Users: 16,384

Non-Authenticated Users: 8,192

Authenticated Users:

16,364

Non-Authenticated Users: 8,172

Authenticated Users:

16,384

Non-Authenticated Users: 8,192

For a more in-depth explanation of the difference between Authenticated Users (MAPI) and Non-Authenticated Users (Non-MAPI), please see Jason Nelson's blog about Named Properties, X-Headers, and You (http://msexchangeteam.com/archive/2009/04/06/451003.aspx)

You can increase the thresholds so you don't get the warnings until, say 22,000. We don't recommend setting the warning quota any higher than 16,000 so you will have adequate time to take action.

And we definitely don't recommend setting the error quota to 32,767 because at that point everyone in your Exchange organization is miffed with you and you find yourself uploading your resume to a popular job site on the Internet.

You may ask yourself "where is my beautiful..."; hold on, wrong question.

Is there a way to suppress the creation of future for named properties for an Exchange 2003 or Exchange 2007 database? And what about Exchange 2010?

I am glad that you asked!

For Exchange 2007 SP1 RU1 - RU7, there is a transport agent named HeadFilterAgent that is available for download at:

http://headerfilteragent.codeplex.com/

Exchange 2007 RU 8 for Service Pack 1 and Service Pack 2 (and later) have new code that prevents future promotion of named properties. And this code is already in Exchange 2010 so no action is needed on your part.

For Exchange 2003, we have a hot fix for Service Pack 2 that enables the control for the creation of x-headers for named properties using a Registry Editor entry:

972077 "Outlook cannot display this view. Unknown Error" error message is generated in Outlook client and Event ID 9667 is logged on an Exchange Server 2003 server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972077

After you apply this fix, you may follow these steps to set a registry entry to control the promotion of X-headers for named properties:

1. Click Start , click Run , type regedit , and then click OK .
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS
\ParametersSystem\InternetContent
3. On the Edit menu, point to New , and then click DWORD Value .
4. Type GenerateNamedProperties , and then press ENTER .
5. Quit Registry Editor.
A 0 value of the GenerateNamedProperties attribute will not generate new named properties.

The default behavior (of the promotion of X-headers for named properties) is true when this registry entry is not found or set to 1.

Let's recap:

Setting the quota limits does not increase the number of named properties that can be created in an Exchange 2003 or Exchange 2007 database.

There is not a way to ever increase the number of named properties that can be created in Exchange 2003 or Exchange 2007 database is a limitation of the size of the data type.

You can suppress the promotion of named properties in Exchange 2007 SP1 RU1 - RU7 using the transport agent named HeadFilterAgent . Or by applying Exchange 2007 SP1 RU8 or Exchange 2007 SP2. For Exchange 2003 SP2, a hot fix is available that utilizes a registry setting to suppress the promotion.

- Eileen O'Rourke

Forest Name	Active Directory user object status	Mailbox Status
Exchange Forest	Enabled User Object	Mailbox Enabled
Account Forest	Enabled User Object	No mailbox enabled objects
Resource Forest	Disabled User Object (linked to a separate enabled user object in an Account Forest)	Mailbox Enabled
Hybrid Forest	Both 1.) AD Enabled Mailbox Enabled 2.) AD Disabled Mailbox Enabled	Both mailbox enabled and disabled objects

Port	Protocol
808 (TCP)	Mailbox Replication Service uses to communicate
53 (TCP)	DNS
135 (TCP)	RPC End Point
389 (TCP)	LDAP
3268	LDAP
1024 > (TCP)	if mailbox store is not statically configured then 1024 higher ports need to be open
88 (TCP)	Kerberos
445 (TCP)	Microsoft-DS Service
443 (TCP)	Mailbox Replication Proxy service uses port 443 to communicate with other Exchange 2010 client access server via HTTPS.

You Had Me At EHLO...

Exchange “How do I?” videos

Exchange 2010 SP1 FAQ and Known Issues

Upgrade order

SP1 Prerequisites

Prerequisite download pages linked from SP1 Setup are unavailable

The Missing Exchange Management Shell Shortcut

Upgrading Edge Transport on Forefront Threat Management Gateway (TMG) and Forefront Protection for Exchange 2010

Static Address Book Service Port Configuration Changes

iPhone, OWA Premium and POP3 & IMAP4 issues due to invalid accepted domain

Resolution

Error when adding or removing a mailbox database copy

Updates:

Exchange 2010 SP1 and Support for FIPS Compliant Algorithms

Effects of Throttling on Your Deployment in Exchange 2010 SP1

The Future of Exchange Starts Here: Exchange Server 2010 SP1 Is Now Available

Exchange 2010 SP1: Database Integrity checking

Cool Features

ISInteg can now work at the database or mailbox level

New-MailboxRepairRequest

Syntax

Parameters

New-PublicFolderDatabaseRepairRequest

Syntax

Parameters

Examples

Event Reporting

Geek Out with Perry on More Exchange Archiving and Storage

Exchange Circular Logging and VSS Backups

White Paper: Understanding the Relative Costs of Client Access Server Workloads In Exchange Server 2010

Summer reading fun

Exchange 2010 Cross-Forest Mailbox Moves

Active Directory Forest Configuration examples:

Three Migration paths you need to choose from:

ILM and PrepareMoveRequest Scenarios broken-down:

Gotchas running ADMT first and then PrepareMoveRequest script:

Network Prerequisites

Administrator Permissions

Remote

Remote Legacy

Destination Forest Permissions

Moving the mailbox

Exchange Management Console

Exchange Management Shell

Clean-up

What's coming in Exchange 2010 SP1

Common Issues

What is Exchange 2010 automatic mailbox distribution?

Understanding Remote Mailbox Move and Unified Messaging

So... why do you care?

How it works

Further reducing voice mail downtime

SourceForestPolicyNames Attribute

Other considerations

Throttling Policy Associations in Exchange 2010 SP1

Confused About Named Properties Quotas in Exchange 2003 and Exchange 2007? Join the Club!