So far, Johan has walked us through the whole process of preparing our new Lync Server 2010 environment, step-by-step. Now it's time to expand that environment, migrate the rest of our users and legacy resources across, and start getting ready to decommission OCS 2007 R2.
In the second part of this series, we discussed how to merge the legacy OCS settings with the new Lync Server configuration. After that, we connected the Lync Server environment to the outside world using the OCS 2007 R2 Edge Server, and we did some test migrations and validated the functionality of our new deployment.
To continue with the migration progress, we will first need to prepare the groundwork before our OCS 2007 R2 Edge Server can be completely replaced; let’s have a look at how to do this now.
Add the Edge Server
As already mentioned, we are still using the OCS 2007 R2 Edge Server to connect to the outside world, and we naturally want to switch to a Lync server. So, to add the Lync Edge Server to our Lync environment, we will first need to add it to our topology, which can be done using the Topology Builder we’ve used in previous articles. Once you have the tool open, select the Download Topology from existing deployment option and choose a location to store the topology file. Next, select the Edge Pool node and pick the New Edge Pool from the Actions menu. A wizard will be launched to guide you through the process.
In the second stage of the process, you will be asked what type of Edge Server you wish to deploy. Select the Single Computer Pool and specify the internal FQDN of the Edge Server.
With the Multiple Computer Pool option, you have the ability to install multiple Edge Servers and place them in one pool, which will require a Hardware Load Balancing solution in front of the Edges, but keep in mind the expanded configuration is not supported during the migration phase.
After that, we will need to specify the features for the Edge pool where the following options can be configured:
- Use a single FQDN and IP Address
- Enable federation
- Enable NAT Translation
It is recommended to configure these features to be the same as the OCS 2007 R2 Edge Server (with one caveat, which I’ll come to in a moment), as you might lose some functionality if you forget to enable a feature (unsurprisingly). Although not recommended, you may also enable the Use a single FQDN and IP Address option, which gives you the opportunity to use a single IP and FQDN for all three Edge Services. However, this will require some changes to the default port settings of the Edge Services (By default all services are configured to use 443).
Now, about that caveat - Do not enable the federation option for your new Lync Server, because this will generate a warning during the publishing of the topology. This is due to the fact that only one federation route can be used in a deployment, and this continues to take place over the OCS Edge in our co-existent scenario.
The configuration of the FQDN and port numbers is handled in the next step. As you can see from Figure 1, you can populate the FQDNs and port numbers for each of the Lync Edge services at this gate. However, if we select the Use a single FQDN and IP Address option, the external FQDN fields for both Web Conferencing and Audio/Video will be grayed out, and the wizard would assign unique ports to the services.
In the next step, you must provide the name or FQDN of the Lync Edge server. Click Add and specify the internal IP address and FQDN which will be assigned to the Edge Server; all traffic between the Front End Server and the external world will be sent via this IP address. When the internal IP address has been specified, the wizard will then ask for the external IP addresses.
As one of the final steps, you will be asked to specify the NAT address (if you previously enabled the NAT option) - this address will be used to hide all external IP addresses. In case you’re wondering, one of the benefits of a NAT is that you will prevent the “real” IP address of the server from being exposed to the internet, and the NAT can be used to add a sort of “routing” functionality. When NAT is used together with Lync Server, the following happens:
- ChangeDST - this process changes the destination IP address on packets destined for the network that is using NAT. This NAT method is also known as transparency, port forwarding, destination NAT mode, or half-NAT mode.
- ChangeSRC - this process changes the source IP address on packets leaving the network that is using NAT. This NAT method is also known as proxy, secure NAT, stateful NAT, source NAT or full-NAT mode.
The diagram below illustrates an example network where NAT is being used:
One final remark should be made about NAT: when using a Hardware Load Balancer and an Edge Pool, NAT should not be used as it is not supported in this context.
Because all traffic will need to be sent to a Front End Server, we will need to specify the Next Hop, which will be our Lync Front End Server, but could just as easily be a Lync Director. In this case we select our Front End Server and continue with the next step.
During the next step, we will associate the Edge Server with our single Standard Edition Front End pool; Just place a checkmark and press the Finish button to close the wizard.
Once all these steps have been completed, a new object is added to the Edge pools node, and our next step is to publish our new topology. Select the root node, called Lync Server 2010, and select the Publish Topology option from the Action menu.
Before starting with the installation of the Edge Server, confirm that a DNS host (A) record already exists. This needs to be done because a DNS record will not be created automatically, which also means that we will need to export the Lync Server configuration, and then manually import it during the installation of the Edge Server. To export the Lync configuration, we will need to use the Lync Server Management Shell:
The cmdlet above will export the current configuration to a file called config.zip, which is placed in the install directory.
Copy this file to the Edge Server, and then it can imported during the installation. Finally, before starting the setup, make sure the following things are configured correctly:
- Primary DNS suffix - incorrect configuration will cause traffic to be blocked because of an incorrect name;
- Host file- as a best practice, Microsoft recommends that you use a host file to provide name resolution when no DNS server is available in the DMZ to hosts the internal zone;
- Network configuration- make sure all NICs are configured correctly. As a best practice, don’t configure a gateway on the internal NIC, but use a static route and configure DNS servers only on your external NICs.
- Certificate chain - install the certificate chain of the internal CA;
- And make sure .NET 3.5.1 is installed;
Installing the Lync Edge Server
Once all these requirements are met, you can start the setup; install Visual C++ 2008 runtime and provide the installation location. When the GUI launches, select the option Install or Update Lync Server System, which will bring you to the page we need.
As already explained in Part I, each Lync server contains a replica of the CMS - to install this local replica, start the Lync setup and then select the Install Local Configuration Store option.
The setup will prompt you for the config file which we just exported; select the file using the Browse button, and then press Next to start the installation of the Local Configuration Store. Once this installation has been finished, it’s time for the next step: Setup or Remove Lync Server Components.
During this step, the necessary components for the Edge Server will be installed, and upon completion, we can continue with the certificate part of the installation.
For the Edge Server, this is a bit different than for the Front End Server. Because the Edge Server is connected to the internet on the external network interface, we typically require certificates issued by publicly trusted third party Certificate Authorities such as Digicert or Verisign. Here’s a quick overview of which certificates are needed:
Subject Alternate Name (SAN)
As you can see, we only need one external certificate for the Edge Server. The A/V Edge can have an internal certificate if you have an internal CA, otherwise you should assign a separate external certificate to the A/V Edge.
Because this process is almost the same for both certificates, we will only describe it once for the external interfaces, because this is the most complicated process. First expand the External Edge certificate entry and uncheck the A/V Edge external option:
Press the Request button to start the wizard, which will guide you through the process of creating a Certificate Signing Request (CSR). Select the option to Prepare the request now, but send it later, and then press Next. Provide a location to store the CSR file, which ultimately needs to be sent to the CA. The next step is optional, and is only needed when you want to use a different certificate template (By default the WebServer certificate template is used).
In this optional step, you will be able to specify the Friendly Name which can be used to easily recognize the certificate. Additionally, you can mark the certificate as exportable, which will give you the opportunity to export the certificate, including private key. This option is only required when you want to install the same certificate on multiple servers or in a load balancing environment.
Provide the company and geographical information, and then we will arrive at the Subject Name/Subject Alternate Names page. This page already contains the correct FQDN (if properly configured using the Topology Builder), so press Next which will bring you to the page where you can configure the SIP Domains. In our case, this is only corp.local, so we can place a checkmark and press Next. The last stage of this process will give you the option to add an additional SAN entry, which is not necessary in most cases. Continue with the wizard, have a look at the summary, and then save the CSR.
Repeat this process for the other certificates; the only difference is the choice of a CA to submit the CSR (The one just created will be submitted to an external CA.)
Once all certificates are requested and have been received, it’s time to install the certificates, which can be done by pressing the Import Certificate button. Select the certificate using the Browse button, and uncheck the Certificate file contains certificate’s private key option. Repeat this process for all certificates.
Now that all certificates have been imported, it’s time to assign them to the services; press the Assign button and follow the steps of the wizard.
The wizard will give an overview of the installed certificates. To get started, select the correct certificate and press Next to continue. Review the summary, which describes the certificate, and wait till the certificate has been assigned. Keep in mind to highlight the correct options when assigning the certificate to the external Edge Services: Access and Webconference as one pair (figure 5), and A/V separately. When finished, you will see that the status of all certificates has been changed to assigned.
Now everything is configured correctly, and we can start the services by selecting the Start Services option.
Once all services are started, you should see the as the screen above (figure 5). You might want to check if all services are really started using the services MMC.
Migrating all other users
Due to the fact that we want to reuse a number of external FQDNs, we shall need to first migrate all other users from OCS 2007 R2 to Lync Server. After the users have been migrated, we can make a configuration change so that the new Edge Server will be used.
To migrate the users, we can use the same steps as described in part II of this series, but to speed up the process a little bit we will move migrating all users at once, rather than just test cases. This can be done using the same methods as described in that earlier article, so let’s first have a look at the Lync Server 2010 Control Panel.
Open the Lync Server Control Panel and select the Users menu option. Create the legacy user filter again to search for all OCS 2007 R2 users, and then select Action followed by Move all users to pool…
Next, select the OCS 2007 R2 Front End Server as Source registrar pool and the Lync Server 2010 Front End Server as Destination registrar pool. Finally, click the Move button to migrate all users from OCS 2007 R2 to Lync Server 2010. Once this process is completed, you shouldn’t see any legacy user when performing the same search.
However, there is another, quicker method using the Lync Server Management Shell:
This cmdlet will first perform a search for users which are hosted on OCS, and then move those users to Lync Server.
As you can see in figure 7, you are prompted for confirmation before the actual move happens; in this case we can answer with A to migrate all users.
You might think that, since all of our users have been migrated, our OCS 2007 R2 Edge Server can be removed? Wrong, I’m afraid. Before decommissioning the legacy server, we need to reconfigure our environment (which will be discussed in Part 4 of this series).
So for now we will continue to use our OCS 2007 R2 Edge Server and first migrate the response groups and dial-in features.
Migrating Response Groups
Before you can migrate the response groups from OCS 2007 R2 to Lync Server, you must first install the SQLCLI.MSI from the Feature Pack for SQL 2005 – December 2008. Keep in mind that after the update has been installed, you will need to reboot the server. Once the update for the SQL Client is installed, open the Lync Server Management Shell on the Lync Front End Server. To migrate the Response Group Configuration, we will need to use the Move-CsRgsConfiguration cmdlet, which will migrate all current Response Groups to Microsoft Lync Server 2010:
By default nothing is displayed; if you would like to see what is really happening, append the –v parameter to the cmdlet to enable verbose logging.
To confirm that the migration completed successfully, open the Lync Server Control Panel and check if the response groups are listed on the Response Groups page. If you prefer scripting, another method is to use the following cmdlets via the Lync Management Shell:
- Get-CsRgsAgentGroup - to display all agent groups
- Get-CsRgsQueue - to display all queues
- Get-CsRgsWorkflow - to display all workflows
If you are having informal agents assigned to groups which used the tabs.xml file in OCS 2007 R2, remove this file and point the users to the new response groups website. The URL of this website is, in this example: https://lync-fe.corp.local/RgsClients/Tab.aspx. As soon as the client software has been migrated, the user can easily go to this page via the Tools menu.
Migrating Dial-In Access
Next up, it’s time to migrate the dial-in access features from OCS to Lync Server. The first step is to identity the currently configured dial-in access numbers. To do this, you will need to start the Admin console for Office Communications Server 2007 R2 , get the properties of the forest, and then select Conferencing Attendant Properties, which will open the following window:
In this case only one access number is configured; select that number and click on the Edit button.
Write down the value of the SIP URI, as this is needed to migrate the access number. Repeat this step for each access number which is associated to the pool which you would like to migrate, and once you have completed this, we can continue with the next step: the actual migration.
To migrate the access number from the OCS 2007 R2 pool to the Lync Server 2010 Pool, we will need to use the Lync Server Management Shell and the Move-CsApplicationEndpoint cmdlet. The access number can be migrated using the following parameters:
There are two parameters which you need to specify: Identity, which is the SIP URI from the access number, and Target, which is the FQDN of the Lync Server 2010 pool.
To confirm that the number has been migrated to the new pool, check the Lync Server Control Panel or the Lync Server Management Shell. To use The Lync Server Control Panel:
- Start the Lync Server 2010 Control Panel;
- Select the Conferencing option;
- Go to the Dial-in Access Number tab;
- Check if the access number is listed.
Alternatively, if you’d like to use the Lync Server Management Shell:
- Run Get-CsApplicationEndPoint –Identity SIP-URI
Repeat these steps for each access number. As a final check, you can dial in to the access number(s) and check if it works.
In this third article discussing the migration from OCS 2007 R2 to Lync Server 2010, we’ve seen how to expand our Lync Server environment and migrate the remaining legacy resources. This included introducing a Lync Server 2010 Edge Server to our new Lync deployment, migrating the remaining users, as well as the response groups and the dial-in access numbers.
Keep in mind: You can’t switch off the old environment yet, as it still is being used.
In the next article we will reconfigure the federation route used by our Lync environment, and then we will continue with removing the OCS 2007 R2 pool. As a bonus, we will have a look at some nice additional features which can be added to our Lync Server 2010 deployment, and also some gotchas you need to know about when migrating.