Blog Post

Exchange Team Blog
2 MIN READ

Changing the behavior of MoveRequest cmdlets

The_Exchange_Team's avatar
Mar 25, 2022

Although most migrations between on-premises Exchange Server and Microsoft 365 are performed using the Migration Service’s batching functionality, a few stalwart admins have held onto the more granular control given by using the MoveRequest cmdlets directly.  But as time goes on even the hardiest and most proven of tools need to be sharpened or have components replaced, and it is now time for the MoveRequest cmdlets to be refreshed a little.

We are taking this opportunity to bring these cmdlets more in line with some of our other cmdlets.  Most admins who use these cmdlets will notice little to no difference in how these cmdlets function, which is intentional on our part.  But some may have scripts break if they aren’t updated before the cmdlets are updated.  We plan to release the updated cmdlets starting April 30th, 2022.

  1. New-MoveRequest will change from returning a MoveRequestStatistics object to returning a MoveRequest object.  Most New-* cmdlets are expected to return a data object matching their noun, which New-MoveRequest didn’t historically follow.  The MoveRequest object contains less data than the MoveRequestStatistics object, but that is desirable in this case because most of the extra data is only relevant or interesting after the request has made progress.
  2. The MoveRequest data object that is returned from Get-MoveRequest (and now New-MoveRequest) will have a slightly smaller set of properties.  Compared to the old data object, it will remove several generic user properties that are not relevant to move requests in particular, which could lead to confusion.  Each of those properties should remain available as output from the Get-Recipient, Get-Mailbox, Get-MailUser, etc. cmdlets instead.
Maintained properties Alias, DisplayName, RecipientTypeDetails, SourceDatabase, SourceArchiveDatabase, TargetDatabase, TargetArchiveDatabase, RemoteHostName, IsOffline, SuspendWhenReadyToComplete, ExchangeGuid, Flags, BatchName, Status, Protect, Suspend, Direction, RequestStyle, OrganizationId, Identity, IsValid, ObjectState
Renamed properties User (previously “Id”), UserGuid (previously “Guid”)
Added properties RequestQueue
Removed properties AdministrativeUnits, ExtensionCustomAttribute1, ExtensionCustomAttribute2, ExtensionCustomAttribute3, ExtensionCustomAttribute4, ExtensionCustomAttribute5, ExternalDirectoryObjectId, LastExchangeChangedTime, RecipientType, Name, DistinguishedName, ExchangeObjectId, OrganizationalUnitRoot, OriginatingServer, WhenCreatedUTC

The rest of the cmdlet behavior should remain the same.

There may be some other pieces deprecated in the future, such as removing SuspendWhenReadyToComplete behavior in favor of CompleteAfter, but a timeline for that will be determined at a later time.

The Exchange Migration Team

Updated Mar 29, 2022
Version 3.0
  • martinthiem's avatar
    martinthiem
    Copper Contributor

    Why do you want to remove SuspendWhenReadyToComplete? We are excessively use this feature to optimize our migrations…

  • CSU_Scott's avatar
    CSU_Scott
    Brass Contributor

    If they are removing suspendwhenreadytocomplete, I have to throw my voice in and say we used that feature extensively and hope that enough voices will change the direction.

     

     

  • Kreera_House's avatar
    Kreera_House
    Steel Contributor

    Same here. SuspendWhenReadyToComplete is important for us to reduce impact on the users. It is much more useful than CompleteAfter.

  • Djcarr's avatar
    Djcarr
    Brass Contributor

    martinthiemand Kreera_House  SuspendWhenReadytoComplete is not currently listed as something that is being removed unless I am reading this after the post was updated. As of 4/4/2022 SuspendWhenReadyToComplete is in the maintained properties. 

  • CSU_Scott Kreera_House martinthiem, I'm curious how SuspendWhenReadyToComplete is more useful than CompleteAfter, particularly when compared to using "-CompleteAfter $([DateTime]::MaxValue)".    CompleteAfter automatically keeps the move healthy by running daily incremental syncs.  Then when you're actually ready to complete, simply remove CompleteAfter: "-CompleteAfter $null."

     

    One common cause for escalations in the past was admins forgetting to run incremental syncs leaving removal/recreation as the only way for a move to catch back up for high-churn mailboxes.

  • JohnQuest's avatar
    JohnQuest
    Copper Contributor

    I agree with the above posts regarding 'SuspendWhenReadyToComplete' (acknowledging that it is listed as a possible future deprecation).  We use this feature extensively.

  • JohnQuest's avatar
    JohnQuest
    Copper Contributor

    Notably absent from the properties list is “RequestGuid”. Will this property be maintained?

  • The_Exchange_Team I believe this change is responsible for breaking the ability to pipe Get-MoveRequest into Get-MoveRequestStatistics.  If you care to see more detail, private message me for the MS Support case I opened about this issue, which is now closed where there was no pathway for a ticket to report that kind of problem.  TL;DR is that UserGuid needs to be an Alias on the -Identity parameter in the Get-MoveRequestStatistics cmdlet, and the User property in the output from Get-MoveRequest needs to be something more unique than the DisplayName of the user.  It doesn't appear to be a nested property either, so it's not like we can drill in (e.g., $MR = Get-MoveRequest; $MR[0].User.<some-better-unique-property>).

     

    Is it possible to find out here, is this 'breaking' part of this change intended or accidental and will it be repaired?

     

    Thanks in advance.

  • CSU_Scott's avatar
    CSU_Scott
    Brass Contributor

    @Kreera House @martinthiemwirall

     

    It was a convenience thing for us, I guess, and we didn't forget to follow up on our move jobs.  We have since switched to setting the CompleteAfter to stay inline with the GUI options.

     

    Sorry for the late response, I must have missed it in email. 😕