Are we done so soon? Well, for me this seemed all too quick but it looks like we’re in the last phase in your migration to Skype for Business Server 2019! If you are joining us for the first time, I highly recommend you check our Phases 1-7 here, as this article won’t make much sense without it

Phase 8: Decommission legacy pools

You’ve made it to the last phase! Phase 8 will discuss how to decommission your legacy Lync Server 2013 or Skype for Business Server 2015 pools. This will consist of updating DNS entries, moving the Content Management Server, decommissioning pools, and deactivating and removing servers and pools from a legacy deployment. Please note though, that not all of the procedures listed in this section are required. If you are interested in extensive documentation on decommissioning a deployment, please refer to the documentation here. Otherwise, just hang tight and I’ll give you the abbreviated version.

Important: For information on migrating and upgrading Microsoft Unified Communications Managed API (UCMA) applications, before decommissioning your legacy environment, see UCMA applications: Coexistence, migration, and upgrade scenarios. 

Updating DNS Records

To successfully complete this procedure, you should be logged on to the server or domain as a member of the Domain Admins group or a member of the DnsAdmins group. Below are the steps that should be taken to update your DNS records after you have finished your migration to Skype for Business Server 2019.

1. On the DNS server, click Start, click Administrative Tools, and then click DNS.
2. In the console tree for your SIP domain, expand Forward Lookup Zones, expand the SIP domain in which Skype for Business Server 2019 is installed, and navigate to the _tcp setting.
3. In the right pane, right-click _sipinternaltls and select Properties.
4. In Host offering this service, update the host FQDN to point to the Skype for Business Server 2019 pool.
5. Click OK.

Verifying that the FQDN of the Front End pool or Standard Edition server can be resolved

1. Log on to a client computer in the domain.
2. Click Start, and then click Run.
3. In the Open box, type cmd, and then click OK.
4. At the command prompt, type nslookup <FQDN of the Front End pool> or <FQDN of the Standard Edition server>, and then press ENTER.
5. Verify that you receive a reply that resolves to the appropriate IP address for the FQDN.

• After migrating to Skype for Business Server 2019, and before you can remove the legacy server, you need to move the Central Management Server to the Skype for Business Server 2019 Front End Server or pool. The Central Management Server is a single master/multiple replica system, where the read/write copy of the database is held by the Front End Server that contains the Central Management Server. After you have successfully moved the Central Management Server, you should remove the Central Management Server databases from the original Front End Server. For information on removing the Central Management Server databases, see Remove the SQL Server database for a Front End pool.
  • You use the Windows PowerShell cmdlet Move-CsManagementServer in the Skype for Business Server Management Shell to move the database from the legacy install SQL Server database to the Skype for Business Server 2019 SQL Server database, and then update the SCP to point to the Skype for Business Server 2019 Central Management Server location.

Preparing an Enterprise Edition Front End pool

1. On the Skype for Business Server 2019 Enterprise Edition Front End pool where you want to relocate the Central Management Server, log on to the computer where the Skype for Business Server Management Shell is installed as a member of the RTCUniversalServerAdmins group. You must also have SQL Server database sysadmin user rights and permissions on the database where you want to install the Central Management store.
2. Open the Skype for Business Server Management Shell.
3. To create the new Central Management store in the Skype for Business Server 2019 SQL Server database, in the Skype for Business Server Management Shell, type: Install-CsDatabase -CentralManagementDatabase -SQLServerFQDN <FQDN of your SQL Server> -SQLInstanceName <name of instance>

4. Confirm that the status of the Skype for Business Server Front-End service is Started.

Preparing a Standard Edition Front End Server

1. On the Skype for Business Server 2019 Standard Edition Front End Server where you want to relocate the Central Management Server, log on to the computer where the Skype for Business Server Management Shell is installed as a member of the RTCUniversalServerAdmins group.

2. Open the Skype for Business Server Deployment Wizard.
3. In the Skype for Business Server Deployment Wizard, click Prepare first Standard Edition server.
4. On the Executing Commands page, SQL Server Express is installed as the Central Management Server. Necessary firewall rules are created. When the installation of the database and prerequisite software is completed, click Finish.
5. To create the new Central Management store on the Skype for Business Server 2019 Standard Edition Front End Server, in the Skype for Business Server Management Shell, type: Install-CsDatabase -CentralManagementDatabase -SQLServerFQDN <FQDN of your Standard Edition Server> -SQLInstanceName <name of instance - RTC by default>

6. Confirm that the status of the Skype for Business Server Front-End service is Started.

Note: The initial installation may take some time with no visible updates to the command output summary screen. This is due to the installation of SQL Server Express. If you need to monitor the installation of the database, use Task Manager to monitor the setup.

Moving the legacy installs Central Management Server to Skype for Business Server 2019 

1. On the Skype for Business Server 2019 server that will be the Central Management Server, log on to the computer where the Skype for Business Server Management Shell is installed as a member of the RTCUniversalServerAdmins group. You must also have the SQL Server database administrator user rights and permissions.

2. Open Skype for Business Server Management Shell.

3. In the Skype for Business Server Management Shell, type:

   Enable-CsTopology
   

   CAUTION: If Enable-CsTopology is not successful, resolve the problem preventing the command from completing before continuing. If Enable-CsTopology is not successful, the move will fail and it may leave your topology in a state where there is no Central Management store.

4. On the Skype for Business Server 2019 Front End Server or Front End pool, in the Skype for Business Server Management Shell, type:

   Move-CsManagementServer
   

5. Skype for Business Server Management Shell displays the servers, file stores, database stores, and the service connection points of the Current State and the Proposed State. Read the information carefully and confirm that this is the intended source and destination. Type Y to continue, or N to stop the move.

6. Review any warnings or errors generated by the Move-CsManagementServer command and resolve them.
7. On the Skype for Business Server 2019 server, open the Skype for Business Server Deployment Wizard.
8. In Skype for Business Server Deployment Wizard, click Install or Update Skype for Business Server System, click Step 2: Setup or Remove Skype for Business Server Components, click Next, review the summary, and then click Finish.
9. On the legacy install server, open the Deployment Wizard.
10. In Skype for Business Server Deployment Wizard, click Install or Update Skype for Business Server System, click Step 2: Setup or Remove Skype for Business Server Components, click Next, review the summary, and then click Finish.
11. Reboot the Skype for Business Server 2019 server. This is required because of a group membership change to access Central Management Server database.
12. To confirm that replication with the new Central Management store is occurring, in the Skype for Business Server Management Shell, type:

    Get-CsManagementStoreReplicationStatus
    

    Note: The replication may take some time to update all current replicas.

Removing legacy install Central Management store files after a move

1. On the legacy install server, log on to the computer where the Skype for Business Server Management Shell is installed as a member of the RTCUniversalServerAdmins group. You must also have the SQL Server database administrator user rights and permissions.

2. Open Skype for Business Server Management Shell

   CAUTION: Do not proceed with the removal of the previous database files until replication is complete and is stable. If you remove the files prior to completing replication, you will disrupt the replication process and leave the newly moved Central Management Server in an unknown state. Use the cmdlet Get-CsManagementStoreReplicationStatus to confirm the replication status.

3. To remove the Central Management store database files from the legacy install Central Management Server, type:

   Uninstall-CsDatabase -CentralManagementDatabase -SqlServerFqdn <FQDN of SQL Server> -SqlInstanceName <Name of source server>
   

   For example:

   Uninstall-CsDatabase -CentralManagementDatabase -SqlServerFqdn sql.contoso.net -SqlInstanceName rtc
   

   Where the <FQDN of SQL Server> is either the legacy install Back End Server in an Enterprise Edition deployment or the FQDN of the Standard Edition server.

Moving Conference Directories

• Before decommissioning a pool, you must perform the following procedure for each conference directory in your legacy pool.

1. Open the Skype for Business Server Management Shell.

2. To obtain the identity of the conference directories in your organization, run the following command:

   Get-CsConferenceDirectory
   

   The preceding command returns all the conference directories in your organization. Because of that, you might want to limit the results to the pool being decommissioned. For example, if you are decommissioning the pool with the fully qualified domain name (FQDN) pool01.contoso.net, use this command to limit the returned data to conference directories from that pool:

   Get-CsConferenceDirectory | Where-Object {$_.ServiceID -match "pool01.contoso.net"}
   

   That command returns only the conference directories where the ServiceID property contains the FQDN pool01.contoso.net.

3. To move conference directories, run the following command for each conference directory in the pool:

   Move-CsConferenceDirectory -Identity <Numeric identity of conference directory> -TargetPool <FQDN of pool where ownership is to be transitioned>
   

   For example, to move conference directory 3, use this command, specifying a Skype for Business Server 2019 pool as the TargetPool:

   Move-CsConferenceDirectory -Identity 3 -TargetPool "pool02.contoso.net"
   

   If you want to move all the conference directories on a pool, use a command similar to the following:

   Get-CsConferenceDirectory | Where-Object {$_.ServiceID -match "pool01.contoso.net"} | Move-CsConferenceDirectory -TargetPool "pool02.contoso.net"
   

Download Uninstalling Microsoft legacy and Removing Server Roles for comprehensive, step-by-step instructions on decommissioning legacy pools.

When moving conference directories, you might encounter the following error:

WARNING: Move operation failed for conference directory with ID "5". Cannot perform a rollback because data migration might have already started. Retry the operation.
WARNING: Before using the -Force parameter, ensure that you have exported the conference directory data using DBImpExp.exe and imported the data on the target pool. Refer to the DBImpExp-Readme.htm file for more information.
Move-CsConferenceDirectory : Unable to cast COM object of type 'System._ComObject' to interface type 'Microsoft.Rtc.Interop.User.IRtcConfDirManagement'. 
This operation failed because the QueryInterface call on the COM component for the interface with SID '{4262B886-503F-4BEA-868C-04E8DF562CEB}' failed due to the following error: The specified module could not be found.

This error typically occurs when the Skype for Business Server Management Shell requires an updated set of Active Directory permissions in order to complete a task. To resolve the problem, close the current instance of the Management Shell, then open a new instance of the shell and re-run the command to move the conference directory.

Removing the Archiving server association

To remove an Archiving Server, you need to change or clear the dependency on the associated Front End pool, Front End Server, Survivable Branch Appliance, and Survivable Branch Server. You edit the properties of the Front End pool, Front End Server, Survivable Branch Appliance, and Survivable Branch Server to remove the dependency. After you clear the dependency and delete the server in Topology Builder, you are notified that the associated database store object in Topology Builder will also be deleted.

1. On the Skype for Business Server 2019 Front End Server, open Topology Builder.

2. Navigate to the legacy install node.
3. In Topology Builder, expand Enterprise Edition Front End pools, Standard Edition Front End Servers, or Branch sites, depending on where the Archiving Server is defined.
4. If you have Survivable Branch Server associated, expand Branch sites, expand the branch site name, and then expand Survivable Branch Appliances.

   Note: Survivable Branch Appliances in the user interface applies to both Survivable Branch Server and Survivable Branch Appliance.

5. Right-click the pool, server, or device that is associated with the Archiving Server, and then click Edit Properties.
6. In Edit Properties, under General > Associations, clear the Associate Archiving Server check box, and then click OK.
7. Repeat the previous step for any other pool, server, or device associated with the Archiving Server that you want to remove.
8. Right-click the Archiving Server, and then click Delete.
9. On Delete Dependent Stores, click OK.
10. Publish the topology, check replication status, and then run the Skype for Business Server Deployment Wizard as needed.

Removing the Monitoring server association

To remove the Monitoring Server, you need to change or clear the dependency on the associated Front End pool, Front End Server, Survivable Branch Appliance, and Survivable Branch Server. You edit the properties of the Front End pool, Front End Server, Survivable Branch Appliance, and Survivable Branch Server to remove the dependency. After you clear the dependency and delete the server in Topology Builder, you are notified that the associated database store object in Topology Builder will also be deleted.

1. On the Skype for Business Server 2019 Front End Server, open Topology Builder.

2. Navigate to the legacy installs node.
3. In Topology Builder, expand Enterprise Edition Front End pools, Standard Edition Front End Servers, or Branch sites, depending on where the Monitoring Server is defined.
4. If you have Survivable Branch Server associated, expand Branch sites, expand the branch site name, and then expand Survivable Branch Appliances.

   Note: Survivable Branch Appliances in the user interface applies to both Survivable Branch Server and Survivable Branch Appliance.

5. Right-click the pool, server, or device that is associated with the Monitoring Server, and then click Edit Properties.
6. In Edit Properties, under General > Associations, clear the Associate Monitoring Server check box, and then click OK.
7. Repeat the previous step for any other pool, server, or device associated with the Monitoring Server.
8. Right-click the Monitoring Server, and then click Delete.
9. On Delete Dependent Stores, click OK.
10. Publish the topology, check replication status, and run the Skype for Business Server Deployment Wizard as needed.

Removing the Enterprise Edition Front End Pool or Standard Edition Front End Server

