When Microsoft released Exchange Server 2007, one of the new features that received the most attention was unified messaging. Out-of-the-box unified messaging was certainly new to Exchange, but it wasn't Microsoft's first product to focus on unified communications. Long before Exchange 2007, Microsoft had created a unified communications product called Microsoft Office Live Communications Server (LCS). LCS was a nice first attempt at providing true unified communications capabilities, but it was really difficult to set up, and as with any first-generation product it was a bit lacking.
In 2007, Microsoft released a new version of LCS that was named Microsoft Office Communications Server 2007 (OCS). Like its predecessor, OCS was designed to be a full-featured unified communications platform, but it was still missing some features. As you may have already guessed, the features that OCS lacks have been incorporated into Exchange Server 2007. In fact, the two products were designed from the very beginning to be complementary and to integrate with each other.
An Introduction to OCS 2007
In my personal experience, OCS is, by far, the most difficult Microsoft product to deploy. The initial configuration process usually takes several hours to complete, and I have to admit that running the product for the first time after the installation completes is a bit anticlimactic. That's because on the surface, OCS seems like nothing more than an instant messaging server. Granted, instant messaging is nice, but OCS can be a bit of a letdown if you are expecting it to initially act as a comprehensive communications solution.
All is not as it initially appears, however. First, it's important to keep in mind that instant messaging is a type of communication, so it fits in perfectly with the goal of creating a unified communications platform. More importantly, though, a basic OCS deployment supports the use of presence information.
Presence is a very important part of any unified communications system. One of the problems with offering users so many different ways of communicating with each other is that it can become difficult to know how to contact a user. You don't know which communications method the user prefers, whether a user is available, or the best way of reaching a user at a given moment. Presence solves all of these problems by acting as a mechanism through which users can convey their availability status.
I'll be the first to admit that in a basic OCS deployment, the way that presence is used really isn't all that impressive. It's basically just used to tell users which other users are currently available for instant messaging chats. Even so, this presence information is extended as your unified communications deployment grows. When the full deployment process is complete, presence information becomes a definitive means for conveying if, when, and how users on your network can communicate with one another.
Another thing that I want to explain about OCS is that presence and instant messaging aren't the only capabilities that it can provide. In fact, OCS can be configured to allow users to make telephone calls from their PC. It also supports point-to-point videoconferencing and some other collaborative tools.
Although OCS 2007 clients can place and receive VoIP-based telephone calls from their desktop, OCS doesn't provide all of the calling features that most organizations would probably expect. The most obvious feature it lacks is voicemail. Of course, this is where Exchange comes into play. Exchange Server 2007’s unified messaging component allows voicemail and faxes to be received and stored in a user's inbox, alongside their e-mail messages.
Exchange Server 2007 also provides a feature called Outlook Voice Access (OVA), which is basically a telephone version of Outlook Web Access (OWA). This feature allows users to dial into the Exchange organization and check their calendar and messages over the telephone. OVA provides much of the same basic functionality that OWA provides, with the biggest difference being that users interact with Exchange over OVA solely through the telephone. You can configure OVA to accept verbal or touch tone input.
Preparing an Enterprise Pool
The first decision that you need to make is what IP address you're going to assign to your OCS server. OCS requires the server that is hosting it to have a static IP address, and even though you're not even installing OCS yet, you are going to need to decide on this address up front so that you can complete the preparation work.
Once you've decided on an IP address, pick a name for your enterprise pool. An enterprise pool is simply a group of OCS servers that work together to balance the unified communications workload. An enterprise pool is required even if you're only going to be installing a single OCS server. If you deploy additional OCS servers later on, you can easily make them a part of your enterprise pool.
The actual process of creating the enterprise pool is something that I will be covering in the next article in the series. For now though, you need to pick a name for the enterprise pool. You can use pretty much any name that you want, so long as no other objects in the domain that your OCS servers will be residing in have the same name. It's important to remember that the pool name is different from the name of your OCS server.
Once you've decided what you want to call your enterprise pool, you're going to have to determine the pool’s fully qualified domain name (FQDN). To do that, simply append the name of the domain that the server is a member of to the end of the pool name. For example, if the server resides in a domain named Contoso.com, and the enterprise pool name is MyPool, then the pool’s FQDN would be MyPool.contoso.com.
Now that you know what the enterprise pool’s FQDN name is going to be, you're going to need to create a Host (A) record for it on your DNS server. The actual steps that you perform to do this will vary depending on the type of DNS server that you have installed on your network. For a Windows Server 2008 DNS server, follow these steps:
- Open the DNS Manager console.
- Navigate through the console tree to DNS, then your DNS server, then Forward Lookup Zones, then your domain.
- Right-click the container corresponding to your domain name, and choose the New Host (A or AAAA) command from the shortcut menu.
- Windows will now display the New Host dialog box. Enter the pool name into the Name field.
- Verify that the FQDN matches the name that you came up with earlier.
- Enter the OCS server’s IP address into the IP address field, as shown here.
- Click the Add Host button.
- Click OK to clear the message telling you that the new record has been created.
- Click the Done button.
- Verify that the new host record appears in the container for your domain.
Now that you've created a host record, you need to create a service record. A service record is a special kind of DNS record that tells the machines on your network where to look for specific types of network services. In this particular case, you need to create a service record for SIP internal TLS.
SIP an acronym standing for Session Initiation Protocol. SIP is the protocol that is used to create, manage, and terminate unified communications sessions. SIP doesn't provide any services itself, but rather provides a framework for higher level protocols.
Once again, the exact steps that you will have to follow to create the service record will vary depending on the type of DNS server that you're using. To create the service record on a Windows 2008 DNS server, follow these steps:
- Open the DNS Manager console.
- Navigate through the DNS Manager tree to DNS, then your server, then forward Lookup Zones, then your domain.
- Right-click the container for your domain, and choose the Other New Records command from the shortcut menu.
- Windows will now display the Resource Record Type dialog box. Scroll through the list of record types, choose the Service Location (SRV) option, and click the Create Record button.
- At this point, Windows will display the New Resource Record dialog box. This dialog box can be a bit misleading, because if you simply click on the Service drop down list, there are only a few options available to you. You do however have the option of manually entering test into the Service field, which is what you're going to have to do. Therefore, enter _sipinternaltls into the Service field.
- Next, enter _tcp in the Protocol field.
- Enter 5601 in the Port Number field.
- Enter the enterprise pool’s FQDN into the Host Offering this Service field, as shown here.
- Click OK.
- Click Done.
- Verify that a container named _tcp has been created in the DNS Manager console beneath the listing for your domain, and that it contains the _sipinternaltls record, as shown here.
Click to expand
Prepare the OCS Server
Even though I'm not discussing how to actually install OCS here, you need to take some steps to prepare the server that OCS will be running on. More specifically, this means installing Windows onto the Server, and meeting a few other prerequisites.
OCS 2007 was released before Windows Server 2008, so this means that your OCS server is going to have to run Windows Server 2003 Enterprise Edition with SP1 or higher or Server 2003 R2. That’s just the beginning though. There is a whole laundry list of other software requirements for your OCS 2007 server.
You also need SQL Server 2005 with SP2 or higher. Generally speaking, your OCS deployment will perform better if SQL is installed onto a separate server, but for lab deployments or for small scale production deployments, you can get away with installing SQL server directly on your OCS server.
Although it isn’t going to be a problem for most organizations, you must also make sure that any Active Directory domains in which OCS servers will be present are running Windows 2000 Native Mode or higher.
One component that must be installed onto your OCS server is IIS 6.0. When you install IIS, you must make sure to install the Active Server Pages component.
The last prerequisite component that you need to have in place is an enterprise certificate authority. In most cases, an enterprise certificate authority should be installed on a dedicated server for performance and security reasons. In a lab environment or in a small company it is sometimes a common practice to install the certificate services onto a domain controller. If you need assistance with this step, then I recommend checking out this article by Robert McIntosh. Although the article pertains to Windows 2000, the steps involved in setting up an enterprise root certificate authority really haven't changed very much since the days of Windows 2000.
Create UNC Shares
Once the necessary DNS records are in place, create a few UNC shares on your OCS server. You can call these shares anything that you want, but it's important that you keep track of the names that you use, and that you create four separate shares. OCS can't use a single share for multiple purposes. The four shares that you will have to create are going to be used for meeting content, meeting metadata, meeting archives, and address book information.
The first three of these shares will be used to store data related to collaborative sessions. The Address book Information share will be used to store contact information for the OCS users. For our purposes, a default share will work fine. You don’t have to worry about applying any type of security to the shares right now, because you'll take care of that later in the configuration process.
Related Reading:
