Moving Lync 2010 CMS in 2013 Coexistence

The intended title on this article is a really long one…so the actual title got shortened.  What it should read is:

Moving Lync 2010 CMS to another Lync 2010 server while you are in a Lync 2013 Coexistence Posture.

See what I mean?

Scenario

You have both Lync 2010 and Lync 2013 deployed in your organization.  Whether or not you have site resiliency setup is not important – although the commands to move the CMS are taken from the Disaster Recovery section of the 2013 online documentation.

For one reason or another you decide you need to move the Central Management Server (CMS) to another server – and again, for one reason or another, you want to move it to another 2010 server.  Reading through this reference – here – leads you to believe that you can use the standard preparation and 2010 move commands.  But you don’t necessarily have a site outage, so the existing CMS is available, and you conclude there is not a need to do a –force move or use the CMS and LIS backup files.  So then you review this documentation about moving a 2010 CMS under normal circumstances. Using both sources, a summarized list of these steps is fairly close to just moving the Lync CMS in a pure 2010 environment:

1. Make sure you have a backup of the CMS and LIS.  You DO have these backups, right?
2. On the target 2010 server:  install-csdatabase –centralmanagementdatabase –clean –sqlserverfqdn –sqlinstancename rtc (for an Enterprise Pool target, the sqlserverfqdn will be the SQL backend to the target Enterprise pool.  For an SE pool (as I used in this example) the sqlserverfqdn is the FQDN of the SE Server).
3. From the target 2010 server: move-csmanagementserver
4. On the target server or pool servers:  run the deployment wizard and do a setup of Lync components (or run c:\program files\microsoft lync server 2010\deployment\bootstrapper.exe).

But we have a 2013/2010 coexistence environment!  So when you get to step 3, you get the following:

Move-CsManagementServer : ServiceId "UserServer:LS2013Pool.tsoorad.net" is of R
oleId "UserServices:2",  where RoleId "UserServices:2" is not defined.
At line:1 char:24
+ Move-CsManagementServer <<<<
    + CategoryInfo          : InvalidData: ([0] 1-UserServices-6:SourceCollect
   ion) [Move-CsManagementServer], Exception
    + FullyQualifiedErrorId : MissingRoleDefinition,Microsoft.Rtc.Management.D
   eployment.MoveCms.MoveCmsCmdlet
Move-CsManagementServer : ServiceId "Registrar:LS2013Pool.tsoorad.net" is of Ro
leId "Registrar:2",  where RoleId "Registrar:2" is not defined.
At line:1 char:24
+ Move-CsManagementServer <<<<
    + CategoryInfo          : InvalidData: ([0] 1-Registrar-6:SourceCollection
   ) [Move-CsManagementServer], Exception
    + FullyQualifiedErrorId : MissingRoleDefinition,Microsoft.Rtc.Management.D
   eployment.MoveCms.MoveCmsCmdlet
Move-CsManagementServer : ServiceId "EdgeServer:LS2013EdgePool.tsoorad.net" is
of RoleId "EdgeServer:2",  where RoleId "EdgeServer:2" is not defined.
At line:1 char:24
+ Move-CsManagementServer <<<<
    + CategoryInfo          : InvalidData: ([0] 1-EdgeServer-7:SourceCollectio
   n) [Move-CsManagementServer], Exception
    + FullyQualifiedErrorId : MissingRoleDefinition,Microsoft.Rtc.Management.D
   eployment.MoveCms.MoveCmsCmdlet
Move-CsManagementServer : ServiceId "WacService:lswaspoolint.tsoorad.net" is of
RoleId "WacService:1",  where RoleId "WacService:1" is not defined.
At line:1 char:24
+ Move-CsManagementServer <<<<
    + CategoryInfo          : InvalidData: ([0] 1-WacService-8:SourceCollectio
   n) [Move-CsManagementServer], Exception
    + FullyQualifiedErrorId : MissingRoleDefinition,Microsoft.Rtc.Management.D
   eployment.MoveCms.MoveCmsCmdlet
Move-CsManagementServer : ServiceId "UserServer:LS2013SE1.tsoorad.net" is of Ro
leId "UserServices:2",  where RoleId "UserServices:2" is not defined.
At line:1 char:24
+ Move-CsManagementServer <<<<
    + CategoryInfo          : InvalidData: ([0] 1-UserServices-9:SourceCollect
   ion) [Move-CsManagementServer], Exception
    + FullyQualifiedErrorId : MissingRoleDefinition,Microsoft.Rtc.Management.D
   eployment.MoveCms.MoveCmsCmdlet
Move-CsManagementServer : ServiceId "Registrar:LS2013SE1.tsoorad.net" is of Rol
eId "Registrar:2",  where RoleId "Registrar:2" is not defined.
At line:1 char:24
+ Move-CsManagementServer <<<<
    + CategoryInfo          : InvalidData: ([0] 1-Registrar-9:SourceCollection
   ) [Move-CsManagementServer], Exception
    + FullyQualifiedErrorId : MissingRoleDefinition,Microsoft.Rtc.Management.D
   eployment.MoveCms.MoveCmsCmdlet
WARNING: Move-CsManagementServer failed.
WARNING: Detailed results can be found at
"C:\Users\john.weber\AppData\Local\Temp\1\Move-CsManagementServer-bbf7824a-8150
-47dc-b429-d09e25ca5ac4.html".
Move-CsManagementServer : Command execution failed: "1" error categories report
ed in topology document.
At line:1 char:24
+ Move-CsManagementServer <<<<
    + CategoryInfo          : InvalidOperation: (:) [Move-CsManagementServer],
    FormatException
    + FullyQualifiedErrorId : ProcessingFailed,Microsoft.Rtc.Management.Deploy
   ment.MoveCms.MoveCmsCmdlet

Ugly, yes?  If you are in coexistence with Lync 2010 and Lync 2013, and are moving the CMS from one Lync 2010 to another Lync 2010 server, and you are using the target Lync 2010 server to run the move-csmanagementserver cmdlet, you are going to fail with the above errors.

How to Fix This

One of the changes in Lync 2013 is that the move-csmanagementserver cmdlet now has a TargetFQDN switch and the move does not need to be performed on the gaining server. As it turns out, the documentation is a tad wrong.  What it should say is that in the coexistence environment, you need to run step 3 from one of the 2013 servers and use the –TargetFQDN switch.  So, do step 3 but using a Lync 2013 FE.  Now the command looks like the following:

The warnings are due to the move-csmanagementserver cmdlet being unable to execute enable-cstopology on the gaining server – that needs to be run locally.  Also note that we are told to run setup on the gaining server.

I think this is a great improvement over the previous method/process – however, the documentation is just a bit off-kilter.  According to my sources, a document bug has been filed, and we can expect to see a documentation update in the future to address this at the “official” level. 

Thanks to Bob Wille (CDW), fellow MVP Tom Pacyk, and Nick Smith (Microsoft) for helping with this issue and coming up with a workable solution. 

In the meantime, YMMV.