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: How to
In the fast-paced world of legal proceedings, where time is critical and precision is a must, the challenges of eDiscovery have never been more important. Legal professionals often find themselves overwhelmed by mountains of email data, desperately searching for that crucial piece of evidence that could turn the tide in their favor.
Enter Super-ExMerge, your comprehensive solution for simplifying eDiscovery. In this excerpt, we explore how Super-ExMerge can transform your eDiscovery process, saving you time, preserving data integrity, and keeping your legal team ahead of the game.
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.
If you are an Exchange Online administrator, you may have encountered a situation where the PowerShell cmdlets fail to execute. This issue can be frustrating, as it can lead to delays in critical tasks such as mailbox management, message tracking, and other essential Exchange Online operations. In this article, we will explore some of the reasons why Exchange Online PowerShell cmdlets fail and how to resolve them.
One of the most common reasons why Exchange Online PowerShell cmdlets fail is due to connectivity issues. The first step in resolving this issue is to ensure that your internet connection is stable and that you are not experiencing any network issues. If you are using a VPN connection, try disconnecting and reconnecting to the VPN to see if that resolves the issue.
Another reason why Exchange Online PowerShell cmdlets fail is due to authentication issues. This can occur if you are using an incorrect or expired credential. Ensure that the credential you are using is valid and has the necessary permissions to execute the cmdlet. If you are unsure, try running the cmdlet with elevated privileges.
Sometimes, PowerShell modules may not be loaded correctly, which can cause cmdlets to fail. To resolve this issue, try reloading the PowerShell modules by running the following cmdlet:
Import-Module ExchangeOnlineManagement
This cmdlet will reload the Exchange Online PowerShell module, and you should be able to execute the cmdlets without any issues.
In some cases, the issue may be related to the Exchange Online service itself. Microsoft periodically performs maintenance and updates to the service, which may result in cmdlets failing to execute. If you suspect that the issue is related to the Exchange Online service, try executing the cmdlet at a later time or contact Microsoft support for assistance.
In conclusion, Exchange Online PowerShell cmdlets can fail for various reasons, including connectivity issues, authentication issues, module loading issues, and Exchange Online service maintenance. By following the steps outlined above, you should be able to resolve most issues and execute PowerShell cmdlets successfully. If you continue to experience issues, reach out to Microsoft support for assistance.
This is one of the more common tasks for administrators and users alike. The need to export mail outside of the mailbox can stem from simple archiving to legal subpoenas.
In this example, we’ll show how to select several mailboxes from Microsoft Exchange, export the data, and some of the reporting that is available. Super-ExMerge, in contrast to the commands available on an exchange server such as New-MailboxExportRequest, Super-ExMerge does not run on the mail server. This means that the CPU demand for this work is also separated from the server. This can be valuable for cases where there may be concern about exporting a large quantity of mailboxes quickly. A Microsoft Exchange server is not going to allow “too much” to occur at the same time since it has to share the CPU between regular mail tasks and the export process.
The first step in this task is to identify all the mailboxes that need to be exported. Super-ExMerge uses Microsoft Exchange’s AutoDiscover feature to find and validate mailboxes to which to connect.
AutoDiscover accepts SMTP addresses for lookup requests. So, in this case we’ll need a list of email addresses for the mailboxes to be exported. If using Exchange 2007 or later, collecting email addresses for mailboxes is quite trivial using Exchange PowerShell:
Super-ExMerge uses MAPI to access mail data, not EWS (Exchange Web Services). This provides better performance and the ability to use multiple threads, and also better data fidelity since data stays in a native binary format thru the entire process.
$names = @('bruce wayne', 'alfred pennyworth', 'richard greyson', 'edward nygma')
$mbxs = $names | Get-MailboxNow that a list of mailboxes is found, we can build a set of connection objects that define our source and target stores for the export.
if (![System.IO.Directory]::Exists('c:\pstfiles')) { [System.IO.Directory]::CreateDirectory('c:\pstfiles') }
foreach ($mbx in $mbxs){
$conn = New-ConnectionInfo Mailbox PST $mbx.PrimarySMTPAddress 'exch01.my-domain.com' 'admin@my-domain.com:Password' "c:\pstfiles\$($mbx.PrimarySmtpAddress).pst"
$task = New-SyncTask $conn -OneWaySyncSourceToTarget
Add-SyncTask $task
}
In the above script, we first make sure the destination for the PST files exists, and if not create it. The sync task won’t create the folder.
Next, we enumerate all the mailboxes collected earlier, creating a new connection object for each one. Note that some shorthand was used – the New-ConnectionInfo example doesn’t have any parameter names. All the parameters of that cmdlet are positional parameters, so if you set all the data in order on the command line, PowerShell will line up your arguments to the matching parameters.
We chose to use the email address of each mailbox as the name for our PST files. A “double quote” around text allows PowerShell replace tokens in the string with values. However, because $mbx is an object, if we don’t do some extra stuff, PowerShell will simple try to replace only the $mbx token with a string, followed by .PrimarySmtpAddress. The $(expression) syntax ensures that PowerShell evaluates the expression first, then converts that result to a string.
Once we have the $conn object created, we use it to create the $task object, specifying that it will be a one-way sync, from the source mailbox to the PST. Having been added to the task queue, the task engine will start processing the tasks. One question that will immediately arise is “how to I check on this?” Checking on running tasks is easy, as follows:
Show-SyncTaskProgress TaskID : 335d55d1-1fc2-4f57-bc23-71c8319fa84d TaskName : Sync from [Mailbox] bruce.wayne@wayne-enterprises.com to [PST] c:\pstfiles\bruce.wayne@wayne-enterprises.com.pst ------------------------------ : Startup Progress : [oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo] Source Folder Enumeration : [oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo] Target Folder Enumeration : [oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo] Source Folder Analysis : [oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo] Target Folder Analysis : [oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo] Source Items Enumerated : [oooooooo ] Target Items Enumerated : [oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo] Source Item Analysis : [oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo] Target Item Analysis : [ ] Source Folder Content Collect : [ooooooooooooooooooooooooooooooooooooooooooo ] Target Folder Content Collect : [oooooooooooooooooooooooooooooooooooooooooooooooooooo ] Item Processing : [ ] Item Completion : [ ]
When Super-ExMerge is processing, the items and folders are discovered in separate threads. As such, progress is non-linear, meaning that many, if not all, of the progress bars will show increases as time proceeds. For example, the Items Completed may show 100% in one moment, but then show 20% in another because a different thread that is processing folders discovers more items.
We can see from the above that progress is being made on the export process. Given the performance-oriented nature of Super-ExMerge by the use of many independent threads, an ‘overall progress’ is not exactly easy to show. Once the enumeration and analysis progress bars show 100%, the Item Completion progress bar can be used as an overall progress indicator.
Introduction
When attempting to manage mail-enabled public folders many points of friction or frustration can occur. Most of these points of pain come from the fact that the mail-enabled aspect of a public folder is a separated object from the folder in the hierarchy and the Active Directory proxy object does not store the folder path of the related folder in the hierarchy. The relationship between the proxy object and the folder in the hierarchy can be broken and happens whenever the directory ‘ObjectGuid’ does not match the value stored on the PR_PF_PROXY value of the hierarchy folder. This break in the relationship can occur for many reasons:- The proxy object was somehow deleted and recreated which causes the object to receive a new ObjectGuid, and which now doesn’t match the hierarchy folder’s value.
- The hierarchy folder loses the linking value thru some odd user interaction or by a replication failure.
- The public folder in the hierarchy is moved to a new replica or public-folder-mailbox. When a public folder is moved to a different ‘store’ (database or mailbox) its underlying EntryID value will change slightly as a result which can break the mail delivery since the AD proxy object had previously stored the value.
- The public folder in hierarchy can be deleted and fail to delete the AD proxy object. This leaves behind an orphaned object in Active Directory and in the Global Address List.
When attempting to manage mail-enabled public folders many points of friction or frustration can occur.
Much of the management issue with public folder links comes from the carrying forward of older mail-enabled public folders from prior versions of Microsoft Exchange. This is very prevalent if an organization’s mail system has existed since Exchange 2000 or 2003. In these older versions of Exchange EVERY new folder created was automatically mail-enabled but was hidden from the GAL. When upgrading Exchange over the years many of these may simply have “come along for the ride”. They will appear as mail-enabled folders from a management perspective, but in reality do not actually deliver mail because the mapi EntryID link format is incompatible with later versions of Exchange. We have published a detailed document, The Secret Challenges of Mail-Enabled Public Folders in Microsoft Exchange, on this subject as well as provide some recommendations as to how to detect and solve this issue. To learn more, Click HerePost migration the source user’s mailbox is left in a “dormant state” so that if the need arises you can roll back the user. However, you may want to access the source mailboxes data without having to roll the source user back. This article will explain how to access a source mailbox post migration after migration using the Priasoft Migration Suite for Exchange.
Several properties are set on the source object post migration to place it in a “dormant state”. This is done to allow for roll back and to prevent unauthorized access to the source post migration. The main property that will block access to the source mailbox data post migration is the ProtocolSettings attribute on the users source AD object.
The ProtocolSettings attribute on the source user object in the Active Directory stores client access settings. This attribute is a multi-valued string property, where each string applies to a different protocol. MAPI access is restricted by adding the following string to the ProtocolSettings:
MAPI§<Bool1>§<Bool2>§§§§§§
The eight § separators define exactly nine fields. The meanings of the fields are as follows:
| MAPI | Specifies that this string contains settings that apply to the MAPI protocol |
| Bool1 | 0 to block all MAPI access; 1 to determine MAPI access based on Bool2. |
| Bool2 | 0 for “no effect”; 1 to deny access to non-cached mode Outlook clients |
| Remaining 6 fields | Currently not used |
If there is no MAPI string in ProtocolSettings, all MAPI clients are allowed.
In order to gain access to the source mailbox post migration you will need to clear the MAPI§ setting in the ProtocolSettings attribute on the source mailbox.
Please note:
Changes to this setting do not take effect immediately and can up to two hours to take effect. This is because, as with others mailbox properties stored in the DS, ProtocolSettings are cached in the MIBCache (default TTL = 2hrs) and in DSAccess (default TTL = 15 min). These caches may delay the time it takes for a change in the ProtocolSettings to become effective.
In order to read more about the Information Store cache, please see the following article: http://support.microsoft.com/?id=179065
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.
Exchange Quick Links
Recent Posts
Contact Priasoft – The Exchange Experts
Have questions? Speak to a Priasoft Engineer
Email: sales (at) priasoft.com
+1 (480) 520-0873









