Learn how to migrate public folders to Office 365 with our free comprehensive guide. Gain insights from two decades of expertise in Microsoft Exchange Public Folder Migration.
Tag Archive for: Exchange 2010
Last reviewed: April 2026 — checked against current Microsoft product lifecycle and Exchange Online enforcement timelines.
Migrating large Exchange archive mailboxes to the cloud poses a significant challenge due to throttling issues that can hinder the smooth transfer of data. Throttling, a mechanism designed to maintain system performance and prevent overload, often occurs during migrations of large volumes of data, such as Exchange archive mailboxes. Microsoft’s article on auto-expanding archiving highlights the importance of being aware of throttling limitations when transferring large amounts of data to the cloud. Throttling can significantly impact migration efficiency, leading to extended time-frames, failed migrations, and frustration among end users.
In this blog post, we will address the throttling problem organizations face during such migrations and present a solution that simplifies the migration process by mitigating throttling concerns. Our approach combines industry best practices with innovative strategies to ensure a seamless transition of large archive mailboxes to the cloud.
To overcome throttling challenges, we recommend leveraging specialized migration tools designed to handle large data volumes efficiently. One such solution is Priasoft Super ExMerge. This powerful tool incorporates features specifically tailored to address the throttling issues encountered during the migration of large Exchange archive mailboxes. Let’s explore how Super ExMerge can help simplify your migration process and mitigate throttling concerns:
- Dynamic Multi-Threading: Super ExMerge intelligently manages threads during the migration, ensuring the maximum utilization without overwhelming the system. This feature optimizes performance, minimizing the impact of throttling and expediting the migration process.
- Multi-Process Capability: Leveraging the power of multi-process architecture, Super ExMerge can handle multiple migration tasks concurrently. By utilizing available CPU and RAM resources efficiently, it significantly improves throughput and mitigates throttling-related slowdowns.
- Efficient Data Transfer: Super ExMerge only copies new and changed data, thanks to its full fidelity synchronization tracking. This smart approach eliminates unnecessary data transfer, reducing the overall volume of data to be migrated. As a result, throttling concerns are alleviated, and the migration process becomes more streamlined.
- Granular Control and Folder Exclusion: Administrators have granular control over the migration process, enabling them to select specific folders or subtrees for synchronization. Additionally, the ability to exclude certain folders minimizes the migration load, addressing potential throttling issues effectively.
- Authentication Flexibility: Super ExMerge allows each migration task to authenticate with different accounts, distributing the migration load across multiple credentials. This capability prevents throttling limits imposed by Microsoft Exchange, ensuring a smooth and uninterrupted migration.
- Comprehensive Reporting and Logging: Super ExMerge provides detailed reports and logs, offering valuable insights into the migration progress. Administrators can closely monitor the process, identify potential bottlenecks, and take necessary actions to mitigate throttling challenges promptly.
By adopting our alternative solution and utilizing specialized migration tools like Priasoft Super ExMerge, organizations can streamline the migration process and mitigate throttling concerns. This approach ensures a seamless transition to the cloud, minimizing downtime, maximizing data integrity, and enabling your organization to fully embrace the advantages of a cloud-based infrastructure.
Contact our Exchange Engineers today to learn more about our solution and how we can assist you in simplifying the migration of large Exchange archive mailboxes while overcoming throttling challenges. Say goodbye to the frustrations of throttling and embrace a smoother migration journey with Super ExMerge.
Exchange Server 2010 will reach end of support on January 14, 2020. If you haven’t already started thinking about your migration from Exchange 2010 to Office 365 or Exchange 2016 now’s the time.
What Does End Of Support Mean For My Organization?
All Microsoft products have a support lifecycle during which Microsoft will provide new features, bug fixes, and security fixes. The typical Microsoft product lifecycle is 10 years from the date the product was RTM (released to manufacturing). Therefore, when Exchange 2010 reaches its end of support on January 14, 2020, Microsoft will no longer provide:
- Bug fixes for issues that may impact the stability, usability, or performance of the server
- Security updates for vulnerabilities that will make the server vulnerable to possible security breaches
- Time zone updates
- Technical support for critical issues that may occur
You can continue to run Exchange 2010 after January 10, 2020, however, we strongly recommend that you migrate from Exchange 2010 as soon as possible and Priasoft can help make the transition smooth and painless regardless if you’re moving to Office 365, Exchange 2016, or Exchange 2019.
To learn more about migrating Exchange 2010 to Exchange 2016 have a look at our article here.
If you would like to speak to one of our migration experts about migrating Exchange 2010 to Office 365 or Exchange 2016 please contact us. You can also request a free trial of our Priasoft Migration Suite for Exchange to begin testing migrations and estimating migration timing using our Dry-Run feature that lets you simulate the migration without disrupting end users.
Often, setting up a separate Active Directory forest that is dedicated to running Exchange is a better solution than integrating the Exchange application into your production Active Directory security forest.
The Exchange forest (also known as the resource forest) is dedicated to running Exchange and hosting mailboxes. User accounts are contained in one or more forests, referred to as the account forests, which are separate from the resource forest. Using this model, updates and changes to Exchange can be made without affecting the production user account forests.
How it works:
The user from the account forest (where logons occur) is associated with a mailbox attached to a disabled placeholder user in the resource forest. This allows users to access mailboxes that reside in the Exchange resource forest.
The resource forest model is nearly identical to what is provided by Office 365’s Exchange Online, only with more control and easier configuration and setup. There are 3 ways a user would access the mailbox in the resource forest:
- Without a Windows Trust: Users would be prompted for credentials by Outlook and other clients. There is not a built-in Single-Sign-On feature without a Trust.
- With a Windows Trust Using ‘Linked Mailboxes’: Users are not prompted for credentials and the mailbox account in the resource forest is marked with the SID of the logon user in the account forest.
- With a Windows Trust Using ‘SID Future’: Users are not prompted for credentials and the SID of the resource forest account is copied to the user in the account forest as an additional SID.
Note that setting up a Resource Forest does NOT mean that the same level of complexity must be created with regards to Active Directory Domain Controllers and AD Sites. In this scenario, AD plays a supporting role to Exchange and its primary purpose is to provide the address book (by way of the Global Catalog). As such, one (or more likely two, for redundancy) Domain Controller is all that is required, even if there is a need for many Exchange servers. This means that the setup and deployment of a resource forest is quick and not as costly as may have initially been imagined. The DCs in this Resource Forest are not processing logons, logon scripts, and the myriad of other actions and services that a DC normally provides.
A few key Benefits:
- A dedicated security boundary between Active Directory and Exchange administration.
- Features of new platform are realized immediately compared to a ‘mixed-mode’ setup where some key features are always disabled during the while 2 versions run concurrently.
- You can move to new versions of Exchange, like Exchange 2010, 2013, 2016, without polluting, corrupting, or disrupting your existing production Exchange implementation
- Eliminates risk to your existing Exchange implementation
- There are important risks to consider by adding a newer version of exchange to an existing one such as:
- …the newer version will try to take control of many actions, like inbound mail flow, transport rules, and other system level operational tasks.
- …the newer version may enforce attributes on users that are incompatible, but which the current deployment does not
- …the newer version cannot be fully tested and made “production-ready” without interfering with the current environment
- …once the AD Schema is extended to support the new version, there is no ability to reverse the changes
- …Public Folder databases/mailboxes may not sync to newer versions. For example, there is NO REPLICATION between Exchange 2013 PFs and older versions of exchange. If the PF deployment is very large, users may be without PF data for days or weeks after the mailbox migration.
- If a need arises during setup or testing of the Resource Forest to re-architect the environment, such can be done with no impact to the current environment.
- If you merge with another entity it’s simply a matter of creating a trust with the new accounts forest and not having to disrupt the exchange organization
- If you divest part of your business entity’s its much simpler to break off the Exchange resources without giving away sensitive security objects that would be part of the User Domains.
- Schema modifications needed for Exchange are isolated to just the Exchange forest and do not need to be implement in the Accounts forest
- Less stress on Global Catalogs and directory replication in the user accounts forest as all this traffic can remain in the Exchange resource forest
- Patches and updates that are not Exchange related, do not have to be installed in the Exchange forest. This adds a level of stability that is unavailable in a mixed AD/Exchange forest.
- AD container and OU structure can be designed with Exchange Administration in mind and does not have to follow complex architecture of a user forest You can manage users and groups in a way the makes sense for Exchange and not be dependent on how users in the account forest are managed – imagine having a container structure where Executive and Large mailboxes were separated from contractors and simple “mail-consumers”.
- Distribution lists are not co-mingled with security groups because of separate forests. DLs in the Exchange forest can be guaranteed to only provide access to exchange resources.
A few “reported” detractors to the Resource Forest (but not really)
- More admin work
- This is one of the first proposed “negatives” of a Resource Forest. However, it’s a bit of a fallacy. While it is true, at a technical level, that 2 object have to be created and configured when a new user is hired, there is plenty of ability to script such actions into a single atomic event. Powershell, available since Exchange 2007 makes such work trivial now.
- Compared to the many advantages and the infrequency (in most organizations…but not all) of new hires/terminations, the Resource Forest should still be considered.
- Password Sync
- This is reported from time to time, but really only by those that don’t truly understand the model. There are 2 options listed above to provide single-sign-on, which inherently means that passwords do not need to sync.
Prerequisites
- Two Active Directory forests:
- One forest contains the user accounts for your organization. In this procedure, this forest is called the accounts forest.
- One forest does not contain user accounts and does not yet have Exchange installed. In this procedure, this forest is called the Exchange Forest or Resource Forest. You will use the procedure to install Exchange in this forest.
- You have correctly configured Domain Name System (DNS) for name resolution across forests in your organization. To check that you have DNS configured correctly, ping each forest from the other forest or forests in your organization.
For more detailed information on deploying an Exchange resource forest see the following:
The poster helps you understand how the major components of Exchange 2010 work and serves as a quick reminder and a learning tool. The printed version also looks really impressive on your wall!
Download your copy here
You may receive the following error trying to install Exchange 2010 SP1. We sure did…
Error message is as follows:
Some controls aren’t valid. Setup previously failed while performing the action “Install”. You can’t resume setup by performaing the action “BuildToBuildUpgrade”.
Steps to resolve and be able to install SP1:
- Open regedit and browse to the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\
- Look in the installed rolls for a key named Action (in our case it was under the MailboxRole key)
- Back up the section of the registry in case you need to roll back
- Delete the Action key
SP1 setup should now proceed without any further issues.
Issues that the update rollup fixes
Update Rollup 4 for Exchange Server 2010 RTM fixes the following issues: (Get it here)
- An attachment is not visible when an Exchange Server 2010 user opens a signed mail message by using Outlook 2003
- You cannot send a message to a Dynamic Distribution Group in a mixed Exchange Server 2007 and Exchange Server 2010 environment
- An IMAP4 client crashes when accessing an Exchange Server 2010 mailbox
- An error message is generated in Exchange Server 2010 when you use Exchange Troubleshooting Assistant
- You cannot connect an Exchange Server 2010 mailbox by using a MAPI client
- Event ID 1066 is logged and you cannot move a mailbox from an Exchange Server 2003 server to an Exchange Server 2010 server
- Event ID 4999 and Event ID 7031 are logged when you move a mailbox to an Exchange Server 2010 server
- You cannot replicate a public folder from one Microsoft Exchange Server 2010 server to another, and Event ID 3079 is logged on the target server
- The Add-MailboxDatabaseCopy command fails when it is used to add a database copy to a Database Availability Group in an Exchange Server 2010 environment
- A MAPI application that is used to access Exchange Server 2010 mailboxes crashes when the application accesses an address book
- “MAPI_E_INVALID_PARAMETER” error message when you copy email messages from an Exchange Server 2010 mailbox
- Microsoft Exchange Transport service on an Exchange Server 2010 server crashes when a certain message is processed
- An Exchange Server 2010 mailbox user receives a NDR error message when the user sends an email message to multiple internal users
- The RpcClientAccess process on an Exchange Server 2010 server crashes when you access a mailbox by using a MAPI application
- Error message when you expand the Microsoft Exchange On-Premises node in the EMC of Exchange Server 2010
- Event ID 4033 is logged and the Free/Busy replication from an Exchange Server 2003 server to an Exchange Server 2010 server fails
- Some embedded messages are corrupted when they are contained in a message that is sent from an Exchange Server 2010 mailbox address
- delegate receives only one meeting request when someone sends a meeting request to several principals in an Exchange Server 2010 RU1 or later environment
- The msExchVersion attribute value of a user is stamped incorrectly after you run the Enable-MailUser cmdlet to mail-enable the user
- The .xls file as an attachment is empty when you access an Exchange Server 2010 mailbox by using OWA
- “redirect it to people or distribution list” rule does not work on an Exchange Server 2010 mailbox address
- A user intermittently fails to access an Exchange Server 2010 mailbox after the mailbox is moved
UDP notification support was removed from Exchange 2010. As a result, Outlook 2003 can only use polling notifications in online mode. This will result in a slight delay in updates to item status (30 seconds on average with up to a one-minute delay) when changes are made to items in a mailbox accessed by Outlook 2003. There are two workarounds for this issue:
- Use Outlook 2003 in Cached Exchange Mode.
- Adjust the polling interval on the Client Access server. Note: This will impact the performance of the Client Access server.
To resolve this problem, use one of the following methods.
Option 1: Install Update Rollup 1 For Exchange Server 2010
After you install the update, you must add the following registry data to the server by using the Client Access role.
Start Registry Editor.
Locate and then click to select the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
Note: Create the \ParametersSystem registry subkey if it does not exist.
Add the following registry data to the server:
Value type: REG_DWORD
Value name: Maximum Polling Frequency
Value data: any integer between 5000 and 120000 (decimal value)
The registry change is dynamically detected. Therefore, the new settings will be applied to any new connections that clients make after the change is made. If you want to make sure that the new settings are applied to all clients, you should recycle the Microsoft Exchange RPC Client Access service because connections from clients can remain alive for a long time.
Outlook 2003 does not poll the Exchange Server 2010 server in intervals that are less than 10 seconds. Therefore, any value less than 10000 will generally have the same effect.
This change does not reinstate UDP communication between Exchange Server 2010 and Outlook 2003. This change only enables polling to occur more frequently between Exchange Server 2010 and Outlook 2003.
Option 2: Use cached mode with your Outlook 2003 profile
If you cannot install Update Rollup 1 for Exchange Server 2010 at this time, use cached mode for your Outlook 2003 profile. The cached mode synchronization process uses a different architecture to update folders that are in your mailbox.
To configure your profile to use cached mode, follow these steps:
- Exit Outlook 2003 if it is running.
- In Control Panel, start Mail.
- Click E-mail Accounts.
- Click to select View or change existing e-mail accounts, and then click Next.
- Select your Microsoft Exchange Server account, and then click Change.
- Click the Use Cached Exchange Mode check box to enable cached mode.
- Click Next, and then click Finish.
- Start Outlook 2003.
When you upgrade to Exchange 2010, your clients running Outlook 2007 or later versions will automatically be compatible with the change to RPC Client Access services in Exchange 2010, since they support RPC encryption by default. Outlook 2003 doesn’t use RPC encryption; however, RPC Client Access requires it by default. If you haven’t turned off RPC encryption, your users will need to configure Outlook 2003 for RPC encryption.
Note: When using the Priasoft Profile Update Manager to update Outlook client profiles, Outlook 2003 clients are configured to support RPC encryption to avoid these issues.
Symptoms of this problem include the following error messages:
- Cannot start Microsoft Office Outlook. Unable to open the Office window. The set of folders could not be opened.
- Unable to open your default e-mail folders. The information store could not be opened.
- If your users are using Cached Exchange Mode, Office won’t display an error, but will start in disconnected mode.
To correct this use the following workarounds:
Option 1: Disable the encryption requirement on all CAS servers
To disable the required encryption between Outlook and Exchange, follow these steps:
On the server that is running Exchange 2010, run the following command in the Exchange Management Shell:
Set-RpcClientAccess –Server Exchange_server_name –EncryptionRequired $False
Note The Exchange_server_name placeholder represents the name of an Exchange Server 2010-based server that has the Client Access Server role.
Rerun this command for each Exchange 2010-based server that has the Client Access Server role.
Option 2: Manually update or create your Outlook profile with RPC encryption
- In Control Panel, open the Mail item.
- Click Show Profiles.
- Select your profile, and then click Properties.
- Click E-mail Accounts.
- Select View or change existing e-mail accounts, and then click Next.
- Select the Microsoft Exchange Server account, and then click Change.
- In the dialog box that contains your mailbox server and user name, click More Settings.
- In the Microsoft Exchange Server dialog box, click the Security tab.
- Click to select the Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server check box, and then click OK.
- Click Next, and then click Finish.
- Click Close, and then click OK.
Option 3: Deploy a Group Policy setting to update existing Outlook profiles with RPC encryption
From a client perspective, deploying the Outlook-Exchange encryption setting is probably the simplest solution for organizations that have many Outlook clients. This solution involves a single change on a server (domain controller), and your clients are automatically updated after the policy is downloaded to the client.
The default Group Policy template (Outlk11.adm) for Outlook 2003 Service Pack 3 (SP3) does not contain the policy setting that controls the setting for encryption between Outlook and Exchange. Therefore, you must use a custom Group Policy template to update existing Outlook 2003 profiles so that RPC encryption is used in Outlook-Exchange communication.
You can download the required Outlook 2003 policy template here.
For more detailed information on Outlook and RPC encryption see the follow Microsoft page.
The Exchange Experts – Who Are We?
Priasoft, a Microsoft Partner, offers enterprise-class solutions for Exchange migration, management, and eDiscovery. Supporting Exchange 2010, 2013, 2016, 2019, and Office 365/Exchange Online, our platform enables secure migration, management, and organization of email data, with advanced tools for compliance, public folder analysis, and AI-driven insights.
