Deploying Microsoft Live Communications Server in a production environment

Unfortunately, there is no way I can possibly tell you everything you need to know about preparing your network for the implementation of UC within the context of a single article. There are simply too many UC products on the market, and all of them work differently. Even if I were to limit my discussion to a single product, entire books could be written on the subject.

With that in mind, I want to focus my discussion on how deploying Microsoft Live Communications Server in a production environment might differ from a lab deployment in regard to the impact on your network.

Lab vs. production network: What's the difference?

There are several differences between lab deployments and real-world deployments. In most cases, the biggest difference is going to be the scale of the deployment. If you are setting up a simple lab deployment for training and proof-of-concept purposes, then a simple, single-domain network will usually suffice. In an enterprise-class deployment, many different domains are typically involved, and the network will usually span multiple Active Directory sites.

That being the case, the first thing that you must consider is the impact the deployment will have on the Active Directory. Microsoft Live Communication Server 2005 with SP1 extends the Active Directory schema to include 15 additional classes and 54 additional attributes.

Extending the Active Directory schema isn't really that big a deal, but you will want to back up your domain controllers beforehand, just in case something goes wrong. You will also want to keep in mind that the schema extension process may temporarily affect the Active Directory's performance. Schema extensions consume disk and CPU resources on the domain controllers; they also generate replication traffic.

Larger organizations should pay particular attention to the replication traffic that will be flowing between Active Directory sites, because sites are often connected by relatively slow links. When you install Live Communications Server, its setup program creates a number of new security groups. This means that updates must be made to the Global Catalog. Typically, each Active Directory site contains at least one global catalog server, so you must take global catalog-related replication traffic into consideration when planning for the initial deployment.

DNS considerations

Another area in which a lab deployment may differ from a real-life deployment is in the DNS requirements. In a lab environment, you can get away with deploying Live Communications Server without having to perform any additional DNS-related tasks beyond those required by any other Active Directory environment. If you don't prepare the DNS Server ahead of time in a lab environment, you will receive a warning message in the installation log, but the installation will complete successfully.

The reason you should take the time to create some records on your DNS Server is that without certain records being present, client auto configuration will not work. This isn't a big problem in a lab environment, but automatic configuration is essential in a production environment because few administrators have the time to manually configure each client.

If you are deploying the standard edition of Live Communications Server, you must create a host record (an A record) that points to your Live Communications Server. If you are deploying the Enterprise Edition, then the host record must point to the IP address that's assigned to the Live Communications Server pool rather than to the individual servers within the pool.

In addition to the host record, you will also need to create a service record (an SRV record). In case you aren't familiar with service records, their job is to tell clients which protocol they should be using to communicate with a particular application. In the case of Live Communications Server, the SRV record is what actually facilitates automatic client configuration.

Even if you have created the various DNS records in your lab environment, you may find that you need to create a slightly different type of SRV record in a production environment. The actual contents of the SRV record will vary depending on whether or not TLS is encrypted, whether Live Communications Server is being accessed internally or externally, and the type of client application that is being used. The table below lists the information that you need in order to create the necessary SRV record:

I don't want to get into an in-depth discussion of DNS records, but I feel that I need to clarify the table above a little. If you look at Figure A, you can see the New Resource Record dialog box that is used when you create a new SRV record. If you look closely, you can see that I am creating a record for the service _SIPINTERNALTLS. If you look at the table above, though, you will notice that _SIPINTERNALTLS isn't one of the choices. The closest match is _SIPINTERNALTLS._TCP.

The reason for this is that the first portion of the service record (_SIPINTERNALTLS) is the service type. The second portion (._TCP) is the protocol that is being used. The protocol is selected from the Protocol drop-down list, rather than being entered on the Service line. Incidentally, none of the services listed in the table is available from the Service drop-down list by default. You must simply clear the contents of the Service drop-down list and manually type the name of the service that you want to use.

This is what the dialog box used for creating an SRV record looks like.

Before I move on, I also want to point out the "Port Number" and the "Host Offering This Service" fields shown in the figure. The port number should always be set to 5061, and the Host Offering This Service field should match your domain name.

TLS certificates

One last issue that I want to quickly address is that of the TLS certificates used by Live Communications Server. In a multi-domain deployment, you are likely to run into a situation in which multiple domains have a common Live Communications Server. When that happens, the clients in each domain will be expecting the DNS record for the Live Communications Server to match their own domain name. For example, users in domain1.com will expect a DNS record that reflects domain1.com. You can get around this problem by creating a separate host record for each domain, each of which points to the same IP address.

The problem with this configuration is that the TLS certificate is domain specific. If a TLS certificate references domain1.com, then users in domain2.com will receive an error message because the TLS certificate is registered to a different domain.

You can get around this problem by taking advantage of the certificate's "Subject Alternative Name" field. This field allows you to specify all of the domains for which the certificate should be used.

Conclusion

Unfortunately, I've only been able to scratch the surface in talking about the things that you will need to consider when preparing your network for a Live Communications Server deployment. Hopefully, though, I have given you enough information to get you past some of the biggest deployment hurdles.

About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.