Lync SE to EE Migration Checklist

There are plenty of articles that outline the migration process for taking a Standard Edition installation of Lync to Enterprise Edition, but what I’ve not seen covered off is a check-list of things to look out for BEFORE you kill the old SE.

The obvious things are checking you’ve:

  • swung DNS
  • updated the Edge (hosts file?)
  • moved the file share
  • made sure ISA/TMG is pointing your external traffic to the new FE pool (or HLB if you have one)
  • updated the Gateways to also point to (and accept traffic from) the new FE
  • re-run the Exchange integration script (Exchange 2010: %Program Files%\Microsoft\Exchange Server\V14\Scripts\exchucutil.ps1)

There are still a few commandlets you need to run to ensure the old SE is ‘clean’. The process here is essentially the same as when migrating from OCS to Lync, and covered off fairly comprehensively in the document Migrating from Office Communications Server 2007 R2 to Lync Server 2010.

Here’s a collection of commands to run, extracted from the above, with some additions from a Lync beta migration document and a few of my own embellishments. If the first command in any group doesn’t respond clean, then issue the following command to move.

Scrape the following into a text document on your FE, and find/replace (^H) the EE & FE pool names with your own before then pasting each command in turn into the Shell:

Conference Directories

Get-CsConferenceDirectory | Where-Object {$_.ServiceID -match "<SE-FQDN>"}
Move-CsConferenceDirectory -Identity <Numeric identity of conference directory> -TargetPool <EE-PoolFQDN>

Common Area Phones

Get-CsCommonAreaPhone -Filter {RegistrarPool –eq "<SE-FQDN>"}
Get-CsCommonAreaPhone -Filter {RegistrarPool –eq "<SE-FQDN>"} | Move-CsCommonAreaPhone -Target <EE-PoolFQDN>

Get-CsCommonAreaPhone | Where-Object {$_.RegistrarPool -eq "<SE-FQDN>"}
Get-CsCommonAreaPhone | Where-Object {$_.RegistrarPool -eq "<SE-FQDN>"} | Move-CsCommonAreaPhone -Target <EE-PoolFQDN>

Analog Phones

Get-CsAnalogDevice -Filter {RegistrarPool –eq "<SE-FQDN>"}
Get-CsAnalogDevice -Filter {RegistrarPool –eq "<SE-FQDN>"} | Move-CsAnalogDevice -Target <EE-PoolFQDN>

Get-CsAnalogDevice | Where-Object {$_.RegistrarPool -eq "<SE-FQDN>"}
Get-CsAnalogDevice | Where-Object {$_.RegistrarPool -eq "<SE-FQDN>"} | Move-CsAnalogDevice -Target <EE-PoolFQDN>

Dial Plans

Get-CsDialPlan -id service:registrar:<SE-FQDN>

You might not care for an old pool-scoped dial plan on the SE server, but make sure you don’t need to replicate the functionality on the EE pool.

Don’t be freaked if this reports a mess of red – the key takeaway here is if it says what you’ve asked for doesn’t exist:

Get-CsDialPlan : Cannot find "DialPlan" "Registrar:<FQDN>" because it does not exist.


Get-CsUser -Filter {RegistrarPool -eq "<SE-FQDN>"}
Get-CsUser | Where-Object {$_.RegistrarPool -eq "<SE-FQDN>"}

Response Groups

Get-CsRgsConfiguration service:ApplicationServer:<SE-FQDN>
Get-CsRgsWorkflow service:ApplicationServer:<SE-FQDN>
Get-CsRgsQueue service:ApplicationServer:<SE-FQDN>
Get-CsRgsAgentGroup service:ApplicationServer:<SE-FQDN>
Get-CsRgsHolidaySet service:ApplicationServer:<SE-FQDN>
Get-CsRgsHoursOfBusiness service:ApplicationServer:<SE-FQDN>

Migrating Response Groups used to be a hassle, requiring the use of special scripts from the ResKit. These days the cmdlets are inbuilt.

As with the Dial Plan above, red here is good news (for a change):

Get-CsRgsConfiguration : Cannot bind parameter 'Identity' to the target. Exception setting "Identity": "The application "RGS" is not installed on pool "<FQDN>"."

And in case you’ve found an “obvious” shortcut in Move-CsRgsConfiguration, I refer you to this spoiler from the party-poopers at TechNet:

“The Move-CsRgsConfiguration cmdlet is only for migrating from Office Communications Server 2007 R2 or Lync Server 2010 to Skype for Business Server 2015; you cannot use this cmdlet to migrate from one instance of Skype for Business Server 2015 to a new instance of Skype for Business Server 2015. That type of migration can only be done by using the new Import-CsRgsConfiguration and Export-CsRgsConfiguration cmdlets.”

So; down to business.

To backup:

Export-CsRgsConfiguration -Source "service:ApplicationServer:<SE-FQDN>" -FileName "C:\" -RemoveExportedConfiguration

(Note that the above has DELETED your now-previously-working RGS config, so you don’t want to be doing this during operating hours!)
To import into the new EE:

Import-CsRgsConfiguration -Destination "service:ApplicationServer:<EE-PoolFQDN>" -FileName "C:\" -OverwriteOwner -ReplaceExistingRgsSettings

Reference. Note that at the time of writing (July 2015) there are some bugs in the examples on the TechNet page. I’ve corrected the syntax in this post.

Unassigned Numbers

Get-CsUnassignedNumber | ? { $_.AnnouncementServerFqdn -eq "<SE-FQDN>" }

Call Park Orbits

Get-CsCallParkOrbit | ? { $_.CallParkServerFqdn -eq "<SE-FQDN>" }

Call Park MOH

Don’t forget to extract any customised MOH for Call Park. There’s a formal process to find it, but it’s cumbersome. This is much quicker and more practical:

CD <SE file share>

DIR *.wma /s

Audio-Conferencing Access Numbers

Get-CsDialInConferencingAccessNumber | where {$_.Pool -eq "<SE-FQDN>"}

These you’ll move with:

Move-CsApplicationEndpoint -Identity <SIP URI revealed above> -Target <EE-PoolFQDN>

Exchange UM Contacts

Get-CsExUmContact -Filter {RegistrarPool -eq "<SE-FQDN>"}
Get-CsExUmContact -Filter {RegistrarPool -eq "<SE-FQDN>"} | Move-CsExUmContact -Target <EE-PoolFQDN>

And Finally

… and just to be sure you (and I) haven’t missed anything, take one final sweep through the Control Panel and make sure no other pool-related configurations remain – or that those that do you’re OK with leaving behind. (As you’ve already moved the users they’ll be referencing the new pool-scoped policies you might have created on the new EE FE, or otherwise they’ll be now following the attributes from the Global scope. This could result in a change of user experience, and possibly some fault complaints).

Revision History

27th July 2015: Added more info, updated RGS migration process from ResKit app to cmdlets.


Leave a Reply

Your email address will not be published. Required fields are marked *

... and please just confirm for me that you're not a bot first: Time limit is exhausted. Please reload the CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.