As part of its parameteres, Move-ActiveMailboxDatabase  also has the -ActivatePreferredOnServer parameter, as stated in the cmdlet's Technet page. Its description read "The ActivatePreferredOnServer parameter specifies the name of a Mailbox server on which to activate all mailbox databases that have copies with an ActivationPreference value of 1. You can use this parameter as part of ending maintenance mode on a Mailbox server." Since I didn't really get that after reading it a few times, nor does there seem to be a mention around the web aside from that Technet page, I though about testing it in a lab with a 3-site-stretched DAG. However the parameter isn't recognized.

Next I've tried figuring out if there's any problem with the management role assignment that grants permissions to this cmdlet. The user running it in the lab was the built-in Administrator account, which is a member of Organization Management. In identifying the management role that includes this cmdlet, I've followed the redirection on the aforementioned page, which links here. Yet none of the management roles specified there contain Move-ActiveMailboxDatabase as entry; actually it turns out that "Databases" is the only role that has it from the list that are assigned by default to the "Organization Management". However the entry in this role doesn't contain -ActivePreferredOnServer in its parameter list, which makes it pretty clear why it wouldn't work in the first place.

I also thought about the delegating only role assignments, since Organization Management has a couple of powers governed by various roles which it cannot directly use. Mailbox Search is one of them. But there's no mention of this parameter for the Move-ActiveMailboxDatabase cmdlet.

Did anyone ever use this parameter ?

Hi Albert,

Strange, its not listed for me as well, could be Microsoft Reserved, and missed to put the note for us :).

However looked up the RedistributeActiveDatabases.ps1 $exscript, which I presume does similar to what the description somewhat reveals unclearly though.

This script also doesn't use that -parameter, instead relies on -ActivateOnServer and some other methods.

I'll try to lookup something more on

Hi Albert,

Just realized that one of my older Exchange versions didn't list it. However the one with CU7 is listing it.

gcm Move-ActiveMailboxDatabase | fl


