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:
- 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.
- 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.
- 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
- On the Skype for Business Server 2019 Front End server, open the existing topology in Topology Builder.
- In the left pane, navigate to the site node, which is located directly below Skype for Business Server.
- Right-click the site, and then click Edit Properties.
- In the left pane, select Federation route.
- Under Site federation route assignment, clear the Enable SIP federation check box to disable the federation route through the legacy environment.
- Click OK to close the Edit Properties page.
- From Topology Builder, select the top node Skype for Business Server.
- From the Action menu, click Publish Topology.
- 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
- In the left pane, navigate to the legacy install node and then to the Edge pools node.
- Right-click the Edge server, and then click Edit Properties.
- Select General in the left pane.
- Clear the Enable federation for this Edge pool (port 5061) check box and select OK to close the page.
- From the Action menu, select Publish Topology, and then click Next.
- When the Publishing wizard completes, click Finish to close the wizard.
- Verify that federation for the legacy Edge server is disabled in Topology Builder.
Configuring the certificates on the legacy Edge Server
- Export the external Access Proxy certificate, with the private key, from the legacy Edge Server.
- On the Skype for Business Server 2019 Edge Server, and import the Access Proxy external certificate from the previous step.
- Assign the Access Proxy external certificate to the Skype for Business Server 2019 external interface of the Edge Server.
- 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
- From Topology Builder, in the left pane, navigate to the Skype for Business Server 2019 node and then to the Edge pools node.
- Right-click the Edge server, and then click Edit Properties.
- Select General in the left pane.
- Select the check box for Enable federation for this Edge pool (port 5061), and then click OK to close the page.
- From the Action menu, select Publish Topology, and then click Next.
- When the Publishing wizard completes, click Finish to close the wizard.
- Verify that Federation (port 5061) is set to Enabled in Topology Builder.
Updating Skype for Business Server 2019 Edge Server federation next hop
- From Topology Builder, in the left pane, navigate to the Skype for Business Server 2019 node and then to the Edge pools node.
- Expand the node, right-click the Edge Server listed, and then click Edit Properties.
- On the General page, under Next hop selection, select from the drop-down list the Skype for Business Server 2019 pool.
- Click OK to close the Edit Properties page.
- From Topology Builder, select the top node Skype for Business Server.
- From the Action menu, click Publish Topology and complete the wizard.
Configuring Skype for Business Server 2019 Edge Server outbound media path
- 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.
- Right-click the pool, and then click Edit Properties.
- In the Associations section, select the Associate Edge pool (for media components) check box.
- From the drop-down box, select the Skype for Business Server 2019 Edge Server.
- Click OK to close the Edit Properties page.
Turning on Skype for Business Server 2019 Edge Server federation
- From Topology Builder, in the left pane, navigate to the Skype for Business Server 2019 node and then to the Edge pools node.
- Expand the node, right-click the Edge Server listed, and then click Edit Properties.
- 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.
- On the General page, verify that the Enable federation for this Edge pool (Port 5061) check box is selected.
- Click OK to close the Edit Properties page.
- Navigate to the site node.
- Right-click the site, and then click Edit Properties.
- In the left pane, click Federation route.
- Under Site federation route assignment, select Enable SIP federation, and then from the list select the Skype for Business Server 2019 Edge Server listed.
- Click OK to close the Edit Properties page.
- For multi-site deployments, complete this procedure at each site.
Publishing Edge Server configuration changes
- From Topology Builder, select the top node Skype for Business Server.
- From the Action menu, select Publish Topology and complete the wizard.
- Wait for Active Directory replication to occur to all pools in the deployment.
Note: You may see the following message: Warning: The topology contains more than one Federated Edge Server. This can occur during migration to a more recent version of the product. In that case, only one Edge Server would be actively used for federation. Verify that the external DNS SRV record points to the correct Edge Server. If you want to deploy multiple federation Edge Server to be active concurrently (that is, not a migration scenario), verify that all federated partners are using Skype for Business Server. Verify that the external DNS SRV record lists all federation enabled Edge Servers. This warning is expected and can be safely ignored.
Configuring the Skype for Business 2019 Edge Server
- Bring all of the Skype for Business Server 2019 Edge Servers online.
- 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.
- Stop the Skype for Business Server Access Edge from each Edge Server computer.
- From each legacy Edge Server computer, open the Services applet from the Administrative Tools.
- In the services list, find Skype for Business Server Access Edge.
- Right-click the services name, and then select Stop to stop the service.
- Set the Startup type to Disabled.
- 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
- In Topology Builder, right-click the top node Skype for Business Server, and then click Edit Properties.
- Select Simple URLs in the left pane, then below Meeting URLs: select the Meet URL and then click Edit URL.
- Update the URL to the value you want, and then click OK to save the edited URL.
Updating the Admin simple URL
- In Topology Builder, right-click the top node Skype for Business Server, and then click Edit Properties.
- 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:
- Verify the conferencing policy that is assigned to them.
- 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.
- 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!