The procedures outlined in this section are designed to guide you through the process of removing an Enterprise Edition Front End pool or a Standard Edition Front End Server. After migrating to Skype for Business Server 2019, this is one of the first steps in decommissioning your legacy environment.

Reset Call Admission Control

1. Open Topology Builder.
2. Right-click the site node, and then click Edit Properties.
3. Under Call Admission Control setting, make sure Enable Call Admission Control is selected.
4. Under Front End pool to run call admission control (CAC), select the Skype for Business Server 2019 pool that is to host CAC, and then click OK.
5. Publish the topology.

Prevent sessions from services

1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or assigned to the CsServerAdministrator or CsAdministrator role, log on to any computer that is in the network in which you deployed Skype for Business Server 2019.
2. Open Skype for Business Control Panel.
3. In the left navigation bar, click Topology, and then click Status.
4. On the Status page, sort or search through the list as needed to find the computer that is running the services for which you want to prevent new sessions, and then click it.
5. Click Action.
6. Click Prevent new sessions for all services.

Prevent new sessions for a specific service

1. From a user account that is a member of the RTCUniversalServerAdmins group (or has equivalent user rights), or assigned to the CsServerAdministrator or CsAdministrator role, log on to any computer that is in the network in which you deployed Skype for Business Server 2019.
2. Open Skype for Business Control Panel.
3. In the left navigation bar, click Topology, and then click Status.
4. On the Status page, sort or search through the list as needed to find the computer that is running the service you want to start or stop, and then click it.
5. Click Properties.
6. Sort the list of services, if necessary, and click the service for which you want to prevent new sessions.
7. Click Action.
8. Click Prevent new sessions for service.
9. Click Close.

Stop/Start legacy services

1. Open Skype for Business Server Control Panel.
2. In the left navigation bar, click Topology, and then click Status.
3. On the Status page, sort or search through the list as needed to find the computer that is running the services you want to start or stop, and then click it.
4. Click Action.
5. Click Start All services or Stop All services.

Stop/Start a specific service

1. Open Skype for Business Server Control Panel.
2. In the left navigation bar, click Topology, and then click Status.
3. On the Status page, sort or search through the list as needed to find the computer that is running the service you want to start or stop, and then click it.
4. Click Properties.
5. Sort the list of services, if necessary, and click the service you want to start or stop.
6. Click Action.
7. Click Start service or Stop service.
8. Click Close.

Removing a Front End Server from a pool

The Front End Server cannot exist as a stand-alone computer. It must be defined as a Front End pool, even if there is only a single computer in the pool.

This topic guides you through the process of removing an individual Front End Server from an existing Front End pool. If the Front End Server is the last server in the pool or if you are removing the pool completely, see Remove Front End pool or Standard Edition server. There is no need to remove the individual Front End Servers before you remove the Front End pool. When you remove the pool, you remove each Front End Server.

1. On the Skype for Business Server 2019 Front End Server, open Topology Builder.
2. Navigate to the legacy install node.
3. Expand Enterprise Edition Front End pools, expand the Front End pool with the Front End Server that you want to remove, right-click the Front End Server that you want to remove, and then click Delete.

Removing the entire Front End Pool or Standard Edition Server

This article guides you through the process of removing a Front End pool or a Standard Edition Front End Server. When you remove a Front End pool, you remove each Front End Server that belongs to the pool as a part of the pool removal process. When you remove a Standard Edition Front End Server, you must remove the SQL Store definition from Topology Builder.

To remove a Front End Server pool

1. Open Topology Builder.
2. Navigate to the legacy node.
3. Expand Enterprise Edition Front End pools, expand the Front End pool, right-click the Front End pool that you want to remove, and then click Delete.
4. Publish the topology, check replication status, and then run the legacy Deployment Wizard as needed.

To remove a Standard Edition Front End server

1. Open Topology Builder.

2. Navigate to the legacy installs node.
3. Expand Standard Edition Front End servers, right-click the Front End Server that you want to remove, and then click Delete.
4. Expand SQL stores, right-click the SQL Server database that is associated with the Standard Edition Front End Server, and then click Delete.

   Important: You must remove the definition of the collocated SQL Server databases from the Standard Edition Front End Server.

5. Publish the topology, check replication status, and then run the Deployment Wizard as needed.

You’re done! This concludes the series of migrating to Skype for Business Server 2019. I hope you have found this series helpful and check back to my blog regularly as I like to post about anything new in the Skype for Business and Microsoft Teams world! For the Microsoft documentation that I referenced throughout this series please see the docs articles here. I did my best to cut out the extraneous information however, I have found that Microsoft is very clear-cut with their instructions. Nevertheless, I look forward to seeing you in the next blog!

Welcome back! Or if you’re new, then welcome! In yesterday’s blog we discussed Phase 6 which included moving from a pilot to a production deployment. Today we work on sealing the deal by going over our post-migration tasks. The list of tasks is pretty extensive but we’ll be sure to cover each one in detail so you don’t feel stranded. Also, if you haven’t checked out Phases 1-6, you find them here.

Phase 7: Complete post-migration task

Congrats! You’re in the home stretch! Now that the migration to Skype for Business Server 2019 is complete, we’ll just need to discuss the post-migration tasks that you will need to perform. This list may seem quite extensive but it crucial to cover all of your bases to ensure a smooth transition from the legacy system to your new one. The post-migration list includes:

Migrate existing meetings and meeting content

• When a user account is moved to a Skype for Business Server 2019 server, the following information is moved with that user account
  • Meetings already scheduled by the user. This includes moving the conferencing directories and conferencing data.
  • User’s personal identification number (PIN). The user’s current PIN continues to work until it expires or the user requests a new PIN.
• The following user account information does not move to the new server.
  • Meeting content. In order to move the content shared during a meeting, such as PowerPoint, Whiteboard, attachments, or poll data, use the -MoveConferenceData parameter as part of the Move-CsUser cmdlet.

Migrate dial-in access numbers

• Migrating dial-in access numbers to Skype for Business Server 2019 requires running the Move-CsApplicationEndpoint cmdlet to migrate the contact objects.
• Dial-in access numbers that you created in the legacy install but moved to Skype for Business Server 2019, or that you created in Skype for Business Server 2019 before, during, or after migration, have the following characteristics:
  • Do not appear on Office Communications Server 2007 R2 meeting invitations and the dial-in access number page.
  • Appear on the legacy install meeting invitations and the dial-in access number page.
  • Appear on Skype for Business Server 2019 meeting invitations and the dial-in access number page.
  • Cannot be viewed or modified in the Office Communications Server 2007 R2 administrative tool.
  • Can be viewed and modified in the legacy install Control Panel and in the legacy install Management Shell.
  • Can be viewed and modified in the Skype for Business Server 2019 Control Panel and in Skype for Business Server 2019 Management Shell.
  • Can be re-sequenced within the region by using the Set-CsDialinConferencingAccessNumber cmdlet with the Priority parameter.
• You must finish migrating dial-in access numbers that point to the legacy install pool before you decommission the legacy install pool. If you do not complete dial-in access number migration as described in the following procedure, incoming calls to the access numbers will fail.

Important: You must perform this procedure prior to decommissioning the legacy install pool.

Identifying and moving dial-in access numbers

1. Start the Skype for Business Server Management Shell: Click Start, click All Programs, click Microsoft Skype for Business Server 2019, and then click Skype for Business Server Management Shell.
2. To move each dial-in access number to a pool hosted on Skype for Business Server 2019, from the command line run: Move-CsApplicationEndpoint -Identity <SIP URI of the access number to be moved> -Target <FQDN of the pool to which the access number is moving>

3. Open Skype for Business Server Control Panel.
4. In the left navigation bar, click Conferencing.
5. Click the Dial-in Access Number tab.
6. Verify that no dial-in access numbers remain for the legacy install pool from which you are migrating.

Note: When all dial-in access numbers point to the Skype for Business Server 2019 pool, you can then decommission the legacy install pool.

Verifying the dial-in access number migration using Skype for Business Server Control Panel

1. From a user account that is assigned to the CsUserAdministrator role or the CsAdministrator role, log on to any computer in your internal deployment.
2. Open Skype for Business Server Control Panel.
3. In the left navigation bar, click Conferencing.
4. Click the Dial-in Access Number tab.
5. Verify that all the dial-in access numbers are migrated to the pool hosted on Skype for Business Server 2019.

Verifying the dial-in access number migration using Skype for Business Server management shell

1. Open Skype for Business Server Management Shell.
2. To return all the dial-in conferencing access numbers migrated, from the command line run: Get-CsDialInConferencingAccessNumber -Filter {Pool -eq "<FQDN of the pool to which the access number is moved>"}

3. Verify that all the dial-in access numbers are migrated to the pool hosted on Skype for Business Server 2019.

Migrate Call Park application settings

• The migration of the Call Park application includes provisioning the Skype for Business Server 2019 pool with any custom music-on-hold files that have been uploaded in the legacy install, restoring the service-level settings and re-targeting all Call Park orbits to the Skype for Business Server 2019 pool.
• If customized music-on-hold files have been configured in the pool, these files need to be copied to the new Skype for Business Server 2019 pool.
• The customized music-on-hold files for the Call Park application are stored in the file store of the pool. To copy the audio files from a pool file store to a Skype for Business Server 2019 file store, use the Xcopy command with the following parameters: Xcopy <Source: legacy Pool CPS File Store Path> <Destination: Skype for Business Server 2019 Pool CPS File Store Path>
  • Example usage: Xcopy “<legacy File Store Path>\OcsFileStore\coX-ApplicationServer-X\AppServerFiles\CPS\” “<Skype for Business Server 2019 File Store Path>\OcsFileStore\coX-ApplicationServer-X\AppServerFiles\CPS\”
• When all customized audio files have been copied to the Skype for Business Server 2019 file store, the Call Park application settings of the Skype for Business Server 2019 pool must be configured, and the Call Park orbit ranges that are associated with the legacy pool must be reassigned to the Skype for Business Server 2019 pool.
• The Call Park application settings include the pickup timeout threshold, enabling or disabling music on hold, the maximum call pickup attempts, and the timeout request. You must manage Call Park application settings by using the Skype for Business Server Management Shell to run the Set-CsCpsConfiguration cmdlet. You cannot manage the Call Park application settings using the Skype for Business Server Control Panel.

Reconfiguring the Call Park Service Settings

1. From the Skype for Business Server 2019 Front End Server, open the Skype for Business Server Management Shell.
2. At the command line, type the following: Set-CsCpsConfiguration -Identity “<LS2013 Call Park Service ID>” -CallPickupTimeoutThreshold “<LS2010 CPS TimeSpan>” -EnableMusicOnHold “<LS2010 CPS value>” -MaxCallPickupAttempts “<LS2010 CPS pickup attempts>” -OnTimeoutURI “<LS2010 CPS timeout URI>”

Note: If your Skype for Business Server 2019 Call Park application settings are identical to the legacy settings, you can skip this step. If Call Park application settings are different for the Skype for Business Server 2019 and legacy environments, use the cmdlet below as a template to update those changes.

To reassign all Call Park orbit ranges from the legacy pool to the Skype for Business Server 2019 pool, you can use either the Skype for Business Server Control Panel or the Skype for Business Server Management Shell.

Reassigning all Call Park Orbit Ranges using Skype for Business Control Panel

1. Open Skype for Business Server Control Panel.
2. In the left pane, select Voice Features.
3. Select the Call Park tab.
4. For each Call Park orbit range assigned to a legacy pool, edit the FQDN of destination server setting and select the Skype for Business Server 2019 pool that will process the Call Park requests.
5. Select Commit to save the changes.

Reassigning all Call Park Orbit Ranges using Skype for Business Management Shell

1. Open Skype for Business Server Management Shell.
2. At the command line, type the following: Get-CsCallParkOrbit


This cmdlet lists all of the Call Park orbit ranges in the deployment. All Call Park orbits that have the CallParkServiceId and CallParkServerFqdnparameters set as the legacy pool must be reassigned.

To reassign the legacy Call Park orbit ranges to the Skype for Business Server 2019 pool, at the command line, type the following:

Set-CsCallParkOrbit -Identity "<Call Park Orbit Identity>" -CallParkService "service:ApplicationServer:<Skype for Business Server 2019 Pool FQDN>"


After reassigning all Call Park orbit ranges to the Skype for Business Server 2019 pool, the migration process for the Call Park application will be completed and the Skype for Business Server 2019 pool will handle all future Call Park requests.

Migrating response groups

• Migrating response groups includes copying agent groups, queues, workflows, audio files, and moving Response Group contact objects from the legacy deployment to the Skype for Business Server 2019 pool. After you migrate your legacy response groups, calls to the response groups are handled by the Response Group application in the Skype for Business Server 2019 pool. Calls to response groups are no longer handled by the legacy pool.
• Before you migrate response groups, you must have deployed a Skype for Business Server 2019 pool that includes the Response Group application. The Response Group application is installed and activated by default when you deploy Enterprise Voice. You can ensure that the Response Group application is installed by running the Get-CsService -ApplicationServer cmdlet.

