RSS Subscription 148 Posts and 2,107 Comments

Archive for June, 2011

Lync 2010 – Deploy First Standard Edition Server Option?

General Information

When you’re first installing Lync Server 2010, there’s some confusion out there as to why you would or wouldn’t choose the option, “Deploy First Standard Edition Server” option.  Every Lync 2010 Server in your deployment will hold a copy of your Lync Server 2010′s topology configuration called the Central Management Store (CMS).  These copies are located in a SQL 2008 Express instance called rtclocal on each Lync Server 2010 Server.  A very good post on the CMS can be read here.  The purpose of this article is not to explain what the CMS is, but how you go about utilizing the setup process of Lync to deploy the CMS if your first pool is a Standard Edition Server or an Enterprise Pool.

To help understand the difference, I wanted to preface the remainder of my post with a couple images that were taken from Jen’s excellent CMS post which I linked to in the above paragraph.

This first image shows how the CMS database is placed in the first Enterprise Edition Pool.  With this setup, we can see we have two Front End Servers (FE1 and FE2) which are collocated within the same Enterprise Pool.  Each of these servers have SQL 2008 Express which contain the rtclocal instance that contains a copy of the Master CS on the BE SQL Server which would be a SQL Standard or SQL Enterprise. A key thing to note here, is that the SQL BE Server has only one instance called rtc.  From a CMS standpoint, this rtc instance contains the master xds database.  The xds database is the cms database.  This rtc instance also holds your other Lync databases: cpsdyn, lis, rgsconfig, rgsdyn, rtc, rtcdyn, rtcab, rtcab1, and rtcdyn.

al

This second image shows how the CMS database is placed in the first Standard Edition Server.  The key difference here, is we can see that on this first Standard Edition Server, we see two instances; rtclocal and rtc.  We can see, that because we do not have a dedicated BE server as we would in an Enterprise Edition Server, we collocate that dedicated rtc instance on the SE Server which will hold the same databases that the rtc instance would on the first Enterprise Edition Pool; the master xds database, cpsdyn, lis, rgsconfig, rgsdyn, rtc, rtcdyn, rtcab, rtcab1, and rtcdyn.  But this SE Server will also have the same rtclocal instance that Enterprise Edition FE Servers would have that would contain a copy of the xds instance.  Because of this, from a CMS standpoint, the first SE Server would contain two instances; one with the master xds and one with the replica xds.  Any subsequent Standard Edition Front End Servers (and any other Lync Server 2010 Server in the environment) would only have the rtclocal database holding a copy of the master xds as there can only be one Pool (Standard Edition Pool or Enterprise Edition Pool) that can hold the master CMS role.

It is possible, however, to move the CMS Master role to a new pool after the fact in case you deployed a Standard Edition Front End first such as a Pilot and then later deploy Enterprise Edition Pools such as when determining the pilot is a success and going full production. A very good blog article that explains this process can be read here.

Let’s take a look at how we accomplish the setup if our first Front End will be a Standard Edition and how it differentiates with an Enterprise Edition Front End.

Standard Edition Setup

Now when running setup.exe for Lync Server 2010, one of the deployment options you can see is “Prepare first Standard Edition Server.”

You will only want to run this option when you are deployment the first Lync Server 2010 Standard Edition Server in your deployment and you don’t already have any Lync Server 2010 Enterprise Edition Front End Servers.

What the Prepare first Standard Edition server does is simple.  It creates the rtc instance if it does not exist already and it creates the xds master database within the rtc instance.  This creates a Service Connection Point (SCP) record in Active Directory that allows any future deployment options to know how to locate the CMS information.  Taken from Jen’s blog article, “The SCP is an object in Active Directory created under the path of the following Distinguish Name (DN), CN=Topology Settings, CN=RTC Service,DC=<domain>, of type msRTCSIP-GlobalTopologySetting. This object contains the msRTCSIP-BackEndServer attribute, which specifies the FQDN of the master and the instance name of the SQL Instance. All tools use the SCP to locate and connect to the CMS master.”

If you ever wondered how the Topology Builder automatically knows how to find and download Topology Information, the Topology Builder queries this SCP record, uses the msRTCSIP-BackEndServer attribute, contacts the FQDN of the master, and downloads the topology information.

Now because the rtc instance has been created with the xds database, when you go to run the actual install, you will see “Install Local Configuration Store” which will install the rtclocal instance which contain a copy of the master xds database.  The regular databases will still be installed in the rtc instance.

Enterprise Edition Setup (Read the Standard Edition section first to fully understand this section)

Now when deploying the first pool in your Lync Server 2010 deployment happens to be an Enterprise Edition Pool, you won’t bother with the “Prepare first Standard Edition server” option. When taking a look at the first Standard Edition Front End, you can see we needed to create the rtc instance first with the master xds.  The same thing happens with the Enterprise Edition but in a different fashion.  Because this is an Enterprise Edition Pool, you will be using a SQL Standard or SQL Enterprise.  During the Topology Builder process, you need to define your SQL Server unlike a Standard Edition Deployment.  When publishing your Enterprise Edition Pool, at that time your rtc instance is being created on your SQL Server as well as the xds database.  Just like with the Standard Edition deployment, the SCP record in AD is getting created.