Name        : Move-ActiveMailboxDatabase
CommandType : Function
Definition  :
                  param(

                  [Alias('ea')]
                  ${ErrorAction},

                  ${ActivateOnServer},

                  [Alias('ov')]
                  ${OutVariable},

                  [Alias('wi')]
                  [switch]
                  ${WhatIf},

                  ${ActivatePreferredOnServer},

Run this command on your server to find your version.

Get-ExchangeServer | fl AdminDisplayVersion


AdminDisplayVersion : Version 15.0 (Build 1044.25)

Compare the version from here.

Exchange Server 2013 Build Numbers (with Cumulative Updates)

Hi Albert,

If I compare the article modified date and the CU release dates.

Move-ActiveMailboxDatabase

Applies to: Exchange Server 2013 Topic Last Modified: 2014-10-07

Exchange Server 2013 Service Pack 1 (SP1 aka CU4)	15.0.847.32	02/25/2014	KB2926248
Exchange Server 2013 Cumulative Update 5 (CU5)	15.0.913.22	05/27/2014	KB2936880

I guess it should be available from CU5 onwards. Normally the articles would be updated based on the latest available patch.

One more thing that you should be aware of is Microsoft Support Lifecycle for Exchange 2013

This would mean SP1 support ended on CU5 release date +1year = 05/27/2015

Just deployed CU9, rebooted the machine, and tried it again - however I'm still not seeing -ActivatePreferredOnServer. Would it have been removed in a subsequent CU ? :)

Just deployed CU9, rebooted the machine, and tried it again - however I'm still not seeing -ActivatePreferredOnServer. Would it have been removed in a subsequent CU ? :)

Hi Albert,

If I compare the article modified date and the CU release dates.

Move-ActiveMailboxDatabase

Applies to: Exchange Server 2013 Topic Last Modified: 2014-10-07

Exchange Server 2013 Service Pack 1 (SP1 aka CU4)	15.0.847.32	02/25/2014	KB2926248
Exchange Server 2013 Cumulative Update 5 (CU5)	15.0.913.22	05/27/2014	KB2936880

I guess it should be available from CU5 onwards. Normally the articles would be updated based on the latest available patch.

One more thing that you should be aware of is Microsoft Support Lifecycle for Exchange 2013

Microsoft Exchange Server 2013 Service Pack 1

2/25/2014

Review Note

Review Note

Support ends 12 months after the next service pack releases or at the end of the product's support lifecycle, whichever comes first. For more information, please see the service pack policy at http://support.microsoft.com/lifecycle/#ServicePackSupport.

This would mean SP1 support ended on CU5 release date +1year = 05/2

Andy, the user running it is the builtin Administrator. This was the account used to setup Exchange Server 2013 on the first box. I've double checked and it's a member of Organization Management. There were no split permissions setup or anything to make this environment "special".

I even did a remote PSSession from a different machine using the Administrator credentials as to avoid any possible issue with the local remoteExchange.ps1 on the specific server being faulty - but still the same.

As for invoking it, tried to tab it out, and also gcm Move-ActiveMailboxDatabase | fl - as Satyajit issued above on his environment - doesn't show the new parameter as well in the Definition attribute. The definition is a sort of stub that invokes and picks up the PS results via the remote connection, from what I can tell.

One thought though - the server I've installed CU9 is a mailbox server that's not part of the DAG. Would the imported cmdlets inside a PSSession depend on the role that the remote server has ? Wouldn't really make sense here, since Move-ActiveMailboxDatabase is after all recognized, albeit without the -ActivatePreferredOnServer, and using it on a standalone mailbox server won't do any good, but just trying to rule everything out.

What CU were you at and when installed CU9, did you run all the prep commands?

Setup/PrepareSchema,

Setup/PrepareAD

Setup/PrepareAllDomains

?

Hi Andy,

Thanks for correcting me out on the Service pack release and support mis-interpretation.

Hi Albert,

What is your environment, how many DCs, Exchange servers do you have. Are all Exch CU9. OS versions.

You can run the below cmdlet to find out the server you are currently connected to.

Get-PSSession

Without parameters, Get-PSSession gets all sessions that were created in the current session.

Refer to this article to Cross check if you are on the correct schema,config level etc. as Andy pointed out. Give some time if you have multiple DCs when you run the /Prepare Commands.

Andy, the box updated was previously at Exchange 2013 SP1 level. I didn't prepare schema/domains manually, but instead left the wizard take care of it.

Satyajit, thanks for the link used to show how to check if the update operations completed successfully. Checking against my environment, I'm seeing the rangeUpper property on ms-Exch-Schema-Verision-Pt being set to 15312 for the Schema; objectVersion property in the CN=Fabrikam,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=fabrikam,DC=com is 15965; objectVersion property in the Microsoft Exchange System Objects container under DC=fabrikam,DC=com is 13236. The values match the ones provided for CU9 at the bottom of that Technet article.

The forest has 1 domain (fabrikam.com) with 3 AD sites. One domain controller is installed in each site. 2 of DCs are Windows Server 2012, while a 3rd one is Windows Server 2012 R2. 9 Exchange 2013 servers are deployed, with various roles, including an Edge server; all are exclusively deployed on Windows Server 2012 R2. The minimum version of any Exchange box is Exchange 2013 SP1:

Issuing a Get-PSSession in the EMS that's opened using the default shortcut shows the updated box (winserver63) as the one it's connected to - so all looks good from this standpoint as well.

I've also taken a look at ExchangeSetup.log, but no errors or warnings were visible near the tail of that file.

Hi Albert,

Its always a good practice to /Prepare manually. As per this blog Released: June 2015 Exchange Cumulative Update and Update Rollups, if you do not see the new CMDlet parameters available in Exchange 2013 CU9, please perform /PrepareAD manually.

Note: if after installation of Exchange 2013 CU9 in an on-premises environment you do not see the new CMDlet parameters, you should run /preparead explicitly with CU9 setup.