Note: Although you can migrate response groups before you move all users to the Skype for Business Server 2019 pool, we recommend that you move all users first. In particular, users who are response group agents will not have full functionality of new features until they are moved to the Skype for Business Server 2019 pool. Additionally, you can create new Skype for Business Server 2019 response groups in the Skype for Business Server 2019 pool before you migrate your legacy response groups.

To migrate response groups from a legacy pool to the Skype for Business Server 2019, you run the Move-CsRgsConfiguration cmdlet.

Important: The Response Group migration cmdlet moves the Response Group configuration for the entire pool. You cannot select specific groups, queues, or workflows to migrate.

After you migrate the response groups, you need to use Skype for Business Server Control Panel or Skype for Business Server Management Shell cmdlets to verify that all agent groups, queues, and workflows moved successfully.

When you migrate response groups, the legacy response groups are not removed. When you manage response groups after migration by using either Skype for Business Server Control Panel or Skype for Business Server Management Shell, you can see both the legacy response groups and the Skype for Business Server 2019 response groups. You should apply updates only to the Skype for Business Server 2019 response groups. The legacy response groups are retained only for rollback purposes.

CAUTION: After the migration has been completed and the new response groups have been created, the Skype for Business Server Control Panel and the Skype for Business Server Management Shell will display the legacy and Skype for Business Server 2019 versions of each response group. Do not use Skype for Business Server Control Panel or Skype for Business Server Management Shell to remove the legacy response groups. If you do remove one, the corresponding response group that was created during migration will stop working. The legacy response groups will be removed when you decommission the legacy pool.

Important: We recommend that you do not remove any data from your previous deployment until you decommission the pool. In addition, we strongly recommend that you export response groups immediately after you migrate. If a legacy response group should get removed, you can then restore your response groups from the backup to get Skype for Business Server 2019 response groups running again.

Skype for Business Server 2019 introduces a new Response Group feature called Workflow Type. Workflow Type can be Managed or Unmanaged. All response groups are migrated with Workflow Type set to Unmanaged and with an empty Manager list.

When you run the Move-CsRgsConfiguration cmdlet, the agent groups, queues, workflows, and audio files remain in the legacy pool for rollback purposes. If you do need to roll back to the legacy pool, however, you need to run the Move-CsApplicationEndpoint cmdlet to move contact objects back to the legacy pool.

The following procedure for migrating Response Group configurations assumes that you have a one-to-one relationship between your legacy pools and the Skype for Business Server 2019 pools. If you plan to consolidate or split up pools during your migration and deployment, you need to plan which legacy pool maps to which Skype for Business Server 2019 pool.

Migrating Response Group configurations

1. Log on to the computer with an account that is a member of the RTCUniversalServerAdmins group or has equivalent administrator rights and permissions.
2. Start the Skype for Business Server Management Shell: Click Start, click All Programs, click Microsoft Skype for Business Server 2019, and then click Skype for Business Server Management Shell.
3. Run: Move-CsRgsConfiguration -Source <source pool FQDN> -Destination <destination pool FQDN>

4. For example: Move-CsRgsConfiguration -Source skype-old.contoso.net -Destination skype-new.contoso.net

5. After you migrate response groups and agents to the Skype for Business Server 2019 pool, the URL that agents use to sign in and sign out is a Skype for Business Server 2019 URL and is available from the Tools menu. Remind agents to update any references, such as bookmarks, to the new URL.

Verifying Response Group migration by using Skype for Business Server Control Panel

1. Log on to the computer with an account that is a member of RTCUniversalReadOnlyAdmins group or is minimally a member of the CsViewOnlyAdministrator role.
2. Open a browser window, and then enter the Admin URL to open the Skype for Business Server Control Panel. For details about the different methods you can use to start Skype for Business Server Control Panel, see Open Skype for Business Server 2019 administrative tools.
3. In the left navigation pane, click Response Groups.
4. On the Workflow tab, verify that all the workflows in your legacy environment are included in the list.
5. Click the Queue tab, and verify that all the queues in your legacy environment are included in the list.
6. Click the Group tab, and verify that all the agent groups in your legacy environment are included in the list.

Verifying Response Group migration by using Skype for Business Management Shell

1. Log on to the computer with an account that is a member of RTCUniversalReadOnlyAdmins group or is minimally a member of the CsViewOnlyAdministrator role.
2. Start the Skype for Business Server Management Shell: Click Start, click All Programs, click Microsoft Skype for Business Server 2019, and then click Skype for Business Server Management Shell.
3. For details about the following cmdlets, run:Get-Help <cmdlet name> -Detailed

4. Run:Get-CsRgsAgentGroup

5. Verify that all the agent groups in your legacy environment are included in the list.
6. Run:Get-CsRgsQueue

7. Verify that all the queues in your legacy environment are included in the list.
8. Run:Get-CsRgsWorkflow

9. Verify that all the workflows in your legacy environment are included in the list.

Migrating the Address Book

• In general, the Address Book is migrated along with the rest of your topology. However, you might need to perform some post-migration steps if you customized the following in your legacy environment:
  • Set the PartitionbyOU WMI property to group Address Book entries by organizational unit (OU).
  • Customized the Address Book normalization rules.
  • Changed the default value for the UseNormalizationRules parameter to False.

Grouped Address Book Entries

• If you set the PartitionbyOU WMI property to True to create address books for each OU, you need to set the msRTCSIP-GroupingId Active Directory attribute on users and contacts if you want to continue grouping address book entries. You might want to group address book entries to limit the scope of Address Book searches. To use the msRTCSIP-GroupingId attribute, write a script to populate the attribute, assigning the same value for all of the users that you want to group together. For example, assign a single value for all the users in an OU.

Address Book Normalization Rules

• If you customized Address Book normalization rules in your legacy environment, you must migrate the customized rules to your pilot pool.
• The default normalization rules for Skype for Business Server 2019 are the same as the default rules for the legacy install. Follow the procedure later in this section to migrate customized normalization rules.

Note: If your organization uses remote call control and you customized Address Book normalization rules, you must perform the procedure in this topic before you can use remote call control. The procedure requires membership in the RTCUniversalServerAdmins group or equivalent rights.

UseNormalizationRules Set to False

• If you set the value for UseNormalizationRules to False so that users can use phone numbers as they are defined in Active Directory Domain Services without having Skype for Business Server 2019 apply normalization rules, you need to set the UseNormalizationRules and IgnoreGenericRulesparameters to True. Follow the procedure later in this section to set these parameters to True.

Migrating Address Book normalization rules

1. Find the Company_Phone_Number_Normalization_Rules.txt file in the root of the Address Book shared folder, and copy it to the root of the Address Book shared folder in your Skype for Business Server 2019 pilot pool.

   Note: The sample Address Book normalization rules have been installed in your ABS Web component file directory. The path is $installedDriveLetter:\Program Files\Microsoft Skype for Business Server 2019\Web Components\Address Book Files\Files\ Sample_Company_Phone_Number_Normalization_Rules.txt. This file can be copied and renamed as Company_Phone_Number_Normalization_Rules.txt to the address book shared folder’s root directory. For example, the address book shared in $serverX, the path will be similar to: \$serverX \SkypeForBusiness-FileShare\2-WebServices-1\ABFiles.

2. Use a text editor, such as Notepad, to open the Company_Phone_Number_Normalization_Rules.txt file.
3. Certain types of entries will not work correctly in Skype for Business Server 2019. Look through the file for the types of entries described in this step, edit them as necessary, and save the changes to the Address Book shared folder in your pilot pool.Strings that include required whitespace or punctuation cause normalization rules to fail because these characters are stripped out of the string that is input to the normalization rules. If you have strings that include required whitespace or punctuation, you need to modify the strings. For example, the following string would cause the normalization rule to fail:

   \s*\(\s*\d\d\d\s*\)\s*\-\s*\d\d\d\s*\-\s*\d\d\d\d
   

   The following string would not cause the normalization rule to fail:

   \s*\(?\s*\d\d\d\s*\)?\s*\-?\s*\d\d\d\s*\-?\s*\d\d\d\d

Setting UseNormalizationRules and IgnoreRules to True

1. Start the Skype for Business Server Management Shell: Click Start, click All Programs, click Microsoft Skype for Business Server 2019, and then click Skype for Business Server Management Shell.
2. Do one of the following:
   • If your deployment includes only Skype for Business Server 2019, run the following cmdlet at the global level to change the values for UseNormalizationRules and IgnoreGenericRules to True: Set-CsAddressBookConfiguration -identity <XdsIdentity> -UseNormalizationRules=$true -IgnoreGenericRules=$true
   • If your deployment includes a combination of Skype for Business Server 2019 and a legacy install, run the following cmdlet and assign it to each Skype for Business Server 2019 pool in the topology: New-CsAddressBookConfiguration -identity <XdsIdentity> -UseNormalizationRules=$true -IgnoreGenericRules=$true

3. Wait for Central Management store replication to occur on all pools.

4. Modify the phone normalization rules file, “Company_Phone_Number_Normalization_Rules.txt”, for your deployment to clear the content. The file is on the file share of each Skype for Business Server 2019 pool. If the file is not present, then create an empty file named “Company_Phone_Number_Normalization_Rules.txt”.
5. Wait several minutes for all Front End pools to read the new files.
6. Run the following cmdlet on each Skype for Business Server 2019 pool in your deployment: Update-CsAddressBook

Configure the meeting join page

When a user clicks a meeting link in a meeting request, the meeting join page detects which client is already installed on the user’s computer. If a client is already installed, that client opens and joins the meeting. If a client is not installed, by default the Web App opens.

You can modify the behavior of the meeting join page if you want to allow users to join meetings. These configuration options have been removed from the Control Panel, but you configure them by using the CsWebServiceConfiguration cmdlet.

Meeting Join Page CsWebServiceConfiguration Parameters

Removing legacy Archiving and Monitoring servers

• If your legacy deployment contained an Archiving Server or a Monitoring Server, after migrating to Skype for Business Server 2019, those servers can be removed from the legacy environment, provided all users have been removed from any remaining legacy pools. You can remove the Archiving Server or Monitoring Server in any sequence. The key requirement is that all users have been removed from any remaining legacy pools. You can move users to Skype for Business Server 2019 by referencing the move procedures in “Phase 4: Moving test users to pilot pool“.
• After you have confirmed that all users have been removed from any remaining pools, decommision the server and remove roles. A dated, but relevant, example is “Uninstalling Microsoft Lync Server and Removing Server Roles,” which can be downloaded at https://go.microsoft.com/fwlink/p/?linkId=246227.

Configuring trusted application servers

• In a mixed environment, if you create a new trusted application server, you must set the next hop pool to be a Skype for Business Server 2019 pool. In a mixed environment, both the legacy pool and the Skype for Business Server 2019 pool appear in the drop-down list. Selecting the legacy pool is not supported.

Important: If you are migrating a trusted application server, you should also update the version of UCMA you are using. If you create a new Trusted Application Pool for Skype for Business Server 2019, you should update UCMA to the version that is included with Skype for Business Server 2019 or the latest version available.

Select Skype for Business Server 2019 as next hop when creating a Trusted application server

1. Open Topology Builder.
2. In the left pane, right-click Trusted application servers and click New Trusted Application Pool.
3. Enter the Pool FQDN of the trusted application pool and select whether it will be single-server or multiple-server.
4. Click Next.
5. On the Select the next hop page, from the list, select the Skype for Business Server 2019 Front End pool.
6. Click Finish.
7. Select the top node Skype for Business Server, and from the Action menu select Publish.
8. Verify that the Trusted Application Pool has been created successfully and is associated with the correct Front End pool.

Deploy Skype for Business Server clients

For details, see Deploy clients for Skype for Business Server in the Deployment documentation.

Connect an SBA (Survivable Branch Appliance)

• Every Survivable Branch Appliance (SBA) is associated with a Front End pool that serves as a backup registrar for the SBA. When the Front End pool is migrated to Skype for Business Server 2019, the SBA must be disassociated from the Front End pool while the pool is upgraded. After the pool has been migrated to Skype for Business Server 2019, the SBA can be re-associated with the upgraded Front End pool. This involves deleting the SBA from the legacy topology in Topology Builder and then adding the SBA to the Skype for Business Server 2019 topology. Users homed on the legacy SBA must first be moved to another Front End pool before removing the SBA from the topology. After the SBA is added to the Skype for Business Server 2019 topology, those users can be moved back to the SBA. These steps are summarized below:

1. Move branch users homed on the legacy SBA to another Front End pool.
2. Remove SBA from the legacy topology to disconnect the existing Front End pool as a backup registrar.
3. Add SBA to the Skype for Business Server 2019 topology and configure this new Front End pool as the backup registrar.
4. Move the branch users to the new Skype for Business Server 2019 SBA.

Adding a legacy SBA branch site to your topology

1. Open Topology Builder.
2. In the left pane, right-click Branch sites, and then click New Branch Site.
3. In the Define New Branch Site dialog box, click Name, and then type the name of the branch site.
4. (Optional) Click Description, and then type a meaningful description for the branch site.
5. Click Next.
6. (Optional) In the next Define New Branch Site dialog box, do any of the following:
   1. Click City, and then type the name of the city in which the branch site is located.
   2. Click State/Region, and then type the name of the state or region in which the branch site is located.
   3. Click Country Code, and then type the two-digit calling code for the country/region in which the branch site is located.
7. Click Next, and then, if you are using a Survivable Branch Appliance or Server at this site, be sure to clear the Open the New Survivable Wizard when this wizard closes check box. Click Finish.
8. To associate the legacy SBA to the Skype for Business Server 2019 Front End pool:
   1. Expand the branch site that has been created.
   2. Right-click on legacy version, and then click New.
   3. Click Survivable Branch Appliance.
9. Follow the directions in the wizard that opens. For information about wizard items, see

Note: A SBC can only be associated with a monitoring store.

10. If you are not using a Survivable Branch Appliance or Server at this site, clear the Open the New Survivable Wizard when this wizard closes check box, and then click Finish.

11. Repeat the previous steps for each branch site you want to add to the topology.

Configuring SCOM monitoring 

• After migrating to Skype for Business Server 2019, you must complete a few tasks to configure Skype for Business Server 2019 to work with System Center Operations Manager.
  • Apply updates to a server elected to manage the central discovery logic.
  • Update the central discovery candidate server registry key.
  • Configure your primary System Center Operations Manager management server to override the candidate central discovery node.

Instructions for carrying out each of these tasks are provided below.

Apply updates to a server elected to manage the central discovery logic.

1. Elect a server that has the System Center Operations Manager agent files installed and is configured as a candidate discovery node.
2. Apply updates to this server. See the topic Apply updates.

Update the central discovery candidate server registry key.

1. On the server elected to manage the central discovery logic, open a Windows PowerShell command window.
2. At the command line, type the following:

New-Item -Path "HKLM:\Software\Microsoft\Real-Time Communications\Health"


New-Item -Path "HKLM:\Software\Microsoft\Real-Time Communications\Health\CentralDiscoveryCandidate"

Note: Whenever you edit the registry, you may experience an error that the command failed if the registry key already exists. If you experience this, you can safely ignore the error.

Whenever you edit the registry, you may experience an error that the command failed if the registry key already exists. If you experience this, you can safely ignore the error.

• Migrate Common Area Phones
• Migrate analog devices

Configuring your primary SCOM management server to override the candidate central discovery watcher node.

1. On a computer where the System Center Operations Manager console has been installed, expand Management Pack Objects and then select Object Discoveries.
2. Click Change Scope
3. From the Scope Management Pack Objects page, select LS Discovery Candidate.
4. Override the LS Discovery Candidate Effective Value to the name of the candidate server elected in the earlier procedure.
5. To finalize your changes, restart the health service on the System Center Operations Manager Root Management Server.

Migrating Common Area Phones

Common Area Phones are IP phones that most often reside in a shared workspace or common area, like a lobby, kitchen, or factory floor. Common Area Phones do not need to be connected to a computer to provide Skype for Business Server unified communications (UC) functionality. After migrating a deployment to Skype for Business Server 2019, you must also migrate the contact objects associated with the legacy Common Area Phone. Using Skype for Business Server Management Shell, you will first retrieve all contact objects associated with the legacy Common Area Phones, and then move those objects to the Skype for Business Server 2019 pool.

Migrating Common Area Phones

1. From the Skype for Business Server 2019 Front End server, open Skype for Business Server Management Shell.
2. From the command line, type the following: Get-CsCommonAreaPhone -Filter {RegistrarPool -eq "pool01.contoso.net"} | Move-CsCommonAreaPhone -Target pool02.contoso.net

3. To verify that all contact objects have been moved to the Skype for Business Server 2019 pool, from the Skype for Business Server Management Shell type the following: Get-CsCommonAreaPhone -Filter {RegistrarPool -eq "pool02.contoso.net"}

4. Verify that all contact objects are now associated with the Skype for Business Server 2019 pool.

Migrate analog devices 

1. Start the Skype for Business Server Management Shell: Click Start, click All Programs, click Microsoft Skype for Business Server 2019, and then click Skype for Business Server Management Shell.
2. At the command line, type: Get-CsAnalogDevice -Filter {RegistrarPool -eq "pool01.contoso.net"} | Move-CsAnalogDevice -Target pool02.contoso.net

3. Verify that all contact objects have been moved to the Skype for Business Server 2019 pool. At the command line, type: Get-CsAnalogDevice -Filter {RegistrarPool -eq "pool02.contoso.net"}

4. Verify that all the contact objects are now associated with the Skype for Business Server 2019 pool.

Great job! I know this was a longer blog article, but I wanted to make sure we covered all bases so nothing was missed. On that note though, we’re almost done! In Phase 8, we’ll discuss decommissioning our legacy pools! So you can finally say bye bye to Lync Server 2013 or Skype for Business Server 2015 and brag about how your company is using the latest and greatest that Microsoft has to offer (well besides Teams, but that’s a blog for another day )!

Hello again! Welcome back to Phase 6 of 8 in our migration to Skype for Business Server 2019. Last time we added the Edge Server role to our deployment. In this blog we’ll be making the big move from pilot to production! Don’t be scared though, because we’ll be discussing everything you’ll need to set you up for success! Also, if you haven’t gotten a chance to read through Phases 1-5 I strongly encourage you to check them out here!

Phase 6: Move from pilot deployment into production

Now that we’ve proven we can configure and deploy Skype for Business Server 2019 in a pilot deployment, it is finally time to move things to a production-level deployment. In order to do this, you will be responsible for the following tasks:

• Configure federation routes and media traffic
• Verify federation and remote access for external users
• Change simple URLs after migration
• Move remaining users to Skype for Business Server 2019

After these tasks are completed you will be in the home stretch for your migration to Skype for Business Server 2019, so let’s jump right in!

Configuring federation routes and media traffic

• Federation is a trust relationship between two or more SIP domains that permits users in separate organizations to communicate across network boundaries. After you migrate to your pilot pool, you need to transition from the federation route of your previous version’s Edge Servers to the federation route of your Skype for Business Server 2019 Edge Servers. The following procedures must be followed to transition the federation route and the media traffic from your previous version’s Edge Server and Director to your Skype for Business Server 2019 Edge Server, for a single-site deployment.

IMPORTANT NOTES: 

1. Changing the federation route and media traffic route requires that you schedule maintenance downtime for the Skype for Business Server 2019 and previous version Edge Servers. This entire transition process also means that federated access will be unavailable for the duration of the outage. You should schedule the downtime for a time when you expect minimal user activity. You should also provide sufficient notification to your end users. Plan accordingly for this outage and set appropriate expectations within your organization.
2. If your legacy Edge Server is configured to use the same FQDN for the Access Edge service, Web Conferencing Edge service, and the A/V Edge service, the procedures in this section are not supported. If the legacy Edge services are configured to use the same FQDN, you must first migrate all your users, then decommission the previous versions Edge Server before enabling federation on the Skype for Business Server 2019 Edge Server.
3. If your XMPP federation is routed through a Skype for Business Server 2019 Edge Server, users on the previous version will not be able to communicate with the XMPP federated partner until all users have been moved to Skype for Business Server 2019, XMPP policies and certificates have been configured, the XMPP federated partner has been configured on Skype for Business Server 2019, and, lastly, the DNS entries have been updated.

Removing legacy federation association from Skype for Business Server 2019

1. On the Skype for Business Server 2019 Front End server, open the existing topology in Topology Builder.
2. In the left pane, navigate to the site node, which is located directly below Skype for Business Server.
3. Right-click the site, and then click Edit Properties.
4. In the left pane, select Federation route.
5. Under Site federation route assignment, clear the Enable SIP federation check box to disable the federation route through the legacy environment.
6. Click OK to close the Edit Properties page.
7. From Topology Builder, select the top node Skype for Business Server.
8. From the Action menu, click Publish Topology.
9. Click Next to complete the publishing process, and then click Finish when the publishing process has completed.

Configuring the legacy Edge Server as a non-federating Edge Server 

1. In the left pane, navigate to the legacy install node and then to the Edge pools node.
2. Right-click the Edge server, and then click Edit Properties.
3. Select General in the left pane.
4. Clear the Enable federation for this Edge pool (port 5061) check box and select OK to close the page.
5. From the Action menu, select Publish Topology, and then click Next.
6. When the Publishing wizard completes, click Finish to close the wizard.
7. Verify that federation for the legacy Edge server is disabled in Topology Builder.

Configuring the certificates on the legacy Edge Server

1. Export the external Access Proxy certificate, with the private key, from the legacy Edge Server.
2. On the Skype for Business Server 2019 Edge Server, and import the Access Proxy external certificate from the previous step.
3. Assign the Access Proxy external certificate to the Skype for Business Server 2019 external interface of the Edge Server.
4. The internal interface certificate of the Skype for Business Server 2019 Edge Server should be requested from a trusted CA and assigned.

Changing the previous version’s federation route to use Skype for Business Server 2019 Edge Server 

1. From Topology Builder, in the left pane, navigate to the Skype for Business Server 2019 node and then to the Edge pools node.
2. Right-click the Edge server, and then click Edit Properties.
3. Select General in the left pane.
4. Select the check box for Enable federation for this Edge pool (port 5061), and then click OK to close the page.
5. From the Action menu, select Publish Topology, and then click Next.
6. When the Publishing wizard completes, click Finish to close the wizard.
7. Verify that Federation (port 5061) is set to Enabled in Topology Builder.

Updating Skype for Business Server 2019 Edge Server federation next hop

1. From Topology Builder, in the left pane, navigate to the Skype for Business Server 2019 node and then to the Edge pools node.
2. Expand the node, right-click the Edge Server listed, and then click Edit Properties.
3. On the General page, under Next hop selection, select from the drop-down list the Skype for Business Server 2019 pool.
4. Click OK to close the Edit Properties page.
5. From Topology Builder, select the top node Skype for Business Server.
6. From the Action menu, click Publish Topology and complete the wizard.

Configuring Skype for Business Server 2019 Edge Server outbound media path

1. From Topology Builder, in the left pane, navigate to the Skype for Business Server 2019 node and then to the pool below Standard Edition Front End Servers or Enterprise Edition Front End pools.
2. Right-click the pool, and then click Edit Properties.
3. In the Associations section, select the Associate Edge pool (for media components) check box.
4. From the drop-down box, select the Skype for Business Server 2019 Edge Server.
5. Click OK to close the Edit Properties page.

Turning on Skype for Business Server 2019 Edge Server federation

1. From Topology Builder, in the left pane, navigate to the Skype for Business Server 2019 node and then to the Edge pools node.
2. Expand the node, right-click the Edge Server listed, and then click Edit Properties.
3. Note: Federation can only be enabled for a single Edge pool. If you have multiple Edge pools, select one to use as the federating Edge pool.
4. On the General page, verify that the Enable federation for this Edge pool (Port 5061) check box is selected.
5. Click OK to close the Edit Properties page.
6. Navigate to the site node.
7. Right-click the site, and then click Edit Properties.
8. In the left pane, click Federation route.
9. Under Site federation route assignment, select Enable SIP federation, and then from the list select the Skype for Business Server 2019 Edge Server listed.
10. Click OK to close the Edit Properties page.
11. For multi-site deployments, complete this procedure at each site.

Publishing Edge Server configuration changes

1. From Topology Builder, select the top node Skype for Business Server.
2. From the Action menu, select Publish Topology and complete the wizard.
3. Wait for Active Directory replication to occur to all pools in the deployment.

Configuring the Skype for Business 2019 Edge Server

1. Bring all of the Skype for Business Server 2019 Edge Servers online.
2. Update the external firewall routing rules or the hardware load balancer settings to send SIP traffic for external access (usually port 443) and federation (usually port 5061) to the Skype for Business Server 2019 Edge Server, instead of the legacy Edge Server.
3. Stop the Skype for Business Server Access Edge from each Edge Server computer.
4. From each legacy Edge Server computer, open the Services applet from the Administrative Tools.
5. In the services list, find Skype for Business Server Access Edge.
6. Right-click the services name, and then select Stop to stop the service.
7. Set the Startup type to Disabled.
8. Click OK to close the Properties window.

Note: If you do not have a hardware load balancer, you need to update the DNS A record for federation to resolve to the new Skype for Business Server Access Edge server. To accomplish this with minimal disruption, reduce the TLL value for the external Skype for Business Server Access Edge FQDN so that when DNS is updated to point to the new Skype for Business Server Access Edge, federation and remote access will be updated quickly.

Verify federation and remote access for external users

