-ActivatePreferredOnServer Parameter Missing

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 ?

July 10th, 2015 8:03am

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

Free Windows Admin Tool Kit Click here and download it now
July 10th, 2015 8:43am

Thanks Satyajit. Went even further and did a search against all the .ps1 files in the "scripts" folder, and none is using this parameter.
July 10th, 2015 8:45am

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)


Free Windows Admin Tool Kit Click here and download it now
July 10th, 2015 11:50am

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/27/2015

July 10th, 2015 12:09pm

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 ? :)

Free Windows Admin Tool Kit Click here and download it now
July 11th, 2015 8:43am

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 ? :)


Its there in CU9. Are you tabbing it out? It should show then. If not, then its a permissions issue.
July 11th, 2015 10:12am

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

Free Windows Admin Tool Kit Click here and download it now
July 11th, 2015 10:16am

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.


July 11th, 2015 4:48pm

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

Setup/PrepareSchema,

Setup/PrepareAD

Setup/PrepareAllDomains

?

Free Windows Admin Tool Kit Click here and download it now
July 11th, 2015 6:17pm

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.

July 12th, 2015 7:28am

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.

Free Windows Admin Tool Kit Click here and download it now
July 12th, 2015 8:23am

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.

July 13th, 2015 12:53am

Satyajit, thanks for the link. I've rerun setup /preparead from that specific server, even went ahead and forced a push AD replication from the DC located in the same site as the previously upgraded Exchange server (even though there wasn't much sense in that really) and rebooted the machine as well. However after reopening EMS, the parameter still doesn't show up.

I'll try deploying CU9 on a different server and will post back the results.

Free Windows Admin Tool Kit Click here and download it now
July 13th, 2015 2:17am

Satyajit, thanks for the link. I've rerun setup /preparead from that specific server, even went ahead and forced a push AD replication from the DC located in the same site as the previously upgraded Exchange server (even though there wasn't much sense in that really) and rebooted the machine as well. However after reopening EMS, the parameter still doesn't show up.

I'll try deploying CU9 on a different server and will post back the results.

Let us know. That is a strange one. Since you went from CU5 to CU9, you should have not needed to run setup/prepareAD explicitly and really you should be able to see all the avail commands of course from any server - whether its in the DAG or not. 
July 13th, 2015 7:29am

Andy, CU9 deployed on a server belonging to the DAG, with just the Mailbox component; then the machine was rebooted. Post-restart, -ActivatePreferredOnServer shows up when tabbing out in an EMS on that machine. Went back to the server were CU9 was deployed initially - which is a server with only the Client Access Server role -, reopened EMS however I can't tab -ActivePreferredOnServer.

I have to admit it's indeed a strange one.

Going further I'll deploy CU9 to yet another server with just the Mailbox role, that's not part of the DAG. Just trying to identify if it's that initial box at fault, or something more complex. Like you said, the cmdlet available parameters shouldn't be content-specific to the role used.


  • Edited by Albert Mihai 15 hours 4 minutes ago Incorrectly mentioned the original server where CU9 was deployed was Mailbox; it was a CAS
Free Windows Admin Tool Kit Click here and download it now
July 13th, 2015 7:46am

Andy, CU9 deployed on a server belonging to the DAG, with just the Mailbox component; then the machine was rebooted. Post-restart, -ActivatePreferredOnServer shows up when tabbing out in an EMS on that machine. Went back to the server were CU9 was deployed initially - which is a server with only the Client Access Server role -, reopened EMS however I can't tab -ActivePreferredOnServer.

I have to admit it's indeed a strange one.

Going further I'll deploy CU9 to yet another server with just the Mailbox role, that's not part of the DAG. Just trying to identify if it's that initial box at fault, or something more complex. Like you said, the cmdlet available parameters shouldn't be content-specific to the role used.


  • Edited by Albert Mihai Monday, July 13, 2015 4:22 PM Incorrectly mentioned the original server where CU9 was deployed was Mailbox; it was a CAS
July 13th, 2015 11:45am

Ok - went further and installed CU9 on yet another additional machine. Here's the outcome so far, in order of processing:

- Client Access-only server, updated from SP1 to CU9 -> -ActivatePreferredOnServer missing

- Mailbox-only server, part of a DAG, updated from SP1 to CU9 -> -ActivatePreferredOnServer present

- Mailbox-only server, standalone (not part of a DAG), updated from SP1 to CU9 -> -ActivatePreferredOnServer present

- Client Access-only server, updated from SP1 to CU9 -> -ActivatePreferredOnServer missing

Next I'll target a Mailbox + Client Access server, and post back an update when done.

Free Windows Admin Tool Kit Click here and download it now
July 14th, 2015 4:46am

Ok - went further and installed CU9 on yet another additional machine. Here's the outcome so far, in order of processing:

- Client Access-only server, updated from SP1 to CU9 -> -ActivatePreferredOnServer missing

- Mailbox-only server, part of a DAG, updated from SP1 to CU9 -> -ActivatePreferredOnServer present

- Mailbox-only server, standalone (not part of a DAG), updated from SP1 to CU9 -> -ActivatePreferredOnServer present

- Client Access-only server, updated from SP1 to CU9 -> -ActivatePreferredOnServer missing

Next I'll target a Mailbox + Client Access server, and post back an update when done.

Ok, there is your problem right there. The CAS only role proxies everything to a mailbox server. Thats why it didnt show up. If it had hit a mailbox server that knew about that parameter, you would have seen it. I should have caught that earlier. I assumed  a dual-role!
July 14th, 2015 7:34am

Hmm, so in effect the CAS-only role will present cmdlets in its local EMS session based on the available cmdlets on a different server that contains the mailbox role ? I have to admit I never came across this so far.
Free Windows Admin Tool Kit Click here and download it now
July 14th, 2015 8:09am

Hmm, so in effect the CAS-only role will present cmdlets in its local EMS session based on the available cmdlets on a different server that contains the mailbox role ? I have to admit I never came across this so far.

Yea, unless you are specific in most cases. 

As an example, type: "Get-ExchangeCertificate" on the cas only server in PS. You'll get a list of certs on a mailbox server

then type Get-ExchangeCertificate -server <CASONLY> and the list is the local certs on that server.

July 14th, 2015 8:20am

I have to admit I was clueless until today about the remote execution of cmdlets in Exchange Server 2013. After seeing your post I searched up and down looking for this behavior explained, and to my surprise there's quite little information about it. The Client Access role is now simply a thin, proxy/redirection server that also does authentication - that was clear, but never thought this would extend to the execution of cmdlets themselves, even more that the Powershell virtual directory sits nicely in the Default Web Site, used by the CAS component. Finally found the release notes for CU2, were things are explicit:

As explained in Exchange 2013 Client Access Server Role, CAS 2013 is simply an authentication and proxy/redirection server; all data processing (including the execution of remote PowerShell cmdlets) occurs on the Mailbox server. You can either deploy a multi-role server or each role separately (just remember if you deploy them separately, you cannot manage the Exchange 2013 environment until you install both roles).

Andy - thanks for hanging on till the end.

Free Windows Admin Tool Kit Click here and download it now
July 14th, 2015 10:08am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics