Now that Office Communications Server (OCS) 2007 R2 is RTM, I thought it would be nice to create an article on how to deploy a single Enterprise Edition OCS Server which is connected to an x64 SQL Server 2008 RTM Back-End Server. This article will be based off the OCS 2007 R2 RTM version. This article series is very similar to My OCS 2007 R1 RTM series here but will be based off the R2 RTM version instead of the R1 RTM version.
This article is to guide you through the entire OCS deployment process from scratch. This article will include the following:

  1. Certificate Services installation
  2. Single Enterprise Front End Server (No more expanded configurations) – with information on what to do to get a second Front End Server installed behind a Hardware Load Balancer
  3. Edge Server (Only Consolidated Edge Servers now) – NIC Configurations
  4. Dual-Homed ISA 2006 Installation to reverse proxy internal services

Lab Setup

Guest Virtual Machines

One Server 2008 Enterprise (Standard can be used) SP1 x64 Domain Controller which Certificate Services will be installed as the Enterprise Root Certificate Authority. Exchange 2007 SP1 is installed on separate computers. The purpose of Exchange in this lab is for Group Expansion where a Universal Distribution Group can be mail-enabled for it to be expanded within Office Communication 2007. Alternatively, a Distribution Group can be given an e-mail address in its AD properties which satisfies the requirements of Group Expansion.
Two Server 2008 Enterprise (Standard can be used) x64 (x64 required) Member Servers where OCS 2007 R2 will be installed. One of these servers will be the Consolidated Edge Server which will contain 4 NICs.
One Server 2003 Enterprise (Standard can be used) x86 (x86 required) Member Server where ISA 2006 will be installed as a dual-homed box.
One Server 2008 Enterprise (Standard can be used) x64 (x86 can be used) Member Server where SQL 2008 is installed.
IMPORTANT: OCS 2007 R2 introduces some new AD requirements:

  • All Global Catalogs in the forest must be at least Windows 2003 SP1
  • All Domains which will have OCS 2007 R2 or users enabled for OCS 2007 R2 will need to be at least Windows 2003 Domain Functional Level which is obvious due to the next requirement. These Domain Controllers must be at least Windows 2003 SP1.
  • The forest in which OCS 2007 R2 will be deployed needs to be at least Server 2003 Functional Level.


  • You have a domain that contains at least one Server 2003 SP2 Domain Controller (DC)
  • You have configured the IP settings accordingly for all servers to be on the same subnet. I have provided the IP scheme of my lab below, but this will vary depending on your needs and Virtualization Software configuration. One exception to this is one NIC on the ISA Server will belong to a different subnet. This NIC would be the NIC that lives in the DMZ in a production environment.
  • Exchange 2007 Hub Transport Server, Client Access Server, and Mailbox Server are already installed in the environment. This article does not go over the installation or configuration of these roles but will go over mail-enabling a Distribution Group(s).
  • You have at least SQL 2005 SP2 server installed. We will be using SQL 2008 installed on Server 2008 Enterprise. SQL 2005 SP1 is NOT supported for OCS 2007 R2 as it was for OCS 2007 RTM.
  • You have a copy of Office Communicator (OC) 2007 R2. We will be installing our copy of OC 2007 R2 on our Exchange CAS.

Computer Names

OCS Front End Server – SHUD-OCSFE1
Domain Controller / Exchange Server / Root Enterprise CA – SHUD-DC2
ISA 2006 Server – SHUD-ISA1
SQL Server – SHUD-SQL1
Configuration of Domain Controller / Root Enterprise CA

Processor: 4
Memory: 512MB
Network Type - External NIC
Virtual Disk Type – System Volume(C:\): 50GB Dynamic
Note: In a real-world environment, depending on the needs of the business and environment, it is best practice to install your database and logs on separate disks/spindles. We will be installing Active Directory, Certificate Services, and Exchange 2007 SP1 on the same disks/spindles for simplicity sakes for this lab.
Configuration of SQL 2008

Processor: 4
Memory: 512MB
Network Type -External NIC
Disk Type – System Volume(C:\): 50GB Dynamic
Configuration of ISA 2006 SP1

Processor: 2
Memory: 384MB
Network Type -External NIC
Network Type -External NIC
Virtual Disk Type – System Volume(C:\): 25GB Dynamic
Configuration of OCS 2007 R2 Edge