• After transitioning the federation route to Skype for Business Server 2019 Edge Server, you should perform some functional tests to verify that federation performs as expected. Tests for external user access should include each type of external user that your organization supports, including any or all of the following.

  • Users from at least one federated domain, an internal user on Skype for Business Server 2019, and a user on the legacy install. Test instant messaging (IM), presence, audio/video (A/V), and desktop sharing.

  • Users of each public IM service provider that your organization supports (and for which provisioning has been completed) communicating with a user on Skype for Business Server 2019 and a user on the legacy install.
  • Verify that anonymous users are able to join conferences.
  • A user hosted on the legacy install using remote user access (logging i nto Lync Server/Skype for Business from outside the intranet but without VPN) with a user on Skype for Business Server 2019, and a user on the legacy install. Test IM, presence, A/V, and desktop sharing.
  • A user hosted on Skype for Business Server 2019 using remote user access (logging in to Skype for Business Server 2019 from outside the intranet but without VPN) with a user on Skype for Business Server 2019, and a user on the legacy install. Test IM, presence, A/V, and desktop sharing.

Change simple URL’s after migration

• There are 3 simple URL’s that Skype for Business Server supports:
  • Meet – Used as the base URL for all conferences in the site or organization. With the Meet simple URL, links to join meetings are easy to comprehend, and easy to communicate and distribute.
  • Dial-in – Enables access to the Dial-in Conferencing Settings webpage. The Dial-in simple URL is included in all meeting invitations so that users who want to dial in to the meeting can access the necessary phone number and PIN information.
  • Admin – Enables quick access to the Skype for Business Server Control Panel. The Admin simple URL is internal to your organization.

After your migration it is important to understand how this will impact your DNS records and certificates for the simple URL’s. For example, if the Skype for Business Server Director is removed from the topology after migration, the simple URL DNS records must be updated to point to one of the Skype for Business Server pools. However, if the legacy Skype for Business Server Director remains in use in the topology, no changes to your simple URLs are required.

Note: Whenever you change a simple URL name, however, you must run Enable-CsComputer on each Director and Front End Server to register the change.

Updating the Meet simple URL

1. In Topology Builder, right-click the top node Skype for Business Server, and then click Edit Properties.
2. Select Simple URLs in the left pane, then below Meeting URLs: select the Meet URL and then click Edit URL.
3. Update the URL to the value you want, and then click OK to save the edited URL.

Updating the Admin simple URL

1. In Topology Builder, right-click the top node Skype for Business Server, and then click Edit Properties.
2. Select Simple URLs in the left pane, then below Administrative access URL box, enter the simple URL you want for administrative access to Skype for Business Server Control Panel, and then click OK.

For more information on simple URL’s please see the link here.

Move remaining users to Skype for Business Server 2019 

• As mentioned in phase 4, you can move users either via Skype for Business Control Panel or Skype for Business Server Management Shell. For more information regarding moving the users please scroll up to phase 4 where I outlined this process.

Important: You cannot use the Active Directory Users and Computers snap-in or the legacy administrative tools to move users from your legacy environment to Skype for Business Server 2019. 

When moving a user to a Skype for Business Server 2019 pool, the data for the user is moved to the back-end database that is associated with the new pool.

Important: This includes the active meetings created by the legacy user. For example, if a legacy user has configured a my meeting conference, that conference will still be available in the new Skype for Business Server 2019 pool after the user has been moved. The details to access that meeting will still be the same conference URL and conference ID. The only difference is that the conference is now hosted in the Skype for Business Server 2019 pool, and not in the legacy pool.

Note: Homing users on Skype for Business Server 2019 does not require that you deploy upgraded clients at the same time. New functionality will be available to users only when they have upgraded to the new client software.

You did it! You just finished moving your remaining users over to the Skype for Business Server 2019 pool! However, first some quick housekeeping rules before you can celebrate:

1. Verify the conferencing policy that is assigned to them.
2. Ensure that meetings organized by users homed on Skype for Business Server 2019 work seamlessly with federated users who are homed on legacy install, the conferencing policy assigned to the migrated users should allow anonymous participants.
3. Conferencing policies that allow anonymous participants have Allow participants to invite anonymous users selected in Skype for Business Server 2019 Control Panel and have AllowAnonymousParticipantsInMeetings set to True in the output from the Get-CsConferencingPolicy cmdlet in the Skype for Business Server Management Shell.

Once you have done the tasks above, feel free to crack open a brew (if you’re of age ) and celebrate! I hope you have found this blog helpful, and tune in tomorrow when we discuss our post-migration tasks in Phase 7!

Welcome back for Phase 5! In phase 4 we moved some users over to the pilot pool. Today we’ll be taking things a step further by deploying an Edge Server role in our pilot pool. If you haven’t seen the blog articles on Phases 1-4, you can check them out here! However, if you’ve been on the journey with us since the beginning we can proceed on!

Phase 5: Add Edge Server to pilot pool

Great job! Now we have some users in our Skype for Business Server 2019 pilot pool! Next, we’ll be adding the Edge Server role to the pilot pool. In this phase we will be configuring and verifying our edge deployment.

Deploy pilot Edge Server

•  This topic highlights configuration settings you should be aware of before deploying your Skype for Business Server 2019 Edge Server. As you navigate through the Define New Edge Pool wizard, review the key configuration settings shown in the following steps. Note that only a few pages of the Define New Edge Pool wizard are shown.

1. Log on to the computer where Topology Builder is installed as a member of the Domain Admins group and the RTCUniversalServerAdmins group.
2. Navigate to the Skype for Business Server 2019 node. Right-click Edge pools, and click New Edge pool.
3. An Edge pool can be a Multiple computer pool or Single computer pool.
4. On the Select features page, do not enable federation or XMPP federation. Federation and XMPP federation are both currently routed through the legacy Edge Server. These features will be configured in a later phase of migration.
5. Continue completing the following wizard pages: External FQDNs, Define the internal IP address, and Define the external IP address.
6. On the Define the next hop server page, select the Director for the next hop of the legacy Edge pool.
7. On the Associate Front End or Mediation pools page, do not associate a pool with this Edge pool at this time. External media traffic is currently routed through the legacy Edge Server. This setting will be configured in a later phase of migration.
8. Click Finish, and then Publish the topology.
9. Follow the steps in the Deployment documentation to install the files on the new Edge Server, configure certificates, and start the services.

Verify configuration settings

Now that we have deployed the pilot edge server, we must verify the configuration settings. To do this we can run the Get-CsManagementStoreReplicationStatus cmdlet on the internal computer where CMS (Central Management Store) is located, or on a domain joined computer where Skype for Business Server 2019 Core Components (OcsCore.msi) is installed.

Note: Initial results may indicate the status as “False” instead of “True” for replication. If so, run the Invoke-CsManagementStoreReplication cmdlet and allow time for the replication to complete before running the Get-CsManagementStoreReplicationStatus again.

This concludes Phase 5. Today we added the Edge Server role to our topology, published, and verified the configuration settings. In Phase 6 we’ll be discussing possibly the biggest task yet, which is moving from a pilot to a production deployment. So definitely make sure to check back tomorrow for that blog! Until then, I thank you for checking out this blog and I hope you have found this helpful.

We’re half way there! Today we discuss phase 4 of 8 on our migration to Skype for Business Server 2019. In this article we’ll be discussing moving test users to your pilot pool that you have already, planned, prepared, and deployed! If you are just tuning in for the first time, check out my blog page for Phases 1-3. With that said, let’s get moving (get it…hehe)!

Phase 4: Move test users to pilot pool

Now that we have deployed the Skype for Business Server 2019 pilot pool, it is time to start moving test users to that pilot pool. There are two methods that can be used when moving either single users or groups of users:

1. Skype for Business Control Panel
2. Skype for Business Management Shell

The topics in this section outline tasks that must be completed during the pilot deployment, as well as prior to moving your deployment of Skype for Business Server 2019 from pilot deployment to a production-level deployment.

View current users in legacy pool

• Before learning the various ways you can move users between pools, we must first determine which users exist in the legacy pool. In the image below, the Registrar pool column identifies six users who are configured for the legacy pool. These are the test users we will move to the Skype for Business Server 2019 pool.
  • Log on to the legacy Front End Server with an account that is a member of the RTCUniversalServerAdmins group or a member of the CsAdministrator or CsUserAdministrator administrative role.
  • Open Skype for Business Server Control Panel.
  • Click Users, click Search, and then click Find.

Verify user replication has completed

• You may notice that after running a the Move-CsUser cmdlet, you sometimes will experience a failure. This is due to the fact that ADDS (Active Directory Domain Services) and the Skype for Business Server 2019 databases are out of sync because the initial replication is not complete. Depending on the number of domain controllers you are hosting in your Active Directory forest that hosts the Skype for Business Server 2019 pool will determine how long it takes for the successful completion of the Skype for Business Server 2019 User Replicator service’s initial synchronization. This User Replicator service initial synchronization process occurs when the Skype for Business Server 2019 Front End Server is started for the first time. After that point the synchronization is based upon the User Replicator interval. The following steps should be followed to verify that the replication has completed before running the Move-CsUser cmdlet.
  • Log on to the computer where Topology Builder is installed as a member of the Domain Admins group and the RTCUniversalServerAdmins group.
  • Click the Start menu, and then click Run.
  • Enter eventvwr.exe, and then click OK.
  • In Event Viewer, click Applications and Services logs to expand it, and then select Skype for Business Server.
  • In the Actions pane, click Filter Current Log.
  • From the Event sources list, click LS User Replicator.
  • In <All Event IDs>, enter 30024, and then click OK.
  • In the filtered events list, on the General tab, look for an entry that states that user replication has completed successfully.

Move a single user to the pilot pool 

• As mentioned earlier, you have the option of moving either a single user or groups of users to the pilot pool and that can be done either via Skype Management Shell or Skype for Business Control Panel. The steps for each option are as follows:

Moving a user via Skype for Business Server 2019 Control Panel

1. Log on to the Front End Server with an account that is a member of the RTCUniversalServerAdmins group or a member of the CsAdministrator or CsUserAdministrator administrative role.
2. Open Skype for Business Server Control Panel.
3. Click Users, click Search, and then click Find.
4. Select a user that you want to move to the Skype for Business Server 2019 pool. In this example, we will move user Sara Davis.
5. On the Action menu, select Move selected users to pool.
6. From the drop-down list, select the Skype for Business Server 2019 pool.
7. Click Action, and then click Move selected users to pool. Click OK.
8. Verify that the Registrar pool column for the user now contains the Skype for Business Server 2019 pool, which indicates that the user has been successfully moved.

Moving a user via Skype for Business Server 2019 Management Shell

1. Open the Skype for Business Server Management Shell.
2. At the command line, type the following:
3. Move-CsUser -Identity "Brian Siefferman" -Target "pool02.perficient.com"

4. Next, at the command line, type the following:
5. Get-CsUser -Identity "Brian Siefferman"

6. The RegistrarPool identity now points to the Skype for Business Server 2019 pool. The presence of this identity confirms that the user has been successfully moved.

Move multiple users to the pilot pool

• You also have the ability to move multiple users from your legacy pool to your Skype for Business Server 2019 pilot pool using the Skype for Business Control Panel or Skype for Business Management Shell.  The steps for each of these options are as follows:

Moving multiple users via the Skype for Business Server 2019 Control Panel 

1. Open Skype for Business Server Control Panel.
2. Click Users, click Search, and then click Find.
3. Select two users that you want to move to the Skype for Business Server 2019 pool. In this example, we will move users Chen Yang and Claus Hansen.
4. From the Action menu, select Move selected users to pool.
5. From the drop-down list, select the Skype for Business Server 2019 pool.
6. Click Action, and then click Move selected users to pool. Click OK. 
7. Verify that the Registrar pool column for the users now contains the Skype for Business Server 2019 pool, which indicates that the users have been successfully moved.

Moving multiple users via the Skype for Business Server 2019 management shell

1. Open the Skype for Business Server 2019 Management Shell.
2. At the command line, type the following and replace User1 and User2 with specific user names you want to move, and replace pool_FQDN with the name of the destination pool. In this example we will move users Hao Chen and Katie Jordan.
3. Get-CsUser -Filter {DisplayName -eq "User1" -or DisplayName - eq "User2"} | Move-CsUser -Target "pool_FQDN"

4. At the command line, type the following:
5. Get-CsUser -Identity "User1"

6. The Registrar Pool identity should now point to the pool you specified as pool_FQDN in the previous step. The presence of this identity confirms that the user has been successfully moved. Repeat step to verify that User2 has been moved.

Moving all users at the same time via Skype for Business Server 2019 management shell

In this example, all users have been returned to the legacy pool (pool01.contoso.net). Using the Skype for Business Server 2019 Management Shell, we will move all users at the same time to the Skype for Business Server 2019 pool (pool02.contoso.net).

1. Open the Skype for Business Server 2019 Management Shell.
2. At the command line, type the following:
3. Get-CsUser -OnLyncServer | Move-CsUser -Target "pool_FQDN"

4. Run Get-CsUser for one of the pilot users.
5. Get-CsUser -Identity "Hao Chen"

