Solutions in this chapter:
Organizations that currently have Live Communications Server (LCS) 2005 and want to upgrade to Office Communications Server (OCS) 2007 have a defined upgrade path to follow. That path is simple, primarily because there is only one way to upgrade: Use the “side-by-side” method of migration. There is no in-place upgrade option of putting a CD into the old server and performing an upgrade. To perform a side-by-side upgrade, you must have a new OCS 2007 server set up and working; then you need to migrate user accounts and configure settings on the new OCS 2007 environment, and then decommission the old LCS 2005.
However, the migration process isn’t as simple as replacing each LCS 2005 server one for one with a new OCS 2007 server. If it were that simple, I wouldn’t have anything to write about in this chapter. Because the path for migration is well defined and has little flexibility, following the procedures outlined in this chapter will ensure a successful migration from LCS 2005 to OCS 2007.
To migrate from LCS 2005 to OCS 2007 you must follow a specific sequence of steps. Understanding this sequence is important. For example, if you upgrade an existing Microsoft Office Communicator (MOC) client to the new 2007 edition, the user will not be able to access LCS 2005 because MOC 2007 is incompatible with LCS 2005. Similarly, if you move a user to OCS 2007 and enable enhanced presence for that user, he won’t be able to access his account with the old MOC 2005 client software because enhanced presence requires the MOC 2007 client.
As I’ve mentioned, planning and then executing a migration from LCS 2005 to OCS 2007 requires specific steps that you need to follow in a prescribed order. The first step is to plan for the migration and make sure you have the proper sequence for migration, that you’ve performed all prerequisites before migrating, and that you enable features at the right time so that you don’t get ahead of yourself during the migration process.
When you are upgrading from LCS 2005 to OCS 2007, because there is no in-place upgrade that will allow you to simply insert a CD into a server and upgrade a system all at once, LCS 2005 servers and OCS 2007 servers will coexist in your environment at some point. The question is whether the two environments will coexist for a short period specifically to migrate users from one environment to the other, or whether the coexistence will last for a lengthy period. The choice is a matter of feasibility and comfort factor in terms of performing the cutover.
It is unlikely that an organization with dozens of LCS 2005 servers spread around the world will be able to migrate all of its servers and potentially hundreds or thousands of its users all at once. The reality that it “just takes time” to get around to a large number of users dictates that a long coexistence will likely occur for this organization’s migration process. However, an organization with a single server and, say, 50 users could have a short coexistence time frame, and could migrate entirely from LCS 2005 to OCS 2007 in an evening or a weekend.
Even organizations with a limited number of servers that could migrate from LCS 2005 to OCS 2007 in a short period may choose to migrate over a long period, methodically putting in new OCS 2007 servers and testing all aspects of the new installation before migrating users to the new environment, and most certainly before decommissioning an older LCS 2005 server.
Fortunately for you, nothing is forcing you to migrate slowly or quickly; that decision is entirely up to you. No doubt, there will be both LCS 2005 and OCS 2007 servers in your environment because the migration process is a side-by-side migration. However, you can keep the old LCS 2005 servers in place for a long time if you want.
Most administrators who have many servers to migrate tend to start conservatively in that they leave the old LCS 2005 environment running for a lengthy period after they have implemented OCS 2007. However, over time, these administrators become more comfortable with the migration process and tend to drop the LCS 2005 systems off the network soon after they have an OCS 2007 replacement server in place.
The only real decision to make is to not drop the old LCS 2005 server if users still depend on it to access their IM and communications services, or if it is being used to route messages or communications for the environment. You should decommission the server only when the organization truly is no longer using it. I will cover how to validate that your LCS 2005 server is no longer being used before you remove it in the “Removing LCS 2005 from the Network Environment” section later in this chapter.
If you decided on a short coexistence migration path from LCS 2005 to OCS 2007, you can take the “big bang” approach for migration. If you decided on the long coexistence migration path, you can follow a phased migration approach.
With a “big bang” migration, you migrate the entire organization from LCS 2005 to OCS 2007 all at once; as such, you don’t have to worry that some people will be using LCS 2005 and others will be using OCS 2007. Also, you don’t have to extensively test the cross-communication between the LCS 2005 servers and the OCS 2007 servers. Once you add the new OCS 2007 servers and migrate the user information to them, you can give the new servers the same IP address as the old servers and users can launch their client software and access the OCS 2007 environment without even knowing the environment was upgraded.
If your organization has dozens of LCS 2005 servers around the world, it likely won’t be feasible to get to all of the servers and the hundreds, if not thousands, of client systems to upgrade all users simultaneously. In the phased migration, your organization would typically migrate server by server and site by site in an orderly and timely manner. Specific users will be migrated from LCS 2005 to OCS 2007 in groups. The groups will typically reside on specific servers. And servers within one site will be migrated before you move on to the next site.
A key to performing a phased migration is that you cannot easily enable certain features that are available in OCS 2007 (such as one-to-many video conferencing or Voice over IP [VoIP] telephony) until all users in the organization have been upgraded to OCS 2007. You can have some users have these new features and other users not have these features; however, users become confused when they can videoconference and have telephony conversations with some users and not with others. So, a best practice is to wait until all users have been moved to OCS 2007 and have had their client software upgraded from MOC 2005 to MOC 2007, before you turn on the new features of OCS 2007.
Besides migrating servers and user accounts from LCS 2005 to OCS 2007, you will also need to choose the right time to migrate from MOC 2005 to MOC 2007. The first thing you need to know is that MOC 2007 won’t work in an LCS 2005 environment, so it is clear that the client software migration will not happen until after you migrate your servers to OCS 2007.
Because the MOC 2005 client will run against a new OCS 2007 server, you may think that keeping the MOC 2005 client and not migrating to the new MOC 2007 client will make the migration easy because you won’t have to touch user desktops. However, if you don’t plan to migrate to the MOC 2007 client, you shouldn’t waste your time migrating the front-end servers to OCS 2007 in the first place. Most likely, you are migrating from LCS 2005 to OCS 2007 to get the new features in OCS 2007. And you cannot take advantage of those new features until you actually have the users running the MOC 2007 client. So, you will need to migrate the client systems from MOC 2005 to MOC 2007; the decision is really a matter of “when.”
One approach for migrating the client is to migrate the user’s system from MOC 2005 to MOC 2007 as soon as the user’s account is migrated from LCS 2005 to OCS 2007. Effectively, the migration is performed in groups, whereby a group of 50 user accounts is migrated from LCS 2005 to OCS 2007, and then the client systems are migrated from MOC 2005 to MOC 2007. Once that grouping of 50 has been migrated, select the next group of 50 users to migrate from LCS 2005 to OCS 2007, and then migrate those users’ client software.
This approach of migrating small groups of users to the MOC 2007 client is typically selected for organizations that expect the migration process to take awhile (i.e., there are hundreds, if not thousands, of users to migrate). Rather than waiting several weeks or months until the final user has been migrated, stage the migration such that groups of users can gain access to the new features of OCS 2007 relatively soon after their account has been migrated from LCS 2005 to OCS 2007.
The other approach is to migrate all accounts from LCS 2005 to OCS 2007, and once all of the accounts have been migrated, then have a phase in the migration process during which all of the user systems are upgraded from MOC 2005 to MOC 2007. This method effectively has the entire organization wait until all LCS 2005 server data has been migrated to OCS 2007, and then all users are migrated at the same time. This is feasible for an organization with a limited number of users in which the time it takes to migrate accounts and install the new MOC 2007 software on client systems isn’t necessarily lengthy. This may also be selected if the organization wants consistency, whereby everybody in the organization has the same client software and access to the same features.
Some Independent Advice
The real decision of whether to migrate groups of users to the new MOC 2007 client versus waiting until you can switch all users to the new MOC 2007 at the same time comes down to how your users communicate. If your IM traffic is purely group or department based migrating smaller groups of users to the new MOC 2007 client will work. However, if your entire organization intercommunicates, and users get antsy and want to try out features of the new MOC 2007 client, you should wait to switch over the client software until all users can have access to the same client software features. Because the MOC 2007 client does a lot more than its predecessor, users will become frustrated if they try to use a feature in their client software that someone else in the organization doesn’t have access to.
As mentioned at the start of this chapter, the key to migrating from LCS 2005 to OCS 2007 is to follow a methodical process. The process begins by making sure you understand your existing LCS 2005 environment so that when you perform the migration, you are migrating all of the servers and server roles from LCS 2005 to OCS 2007. If you forgot you had an LCS 2005 server hosting users and you do not include that server in your migration plan, you may forget to migrate the users on that LCS 2005 system.
The first step in the planning process is to identify which servers in the organization are running LCS 2005, where the servers are located, and what server roles are currently installed on the systems. The server roles would identify whether the system is an access proxy server on the perimeter, a director server in the organizational network, or a front-end server hosting user accounts.
Note
Director Servers are noted throughout this chapter as optional server systems. If your organization has existing LCS 2005 Director Servers, they would be migrated to OCS 2007 Director Servers just as the replacement of other server roles being migrated from LCS 2005 to OCS 2007.
Identifying existing LCS 2005 servers is a relatively simple process. By accessing the LCS 2005 Administrative tool, you can see a list of servers associated with the organization’s LCS 2005 environment. Specifically, the process to identify existing LCS 2005 servers is as follows:
Log on as an administrator to an LCS 2005 server in the environment.
Launch the LCS 2005 Administrative tool.
Expand the control tree so that you can see the Live Communications servers, archiving servers, and proxy servers, as shown in Figure 11.1.
Note the names of all of the LCS 2005 servers that the Administrative tool has identified.
Identify the location of each server (which might require asking someone in the organization, checking what IP subnet the server is on, or physically looking for the server) as well as note which domain the server(s) resides in. This information will help you map out your plan to make sure you migrate all existing servers in the right order.
Once you have a list of the LCS 2005 servers, create a table listing their server roles. This will help you group the servers into logical blocks of systems so that you can migrate them from LCS 2005 to OCS 2007 in the proper sequence. OCS 2007 adds new server roles to account for its new functionality, such as Web conferencing and VoIP telephony. However, for IM or presence, or for Public IM Connectivity (PIC), those servers can be mapped one for one between LCS 2005 and OCS 2007, and will likely identify the migration grouping you will use to migrate servers from LCS 2005 to OCS 2007.
Table 11.1 lists the server roles in LCS 2005 and OCS 2007. A couple of the server roles have changed in name or function, and new servers have been added to OCS 2007 and will be referenced accordingly through the balance of this chapter.
Table 11.1. Server Roles in LCS 2005 and OCS 2007
Server Role | LCS 2005 SP1 | OCS 2007 |
|---|---|---|
Perimeter server | Called access proxy | Called edge server |
Director | X | X |
Front-end server | X | X |
Archiving server | X | X |
Communicator Web access | X | X |
Standard Edition front-end server | X | X |
Enterprise pool front-end server | X | X |
Address Book server | X | No longer a separate role |
Web conferencing server | X (can be colocated on the front-end server) | |
IM conferencing server | X (can be colocated on the front-end server) | |
Audio-video conferencing server | X (can be colocated on the front-end server) | |
Mediation server | X | |
Quality of Experience Management server | X |
With the physical LCS 2005 servers identified and their roles documented, the next step is to confirm the communications path for both incoming and outgoing communications between the LCS 2005 servers. As much as it might seem obvious that communications flow from the client, to the front-end server, to the director, to the access proxy, amazingly I’ve found that some organizations have director server roles that are completely bypassed in the flow of messages. Somebody put in a director server and never properly configured the front-end server to communicate with the director, so messages actually flow from the front-end server directly to the access proxy.
To check the flow of communications look at the configuration of each server to determine their settings. Do the following for each LCS 2005 server in your environment:
As an administrator, from the LCS 2005 Administrative tool right-click on each LCS 2005 front-end server, choose Properties, and click on the Routing tab to view the outbound connection routes of each server, as shown in Figure 11.2.
Write down the routing configuration information for each front-end server.
Right-click on each LCS 2005 director server (if you have them in your LCS 2005 environment) and choose Properties, and then click on the Routing tab to view the outbound connection routes of each director server.
Write down the routing configuration information for each director server.
Right-click on each LCS 2005 access proxy server, choose Properties, and click on the Routing tab to view the outbound connection routes of each server.
Write down the routing configuration information for each access proxy server.
Note
The changes between LCS 2005 and OCS 2007 made it easier to set up firewall rules for communications to OCS 2007 servers. Whereas LCS 2005 used a proprietary port 5061 for communications, OCS 2007 uses port 443. Those configuring OCS 2007 will find it much simpler to set it up for communications.
Now, with a good understanding of the front-end, internal, and perimeter server infrastructure configuration of LCS 2005, the next step is to understand the client side of LCS 2005. First you need to determine which users are on which server in the LCS 2005 environment. When you pick your pilot users to migrate from LCS 2005 to OCS 2007, you want to know where to find the users so that you can easily migrate them to OCS 2007. Likewise, if you are going to be doing a phased migration from LCS 2005 to OCS 2007 and will be migrating users by departments, workgroups, sites, or roles, you’ll need to know where the users reside in LCS 2005 so that you can choose those users and migrate them to OCS 2007 in a logical manner.
Identifying users and their associated servers is easy because you will see the users when you go into the LCS 2005 Administrative tool, and when you click on each server you will see the users associated with each front-end server. The specific process is as follows:
While logged in as an administrator and in the LCS 2005 Administrative tool, expand the console tree and expand the tree for each front-end server.
Select the Users container that is under each front-end server in the tree. You will see in the right-hand pane a list of users associated with the front-end server, as shown in Figure 11.3.
Another best practice during the existing LCS 2005 assessment and planning phase is to understand how you will be able to push out the new MOC 2007 client to replace the existing MOC 2005 client software. If you have a product such as Systems Management Server (SMS) 2003 or System Center Configuration Manager (ConfigMgr) 2007, you can easily create a scripted process that will uninstall the existing MOC 2005 client and install the new MOC 2007 client in its place.
Some organizations that use Active Directory Group Policies for software distribution can create and push a package via a software distribution Group Policy during a user’s logon process. Other third-party tools exist for updating the client as well. Or, if your organization does not have any automated tools and usually visits desktops and laptops manually to uninstall and install software, you need to take into account the time required to access all systems that will be migrated from LCS 2005 to OCS 2007 that will need their client software eventually migrated as well.
Having an automated software distribution system will enable you to more quickly migrate from MOC 2005 to MOC 2007 and ultimately will provide a more automated path to shift users from LCS 2005 to OCS 2007 to take advantage of the new capabilities of OCS 2007.
Armed with information about your existing LCS 2005 environment, you now need to design your new OCS 2007 environment to include the replacement of old LCS 2005 server roles with corresponding OCS 2007 server roles. And assuming that you will be taking advantage of the new capabilities of OCS 2007, such as Web conferencing and VoIP telephony, the design and architecture of the new OCS 2007 will likely include even more server roles, functions, and features.
The design of OCS 2007 in a migration from LCS 2005 to OCS 2007 is similar to the design of a brand-new installation of OCS 2007. For more information, refer to Chapter 2, which covers the design of OCS 2007.
The last step when planning an LCS 2005 to OCS 2007 migration is to determine how quickly you’ll be migrating to OCS 2007. It is always preferable to keep the coexistence between LCS 2005 and OCS 2007 to a minimum. With some users on OCS 2007 and others not, those that are on OCS 2007 cannot utilize its new capabilities until everyone in the organization has been migrated to OCS 2007 and is using the MOC 2007 client. So, do what is necessary to make the migration timeline as quick as possible!
An organization with one LCS 2005 server and 50 users can do a “big bang” migration for the entire organization because the scope of the migration is limited to a single server and a handful of users. An organization with dozens of LCS 2005 servers and hundreds of users will likely perform a phased migration.
Migrating from LCS 2005 to OCS 2007 is an “outside-in” process, meaning that servers on the perimeter are migrated first, then intermediary servers are migrated, then front-end servers, and finally user client software. Servers are fully backward-compatible, so perimeter and intermediary servers can be migrated early and will allow existing LCS 2005 servers to interoperate and communicate with the new servers. This drastically minimizes the downtime for clients, as servers can be upgraded without impacting user communications.
With this in mind, first we are going to migrate the access proxy servers in LCS 2005 that will be replaced by OCS 2007 edge servers. Because migration from LCS 2005 to OCS 2007 is a side-by-side process, a new OCS 2007 edge server is added to the network first, properly configured to routing information in and out of the network environment. Once the system is working properly, the final switchover of communications is done to the edge server.
Because all OCS 2007 servers use the domain name system (DNS) to find and communicate with other servers, the first step in upgrading perimeter servers is to make sure DNS is set up and configured properly to support the new OCS 2007 edge server system. You need to configure three groupings of DNS settings:
Set internal DNS so that LCS 2005 director and front-end servers can route outbound messages through the new OCS 2007 edge server.
Set external DNS so that inbound messages can find the OCS 2007 edge server to route inbound messages through the new server.
Change the fully qualified domain name (FQDN) external route for communications to formally route public IM information and federated IM communications through the new OCS 2007 edge server.
All of these configuration settings require a properly configured DNS name and IP address on a zone such that users or servers can find the servers they are to connect to. For example, if a user needs to access a server for IM, the FQDN of the server the user needs to access must be published externally for the user to access the server externally. However, if the user only needs to access the server from within the organization’s firewall, the server only needs to be published in the organization’s Active Directory for the user to find the server.
Likewise, if an internal server needs to route messages to an edge server in the perimeter, the edge server and its corresponding IP address and DNS name need to be published internal to the network. And if an edge server needs to communicate with an internal OCS 2007 server, although the organization likely won’t publish the DNS name of the internal server to mask the server for security purposes, the IP address of the internal server needs to be accessible from the edge server.
Note that OCS 2007 uses Secure Sockets Layer (SSL; port 443) for encrypted communications between servers instead of the proprietary port 5061 that was used for LCS 2005. For all external access from clients either using Office Communicator or Live Meeting, the servers these users will access for communications to OCS 2007 need to now have port 443 opened on the firewall to provide the proper flow of communications.
Because the key to any communications that are external to an organization is to ensure that the communications are secure, the use of certificates was standard with LCS 2005 for federated communications or with remote LCS 2005 clients. When replacing servers from LCS 2005 to OCS 2007, you need to transfer the certificates. Because certificates are keyed to server names, if you keep the same server name for the new OCS 2007 server as the old LCS 2005 server, you can simply export the key from LCS 2005 and import it into the OCS 2007 server with the same name. If you add a new OCS 2007 server with a completely different name, you will need to request a new certificate that matches the new server name.
Some Independent Advice
The decision to reuse an existing server name (and thus preserve the existing certificate) versus creating a brand-new server name for OCS 2007 is a matter of simplicity in issuing certificates. If your organization depends on an external certification authority (CA; such as Verisign, Thwart, or Chosen) and pays for certificates to be issued, you will likely want to use the same name for your new edge server as you used for your access proxy. Using the same server name will allow you to export your certificate from LCS 2005 and import it into OCS 2007.
However, if you have your own internal PKI setup where you can issue your own certificates relatively easily, you can choose a new server name and insert a new secured server to your OCS 2007 environment.
You can issue certificates to the new OCS 2007 server in one of two ways: have a new certificate issued to OCS 2007; or have an old LCS 2005 certificate exported so that it can be imported into OCS 2007. The two methods are detailed in the following sections.
If you will be using the same server name for OCS 2007 as one of the LCS 2005 servers that currently exist, export the certificate from LCS 2005 and import it into OCS 2007. To do that, follow this procedure:
Log on as an administrator to the LCS 2005 access proxy system from which you plan to export the certificate.
Click Start | Run, type mmc, and click OK.
From the MMC program, click File | Add/Remove Snap-in.
On the Add/Remove Snap-in dialog box, click Add.
Scroll down and highlight Certificates, as shown in Figure 11.4, and then click Add.
When prompted with “This snap-in will always manage certificates for:” select Computer account, and then click Next.
When prompted to select a computer to manage, choose Local computer, and then click Finish.
Click Close to close the snap-in page, and then click OK to get back to the MMC program view.
Expand the Certificates (Local Computer) branch of the tree, and then expand the Personal branch.
Right-click the certificate that you want to export from the LCS 2005 access proxy server, select All Tasks, and then select Export.
From the Certificate Export Wizard, click Next past the Welcome page.
On the Export file format page, click Personal Information Exchange –PKCS #12 (.PFX) and select Include all certificates in the certification path if possible, deselect the Enable strong protection, and then click Next.
Type in a path and filename where you want to export the certificate, such as c:LCS-Proxy1 (a .cer extension will automatically be added to the end), and then click Next.
Click Finish to export the certificate.
Once you have exported the certificate from the LCS 2005 server, you need to install a new OCS 2007 server as an edge server into the organization (we cover this process in the following section). Because the goal is to have the new server have the same name as the old server, you will need to uninstall the old LCS 2005 server prior to installing the new OCS 2007 server. This is tricky, as you don’t want to drop an LCS 2005 server until you know the new OCS 2007 server is working properly. This is why this process of exporting and importing certificates is usually done when an organization has more than one LCS 2005 access proxy system and can easily afford to uninstall one LCS 2005 access proxy to build up a new OCS 2007 edge server when it has other LCS 2005 access proxy systems actively routing inbound and outbound communications.
Assuming that you have more than one LCS 2005 access proxy and have been able to export the certificate and then uninstall LCS 2005 from the system to remove it from the organization, you can now install the certificate into the new OCS 2007 system. To import the old LCS 2005 access proxy certificate to the new OCS 2007 edge server, do the following:
Log on as an administrator to the OCS 2007 edge server system that you plan to import the certificate.
Launch Microsoft Office Communications Server 2007 (select Start | All Programs | Administrative Tools | Office Communications Server 2007).
Expand the console page and highlight the OCS 2007 edge server, then right-click and choose Certificates.
When the Certificate Wizard begins, click Next past the Welcome screen.
For the Available Certificate Tasks page, choose Import a certificate from a .pfx file, as shown in Figure 11.5, and then click Next.
Enter the name of the certificate that you saved when you exported the LCS 2005 certificates in the “Exporting a Certificate from LCS 2005” section earlier, and then click Next.
When prompted for the password associated with the exported certificate, enter the password and click Next.
Verify that you have all the parameters set, and then click Finish.
If you are creating and installing a new OCS 2007 edge server and will be using a new server name on the network, follow the installation and configuration directions in the next section of this chapter. Then perform the following steps to create and install a new certificate to this new OCS 2007 edge server:
Log on as an administrator to the OCS 2007 edge server system that you plan to import the certificate.
Launch Microsoft Office Communications Server 2007 (select Start | All Programs | Administrative Tools | Office Communications Server 2007).
Expand the console page and highlight the OCS 2007 edge server, then right-click and choose Certificates.
When the Certificate Wizard begins, click Next past the Welcome screen.
For the Available Certificate Tasks page, choose Create a new certificate, then click Next.
Select Send the request immediately to an online certification authority, and then click Next.
On the Name and Security Settings page, change the friendly name if you want, leave the bit length to 1024, select the Mark cert as exportable checkbox so that it looks something like Figure 11.6, and then click Next.
Enter the name for the organization and the organizational unit, and click Next.
For subject name and subject alternate name, make sure the subject name matches the FQDN of the OCS 2007 edge server that is published by the internal firewall, and then click Next.
Enter your country/region, state/province, and city/locality, and then click Next.
Review the Request Summary page and make sure everything is correct, and then click Next and then Finish.
Once you have DNS configured and the certificates are ready for the new OCS 2007 edge server(s), you need to install the OCS 2007 edge server with the proper settings to provide inbound and outbound communications. Chapter 5 covers the installation of an OCS 2007 edge server, so we won’t discuss it here.
Continue with the OCS 2007 edge server installation process until you reach the Enable Features on Access Edge Server page. Then proceed with the following:
On the Enable Features on Access Edge Server page, choose the components that you want to enable on the OCS 2007 server. To enable remote users to use this OCS 2007 edge server to view presence status and exchange IMs, you need to select the Allow remote user to access your network checkbox. To enable users to federate or communicate with a public IM provider (e.g., Yahoo! Messenger, AOL Messenger, or MSN Messenger), choose the Enable federation checkbox.
When you select the Enable federation checkbox to do public IM, select the Federation with selected public IM providers checkbox, and then select the IM providers (AOL, Yahoo!, MSN) that you want to federate with. Click Next.
If you are using an LCS 2005 director, on the FQDN of the Internal Next Hop Server page enter the full DNS name of the LCS 2005 director server. If you are not using an LCS 2005 director, just enter the LCS 2005 server name of the system that is the next hop.
For each Session Initiation Protocol (SIP) domain in your organization, on the Authorized Internal SIP Domains page enter the name of the SIP domain, click Add, and then click Next.
For Authorized Internal Servers, specify each internal server that you want to have connectivity to your OCS 2007 edge server, and then click Next.
If your settings are correctly summarized, click Next and then Finish.
Once you have the edge server installed, return here to continue the migration process from LCS 2005 to OCS 2007.
Once the new OCS 2007 edge server has been installed, it is actually doing nothing on the network. Because no inbound or outbound servers acknowledge that this new server exists, the server is effectively installed, but not processing any communications. When choosing to switch over inbound or outbound communications to the edge server, the standard process is to switch over outbound communications to the new OCS 2007 edge server. You do this by directing the outbound communications from an LCS 2005 director server or an LCS 2005 front-end server.
When you make a relatively simple configuration change on either the LCS 2005 director or the LCS 2005 front-end server, all outbound communications will now go through this new OCS 2007 edge server. Configuring all outbound communications through an OCS 2007 edge server will effectively minimize half of the responsibility of the LCS 2005 proxy. The process of redirecting internal LCS 2005 server communications through a new OCS 2007 edge server is as follows:
While logged on to an internal LCS 2005 server, click Start | All Programs | Administrative Tools | Live Communications Server 2005.
Expand the LCS 2005 tree.
Right-click the forest node, and then click Properties.
On the Access Proxy tab, click Add.
Enter the FQDN of your new OCS 2007 edge server, and then click OK.
The Live Communications Server Global Properties Access Proxy tab should look something like Figure 11.7. Click OK to accept the configuration change.
With an OCS 2007 edge server now handling outbound traffic successfully, the next step is to redirect inbound traffic through this new OCS 2007 edge server as well. Redirecting inbound traffic is a little trickier because the rerouting is done through a modification of public DNS records. Again, though, if the new OCS 2007 edge server has the same server name and IP address of the old LCS 2005 proxy server, the minute the new OCS 2007 edge server is back on the network, communications will go to this new edge server instead of to the old access proxy server.
As long as the external FQDN is set to route inbound traffic through the new OCS 2007 edge server, the new server should take the connections and route the communications to the internal servers for delivery.
Note
Traffic going to the edge server and going from the edge server to internal servers with go to and from the director server(s) or to and from the front-end server(s) depending on whether the organization is using director servers. If your organization has director servers, the traffic being redirected internally in your organization will go to and from the director server to the edge server. However, if you don’t have director servers, the redirection of internal communications will be between the edge server and your existing LCS 2005 front-end servers.
You’re almost finished! The last step in the migration process is to replace the old LCS 2005 front-end servers with new OCS 2007 front-end servers. This is a two-step process, as the first step is to switch out the front-end servers and the second step is to move the users associated with the front-end servers. So, this section of the chapter covers both of these steps.
The process of installing a new OCS 2007 front-end server during migration is identical to the process of installing a new OCS 2007 front-end server in a new production environment. For a recap, see the “Installing and Configuring OCS 2007 Standard Edition” section in Chapter 3. Then come back to this chapter for step-by-step instructions on how to install a new front-end server in the OCS 2007 environment.
Once you have the front-end server installed, return here to continue the migration process from LCS 2005 to OCS 2007. Unlike the installation of OCS 2007 edge servers and OCS 2007 director servers that requires the communications routing to be configured to acknowledge the new servers, when you add a front-end server to your environment the server automatically acknowledges the route of communications based on the configuration of the edge servers and director servers. So, all you need to do is add or move user accounts to the new OCS 2007 front-end server system to have that system integrated with the OCS 2007 environment.
Before migrating users to the new OCS 2007 front-end server, the best thing to do is to add a new user to the new OCS 2007 front-end server and test that user account for successful inbound and outbound communications. This new account will validate that you have outbound communications from OCS 2007 out of the network and inbound communications back into the network working properly. If the test account works, you can begin the process of moving existing LCS 2005 user accounts to OCS 2007.
To create a new user account and to test a new user account with OCS 2007, see Chapter 4. This chapter will guide you through the process of creating and testing a user account in OCS 2007.
With the test user successfully able to send and receive IM communications, the next step is to move LCS 2005 users to OCS 2007. You do this by selecting a user, a group of users, or all users and moving them from LCS 2005 to OCS 2007 (what you choose depends on how many accounts you highlight in the migration tool). It is recommended that you start with just one account and make sure you can successfully move that account, and then move over a small pilot group of users that will be used to test OCS 2007 communications.
To move one user (or a small group of users) from LCS 2005 to OCS 2007, do the following:
Log on as an administrator to the new OCS 2007 front-end server system that you just added to the network.
Expand the console tree and expand the tree for the LCS 2005 branch to expose the LCS 2005 front-end servers still on the network.
Click on the Users container and select the user you want to migrate, as shown in Figure 11.8.
Right-click the user and select Move users to launch the Move Office Communications Server Users Wizard.
Click Next through the Welcome page.
Choose the server to which you want to migrate this user (this would be one of your new OCS 2007 front-end servers). Click Next.
Do not select Force the user to move if the server or pool is unavailable. Click Next.
Confirm that the move was successful, and click Finish when done.
Have the user(s) you just migrated from LCS 2005 to OCS 2007 launch their MOC 2005 client software and IM each other. Also have this pilot group of users communicate externally (if you use public IM communications) and make sure that they continue to have full internal and external IM communications capability. In addition, have this group of users IM with users that haven’t been migrated yet and are still on LCS 2005 to confirm that the new OCS 2007 users can communicate with LCS 2005 users within your organization.
To recap, the testing process should include:
Pilot OCS 2007 users successfully sending and receiving IM communications to other pilot OCS 2007 users
Pilot OCS 2007 users successfully sending and receiving IM communications to existing LCS 2005 users
Pilot OCS 2007 users successfully sending and receiving IM communications to individuals outside the organization (if public IM is set up and used in the organization)
If communications continue to work for the pilot users, the process of migrating the balance of the organization’s users from LCS 2005 to OCS 2007 should commence.
Migrating the rest of the organization’s users from LCS 2005 to OCS 2007 involves nothing more than selecting more users or all users, as described in the step-by-step instructions outlined in the section “Moving Pilot User Accounts from LCS 2005 to OCS 2007.” From the step-by-step process, either hold the Space key down and select all of the users to migrate, or hold the Ctrl key down and choose specific users you want to migrate. The procedure is identical and just takes into account the balance of the users.
Part of the migration process may include consolidating LCS 2005 users from multiple LCS 2005 front-end servers to one or a limited number of OCS 2007 front-end servers. Users can be migrated across servers as long as they have access to the domains where the new OCS 2007 front-end servers reside. A user in DomainA can be migrated to any OCS 2007 front-end server in DomainA. However, a user in DomainA cannot be migrated to an OCS 2007 front-end server in DomainB unless that user has rights or a trust has been established to allow the user to reside in a server in a different domain.
Because you’ve already removed access proxy servers and director servers from the environment, completely removing LCS 2005 from the organization requires just the removal of the remaining LCS 2005 front-end servers. The process is as follows:
Some Independent Advice
If you properly inserted a new OCS 2007 front-end server and all communications are now flowing in and out of the new OCS 2007 environment, you can drop the old LCS 2005 front-end server(s) at any time because the old server(s) aren’t doing anything on the network. However, to be extra safe and conservative, you can leave one of the old LCS 2005 front-end servers still running for a few days, and in case you have problems, you can reconfigure to communicate back to the old LCS 2005 system.
Although this is a nice fallback option, it is highly recommended that you pick a date to bite the bullet and drop LCS 2005 from the environment, typically within 10 days of installing OCS 2007. The longer you wait to remove LCS 2005 from your environment, the further it is in your mind to do so. I’ve seen organizations that have stray servers in their networks two or three years later and when asked why they have the old systems, they say no one in the IT department was around when the new configuration was put in, and no one wants to fiddle with removing the old system because they do not know what might happen. So, clean up your network and get rid of LCS 2005 within a week to 10 days of OCS 2007 taking over user communications.
To begin to completely remove LCS 2005 from the environment, you want to make sure all users have been migrated off of LCS 2005 and onto OCS 2007 front-end server systems. This task simply involves checking the Administrative tool to confirm that no users are still homed to an old LCS 2005 server. The process is as follows:
While logged in as an administrator and in the LCS 2005 Administrative tool, expand the console tree and expand the tree for each front-end server.
Select the Users container that is under each front-end server in the tree. If you have successfully migrated all users off of the LCS 2005 front-end servers, you should not see any users in the right-hand pane being associated with any of the LCS 2005 front-end servers, as shown in Figure 11.9.
Once you confirm that no users exist on LCS 2005, remove the old LCS 2005 servers from the network. If it appears as though some users have remained on LCS 2005, select those users and move them to OCS 2007 until all of the users have been moved.
When removing LCS 2005 from the environment, start by removing LCS 2005 Standard Edition systems first. These systems are the easiest to remove, as each server can be removed individually. The process to remove an LCS 2005 Standard Edition server is as follows:
While logged on as an administrator of the LCS 2005 environment, expand the console tree and select the LCS 2005 Standard Edition server you want to remove.
Right-click the server and select Deactivate.
Click Next through the Deactivation Wizard Welcome page.
Click Next through the Deactivation Option page shown in Figure 11.10.
Click Next through the Ready to Deactivate page.
Click Finish once the deactivate process has been completed.
Uninstall the LCS 2005 code from the server by selecting Start | Control Panel and choosing Add or Remove Programs.
Highlight Microsoft Office Live Communications Server 2005 and click Change.
Check the Keep the user database checkbox and then click Remove, as shown in Figure 11.11.
If you had only LCS 2005 Standard Edition servers in your environment (not LCS 2005 Enterprise Edition systems), you are done. You have successfully migrated from LCS 2005 to OCS 2007, and have successfully removed LCS 2005 from the environment with the removal of the last LCS 2005 Standard Edition system from the network.
If you have LCS 2005 Enterprise Edition systems in the environment, the removal process is a little more involved, as you have to remove servers within an enterprise pool before you can delete the pool. However, the process is effectively the same, and it requires that you follow these steps:
Follow the steps outlined in the “Removing LCS 2005 Standard Edition” section to remove each server.
To remove the Enterprise Edition of LCS 2005, right-click the pool and then click Remove pool.
With the last LCS 2005 Enterprise Edition server removed from the system, and with the removal of the enterprise pool, you have finished the process of removing LCS 2005 from your environment.
Once you’ve migrated your servers from LCS 2005 to OCS 2007, you can take advantage of the new capabilities of OCS 2007. Some of the more common next steps are as follows:
Migrate users off of MOC 2005 and onto the new MOC 2007 client software.
Enable enhanced presence in OCS 2007, which now provides users not only with online or offline status information, but also with integration with Outlook calendaring data.
Add new OCS 2007 capabilities, such as Web conferencing, VoIP telephony, and multipoint video conferencing, which are enhancements to OCS 2007.
Migrating from LCS 2005 to OCS 2007 requires that you follow certain steps in a certain order. These steps comprise installing new OCS 2007 servers into the environment, integrating the new servers into the new environment, and then removing old LCS 2005 servers once the new OCS 2007 servers have successfully taken the place of the LCS 2005 system.
When migrating, it is a best practice to start from the outermost servers and work your way in to the internal servers. In the side-by-side migration process, you install new OCS 2007 edge servers in place of old LCS 2005 access proxy servers; replace old LCS 2005 director servers with new OCS 2007 director servers; and add new OCS 2007 front-end servers and move users from old LCS 2005 front-end servers to the new OCS 2007 servers.
If a server or user fails to migrate to OCS 2007 you can still move the organization back to LCS 2005. With limited or no impact to users, you can perform a side-by-side migration to OCS 2007 without shutting down total services to the organization.
Once you have migrated the users from LCS 2005 to OCS 2007, you can add new features of OCS 2007 such as Web conferencing, VoIP telephony, and multipoint video conferencing. The migration from LCS 2005 to OCS 2007 is one of the easier migrations among the Microsoft Windows server system migrations.
 | You cannot upgrade client software from MOC 2005 to MOC 2007 until after the user has been migrated from LCS 2005 to OCS 2007. |
