Microsoft Office Communications Server (OCS) 2007, launched last month, enables corporate IT departments to provide telephones, instant messaging and web-based conferencing to users located anywhere in the world.

Few IT managers will be willing to rip out their existing communications infrastructure, whether based on analogue or IP private branch exchanges (PBXs), but those moving into new premises should consider OCS alongside other voice over IP (VoIP) alternatives.

OCS needs at least three Windows 2003 Server systems to support a minimum configuration delivering PSTN connectivity and access for external users. It also uses MS Internet Information Services, SQL Server 2005 and Active Directory; and it needs a certificate authority to be running on the network.

Preparation wizard
Most users will connect to OCS using the Office Communicator 2007 unified communications client, but OCS also enables staff to use the Office Live Meeting 2007 client to access web-based voice, video and application sharing communications sessions.

In addition, a plug-in for MS Outlook makes it easy for workers to schedule conferences with colleagues using Outlook to send invitations and to manage diaries. The downside of this is that the suite is relatively complex to set up and in most cases we would expect OCS installations to be managed by specialists.

We reviewed the Standard Edition of OCS using a VMware virtual machine configured with 512MB RAM and running Windows Server 2003 Enterprise Edition. The installation utility instantly spotted that Microsoft Visual C++ 2005 SP1 Redistributable was missing from our system when we ran it, and offered to install it alongside the requisite Microsoft dot-Net Framework 2.0.

Once this was done, we chose the Deploy Standard Edition option, which launched the Active Directory (AD) preparation wizard. As we do not normally use AD in our lab environment, we stopped the OCS wizard at this point and configured our Windows 2003 Server as an Active Directory Domain Controller (DC).

Although many of the steps taken by this wizard are automatic, several manual checks are included in the process, performed by typing a command line and inspecting a file to see the results.

Unfortunately the wizard was not foolproof, and failed at one point because our AD forest was configured to support legacy Windows 2000 servers. This forced us to use the AD Domains and Trusts management tool to raise our domain function level to Windows 2003 before the wizard could continue.

Similarly, we found Microsoft Internet Information Services is also needed. If it is not present it must be manually installed before the wizard can proceed. This mix of manual and automated steps seems to defy logic because the installation wizard went on to automatically install and configure Microsoft SQL Server 2005, which is needed by OCS and is normally sold as a separate product, whereas IIS is included in Windows Server.

Next, the wizard needed to configure a digital certificate to secure connections between clients and the OCS. As our network did not have a certificate authority (CA) we added Microsoft Certificate Services to our main OCS system. With this done we were ready to start OCS.

Deployment guide
The first task we performed was to use the Active Directory Users and Computers management tool to configure some user accounts so those users could log in to OCS. We right clicked on a user and found a new set of OCS menu options that can be used, for example, to quickly enable a user for OCS.

Having enabled some users for OCS access, we found our clients were initially unable to connect. A quick look in the client’s event log showed a message warning that a DNS service (SRV) record was needed to support automatic client logins, so we downloaded the OCS deployment guide for instructions on creating these records.

Though this requirement is mentioned in the wizard, most users will have to read the OCS deployment documentation before they are able to create SRV records.

After another failed connection attempt we again checked the event log on our desktop and found the client failed to connect because it did not have a trust relationship with our CA. A quick trip to the CA with our web browser fixed this and we were then able to connect our first desktop to the OCS server using Microsoft Office Communicator 2007. Most IT organisations would use remote management tools to configure client computers with this trust relationship.

At this point we found our LAN-based clients could connect to OCS using Office Communicator 2007, and the voice, video and instant messaging features worked as expected. While Office Communicator 2007 is the primary user interface into OCS, we were impressed by the integration of certain features into other Windows applications. For example, we liked the way we could see at a glance whether someone was currently available for email or an instant message simply by hovering the mouse over their email address in Outlook.

OCS also includes a subset of the functionality found in Microsoft Live Meeting, and we also installed the Office Live Meeting 2007 client software onto our XP desktop. Again, we suffered connection problems caused by an AD policy setting that prohibited any users from using the Live Meeting features in OCS, but we quickly corrected this using the OCS management tool.

To support connections from users outside the firewall, IT managers will need to use the installation wizard to install OCS Edge and Access Proxy servers. Likewise, in order to route voice calls from OCS to the public switched telephone network (PSTN) they will need to use the wizard to install an OCS Mediation Server, which converts the phone signals used by OCS into signals suitable for the PSTN. A third-party gateway server would also be needed to make the physical connection between the PSTN and the company LAN.