6. The Registrar Pool identity for each user now points to the pool you specified as pool_FQDN in the previous step. The presence of this identity confirms that the user has been successfully moved.
7. Additionally, we can view the list of users in the Skype for Business Server 2019 Control Panel and verify that the Registrar Pool value now points to the Skype for Business Server 2019 pool.

Great job! You’re officially done with Phase 4 in your migration to Skype for Business Server 2019! Check back tomorrow for Phase 5 where we discuss adding an edge server to your pilot pool!

Hi there! Welcome back to part 3 of 8 in our migration to Skype for Business Server 2019! In the last two phases we planned and prepared for the migration. This time, we’ll get our hands dirty by taking our first steps in deploying the Skype for Business Server 2019 pilot pool. Also, if you haven’t had a chance to check out Phase 1 and/or Phase 2, check out my blog page and you can find it there. With that said, let’s get right to it!

Phase 3: Deploy Skype for Business Server pilot pool

The deployment of Skype for Business Server 2019 requires using Topology Builder to define your topology and the components you want to deploy, preparing your environment for deployment of Skype for Business Server 2019 components, publishing your topology design on the first Front End Server, and then installing and configuring Skype for Business Server 2019 software for the components for your deployment. When completed, your Skype for Business Server 2019 pilot pool deployment will coexist with an existing legacy pool. Let’s go over each of these steps in a little more detail.

Prepare Active Directory for Skype for Business Server

• Before deploying Skype for Business Server 2019 in a coexistence state, you must perform some additional Active Directory tasks to configure the schema, forest, and domain for Skype for Business Server 2019. The schema extensions add the Active Directory classes and attributes that are required by Skype for Business Server 2019.
  • On the Skype for Business Server 2019 Front End Server, run Skype for Business Server 2019 Setup.
  • Select Prepare Active Directory .
  • Complete steps 1 through 5 in the wizard.

Download Topology from existing deployment

• When creating a Skype for Business Server 2019 pool, you will use the Central Management Store that is associated with the legacy installation. When you start Topology Builder on first use and subsequent edit sessions, you are prompted for the location where you want Topology Builder to load the current configuration document. Because you already have a topology defined and have established the Central Management store, you should choose to download a topology from an existing deployment. Topology Builder will read the database and retrieve the current definition.
  • Open the Skype for Business Server Deployment Wizard.
  • From the Skype for Business Server 2019 – Deployment Wizard page, click Install Administrative Tools.
  • Start Topology Builder: Click Start, click All Programs, click Microsoft Skype for Business Server 2019, and then click Skype for Business Server Topology Builder.
  • Select Download Topology from existing deployment.
  • Choose a file name, and save the topology with the default .tbxml file type.
  • Expand the Skype for Business Server node to reveal the various server roles in the deployment.

Deploying Skype for Business Server 2019 pilot pool

• The pilot pool is where you test coexistence of Skype for Business Server 2019 with your legacy deployment. Coexistence is a temporary state that lasts until you have moved all users and pools to Skype for Business Server 2019. There are several steps required to deploy your pilot pool but I’ll give you the quick and dirty for each steps for the sake of brevity.

Note: The following procedure discusses features and settings you should consider as part of your overall pilot pool deployment process. This section only highlights key points you should consider as part of your pilot pool deployment.

When you deploy a pilot pool, you use the Define New Front End Pool wizard. You should deploy the same features and workloads in your Skype for Business Server 2019 pilot pool that you have in your legacy pool. If you deployed Archiving Server, Monitoring Server, or System Center Operations Manager for archiving or monitoring your legacy environment, and you want to continue archiving or monitoring throughout the migration, you need to also deploy these features in your pilot environment. The version you deployed to archive or monitor your legacy environment will not capture data in your Skype for Business Server 2019 environment.

1. Log on to the computer where Topology Builder is installed as a member of the Domain Admins group and the RTCUniversalServerAdmins group.

2. Expand the tree until you reach Skype for Business Server 2019 > Enterprise Edition Front End pools.
3. Right-click Enterprise Edition Front End pools and select New Front End Pool.

4. Enter the pool fully qualified domain name (FQDN). When you define your pilot pool, you can choose to deploy an Enterprise Edition Front End pool or a Standard Edition server. Skype for Business Server 2019 does not require that your pilot pool features match what was deployed in your legacy pool.

5. On the Select features page, select the check boxes for the features that you want on this Front End pool. For example, if you are deploying only instant messaging (IM) and presence features, you would select the Conferencing check box to allow multiparty IM, but you would not select the Dial-in (PSTN) conferencing, Enterprise Voice, or Call Admission Control check boxes, because they represent voice, video, and collaborative conferencing features.

6. On the Select collocated server roles page, we recommend that you choose to collocate the Mediation Server in Skype for Business Server 2019. When merging a legacy topology with Skype for Business Server 2019, we require that you first collocate the legacy Mediation Server. After merging the topologies and configuring the Skype for Business Server 2019 Mediation Server, you can decide whether to keep the collocated Mediation Server, or change it to a stand-alone server when you move the Mediation Server role to Skype for Business Server 2019 later in the deployment process.
7. On the Associate server roles with this Front End pool page, during pilot pool deployment, do not choose the Enable an Edge pool to be used by the media component of this Front End pool option. This is a feature you will enable and bring online in a later phase of migration. Keep this setting cleared for now.
8. On the Select an Office Web Apps Server page, click New, and specify the FQDN of the application server.
9. On the Define the Archiving SQL Server store page, when defining the SQL Server store for both Skype for Business Server Archiving and Monitoring, select the SQL Server instance created earlier for Skype for Business Server 2019.
10. To publish your topology, right-click the Skype for Business Server node, and then click Publish Topology.
11. When the publish process has completed, click Finish.

Verifying pilot pool coexistence with legacy pool

• Verify that Skype for Business Server 2019 services have started
  • From the Skype for Business Server 2019 Front End Server, navigate to the Administrative Tools\Services applet.
  • Verify that the following services are running on the Front End Server:
    • Centralized Logging Service Agent
    • Application Sharing
    • Audio Test Service
    • Audio/Video Conferencing
    • Call Park
    • Conferencing Announcement
    • Conferencing Attendant
    • Front-End
    • IM Conferencing
    • Mediation
    • Replica Replicator Agent
    • Response Group
    • Web Conferencing
    • XMPP Translating Gateway
• Open the Skype for Business Server 2019 Control Panel
  • From the Front End Server in your Skype for Business Server 2019 deployment, open the Skype for Business Server 2019 Control Panel and select the legacy pool. Repeat the procedure to open the Skype for Business Server 2019 pool.
• Don’t attempt to open the topology in the legacy Topology builder
  • If you attempt to open the topology using the legacy Topology Builder. The topology can only be viewed using Skype for Business Server 2019 Topology Builder. The Skype for Business Server 2019 Topology Builder must be used to create pools for both Skype for Business Server 2019 and the legacy install.

Connecting pilot pool to legacy Edge Servers

• Once Skype for Business Server 2019 has been deployed, you will need to configure a federation route for your site. In order to use the federated route that is being used by the legacy installation, Skype for Business Server 2019 must be configured to use this route. In order to enable the Skype for Business 2019 site to use the Director and Edge Server of the legacy deployment, you must use Topology Builder to associate the legacy Edge pool. The steps are to do this are as follows:

1. Open Topology Builder.
2. Select your site, which is directly below the Skype for Business Server node.
3. On the Actions menu, click Edit Properties.
4. In the left pane, select Federation route.
5. Under Site federation route assignment, select Enable SIP federation, and then select the legacy Director, or the legacy Edge Server if no Director is listed.
6. Click OK to close the Edit Properties page.
7. In Topology Builder, under the Skype for Business Server 2019 node, navigate to the Standard Edition server or Enterprise Edition Front End pools, right-click the pool, and then click Edit Properties.
8. Under Associations, select the check box next to Associate Edge pool (for media components).
9. From the list, select the legacy Edge Server.
10. Click OK to close the Edit Properties page.
11. In Topology Builder, select the top-most node, Skype for Business Server.
12. From the Action menu, click Publish Topology, and then click Next.
13. When the Publishing wizard completes, click Finish.

Configuring XMPP gateway access policies and certificates

• XMPP federation defines an external deployment based on the eXtensible Messaging and Presence Protocol (XMPP). An XMPP configuration allows users access to XMPP domain users by:
• IM and Presence – person to person only
• Creation of XMPP federated contacts in the Skype for Business client

Note: XMPP functionality has been deprecated in Skype for Business Server 2019, however you can continue to use it on a legacy server that is in coexistence with Skype for Business Server 2019. Make sure you have already deployed the legacy server (Skype for Business Server 2015 / Lync Server 2013) XMPP Gateway, and configured the access policies to enable users for legacy XMPP Gateway. For details, see Migrating XMPP Federation.

The steps to configure an external access policy to enable users for legacy XMPP gateway are as follows:

1. Open the legacy Skype for Business Server Control Panel.
2. In the left navigation bar, click Federation and External Access, and then click External Access Policy.
3. Click New, and then click User policy.
4. Enter a name for the external access user policy.
5. Provide a description for external access user policy.
6. Select Enable communications with federated users.
7. Select Enable communications with XMPP federated users.
8. Click Commit to save your changes to the site or user policy.

Great job! So far we’ve planned and prepared for the migration as well as deployed a pilot pool for Skype for Business Server 2019. In the next phase we’ll start moving our first test users over to that pool to begin using it! Check back in tomorrow for Phase 4!

Welcome back! Today we’ll be discussing the second phase of your migration to Skype for Business Server 2019. If you are just joining us for the first time I’d recommend back tracking to my Phase 1 blog article. In the first phase we planned and now in this phase we will begin preparing for the migration. So with that said, off we go!

Phase 2: Preparing for Migration

Now that we have the basic building blocks on planning the migration, it is now time to discuss preparing for the migration. This is done by considering the following topics:

• Apply updates
  • Before you migrate, updates must be applied to your environment. For the most up-to-date information, see the Skype for Business downloads and updates at https://go.microsoft.com/fwlink/p/?linkid=232630.
• Configure DNS records for pilot pool deployment
  • Before deploying the pilot pool, you must update the DNS Host A entries for the pilot pool. To successfully complete this procedure, you should be logged on to the server or domain as a member of the Domain Admins group or a member of the DnsAdmins group.
• Run Best Practices Analyzer
  • The Best Practices Analyzer tool gathers configuration information from a deployment and if the configuration is set according to Microsoft best practices. You can download the Best Practices Analyzer from the Microsoft Download Center at https://go.microsoft.com/fwlink/p/?linkid=246173.
• Back up systems and data
  • Before you begin the migration, perform a full system backup and document your existing system, including an inventory of user accounts that are homed on each pool, so that you can roll back if it becomes necessary
• Configure clients for migration
  • These configuration changes should be made on Lync Server 2013 or Skype for Business Server 2015 (the version you are migrating from ).
    • Deploy the most recent server, client, and device updates (hotfixes) for your existing installation.
    • On the previous version of Skype for Business Server, use Client Version Filtering to only allow clients with the most current updates installed.
• Verify the legacy environment
  • The steps in verifying your legacy environment are as follows:

1. Verify that legacy services are started
2. Review the legacy topology in Skype for Business Server Control Panel
3. Review legacy users in Skype for Business Server Control Panel
4. Verify legacy Edge and federation settings
5. Verify legacy XMPP federated partner Configuration

Let’s dig a bit deeper into each of these verification steps by showing you a step by step process.

Verifying that legacy services are started

1. From the legacy Front End Server, navigate to the Administrative Tools\Services applet.

2. Verify that the following services are running on the Front End Server:

Reviewing the legacy topology in Skype for Business Control Panel

1. Log on to the Front End Server with an account that is a member of the RTCUniversalServerAdmins group or a member of the CsAdministrator or CsUserAdministrator administrative role.

2. Open the Skype for Business Server Control Panel.

3. Select Topology. Verify that the various servers in your legacy deployment are listed.

Review legacy users in Skype for Business Control Panel

1. Open the Skype for Business Server Control Panel.

2. Select Users, and then click Find.
3. Verify that the Registrar Pool column points to the legacy pool for each user listed.

Verify legacy Edge and federation settings

1. Start Topology Builder.

2. Select Download Topology from existing deployment.
3. Choose a file name, and save the topology with the default .tbxml file type.
4. Expand the legacy installs node to reveal the various server roles in the deployment.
5. Select the site node and verify that a Site federation route assignment value is set.
6. Select the Standard Edition Server or Enterprise Edition front end pool. Determine whether an Edge pool has been configured for media below Associations.
7. Select the Edge pool and identify whether a Next hop pool is configured below Next hop selection.

Verifying legacy XMPP federated partner configuration

1. From the legacy XMPP server, navigate to the Administrative Tools\Services applet.

2. Verify that the Office Communications Server XMPP Gateway service is started.

   

There you have it, now that we have completed phases 1 and 2 of your migration to Skype for Business Server 2019 you are well on your way! However, this only lays the foundation for our migration, in the next few phases we’ll be building on this by deploying our first pilot pool and progressing from there! Nevertheless, I hope you have found this helpful and I’ll see you for Phase 3!

Skype for Business Server 2019 was recently released for preview on 7/24/18. With this release comes a plethora of information on what is included in this revision, what changes were made, and possibly the most important thing, how to migrate from Lync Server 2013 or Skype for Business Server 2015 to Skype for Business Server 2019. In this blog series, we’ll be discussing just that, by walking through each phase necessary to upgrade your existing deployment to the latest and greatest Microsoft has to offer. As you could probably guess, this will be an 8 part series and I’ll be releasing one blog per phase on a daily basis! Just for some context, I’ll be using the following terms throughout the blogs, so to save you some time I’ll define them below:

• Migration: Moving your production deployment from Lync Server 2013 or Skype for Business Server 2015 to Skype for Business Server 2019.
• Coexistence: The temporary environment that exists during migration when some functionality has been migrated to Skype for Business Server 2019 and other functionality still remains on a prior version.
• Interoperability: The ability of your deployment to operate successfully during the period of coexistence.
• Legacy: The system you are migrating away from, which is either Lync Server 2013 or Skype for Business Server 2015.

Great, now that we got that out of the way we should be all set! So without further ado, let’s jump right in!

Prerequisites & Best Practices

Before we even dive in to the migration phases we should understand the migration process and coexistence testing. Best practices when migrating to Skype for Business Server 2019 is to use the side-by-side migration migration process. In a side-by-side migration, you deploy a new server with Skype for Business Server 2019 alongside a corresponding server that is running a previous version (Lync Server 2013 or Skype for Business Server 2015), and then just transfer the operations over to the new server. If things somehow go FUBAR (meaning included if you aren’t familiar with the slang word hehe), worry not, as you can always roll back to a previous version. To do this you will only have to shift operations back to the original servers.

Note: BE AWARE! If you find that you need to roll back to the original servers, any new meetings that were scheduled with the new clients will not work, and the clients would also need to be downgraded.

For coexistence testing, once you have completely deployed Skype for Business Server 2019 in parallel with your legacy system, the deployment will represent a coexistence testing state. While in this state, it is crucial to thoroughly test and ensure that:

• Services are started properly
• Each site is able to be administered
• All clients can communicate with current and legacy users

Before the migration even occurs you must also understand the state of each deployment and ensure that each deployment is functional and working as expected. The coexistence state typically exists throughout the pilot testing of Skype for Business Server 2019. The pilot testing will just consist of moving legacy users to Skype for Business Server 2019 for a certain amount of time to test application compatibility and features to ensure they are working properly. Once the pilot testing is complete, all remaining users are moved to the production version of Skype for Business Server 2019, with an end state of decommissioning the legacy pools and applications.

Within the migration process, it is broken down into 8 different phases:

• Phase 1: Plan your migration
• Phase 2: Prepare for migration
• Phase 3: Deploy Skype for Business Server 2019 pilot pool
• Phase 4: Move test users to the pilot pool
• Phase 5: Add Skype for Business Server 2019 Edge Server to pilot pool
• Phase 6: Move from pilot deployment into production
• Phase 7: Complete post-migration tasks

• Phase 8: Decommission legacy pools

Today we’ll be discussing the first and most important step in your migration journey, which is planning.

Phase 1: Planning your migration

Planning is the first and most crucial phase in your migration journey. As the saying goes, “failing to plan is planning to fail” and this is no exception. Within the planning phase you must focus on the following:

• User migration
  • Create several test users and use them to conduct systems tests. After you have successfully moved and tested those accounts, you should identify a group of pilot production users and move their accounts and conduct validation tests on them. When you get satisfactory results, you can move the rest of your users to the new deployment.
• Migrating Archiving and Monitoring Servers
  • If you deployed Archiving Server and Monitoring Server in your legacy environment, you can deploy these servers in your Skype for Business Server 2019 environment after you migrate your Front End pools. If archiving and monitoring functionality are critical to your organization, however, you should add archiving and monitoring to your Skype for Business Server 2019 pilot pool before you migrate so that the functionality is available during the migration process.
• Administering servers after migration
  • After a Skype for Business Server pilot pool is deployed, you cannot use Topology Builder or Control Panel to manage any 2019 resources. You must use 2019 tools to manage all current and previous version resources.
• Migrating multiple sites and pools
  • After deploying a Skype for Business Server 2019 pilot pool, you need to define a subset of pilot users that will be moved to the Skype for Business Server 2019 pool, and a methodology for validating the functionality of the users. For example, after moving a user to the pilot pool, verify that the user’s conference policy has moved to Skype for Business Server 2019.
  • After deploying an Edge Server in the pilot pool, you need to validate that external users can communicate with the Skype for Business Server 2019 pool.
  • Persistent Chat, SQL Mirroring, and XMPP functionality are deprecated in Skype for Business Server 2019 and no longer available as Skype for Business Server 2019 features, but they can be continued in a coexistence environment if they were previously deployed in a legacy environment. If you want to continue using these features, you should plan to continue with a coexistence environment where certain users will remain in legacy pools.
  • After transitioning the federated routes’ Edge Servers to the pilot Skype for Business Server 2019 Edge Servers, you need to validate that federated users can communicate with the Skype for Business Server 2019 pool.
  • After moving all users and non-user contact objects, you need to validate that the legacy pool is empty.
  • After verifying that the legacy pool is empty, you can then deactivate the pool.
• Migrating XMPP federation
  • The XMPP functionality is no longer available and is deprecated in Skype for Business Server 2019. If you want to continue with the XMPP functionality, you can do so in a coexistence environment with a legacy version (Skype for Business Server 2015 or Lync Server 2013). XMPP functionality is installed in two parts: as an XMPP proxy that runs on the legacy Edge Server, and the XMPP Gateway that runs on the legacy Front End Server.

This concludes the first phase of your migration to Skype for Business Server 2019. I hope you have found this helpful and check back tomorrow when I release Phase 2!

By default in Skype for Business, any two users (internal or external) who can communicate with each other can also see each other’s presence information. Some organizations may want to give their end users control on who they want to see their presence information. This can be configured through a feature called Privacy Mode, and this blog article will cover how to configure it and what it means from an end user’s perspective.
In a Lync or Skype for Business on-premises server deployment, there is not an option in the admin center to enable or disable Privacy Mode. The current settings can be viewed using the PowerShell command Get-CsPrivacyConfiguration. Privacy Mode is controlled through the EnablePrivacyMode property. When set to False, presence information is available to anyone in the organization as well as external federated companies. When set to True, this enables the user the option to control the Privacy Mode in their client. When enabled in their client, only their Skype for Business contacts can see their presence. Use the Set-CsPrivacyConfiguration command to change this for the deployment. Additional privacy configurations can be made at the site or service level using the New-CsPrivacyConfiguration command; however, a new global scope policy cannot be created.
In Skype for Business Online, there is an option in the admin panel to set the privacy mode. It can be found under Organization > General and has two options: Automatically display presence information or Display presence information only to a user’s contacts.

The first option is the equivalent to setting EnablePrivacyMode to False, and the second option is the equivalent to setting it to True. In fact, this can also be controlled in Skype for Business Online PowerShell using the Set-CsPrivacyConfiguration, but new custom configurations cannot be made like they can be in the on-premises server products. When changing this in Skype for Business Online, I typically found it did not take effect for 1 hour, but your mileage may vary due to replication in the system. Most Office 365 tenant related changes seem to have an SLA of 24 hours, so if you do not see the change happen after that, a support ticket is the next step. It also requires signing out and signing back into the Skype for Business client to change the settings options.
When presence information is configured to automatically be available, the Status option in the client appears like this:

When Privacy Mode is enabled, the Status option in the client changes to allow the end-user to choose whether or not their presence will show to everyone or to people in their Contacts list:

Selecting the first option of I want everyone to be able to see my presence will allow anyone in the organization or external federated partners to view your presence. When the second option of I only want people in Contacts to see my presence, you will appear as Offline to any one who is not in your Contact list. However, other people in the organization and federated partners can still contact you via instant message or voice and video calls. It does not prevent contact, only viewing of presence information. Also, these privacy settings are not honored by older clients, such as Microsoft Office Communicator 2007 R2 or Microsoft Office Communicator 2007. If a user signs into one of these older clients, they may be able to see another user’s presence who they are not authorized to view. When enabling Privacy Mode, it is suggested to create client version rules that block these older clients (creating these rules is only possible in the on-premises server environments).
I would be cautious in changing this setting if you have an established deployment in either on-premises or Skype for Business Online. When I enabled Privacy Mode in a test Office 365 tenant and signed into my client, it automatically selected the radio button to only allow people in my Contacts to see my presence. If this were enabled after a deployment, this could cause some confusion among users as to why everyone starts to appear as Offline to them but they are able to contact and to call them. Before making this change, ensure there is proper change management and communication to the end-user population on the effects of the change and how they can control their options.
There is another option in controlling presence and communication through privacy relationships. Privacy relationships allow people to control how much of their information is shared with other people in their Contacts list. There are five privacy relationships that can be set for your Skype for Business contacts:

• Colleagues (default for new contacts)
• External Contacts
• Workgroup
• Friends and Family
• Blocked

This Office Support article has a table that outlines how much information each contact relationship can view for your account. Blocked contacts will not be able to contact you but can still view your name and e-mail address. However, blocking a contact only prevents a Skype for Business call from being established. It will not block an incoming call from the PSTN if the number matches that contacts phone number. To change the privacy relationship for a contact, right-click the contact in your Skype for Business client and choose Change Privacy Relationship. Contact privacy relationships put more control in the user’s hands but will require them to add each contact they want to block into their Contacts list and change the privacy relationship. If you need to block only a few users, this could be manageable but is not sustainable for blocking a large group of users.
References:
Office Support: Control Access to Your Presence Information in Skype for Business
Microsoft Docs: Set-CsPrivacyConfiguration
Microsoft TechNet: Configuring Enhanced Presence Privacy Mode in Lync Server 2013
Did you find this article helpful? Leave a comment below or follow me on Twitter (@JeffWBrown) for more information on Skype for Business and Microsoft Teams.

Great news for enterprise Mac users – this week, out of Redmond: the new Skype for Business client for macOS has been released and is available for download!
If you’re a business Mac user (or if you support Mac users), and currently use Lync Server, Skype for Business Server, or Skype for Business Online as part of Office 365 in your enterprise, you know that your option for a full-featured unified communications client for Mac users has been the Lync 2011 client – client software for the macOS platform has not been updated since that release.  In contrast, Windows users have experienced regular updates and feature enhancements included in the release of the Lync 2013 client, Skype for Business 2015 client, and Skype for Business 2016 client as part of the Office 2016 suite.  Meanwhile Mac users have been patiently waiting for an upgrade.  Your patience as Mac users and administrators has now been rewarded with this release!  It is encouraging to see Microsoft placing such a significant amount of resources into carrying forward the new Skype for Business platform for customers who leverage Apple platforms in the enterprise, yet still want to seamlessly communicate and collaborate using their organizations Office Server or Office 365 platforms.
Some reading this post may already be familiar with the client in its preview state – Microsoft offered users registered in the Skype for Business Preview Program an inside look into the client throughout the development process, and received overwhelming feedback during the run of the Mac client preview (so much, they had to begin turning potential preview users away).  This feedback was used to develop what I anticipate will be the best Mac client yet.  Some of the new functionality introduced in this new client includes:

1. A great new Skype-themed user interface that brings all the familiar features of the Lync 2011 client forward into the new Skype for Business color palate and icon scheme, together with an appearance that is unique and undeniably suited for the Mac
2. Connectivity via Unified Communications Web API (UCWA) rather than standard SIP connectivity used with the Windows client
3. Support for Modern Authentication (ADAL), including Multi-Factor Authentication, previously unavailable with the Lync 2011 client
4. Introduction of Group Video Calling – an alternative to the “Gallery” view implemented in the Windows client
5. Improved centralized records-keeping, thanks to integration with Skype for Business Server Side Conversation History – all of your chats are stored to a searchable repository in your Exchange mailbox

Microsoft has been working on this client for some time now, and has stated that the client was a fresh build, using none of the previous code base for the Lync 2011 client… the new Mac client was built from the ground up.  This means there are still some features that will show up in subsequent updates, as well as some inevitable bugs that we will encounter and work through as we begin to roll this out to our clients.
For additional information on the Skype for Business on Mac client, reference the following resources recently published by Microsoft:
Office Blog: Skype for Business on Mac Release Announcement
Download the Skype for Business on Mac Client
Skype for Business on Mac: Known Issues
Client Comparison Tables, now including the Skype for Business on Mac Platform

 

