Howdy,
So this is a quick guide I wrote to a customer to help the IT-department with How-to decommission their legacy Lync, and thought…well I will just change the screenshots and put it on the blog for all engineers out there that will do this for the first time :)
You can also check this article where I collected a number of my article and put them in one “Complete guide for deploying and migrating to Lync 2013″.
Overview
Before starting with this guide, I’m assuming that you already have Lync 2013 / Lync 2010 co-existence infrastructure and running with no problems and have the following:
- You have already updated the DNS records internally and externally to point to the new Lync Frontend / Lync Edge servers/pools.
- You have already migrated the CMS database to the new Lync 2013 primary pool.
- You have already deployed Lync 2013 clients to all users, or at least updated your user’s Lync 2010 Clients to version that is allowed to connect to Lync 2013 Frontend
And now that all this in order, you can start with the following steps to ensure Lync functionalists not effected and start decommissioning your legacy Lync 2010 infrastructure.
P.S although it goes without saying, you need to do some of those steps after working hours to avoid affecting the users works.
Maintenance mode
One of the things most of the engineers forget is putting the legacy machines of Lync 2010 in maintenance mode in the monitoring system to avoid receiving unwanted number of warning emails or notifications while decommissioning the servers.
So in case you are using SCOM or 3rd-party monitoring tools, PUT YOUR MACHINES IN MAINTENANCE MODE NOW :@
Moving Users, Meetings, Meetings content
So first things first, make sure that you moved all your users and their meetings & meetings contents, usually when you move users from one pool to another the followings are moved with them
- Scheduled meetings
- User’s PIIN
Put the meetings contents are not moved when using the normal “move-csuser” cmdlet, so to make sure you moving the user’s meetings content while moving them to a new pool you need to use the following cmdlet:
PS C:> Get-CsUser | Where-Object {$_.RegistrarPool -like “old pool FQDN”} | Move-CsUser -Target “new Lync2013 pool FQDN” -MoveConferenceData
The -MoveConferenceData will make sure that meeting contents are moved in the process and better do this after working hours, as users will get disconnected during the migration process.
Online Meeting Page options for Legacy clients
So in case your organization didn’t deploy Lync 2013 clients to all users, or I found it also helpful in case you have an online meeting participants with legacy Lync 2010 or OCS 2007R2 client, you can allow users to join the online meetings using Lync 2010 or OCS 2007 R2 Attendant which is done using Set-CSWebServiceConfiguration cmdlet, and set the flag to true on the following two parameters:
- · ShowJoinUsingLegacyClientLink = default value is false
- · ShowAlternateJoinOptionsExpanded = default value is false
PS C:> Set-CsWebServiceConfiguration -ShowJoinUsingLegacyClientLink $true -ShowAlternateJoinOptionsExpanded $true
You can check the configuration after applying the command line using the Get-CsWebServiceConfiguration
Move Common area phones & Analog Devices
Common area Phones
In case you have common area phones that located in a kitchen or waiting area for example, make sure not to forget to move them using following PowerShell cmdlet
PS C:> Get-CsCommonAreaPhone | Move-CsCommonAreaPhone -Target “new lync 2013 pool fqdn”
Analog Devices
To move any analog devices in your organization use the following PowerShell cmdlet:
PS C:> Get-CsAnalogDevice | Move-CsAnalogDevice -Target “lync2013 pool FQDN”
Move Dial-in Access conference numbers
To move the dial-in access numbers you have to move the application endpoint of the conference dial-in number using PowerShell cmdlet, so that’s how I do it
- · Log into Lync Control Panel with user account member of CSAdministrators
- · In the left menu go to “Conferencing” menu and then in middle window go to “Dial-in Access number”
- · Double click on each conference dial-in access number that is hosted on the legacy Lync 2010 pool and take a note of its “sip URI”
- · Now back to PowerShell using the following command line to move the application endpoint of the dial-in access number to the new pool
PS C:> Move-CsApplicationEndpoint -Identity “SIP URI of access number” -Target “Lync2013 Pool FQDN”
- · After moving them, to ensure all are completed successfully, you can login again to the Lync control Panel, go to Conferencing and Dial-in Access tab and make sure the “pool” is stating the new pool FQDN.
Move Response groups
Important notice before starting
This step I see sometime confuse engineers, and it confused me first time I did it because I saw duplicated response groups queues, workflows…etc. and thought that I did something wrong, but actually that’s how it’s done,
After you move the response groups configuration to the new pool, the used cmdlet actually migrate the response groups and copying the agent groups, queues, workflows and custom audio files, as well as moving the response groups contact objects to the new pool, which after all response groups are handled by the new response group application running in the new Lync 2013 pool.
Once you moved the response groups, DO NOT DELETE THE DUPLICATE YOU SEE IN LCP, if you did that, it will break your response groups, those duplicates will be removed once you remove and uninstall the Legacy frontend server/pool.
Also you need to keep in mind that any changes or configuration to be done to the response groups after moving them, need to be done to the copy hosted on the new Lync 2013 pool.
Moving the response group configurations moves everything to the new pool, you cannot select specific group, workflow or queue to move
Moving the Response Groups
Using PowerShell, you can move the response group configuration, which will move /copy all response groups to the new pool as following
PS C:> Move-CsRgsConfiguration -Source “Lync2010 pool FQDN” -Destination “Lync2013 pool FQDN”
Verify movement is a success
To make sure everything went as planned, and your command line didn’t return any errors, do the following
- · Log into the Lync control panel
- · Go in the left menu to “Response Groups
- · On the first page “Workflow” check that workflows from Legacy Lync 2010 is still showed in the list
- · On the first page “Workflow” check that Queues from Legacy Lync 2010 is still showed in the list
- · On the first page “Workflow” check that Groups from Legacy Lync 2010 is still showed in the list
Basically you should see one using the application server of the new pool and one for legacy pool.
Move trusted applications
Next on the list is to move the trusted application pools to the new Lync 2013 pool, this is done by re-configuring the trusted application pool to point to the new Lync 2013 pool, and if required by the application, re-configure the application itself to point to the new Lync 2013 pool (e.g. Lync / OWA integration).
Using PowerShell cmdlet
PS C:> Set-CsTrustedApplicationPool -Identity “Trusted application pool name” -Registrar “Lync2013 new Pool”
Don’t forget to publish the topology after you finish :)
PS C:> Enable-CsTopology
Move Call Park
This step is done on three stages
- · Copy customized on Hold music files
- · Configure the Call park service – (not always)
- · Assign Call Park Orbit Ranges
So you need to copy the music file to the new Lync 2013 pool, and then reconfigure the call park services settings on the Lync 2013 pool and associate the Lync 2010 already associated Call Park orbits ranges with the new Lync 2013 pool.
Copy Customized on hold music files
If any customized on hold music is used with the legacy Lync 2010 call park services, you need to copy them to Lync 2013, according to MS TechNet article, you should use the xcopy cmdlet for this
C:>xcopy “\lync2010_filestore2-ApplicationServer-5AppServerFilesCPS” “\lync2013_filestore2-ApplicationServer-5AppServerFilesCPS“
Re-Configure Call Park services
This should be done only if the new call park service configuration is going to be difference than the one already hosted on Lync 2010 as in different pickup timeout, music on hold…etc.
Anyway let’s say how can you do that
- · Run Get-CSCPConfiguration to see the current values assigned on Lync 2010 CP services
- · Then using the values use the following command line to reconfigure the Lync 2013 CP services
PS C:> Set-CsCpsConfiguration -Identity “LY2013 CP-ID” -EnableMusicOnHold “LY2010 CP value” -MaxCallPickupAttempts “Lync2010 CP value” -OnTimeoutURI “LY2010 CP Value” -CallPickupTimeoutThreshold “LY2010 CP Value”
Assign Call Park Orbit Range
Using the PowerShell cmdlet, list the CP orbit ranges you have in your organization
And using the Set-CsCallParkOrbit assign them to the new Lync 2013 CP services
PS C:> Set-CsCallParkOrbit -Identity “CP Identity” -CallParkService “Service:ApplicationServer:<Lync 2013 pool FQDN>”
With those 3 steps you moved the CP to Lync 2013, and now Lync 2013 pool is responsible for handling the CP services.
Moving Exchange UM Contact Object
If you have Exchange UM integration with legacy Lync 2010 Pool, you need to move the auto attendant & Subscriber contact objects to the new Lync 2013 pool,
Moving AA & SA contact Objects
Using the PowerShell cmdlet Move-CsExUmContact you can move the AA & SA contacts objects to the new Lync 2013 Pool like following
PS C:> Get-CsExUmContact | Where-Object {$_.RegistrarPool -eq “Lync2010 FQDN”} | Move-CsExUmContact -Target “Lync 2013 FQDN”
Adding UM Gateway / Hunt Group (Exchange side)
Now log into your Exchange server and run the ExchUtil script which does the following:
- · Add the UM IP gateway
- · Add the Hunt group
Start PowerShell session and navigate to (C:Program FileMicrosoftExchange ServerV14Scripts) and run the ExchUtil script
PS C:Program FileMicrosoftExchange ServerV14Scripts> .ExchUtil.ps1
Back on the Lync 2013 frontend servers/pool, restart the rtcsrv.exe.
Wait for Part 2 with the decommissioning and uninstalling of the Legacy Lync 2010 pool.
