Beginning around March of this year I took on the project of upgrading the environment where I work from LCS 2005 to Lync 2010. There had been a project to upgrade the LCS environment for some time, however since it hadn’t been broken no one had ever gotten around to doing it. Finally though some features of Communicator 2005 broke during the upgrade to Windows 7, so LCS had to be upgraded.
I figured I would document the whole project so that I could refer back to it myself, and perhaps assist anyone else out there looking to upgrade with a better inside view to the whole thing. Note that everything below is for a “simple” environment. It’s only used for internal IM/Collaboration purposes. Clearly the steps below can’t be followed step by step if you have a more complex setup.
Now, in all seriousness, the whole upgrade from LCS to Lync with no loss of user data could’ve occurred within a month or two. However, due to the way things work in a large business, it’s dragged on into August, and will likely drag on a couple more months. Due to the amount of information that I’m going to attempt to shove into this post, I’ll break the post down into the following sections. There will be a “Preparing LCS” section, a “Preparing for OCS 2007 R2” section, an “Installing OCS 2007 R2” section, a “Decommissioning LCS” section, a “Preparing for Lync 2010 section”, a “Installing Lync 2010” section, a moving users from 2005 client to Lync 2010 client, and finally a “Decommissioning OCS” section.
Preparing LCS 2005
So prior to doing any upgrading to LCS, you have to run through a number of things to prepare it for co-existence with OCS 2007 R2. That’s right, there’s no straight shoot from LCS 2005 to Lync 2010, you have to take a pit stop through OCS first. Don’t worry, it’s really not that big of a deal, and if you follow the steps below, your users will only see the Communicator 2005 client they’re using now and the Lync 2010 client at the end. They won’t even know you took a pit stop on OCS.
So here’s a list of the things that need done to LCS first. I’ll describe them in more detail in a moment.
So starting from the beginning of the list…
You have to first install KB911996 on your back end database server and front end servers so that they can handle having your settings in the configuration container in AD. (You’ll be moving your settings after this.) You need to first install this update on your database servers. Run “LCS2005-KB911996-x86-Usa.msi POOLNAME=poolname” on the SQL server, and then you’re done with that. You do not need to reboot your SQL server. You’ll then just need to run the MSI install on your LCS front end servers.
Once KB911996 is deployed, it’s time to run the Global Settings Migration. Go to the site specified above and download the “Microsoft Office Communications Server 2007 Global Settings Migration Tool”. You’ll get an MSI, however when you run it you’ll end up having a vbs script. Below are the steps for running the “MigrateOcsGlobalSettings.vbs” script. I would run these from a LCS 2005 front end server with a user account that’s a member of the Domain Admins group. It’s possible you could get away with less permissions, but I didn’t bother with it.
- Run “MigrateOCSGlobalSettings.vbs /Action:MigrateGlobalSettingsTree”
- Replicate AD
- Run “MigrateOCSGlobalSettings.vbs /Action:MigrateGlobalSettingsProperties”
- Replicate AD
- From the directory “C:Program FilesCommon FilesMicrosoft LC 2005” run “LcsCmd /Forest /Action:ForestPrep /Global:configuration”
- From the directory “C:Program FilesCommon FilesMicrosoft LC 2005″ run LcsCmd /Domain /Action:DomainPrep”
- Replicate AD
- Run “MigrateOCSGlobalSettings.vbs /Action:MigrateServerDnReferences /SearchBaseDN:DC=domain,DC=local” (Replace the SearchBaseDN parameters with information on your domain…)
- Run “MigrateOCSGlobalSettings.vbs /Action:MigrateUserDnReferences /SearchBaseDN:DC=domain,DC=local” (Once again, replace the SearchBaseDN parameters with information on your domain.) You might get this step failing a couple of times. Just keep re-running this until it succeeds.
- Reboot LCS 2005 Front End Server(s)
Now you need to install KB921543 on your LCS 2005 front end server(s). For some reason my documentation lacks the exact reason this patch needs installed, so I’ll come back and update this section if I find exactly why it needs installed. No reboot is needed after installing this patch.
Now you need to install KB950614 on your LCS 2005 front end server(s). This patch will allow Communicator 2005 clients with KB949280 installed to communicate properly.
Finally, you need to install KB949280 on your Communicator 2005 clients. This update allows for interoperability with OCS 2007 R2. You only need this patch if your Communicator 2005 clients are running on a lower build than 1.0.559.218.
After all of that, we’re done with preparing LCS and can move onto the preparing for OCS phase.
Preparing of OCS 2007 R2
There are three main sections for preparing for OCS 2007 R2. Those are
- Preparing AD
- Setting up SQL
- Setting up a OCS front end server
Before any of those steps, I would start with creating a service account for OCS. The service account I created was a member of the following security groups.
- Domain Admins
Note that it’s possible that you need to have this service account setup with local administrative permissions on the OCS server and the SQL back end server. In my case, my service account remained a Domain Admin throughout the upgrade, which made it a local admin on the servers.
You should now prepare AD for OCS. Launch the OCS installation media and first run the ‘Update Schema Wizard”. Be sure to run this step with a user account that’s a member of the Schema Admins group, and from a computer that has AD tools installed. Replicate AD after doing this.
You’ll then need to run the “Prepare Forest” wizard. If you’re running this on a Server 2008+ system or a Windows Vista+ system then you might have to run this using lcscmd.exe instead, and running that as an Administrator. After this is done, replicate AD.
Now run the “Prepare Domain” wizard. Once again, replicate AD after this.
You’re now done with preparing AD for OCS and can move onto setting up SQL.
When it comes to setting up your back end SQL server, it’s pretty simple. You need to first make sure that if you have SQL instances available, that you do not use one that’s already hosting a LCS/OCS environment, since some database names are re-used. Personally I would recommend just create a SQL instance for OCS. Either way, once you have your SQL instance you need to configure your OCS service account with full access to the instance. (Your SQL server needs to be at least SQL 2005 SP2+. You can use SQL 2008, 2008 R2.)
You now need to setup your OCS front end server. The steps below will guide you through setting up a Server 2008 R2 SP1 system for the OCS front end roles.
- Install Server 2008 R2 SP1, install all available patches.
- Install Windows Media Runtime
c:windowssystem32dism.exe /online /add-package
/ignorecheck /NoRestart /quie
- Install IIS
- Install Message Queuing
- Run ocsasnfix.exe
- Create and share the following folders
- Assign a static IP
- Create a Host A record in DNS with the name of whatever your OCS pool will be called and point it to the static IP of your front end server. (Assuming you’re doing a single FE server setup. Otherwise you would point that Host A record at a load balancer or something, which would then target all your FE servers.)
Now that everything has been prepared for OCS, we can move to installing OCS.
Installing OCS 2007 R2
The installation of OCS can be broken down into the following steps.
- Run through the OCS 2007 R2 setup on your front end server
- Install the OCS administrative console on an x86 system
- Migrate users to your OCS pool
- Enable Enhanced Presence for users in your OCS pool
- Update DNS/GP
Now I’ll break down each of those sections.
First log into your OCS front end server with your OCS service account. Once logged in, launc the OCS 2007 R2 setup and run through the
- Create Pool Wizard
- Configure Pool Wizard
- Install Archiving Server Role Wizard (optional)
- Install Monitoring Server Role Wizard (optional)
- Request and Generate Cert for your OCS pool
- Install OCS 2007 R2 Enterprise Server
- Install Administrative Console
All of the above is pretty simple to get through, except for potentially the step for getting your certificate. For Lync, there’s a built in wizard for doing this, however I recall OCS not having such a simple wizard for getting your certificate. Basically all you need to make sure of is that your certificate is valid for the FQDN of your pool. In my case, the certificate was issued to “ocspool1.domain.local” using the built in WebServer template. Once you get your certificate, just make sure that you’re importing the certificate at the system level and not for the user you’re logged in as. Also make sure that you install all the available updates for OCS. This will require updates being made to the back end SQL server as well. You can get away without installing these updates, however you won’t have any conferencing features. (No chatting between more than 2 people.) Plus it’s always good to be running the latest version of the software when doing production upgrades….
Once you have OCS running (which you should at this point, since with these instructions we’re simply covering how to setup a simple single FE environment, and we covered setting up the pools Host A record in the previous section…), you’ll need to first install the OCS 2007 R2 Administrative Console on a 32-bit Windows XP/Windows 7 system. This needs done so that the 32-bit OCS 2007 R2 console get interface with the 32-bit LCS environment. (This is my assumption, since I can’t find any solid documentation around this.) Whenever you need to move users from LCS to OCS, you’ll need to use the OCS console on the 32-bit system.
So now that you’re all setup there, I’m going to assume that you’ve already moved some test accounts and have verified everything is working. Assuming everything is working, you’re ready to migrate your users from LCS to OCS. This is a pretty painless step. Using the 32-bit OCS 2007 R2 console, move all your users from LCS over to OCS. When you move a user, their Communicator client will get briefly disconnected, however should automatically re-connect within about 30 seconds. All their contacts should get moved over as well. You don’t have to move all your users at once. This can be stretched out over time since users can chat with each other between environments.
Once all your users have been moved over to the OCS pool, you now need to enable enhanced presence for their accounts. From within a OCS 2007 R2 console (doesn’t matter if it’s from a 32-bit system or 64-bit system), enable enhanced presence for every user account. Now, from this point forward, be careful. If any of your users login to the Communicator 2007 R2 client, or some other 3rd party chat client that supports enhanced presence, their user account will be configured for enhanced presence. Once this happens they will no longer be able to login to Communicator 2005.
So at this point you should have a LCS environment with no users based out of it, a OCS environment with all your users based out of it, and a bunch of users still using Communicator 2005 as their chat client. Assuming that you did all your work overnight or on weekends, from a user perspective they have no idea anything is going on. Now onto decommissioning LCS.
Decommissioning LCS 2005
I’m going to be pretty brief on this section. It consists of six steps.
- Verify all your users have been migrated to OCS
- Update your SRV record in DNS or your GPO
- De-activate your LCS 2005 FE server
- De-activate your LCS Archive server (optional)
- Remove your LCS pool
- Shut down your LCS servers
The first step is simple. Open your LCS console and verify no users are left being hosted from LCS. In the event you leave some, it’s not too big of deal. You’ll still be able to move them to OCS, however they’ll loose their contacts.
Next, you need to update your SRV record in DNS or your GPO that configures your Communicator 2005 clients. Up until this point, they’ve been pointing to your LCS pool as the “server”, however when you decommission your LCS environment, any client still pointing to the LCS pool will stop working. So first identify whether your Communicator clients get their configuration automatically via a SRV record, or “manually” via a GPO. Either way, update both to instead specify your OCS pool. Before proceeding, make sure all clients update to using the new settings.
Assuming that all your clients are now talking with OCS, you can go through and deactivate each LCS FE server. If I recall correctly, this is as easy as right clicking each FE server in the LCS console and clicking “De-activate”.
Now, if you have an Archive server, now is the time to also de-active it as well. For compliance/legal purposes, you’ll likely want to export the archive database from your SQL server and save it in a safe place.
You’re now able to remove your LCS pool. Right click the pool in the LCS console and remove it.
At this point, you can just shut down all your LCS servers. They’re done with, and so is the SQL databases / SQL instance that went with them.
Preparing for Lync 2010
You’re now at the point where you can start preparing your environment for Lync. There are four areas that need prepared.
- Setup a service account
- Setup a server for the front end role
- Setup the SQL backend
- Prepare AD for Lync
Start with creating your Lync service account. Once it’s created, add it to the following security groups.
- Domain Admins (Temporarily)
The service account will also need to be a local administrator on your Lync servers and on the SQL back end server. As far as I can tell, this step only needs done if the Domain Admins group membership is ultimately removed.
Now that you have your service account, go ahead and setup a server to act as your Lync 2010 front end server. Install Server 2008 R2 and fully patch it. You’ll then need to do the following on that server.
- Install .NET 3.5
- Install Visual C++ 2008 x64
- Install SQL Server 2008 Native Client
- Install OCSWMIBC.msi
- Install Silverlight
- Disable IE ESC
- Setup a static IP
- Install IIS
Also, now that you have your front end server setup with a static IP, you should create a Host A record for your Lync pool and point it to your future front end server. (Assuming you’re only setting up a single front end server.)
Note as well that if you want to install the Monitoring role or the Archive role that you’ll need to setup an additional server to host those two roles, assuming that you’re installing Lync 2010 Enterprise. Based on what I’ve read, the Standard Edition allows for co-location of all the roles on a single box.
As for the SQL back end, just setup a SQL instance and configure your Lync service account to have full access. Once again, don’t configure Lync to co-exist in a SQL instance that’s already in use by OCS/LCS or another Lync pool.
Finally, run through the AD prep for Lync by running Setup from the Lync installation. You’ll need to do the following.
- Prepare the Schema (with a user account that’s a member of the Schema Admins group)
- Replicate AD
- Prepare the Forest
- Replicate AD
- Prepare the Domain
- Replicate AD
- Create an OU and move all your newly created Lync security groups there (optional)
- Add your Lync service account to the security group “CSAdministrator”
At this point you’re ready to install Lync.
Installing Lync 2010
Installing Lync 2010 is pretty straight forward. Start by launching Lync setup on your future front end server. Install Topology Builder and then build yourself your Lync topology. Once you’re satisfied with the Lync topology you’ve built, publish the topology.
You then need to go to your first (or only) front end server and launch Lync setup. Do the following.
- Install the Local Configuration Store
- Setup Lync Server Components (Setup will automatically install the correct components for the server you’re running setup from based on the topology you already published)
- Request, Install SAN Certificate
- Start Services
- Verify services started
- Install Lync updates
Now that Lync is installed you’re ready to merge your OCS environment and Lync environment. Merging the environments allows you to upgrade users from OCS to Lync, as well as allow for communication between the two environments.
First run the OCS Merge Utility in Topology Builder, and then publish the new topology with the OCS information. You then need to run the following command from the Lync Management Shell. “Import-CsLegacyConfiguration”
At this point you should be good to test moving a user account from OCS to Lync. Now here’s were things get a little bit complicated. Assuming you followed these instructions step by step, you never upgraded any of your users from Communicator 2005 to Communicator 2007 R2. Communicator 2005 doesn’t work with Lync. Therefore you have to upgrade a user to the Lync client at the same time you migrate their user account from the OCS server to the Lync server. Now, some people might be totally against this because of the amount of coordination this requires, but take into consideration the approach I took to it, and then consider how much of a cleaner upgrade this appears to your end users by simply upgrading clients once.
Coordinating user moves from Communicator 2005 to Lync 2010
In order for my approach to work for you, you’ll have to have an environment where for the most part people have assigned systems. And then on that assigned system there’s information either in the registry on in a text file that lists information on the owner of that system. For me, we have a key in the registry populated with a bunch of information on the user that’s assigned to the system. One of the pieces of information is the users email address, which since I use their email address as their SIP address, that makes things extra easy.
The next thing you need to do is configure some way to trigger a user account move in Lync after a users system has been upgraded to the Lync client. There’s several ways you could go about doing this, but I’m only going to cover the method I ended up using.
In my case, we wrap all our installs with a vbscript. I configured that vbscript to create a text file with the name of the users email address on a network share after the Lync client is successfully installed on a system. I then have a PowerShell script running on my Lync Archive/Monitoring server that handles the actual user move. Technically this script could go on any server as long as it has the Lync Management Shell installed on it and you’ve installed OCSWMIBC.msi. The script I’ve setup to handle the user migration is rather complex, allowing the script to fix any issues that are encountered, email special instructions to end users, logging, ect. However, the script really only needs to do the following.
- Monitor the network share that the text files with user information are uploaded to
- For each text file with user information, use the Active Directory and Lync PowerShell modules to gather additional information on the user
- Run “Move-CSLegacyUser” for each user
- Have the script sleep for 10-20 seconds between each user move. The more users that are moved at once, the slower things will get. Allowing for some time between the moves allows things to keep up.
Using this type of a setup will allow you to only have to worry about coordinating client upgrades, knowing that the user accounts are being moved automatically on the back end.
Decommissioning OCS 2007 R2
I haven’t gotten to this part in my own production environment yet since I’m still stuck on the coordinating user moves, however I can supply some basic steps based upon my testing in my Dev environment.
Based upon my notes, there are three main pieces to decommissioning OCS 2007 R2. They are
- Updating your SIP SRV Record / GPO
- Deactivating the OCS environment
- Updating your Lync toplogy
Granted before you do any of the above, you should verify that you don’t have any users living in your OCS pool, and that all your workstations have been upgraded to Lync 2010.
Updating your SIP SRV Record or GPO is just like what was done when decommissioning LCS 2005. You’re simply pointing your Lync 2010 clients to your new Lync front end environment instead of the OCS front end environment. Failure to do so will result in a bunch of clients getting disconnected and not being able to re-connect.
The next thing you need to do is deactivate your OCS environment. This step actually consists of a bunch of smaller steps.
First thing you’ll want to do is check for any conference directories in your Lync environment that are tied to your OCS pool. You can do so by running “Get-CSConferenceDirectory” from the Lync Management Shell and then looking for a conference identity that has a service ID tied to your OCS pool. Assuming you find one, you can use “Remove-CsConferenceDirectory” to get rid of it.
Once you’re done there, remove your OCS archive servers and monitoring servers, then deactivate every other OCS role. Once that’s taken care of, you can remove the OCS pool from the OCS Admin Console.
Now you can begin uninstalling the OCS software from your front end server(s). I’m pretty sure this would be entirely optional, since you could likely just shut down the server and be done with it. However if you do want to uninstall the software, I’ve read that you need to do so in a particular order. Here’s the order for removing the software.
- Administrative Tools
- Conferencing Attendant
- Conferencing Announcement Service
- Response Group Service
- Outside Voice Control
- Application Host
- Application Sharing Server
- Audio/Video Conferencing SErver
- Web Conferencing Server
- Web Components Server
- Front End Server
- Core Components
- API Core
- API Speech
- API Windows
Once that’s taken care of, you should go into Lync Topology Builder and delete the “BackCompatSite”, then publish your topology.
That should be it. You should now be able to sit back and say you’ve upgraded an environment from LCS 2005 to Lync 2010.