Through the web, in-print, and from subject matter experts you can find many materials, scenarios, and use cases on how to migrate to Office 365. It is likely that your unique situation has been partly documented somewhere or an external resource can ease your mind as you begin to evaluate unplugging on-premises hardware.
Don’t forget your line-of-business employees.
Your organization’s core may consist of employees that can be drastically disrupted by the solutions your migration has to offer. Here a few tips to manage that disruption.
Help users understand  “the cloud”
To most nontechnical employees “the cloud” still remains a confusing buzzword. Educating your end users on basic cloud principles can lead to wins:

• Less confusion at the help desk: Do your employees understand the difference between a web app and desktop app? Microsoft has helped with distinctive names (i.e. Word and Word Online), although you may need to go a step further.
• Front line data loss prevention: Understanding the cloud will help users decipher when they are using their personal cloud versus their workplace cloud, thus preventing inadvertent actions.
• Ease their nerves: The concept of having all information available anywhere is scary to most folks. Help your users establish good habits so that they are confident about protecting their data and able to identify if they happen upon a misstep.

Brief and simple communication
If you send emails or training documents too often you run the risk of being taken likely. Some may assume neglecting a piece of communication is okay because it will be there the next time around. Strategically plan your communications and adjust as you evaluate your execution. Have a centralized place where all communications, FAQ’s, and roadmaps can referenced.
Customization Within
Each department of your organization has unique processes and workflows. The technical realm will change consistently across the organization, however how each segment adopts and uses new tools will vary. Be flexible with respect to the various groups and certain that your communication is receptive.
Identify Advocates
As you begin turn on solutions and deploy software look for those who are eagerly receptive to new tools and are fast learners. These individuals will likely want to know more than the necessary details and can relate your content to their job role better. Enable them to teach others that work closely with them. They are advocates for change, immediate aid to their colleagues, and will be great sources for feedback.
“Always learning” for many employees does not include staying up to date with new technologies that help them do work. Their specialization is important to your line-of-business and any change outside of that should be handled tenderly. Your IS department can improve productivity and positively influence workplace culture by mitigating stresses that come with drastic change.

In a previous blog post I talked about how administrators and architects should place more emphasis on planning for application sharing bandwidth in their Skype4B deployments.  Armed with that information, the next logical progression of this blog series continues the focus on application sharing and discusses the available methods within Skype4B to manage and control the bandwidth requirements for application sharing.

General Methods of Controlling Bandwidth

Speaking broadly, there are typically two methods of controlling any sort of application bandwidth across enterprise networks.  Both methods are not mutually exclusive and can be used in concert with one another, but it is largely up to network engineers and the application engineers to work together to find the best solution for your environment.
Control the traffic at the network
For most of the network engineers out there, this is the “preferred method”.  Like controlling traffic on highways via “normal lanes” and “HOV lanes”, network traffic is separated, classified and handled in a manner that is configured by the network engineers to give preferential treatment (and bandwidth) to high priority traffic while giving normal treatment to non-priority traffic.  This is most generally referred to as Quality of Service (QoS).  QoS is typically seen in two forms:

• Differentiated Services – This is a QoS designation split into two layers of the OSI stack
  • Class of Service (CoS) – This is a Data Link Layer classification method whereby a 3-bit CoS field is included in Ethernet headers in a 802.1Q VLAN
  • Differentiated Services Code Point (DSCP) – This is a Network Layer classification method whereby a 6-bit DSCP value is included in the 8-bit Differentiated Services field within the IP headers of traffic
    • This is typically the more common QoS model and the preferred model today.
• Integrated Services – This is a QoS designation where the traffic specification part (TSPEC) and request specification part (RSPEC) help to define and classify the traffic into unique flows. This is not a common QoS model still in deployment.

In either case above, network engineers can control, on a per-hop basis, how each classification of traffic is treated along the entire network path.  While flexible and powerful, this method requires engineers to know all the various types of traffic on the network and to classify it accordingly (and ensure it is classified across all devices), which can be an arduous task and result in traffic being incorrectly classified.  In addition to the work required, as more and more applications move to SaaS available across the Internet, QoS is lost as the traffic leaves the corporate network and moves across the Internet which restricts QoS from being available from end-to-end.
Control the traffic through the application
For most of the application engineers out there, this is the “preferred method”.  Think of this as the “honor system” where some type of built-in application configuration tells the application to limit itself to X bandwidth when utilizing the network.  While undoubtedly easy to deploy, this method has no awareness of other traffic around it and no integration with network devices that send/receive traffic, which results in a more limited “one-size-fits-all” approach.

How does Skype4B fit in?

In almost all enterprise deployments, architects and engineers desire to identify the traffic produced by Skype4B and fit that traffic within the available enterprise network configurations.  Skype4B offers both of the configurations above and can be configured for one or both to suit the needs of the enterprise network.
Limit Application Sharing Bandwidth Within On-Premises Skype4B Conference Policies
This method is by far the easiest option to limiting application sharing bandwidth within Skype4B.  The only built-in method to control application sharing bandwidth is via the Conferencing Policies within Skype4B.  By default, the Global policy has no functional restriction on bitrate and is set to 50000.

Get-CsConferencingPolicy | select Identity,AppSharingBitRateKb | fl
If you decide to limit bandwidth, two approaches could be taken:

1. Alter the Global policy – while this approach is easiest, it will impact all users that don’t have a site or user policy assigned to them. As a result, you may limit users to an artificially low bandwidth in certain sites that have sufficient bandwidth.
2. Create a Site or User policy – this approach allows flexibility in deployment by tailoring bandwidth requirements to a per-site or a per-user basis. As a result, you can limit users in a low bandwidth site to a low bitrate while allowing users in high bandwidth sites to a higher bitrate.

Set-CsConferencingPolicy –Identity Global –AppSharingBitRateKb 1000

New-CsConferencingPolicy –Identity TestPolicy –AppSharingBitRateKb 1000
Limits of this approach
While the second option above is my preferred option for handling bandwidth natively within Skype4B, it does come with limits.  The biggest current limitation is that the AppSharingBitRateKb parameter is handled per-user and only is applicable to the presenter.  Where this becomes a challenge is with branch sites that have much lower bandwidth than other larger branch sites with high bandwidth.

In the figure above, when the user in Site B goes to share their desktop with the user in Site A, the effective limitation is based on the user in Site B.  With Site A limited to 1.5 Mbps, that could result in 67% of available bandwidth being consumed for a single desktop share.  When you add in the possibility of multiple users sharing desktops between the two sites, oversubscription of the 1.5 Mbps circuit becomes a very real risk.  Also of note is that this AppSharingBitRateKb behavior is applied both in P2P calls and within multiparty calls.
Impact of this approach with Lync for Mac
Through several of my deployments I’ve noticed there seems to be a significant difference with RDP performance on Mac OS clients, especially the Retina display models, when the AppSharingBitRateKb setting is reduced to a low value.  Interestingly enough, the low value doesn’t seem to impact Windows-based clients but users on Lync 2011 for Mac would report that application sharing was largely unusable.  In scenarios where there are Lync for Mac clients I would strongly suggest only using the Optimal numbers referenced in my previous post for the AppSharingBitRateKb setting.
Limit Application Sharing Bandwidth Within Skype4B Online Conferencing Policies
Sadly, this is a bit of a bait-and-switch option because it really isn’t an option at all.  Microsoft pre-creates and manages all conferencing policies within Skype4B Online and as a result you cannot create new policies or edit existing ones.  As a result of this any user accounts that are homed online are restricted to using the AppSharingBitRateKb value Microsoft has defined, which is currently 50000.  For all intents and purposes, the application sharing bandwidth is not restricted for Skype4B Online deployments so architects and engineers should carefully plan your network ingress/egress points to ensure sufficient bandwidth is available.  If bandwidth restrictions are required in Skype4B Online deployments, you must begin to examine QoS restrictions for each modality.
Limit Application Sharing Bandwidth for On-Premises Skype4B Deployments through QoS
There are a number of articles on the Internet that already talk about this overall process but it boils down to telling the Skype4B client to utilize certain port ranges for each modality and then configuring client/network devices to treat each modality in a certain way by dedicating queues (loosely equal to bandwidth) for each network hop.  The pre-requisite to all of this is that individual port ranges must be specified first.  The overall process of doing so consists of:

1. Configure port ranges for clients – Remember that each port range should be unique and not overlap. Additionally, you should have 20 ports per modality.
2. Configure port ranges for the MCUs – Remember that each port range should be unique and not overlap. Since MCUs handle modalities from multiple clients be very careful reducing the port numbers to a small number of ports per modality.  Best practices should be observed here and stick as closely to what Microsoft puts on TechNet.
3. Configure port ranges for Mediation Servers – Remember that the audio port range should be unique and not overlap any other server port ranges, such as video or application sharing. Since the Mediation Server handles all traffic to/from IP-PBXs and the PSTN, be very careful reducing the port numbers.  Best practices should be observed here and stick as closely to what Microsoft puts on TechNet.

Once port ranges are defined, the clients and servers will begin utilizing those ranges for each modality when communicating on the network.  With individual port ranges in use, architects can then begin to classify the traffic using QoS using two main methods:

1. Mark DSCP utilizing Group Policy based QoS policies on Windows clients and servers – This method is typically easiest but requires that access-layer switches trust DSCP markings coming from the endpoints. If switches aren’t configured for mls qos trust dscp, then DSCP markings will be stripped and classification is lost.
2. Mark DSCP utilizing class-map policies based off the port ranges per modality – This method requires more work to configure every access-layer switch across the enterprise to mark DSCP based on either source or destination port ranges, but is sometimes the only available option if network engineers choose not to trust client/server DSCP markings.

A typical DSCP/CoS classification of traffic is listed below:

Once you have calculated the expected application sharing bandwidth through the Lync Bandwidth Calculator for each site in your environment, network engineers can configure QoS queues appropriately to handle the expected traffic.
Limit Application Sharing Bandwidth for Online Skype4B Deployments through QoS
This method is similar to on-premises deployments but is limited because administrators cannot define the port ranges utilized for Online Skype4B deployments.  Microsoft has the following port ranges pre-created for clients that are homed Online:

Architects still have the option to utilize Group Policy based QoS policies or class-map policies, but those have two major limitations:

1. Having QoS in place mostly benefits P2P traffic – In this scenario the application sharing never leaves your corporate network so it can be controlled end-to-end.
2. Skype4B Meetings and multi-party communications lose QoS upon egressing to the Internet – In this scenario you can maintain QoS up to the point where the traffic leaves your network. This can be helpful on your network, especially for endpoints that may need to traverse the corporate WAN before egressing to the Internet, but you are still at the mercy of traffic patterns on the Internet for a great deal of the hops and thus cannot guarantee QoS end-to-end.

Despite not being able to maintain QoS end-to-end in an Online deployment, you can still classify the traffic into discrete queues to ensure the bandwidth is allocated for application sharing which in turn ensures that application sharing bandwidth doesn’t impact other traffic on your network.  Without reinventing the wheel, check out this blog post for information on configuring QoS for Online deployments.
The best option:  utilize both application limits and QoS
For every on-premises deployment out there you should absolutely be coordinating application limiting in concert with QoS.  In doing so you gain the following benefits:

1. Predictable application BW limits – by configuring the AppSharingBitRateKb parameter you ensure that a maximum amount of bandwidth will be requested by Skype4B clients
2. Predictable QoS queue utilization – by having expected bandwidth from the Skype4B team network engineers can map expected bandwidth consumption to available queues.
3. Better management through improved communication between network and application teams – this one may not seem obvious but the more the two teams talk the less chance there is of misconfiguration and the better the solution is for the end user.
   1. If queues become saturated, should the application reduce bandwidth (and potentially harm the end user performance) or should queues be increased or potentially both options?
   2. If network bandwidth increases at a site, are queues going to be increased and if so, how will that impact the configuration within the application?
   3. Based on usage patterns of existing sites, how should network engineers plan for bandwidth for new sites that come online?

Note:  There’s a number of other options here I’ve left out, but in every case the benefits are helpful to both the network team AND the application team.
For Online-only deployments, you should still utilize QoS even though you are limited in configuring the application.  Despite granular application control not being available, network engineers can still classify traffic and give a roughly-predictable utilization for each queue of traffic (application sharing included).
But what about Call Admission Control?
An astute reader would point out that Skype has Call Admission Control that can be used to restrict traffic as well, and you would be correct to say that additional control may be available.  Call Admission Control is only available for the following configurations:

1. On-premises deployments – CAC is currently not available for users that are homed Online
2. Audio/Video modalities – CAC is currently available for audio and video modalities only. Application sharing is not a supported CAC modality today.

If CAC is available for your deployment, configure it in tandem with your QoS configuration.  In fact, CAC is my preferred approach to bandwidth limits for audio and video modalities because it allows flexibility per-site AND includes reporting.  Conferencing Policy configurations of audio and video are applicable to each user regardless of where the user physically resides on the network, which can result in a user using more bandwidth than may be available if the user is travelling between sites.  Since application sharing currently isn’t supported in CAC today, architects need to utilize Conference Policies for the foreseeable future.