Microsoft Office Communications Server 2007
Redmond on the line
Reviews August 19th, 2008
Microsoft's platform for voice and video conferencing, instant messaging, web conferencing and VoIP has matured since its previous version, called Live Communications Server, and could now be a viable alternative to other office telephone solutions.
OCS 2007is is thoroughly integrated into the Windows software environment, making it a good fit for firms that already have a modern Active Directory deployment.
Installation procedure quite complex, with several manual steps required. Active Directory running in Windows 2003 mode required.
By Roger Howorth

Microsoft Office Communications Server 2007, launched on October 16th, enables corporate IT departments to provide telephones, instant messaging and web based conferencing to users located anywhere in the world. We don’t expect many firms to rip out their existing communications infrastructures, but organisations moving into new premises should consider OCS alongside other VoIP and traditional ISDN based alternatives.

However, a minimum configuration supporting PSTN connectivity and access for external users requires at least three Windows 2003 Server systems. OCS also uses MS Internet Information Services, SQL Server 2005 and Active Directory; and it needs a certificate authority to be running on your network. Most users will connect to OCS using Office Communicator 2007, but OCS also enables users to participate in web based voice-, video- and application sharing conferences, and users would run the Office Live Meeting 2007 client to access these features.

In addition, a plug-in for MS Outlook makes it easy for people to schedule various types of conference with other people using Outlook to send invitations and to manage diaries. Consequently in our tests we found the suite relatively complex to setup. We expect most OCS installations to be managed by specialists in much the same way as most Exchange and SQL Server systems have trained administrators.

We reviewed the Standard Edition using a VMware virtual machine running Windows Server 2003 Enterprise Edition and configured with 512MB RAM. With the OCS Cd-Rom loaded in our server, the autorun feature started the installation utility automatically. First, the utility spotted that Microsoft Visual C++ 2005 SP1 Redistributable was missing from our system. As this is needed by OCS the wizard offered to install it. Next a similar dialogue offered to install the Microsoft dot-Net Framework 2.0 which is also needed by OCS. With these steps covered, the main installation utility menu appeared offering several options, such as Deploy OCS Standard Edition, Deploy Other Server Roles and Install OCS admin tools.

We used the Deploy Standard Edition option, which launched the Active Directory (AD) preparation wizard. As we don’t 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). Clearly we could have ran the wizard on any AD DC on our network if we so wished. Although many of the steps taken by this wizard are automatic, several manual checks are included in the process, which are performed by typing a command line and inspecting a file to see the results.

Unfortunately the wizard was not foolproof. For example, the wizard failed at one point because our AD forest was configured to support Windows 2000 servers. We needed 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 and if not present it must be manually installed before the wizard could proceed. This mix of manual and automated steps seems to defy logic as 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 the certificates done we were ready to start OCS.

At this point we used the Active Directory Users and Computers management tool to configure some user accounts so those users could login 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 SRV record was needed to support automatic client logins, so we downloaded the OCS deployment guide for instructions on creating these records. While the SRV record requirement is mentioned in the wizard it is not documented enough for most users to be able to create the SRV record without first reading the deployment documentation. 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, so at this point we also installed the Office Live Meeting 2007 client software onto our XP desktop. Again, at first the client would not connect to our server. This time we found the problem was caused by an AD policy setting that prohibited any users from using the Live Meeting features in OCS. We used the OCS management tool to correct this.

To support connections from users outside the firewall we would have needed 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) we would have needed to use the wizard to install an OCS Mediation Server, which converts the phone signal s used by OCS into signals suitable for the PSTN. A third-party gateway server would also be needed to make the physical connection between PSTN and our LAN infrastructure.

Leave a Response

You must be logged in to post a response.