Processor: 4
Memory: 512 MB
Network Type -External NIC – used for internal NIC
Network Type -External NIC – used for Audio/Video Edge NIC
Network Type -External NIC – used for Web Conferencing Edge NIC
Network Type -External NIC – used for Access Edge NIC
Virtual Disk Type – System Volume(C:\): 50 GB Dynamic
Note: There are few different ways the NICs could be set up on the Edge Roles. I have included a mini-write up below entitled, “Various Edge Server NIC Setups.”
Configuration of OCS 2007 R2 Front End

Processor: 4
Memory: 512MB
Network Type -External NIC
IP Addressing Scheme (Corporate Subnet)

IP Address – 192.168.1.x
Subnet Mask –
Default Gateway –
DNS Server – (IP Address of the Domain Controller/DNS Server)
IP Addressing Scheme (DMZ Subnet)

IP Address – 10.10.10.x
Default Gateway – 10.10.10.x
Subnet Mask –
Preparation of ISA 2006 SP1 Node

Network Interface Card (NIC) Configuration

First thing we will want to do is configure the IP Configuration of both the Public DMZ NIC and Internal Corporate NIC.
We will want to rename our Publc DMZ NIC connection to Public and our Internal Corporate NIC connection to Private. To do so, go to Start > Control Panel. Once in the Control Panel, Double Click on Network Connections.

Now you will be presented with the Network Connections window. This is where you can modify the network properties for each NIC in your server. For your Internal Corporate Connection, rename your Local Area Connection to Internal. Likewise, for your Public DMZ Connection, rename your Local Area Connection to Public. After you have done this, it will look something similar to the following:

Note: Do not forget that part of the assumptions earlier in this article as that you have a properly configured TCP/IP Network where all nodes are properly connected to the TCP/IP Network. Because of this, I will skip the actual TCP/IP Configuration. The IP for the Internal NIC is The IP for the Public NIC is that would typically have a Public IP NAT’d to this Public IP via Static Network Address Translation (NAT) rule.
Important: In a production environment, you would generally have the Default Gateway on your public NIC. Depending on the communication and configuration of firewalls, you would want to create a static route so your internal communications would go directly to a router on the inside of your network that is more open to communications. This way, you would not have to open ports on your Edge firewall when not necessary. For example, if you were doing LDAPs and your DMZ Edge Firewall blocked port 636. You would need to create a static route so traffic destined to your internal corporate network would go to the internal router that allows 636. You would not need to do this if your DMZ Edge Firewall allowed port 636 and knew how to route to the internal corporate network.
To ensure you reduce the attack surface of your ISA Server, open the Public NIC properties, open the TCP/IP Properties > go into the Advanced NIC configuration settings by clicking the Advanced button. From there, you will navigate to DNS tab and de-select “Register this connection’s addresses in DNS.”

Select the WINS tab and de-select “Enable LMHOSTS lookup” and configure the NetBIOS setting to “Disable NetBIOS over TCP/IP.”

Once you are done configuring the Advanced settings, press OK three times and you will be back at the Network Connections screen. From here, choose Advanced and select Advanced Settings

You will be presented with the Binding Order for your current NICs. Ensure that the Internal NIC is on top by selecting Internal and pressing the green up arrow key on the right-hand side of the dialog. The reason you want Internal on top is because your Corporate communications happen on this NIC and things like DNS are configured on this NIC.

Rename Computer and Join to Active Directory Domain

Make sure you name your ISA box to a name that complies with your naming convention and then join your ISA box to the domain. For purposes of this lab, we will be naming this box, SHUD-ISA1. A lot of Administrators believe that joining the ISA box to the domain is a security threat, but that is not so. Please refer to this article explaining why.
Preparation of Edge Node

Follow through the same exact steps you did for the ISA 2006 node except for a few things. Instead of 2 NICs, add 4 instead. Also, do not join it to the domain.
A summary of the steps involved consist of:

  • Create 4 NICs
  • Rename the NIC that is wired to the Internal Corporate Network to Internal
  • Rename the NICs that are wired to the DMZ appropriate to their function. Our Access Edge NIC will be named AccessEdge. Our Web Conferencing Edge NIC will be named WebConfEdge. Our Audio/Video Conferencing Edge NIC will be named AudioVideoConfEdge.
  • Assign the appropriate IP Addresses to each NIC. In OCS R2, when you have a single Edge Server, you no longer need to have a Public IP directly on the NIC. When load balancing Edge Servers, the Audio/Video server also has a private IP but the VIP of the load balancer will need to have a Public IP for the A/V Role. This will be discussed more in detail below.
  • Create Static Routes if necessary
  • Disable the Public NICs from registering in DNS
  • Disable the Public NICs NetBIOS settings
  • Modify the Binding Order so the Internal NIC is on the top of the list.
  • Rename the Computer
  • Do NOT join it to the domain

