Exchange 2016 CLI: Can't Accept Pipeline Command for Moving Arbitration Mailboxes

You cannot pipe the output of Get-Mailbox directly into New-MoveRequest for arbitration mailboxes because the cmdlet requires specific parameters like -TargetDatabase that are not inherited through the pipeline. To resolve this, you must iterate through the mailbox list using a Foreach-Object loop or a ForEach statement to explicitly define the target database and other necessary arguments for each individual move request.

Understanding the Pipeline Limitation

In Exchange 2016, the New-MoveRequest cmdlet is designed to handle complex migration scenarios involving user mailboxes, arbitration mailboxes, system mailboxes, and discovery search mailboxes. While many Exchange cmdlets support pipelining, New-MoveRequest has strict parameter binding rules. The primary reason the direct pipeline fails is that the cmdlet does not automatically infer the -TargetDatabase or -BadItemLimit parameters from the input object. When you attempt to run a command like Get-Mailbox -Arbitration | New-MoveRequest -TargetDatabase DB01, PowerShell may throw an error indicating that the pipeline input is not accepted for certain mandatory parameters, or it may fail silently because the binding context is incorrect. This behavior is intentional to prevent accidental mass moves without explicit confirmation of the target environment. Arbitration mailboxes hold critical system data, including calendar processing, auto-discover configurations, and public folder metadata. Therefore, Microsoft requires administrators to be explicit about where these mailboxes are being moved. You must ensure that the target database is specified correctly for each mailbox instance within your script.

Distinguishing Mailbox Types

Before moving arbitration mailboxes, it is crucial to understand that they differ significantly from regular user mailboxes. Arbitration mailboxes are created automatically when you install Exchange Server and are essential for the health of the organization. They include types such as SystemMailbox{GUID} for OWA settings and Migration.* for hybrid migrations. Moving these incorrectly can break functionality across the entire Exchange farm. Always verify the mailbox type using Get-Mailbox -Arbitration before executing any move commands. If you are trying to move user mailboxes, the process is slightly different, but the same principle of explicit parameter definition applies. For more information on general CLI operations, you might find Understanding PS1 File Execution in CLI GUI Explorers helpful for scripting best practices.

Correct Method Using Foreach-Object

The most robust way to move arbitration mailboxes is by using the Foreach-Object alias (%). This approach allows you to capture the mailbox object in a variable and then pass all required parameters to New-MoveRequest explicitly. Here is the standard pattern:

Get-Mailbox -Arbitration | ForEach-Object {
    New-MoveRequest -Identity $_.Identity -TargetDatabase "YourTargetDB" -SuspendWhenReadyToComplete $true
}

In this example, $_.Identity refers to the specific mailbox being processed in the current iteration. The -TargetDatabase parameter is set to a valid database name in your environment. The -SuspendWhenReadyToComplete flag is highly recommended for arbitration mailboxes. It pauses the move request after the initial copy phase, allowing you to review the status and ensure no errors occurred before completing the move. This prevents potential service interruptions if a database issue arises during the final synchronization step.

Alternative Approach with Variable Assignment

If you prefer a more readable script structure, you can assign the mailbox list to a variable first. This is particularly useful if you need to perform additional checks or logging before initiating the move.

$arbMailboxes = Get-Mailbox -Arbitration
foreach ($mbx in $arbMailboxes) {
    Write-Host "Moving $($mbx.Identity)..."
    New-MoveRequest -Identity $mbx.Identity -TargetDatabase "YourTargetDB" -WhatIf
}

Notice the use of -WhatIf in the second example. This is a critical safety feature in Exchange administration. It simulates the move request without actually performing any changes. You should always run your scripts with -WhatIf first to verify that the correct mailboxes are selected and that the target database exists. Once you confirm the output looks correct, remove -WhatIf and execute the actual move. This practice reduces the risk of human error, which is vital when dealing with system-critical objects like arbitration mailboxes.

Verifying Move Status

After initiating the move requests, you must monitor their progress. Use the Get-MoveRequestStatistics cmdlet to check the status of each arbitration mailbox.

Get-MoveRequest | Where-Object {$_.MoveType -eq "Arbitration"} | Get-MoveRequestStatistics

Look for states such as Suspended, Completed, or Failed. If a move fails, check the Failures property for detailed error messages. Common issues include insufficient permissions, database corruption, or resource constraints. If a move is suspended due to -SuspendWhenReadyToComplete, you can resume it using Resume-MoveRequest -Identity $mailboxIdentity. Ensure that the arbitration mailboxes are successfully moved before decommissioning the old database.

Best Practices for Maintenance

Always maintain a backup of your Active Directory configuration before making significant changes to Exchange databases. Moving arbitration mailboxes involves modifying system state objects, so having a restore point is essential. Additionally, coordinate with your team to schedule maintenance windows, as some arbitration mailboxes may experience brief unavailability during the move process. Document the new locations of all arbitration mailboxes for future reference. This documentation will help in troubleshooting and planning for future upgrades or migrations.

Frequently Asked Questions

Can I move arbitration mailboxes to a different server?

Yes, you can move them to a database on a different server, provided the servers are in the same Exchange organization and AD site. Ensure that the target server has the necessary permissions and that network connectivity between the servers is stable during the move operation.

What happens if I move an arbitration mailbox incorrectly?

Incorrectly moving an arbitration mailbox can disrupt services such as Outlook Web App, AutoDiscover, and Public Folder access. In severe cases, it may require restoring from a backup or recreating the mailbox, which can lead to significant downtime and data loss if not handled carefully.

Is it safe to move arbitration mailboxes while users are active?

It is generally safe to move arbitration mailboxes while users are active, as these moves do not impact user mailboxes directly. However, there may be brief latency in certain features like free/busy lookups during the initial synchronization phase. Monitoring the move status is recommended to ensure smooth operation.

How do I check which database an arbitration mailbox is currently on?

Run Get-Mailbox -Arbitration | Select Identity, Database to list all arbitration mailboxes and their current database locations. This helps you plan the move targets and verify that the mailboxes are indeed located on the source database you intend to empty.

Can I automate the completion of suspended arbitration moves?

Yes, you can use Get-MoveRequest -MoveType Arbitration -Status Suspended | Resume-MoveRequest to automatically resume all suspended arbitration moves. However, always verify the statistics first to ensure that no failures occurred during the initial copy phase before resuming.