| You cannot activate enhanced presence until the client has been migrated to OCS 2007 and is using the MOC 2007 client software. |
| Choose the “big bang” method of migration from LCS 2005 to OCS 2007 to minimize the need to run both an LCS 2005 and an OCS 2007 environment in parallel for an extensive period of time. |
| Identify the locations of all existing LCS 2005 servers so that you can make sure you migrate all servers to OCS 2007 in your environment. |
| Know the server roles of all LCS 2005 servers so that you can properly map a migration of those servers and roles to OCS 2007 in the right sequence. |
| Map the routing of communications between servers so that server-to-server communications is set up properly between systems in the new OCS 2007 environment. |
| Understand which users are associated with which LCS 2005 systems so that you can more easily move users to new OCS 2007 systems in the right sequence. |
| Have a strategy regarding how you will upgrade client software from MOC 2005 to MOC 2007. |
| Prepare DNS so that other LCS 2005 and OCS 2007 servers can properly see perimeter servers on the network. |
| Plan for time in advance to order or request SSL certificates required for internal and external communications of the LCS 2005 and OCS 2007 systems. |
| Continue to use the same external FQDN for IM communications. |
| Redirect outbound communications through a new OCS 2007 edge server before directing inbound communications to the server system. |
| Add new OCS 2007 front-end servers capable of handling the demands of the organization, including performance capabilities that are able to handle the new features of OCS 2007. |
| Take this opportunity to consolidate LCS 2005 servers to fewer OCS 2007 systems, because users can be migrated across servers at this time. |
| Create a test user on the new OCS 2007 front-end server and make sure the test user can successfully communicate before moving LCS 2005 users to the new OCS 2007 system. |
| Highlight and move users from LCS 2005 to OCS 2007 once you know the new OCS 2007 is working properly. |
| Have a plan to remove LCS 2005 from the network within seven to 10 days of completing your migration to OCS 2007. |
| Remove LCS 2005 Standard Edition servers first. |
| For environments with LCS 2005 Enterprise Edition, remove all but one enterprise server from the network first, and then remove the enterprise pool to remove the last enterprise server from the network. |
| Migrate users off of MOC 2005 and on to the new MOC 2007 client software. |
| Enable enhanced presence in OCS 2007, which now provides users with not only online or offline status information but also integration with Outlook calendaring data. |
| Add new OCS 2007 capabilities, such as Web conferencing, VoIP telephony, and multipoint video conferencing, which are enhancements to OCS 2007. |