Certificate Authority Configuration

IMPORTANT: Just as a note, the instructions below are for setting up a Certificate Authority in Server 2003 and is from my previous article series on setting up a OCS 2007 RTM. My lab has the certificate authority set up on my Server 2008 Domain Controller and has already been deployed prior to this article series. The process for setting up the Certificate Authority is virtually identical. Because of this, I am not going to set it up all over again just to have the updated pictures via a Server 2008 GUI. the only difference is that in my existing lab environment where the CA lives on Server 2008, the Root CA will be simply named CA.

So as for how to set up a CA on Windows Server 2003 SP2, we will want to make sure that we have the SP2 binaries and our CD1 for our Windows Server 2003 Enterprise installation. It will be required when we install Certificate Services.
To begin the CA installation, go to Start > Control Panel. Once in the Control Panel, Double Click on Add or Remove Programs.

Click Add/Remove Windows Components.

Place a checkmark in the checkbox next to Certificate Services. You will automatically be prompted with a prompt warning you to not modify the computer name. Ensure your computer name is set correctly before continuing. Once you have your computer name set. Click Yes and then Next to Continue.

Because we will be choosing an Enterprise Root CA, leave the defaults selected. Click Next to Continue.
Note: Choosing an Enterprise Root CA can be considered a security risk to many. Make sure a proper design for a PKI infrastructure is done for both functionality, security, etc. before deploying an internal PKI solution for your organization. I am using an Enterprise Root CA because I am doing this in a test environment and it reduces the amount of resources needed for the lab.

We will name our Root CA OCS-CAROOT. Keep in mind, this is not our machine name. This is what the root certificate’s name will be. As stated earlier, this is the CA name we specified in the OCS 2007 RTM article series. If you want to follow along more closely and have the naming convention the same as the rest of the OCS 2007 R2 article series, name the Common Name CA. Click Next to Continue.

Specify where you want to store your Certificate Database and Logs. For purposes of this lab, we will install it on our System Partition (C:\). Click Next to Continue to begin installation. As stated earlier, make sure you have the SP2 binaries and CD1 of your Server 2003 Installation CD.

If you’re like me and always forget to install Internet Information Services (IIS) prior to installing Certificate Services, you will get the following prompt. Don’t worry, we’ll fix this after our Certificate Services installation completes. If you did get this prompt, Click OK to Continue.

Now our Certificate Services Installation should complete successfully. If you did forget to install IIS before Certificate Services installation began and you received the prompt above, go install IIS by following the instructions here. You will also need your SP2 binaries and CD1 of your Server 2003 Installation CD.
Once IIS is installed, to create the CertSrv subfolder within IIS, type the following command:
Certutil -vroot

Various Edge Server NIC Setups

When going over the NIC configuration of our Edge Servers, it has been noted that we will be using 4 NICs for our Consolidated Edge Server. This would be Method #1 below. As you can see, there are two other ways the NIC Setup could be configured.

Note: The IPs in the above diagram do not represent IPs we will be using in our lab. They are only a representation of what you may see in a production environment.
Method #1 (Recommended)

Every Role has its’ own dedicated NIC. This is recommended due to people having issues in the past with communications when roles share IP Addresses on the same NIC.
Method #2

It is also possible to use one NIC for the Audio/Video Edge Server, Web Conferencing Edge Server, as well as the Access Edge Server. Because of this, all 3 Edge Server Roles would have Private IPs meaning they can all be on the same NIC. You would then use a dedicated NIC for the Internal NIC.
Private IP on Audio/Video
In OCS R1, an Audio/Video Edge Server needed a Public IP directly on the NIC. In OCS R2, when you are doing a single Edge deployment with no load balancer, you can have a private IP directly on the Audio/Video Edge NIC. When load balancing, you can also utilize a private IP on the Audio/Vide NIC, but the load balancer IP must be a public IP Address which then NAT’s to the Private IP Address of the Audio/Video Edge NIC.
As you can see, when utilizing Load Balancing on an Edge, you must now use DNAT for incoming connections with a public IP of which then NAT’s to the private IP on the Audio/Video Edge NIC of The same happens outbound except for SNAT being used instead of DNAT. The incoming DNAT and outbound SNAT is a requirement.


Well folks, that is all for Part 1 of this article. For Part 2, I will go over the preparation and installation of a Front End OCS 2007 R2 Server Pool.

موضوعات مشابه: