Administering Lync 2010 and 2013 Coexistence

As everyone is out migrating their Lync 2010 environments to Lync 2013, you must plan for coexistence.  This post will discuss the appropriate tools to use to administer certain scenarios once Lync 2013 is introduced into the environment.

Topology Changes

For any Topology changes (including adding Lync 2010 pools), you must use the Lync Server 2013 Topology Builder.  This is true even if a Lync 2010 pool is still hosting the CMS.  If you attempt to open the Lync Server 2010 Topology Builder, you will receive the following error:

“The topology is from a later version of the product.  Use the correct version of Topology Builder to open this topology.”

Moving Users Across Pools of Different Versions

For all user moves across pool versions, the Lync Server 2013 tools must be used (Control Panel and Management Shell).  If you try to move a user from Lync 2010 to Lync 2013 or from Lync 2013 to Lync 2010 with the Lync 2010 tools, you will get the following error:

“Move to or from the future version of the product is not supported.”

Moving Users Across Pools of Same Version

For all users moves across pools of the same version, that version of tools can be used to move the user.  This means that Lync 2010 tools can be used to move users between 2010 Lync pools and Lync 2013 tools can be used to move users between 2013 Lync pools.  Also, you can use the Lync 2013 tools to move Lync 2010 users between 2010 pools, but you cannot use Lync 2010 tools to move users between Lync 2013 pools.

Assigning User Policies or User Settings

Assigning user policies or changing user settings can be performed with either set of tools no matter what version of pool the user is homed on.

Summary

Below is a summary of the different scenarios above. 

	Lync 2010 Tools	Lync 2013 Tools
Topology Changes	no	YES
Move user from 2010 to 2013	no	YES
Move user from 2013 to 2010	no	YES
Move user between 2010 pools	YES	YES
Move user between 2013 pools	no	YES
Assign user policies and settings	YES	YES

Conclusion

To avoid any confusion, I recommend using the Lync 2013 tools exclusively for any administrative tasks once you have introduced Lync Server 2013 into your environment.

Exploring Default Installation and SQL Paths in Lync Server 2013

A shift has been made in Lync Server 2013 to process more SQL transactions local on the server than on Lync Server 2010.  One of the main reasons for this is to provide better resilience across all workloads (including user/conferencing services) compared to just voice resiliency in Lync Server 2010.  This post will review different installation paths of Lync components based on drives available at the time of installation.

First let’s review the SQL Express instances that are running local on the Lync Front-end servers.  In my example, I will be looking at the Standard Edition of Lync.  The Enterprise Edition Front-End server will only have LYNCLocal and RTCLocal SQL instances.

The following lists each SQL instance and the databases associated with it:

• LYNCLOCAL
  • Lyss
• RTC – located on local Standard Edition servers and in back-end SQL instance for Enterprise Edition
  • RTCab
  • CpsDyn
  • RgsConfig
  • RgsDyn
  • RTCShared
  • RTCXDS
• RTCLOCAL
  • XDS
  • RTC
  • RTCDyn

I wanted to see what would happen to default installation locations based on drives available.  Here are the scenarios that I tested:

Scenario #1 – C: drive only, default installation path

In a very default installation with only a C: drive, obviously all components get installed in their default locations.  The following screenshots shows the location of each Lync component.

Drive configuration:

Lync installation path:

SQL installation paths:

RTCReplicaRoot path:

Database and Logs paths:

Note that the RTCLocal database and log for XDS will always be located on the C: drive in the SQL installation path

Scenario #2 – C: and E: drive, default installation path

The following screenshots shows the location of each Lync component.

Drive configuration:

Lync installation path:

SQL installation paths (on C: ):

Note that the RTCLocal database and log for XDS will always be located on the C: drive in the SQL installation path

RTCReplicaRoot, Database and Log paths for RTC, RTCLocal, and LYNCLocal instances (all on E: ):

Note that you can tell what SQL instance each database belongs to by looking at the parent folder to the DBPath/LogPath folders.

Scenario #3 – C:, E:, and F: drive, default installation path

The following screenshots shows the location of each Lync component.

Drive configuration:

Lync installation path:

SQL installation paths (on C: ):

Note that the RTCLocal databases and logs (XDS) will always be located on the C: drive in the SQL installation path

RTCReplicaRoot, Database and Log paths for RTC, RTCLocal, and LYNCLocal instances (on E: ):

Note that you can tell what SQL instance each database belongs to by looking at the parent folder to the DBPath/LogPath folders.

Log paths for RTC, RTCLocal, and LYNCLocal (on F: )

Scenario #4 – C:, E:, and F: drive, Change installation path to E:

The following screenshots shows the location of each Lync component.

Drive configuration:

Lync installation path:

SQL installation paths (on C: ):

Note that the RTCLocal databases and logs (XDS) will always be located on the C: drive in the SQL installation path

Lync Program Files, RTCReplicaRoot, Database and Log paths for RTC, RTCLocal, and LYNCLocal instances (on E: ):

Note that you can tell what SQL instance each database belongs to by looking at the parent folder to the DBPath/LogPath folders.

Log paths for RTC, RTCLocal, and LYNCLocal (on F: )