Now when running the Setup below and choosing “Install Local Configuration Store,” the Setup Process is creating the rtclocal instance (SQL  2008 Express) local to that Enterprise Edition Front End Server and then goes out to the master xds database that is on the SQL Standard or SQL Enterprise Server, and then creates a copy of that xds database on the Enterprise Edition Front End Server.

Share

:: Jun.16.2011 :: :: 31 Comments »

Exchange 2007 UM to Exchange 2010 UM Partial Upgrades and Redirects

General Information

There’s two ways to migrate to Exchange 2010 UM:

  • Full Upgrade
  • Partial Upgrade

In a Full Upgrade scenario, you are doing a big bang migration for your Exchange 2007 UM users and moving them all to Exchange 2010 UM at the same time.  At the same time, you are replacing your Exchange 2007 UM Servers within your UM Dial Plan with Exchange 2010 UM Servers.

In a Partial Upgrade, you are going to  have Exchange 2007 UM Servers and Exchange 2010 UM Servers coexist within the same Dial Plan.

It is important to note how the call flows work in a Partial Upgrade Path.  You can see this documented very well here. In order for the Partial Upgrade process to work, the documentation clearly states, “When you install the first Exchange 2010 UM server and add it to an existing Exchange 2007 organization, you must add the Exchange 2010 UM server to an existing UM dial plan that contains Exchange 2007 UM servers. Then you must configure each IP gateway or IP PBX to send all incoming calls to the Exchange 2010 UM servers within the same UM dial plan.”

The key part to note is that you must configure each IP Gateway object that is in the Dial Plan to now send ONLY to Exchange 2010.  The problem with the article, is that it does state this clearly and does show example of call flows, but what isn’t really explained is what exactly is happening on the Back-End.  And that, is what I am here to explain.

The basic jist of it, is that Exchange 2010 will redirect the IP Gateway to Exchange 2007 where necessary.  But let’s say you have a PBX connected to a gateway which is connected to UM.  Exchange 2010 UM will always redirect the gateway for an Exchange 2007 user and the gateway will connect directly to Exchange 2007 UM.  The gateway never has to relay any information back to the PBX in this case so there are no considerations you have to make for the PBX here.  The only consideration you should make is to make sure that the gateway has been certified against Exchange 2010 UM before you decide to do your partial upgrade.  The certified gateway/IP-PBX for Exchange 2007 is here and the certified list for Exchange 2010 is located here.

With that said, the redirects from Exchange 2010 to Exchange 2007 work a couple different ways depending on the circumstances.  Thanks to Chun from Microsoft for providing me with these details that were documented in great detail.

There are two broad categories on how the redirection happens:

  • Before UM 2010 accepts the invite, it knows the call is for an UM 2007 user (e.g., diversion exists and UM can tell that the call is for a 2007 user). In this case, we simply use 302 redirect.
  • UM 2010 needs to accept the invite before it knows the call is for an UM 2007 user. E.g., someone calls into the subscriber access from a phone that we cannot resolve to a user. UM needs to answer the call first, and wait for the user to punch in the mailbox extension. In this case, UM will send a REFER to the gateway to cause the gateway to send a new INVITE to the same UM 2010 server. But in the REFER header, we stick in a couple of information which shows up in the new INVITE. The UM 2010 server sees this information, realizes it is for a 2007 user, and redirects the call to UM 2007.

Example

Now let’s take a look at a real life migration example from a procedural standpoint.  Let’s start off with not having Exchange 2010 yet.  We have our IP-PBX which is sending data to an IP Gateway which is then sending data to Exchange 2007.

We then build our Exchange 2010 Server, install Exchange 2010 UM Role on it, and we then add it to our Dial Plan which will then consist of both Exchange 2007 and Exchange 2010 UM.  Keep in mind, when using OCS as the IP-PBX, you must be on at least OCS 2007 R2 CU5 and Exchange 2010 SP1 to be able to allow Exchange 2010 UM SP1 and Exchange 2007 to be in the same Dial Plan.  The reason for this is Exchange 2010 SP1 introduces capabilities that allow OCS 2007 R2 CU5+ and/or Lync to be able to do a user lookup, determine if they’re on Exchange 2010 or Exchange 2007 and route to the appropriate Exchange Version (2007 or 2010) regardless if they’re in the same Dial Plan.

As can be seen above, we now have Exchange 2010 and Exchange 2007 in the same Dial Plan.  We have also started routing all traffic to Exchange 2010.  If the call is for an Exchange 2007  User, Exchange 2010 will redirect the IP Gateway to start talking to Exchange 2007 to service those Exchange 2007 users.

 

 

Share

:: Jun.12.2011 :: :: 9 Comments »