RSS Subscription 167 Posts and 2,769 Comments

Blog Archives

Office Communications Server 2007 R2 Group Chat Deployment – Part 1

Now that Office Communications Server (OCS) 2007 R2 is RTM, and that I have already created an article series on how to deploy OCS R2 Enterprise Edition Front End Servers and Edge Servers here, I thought it would be nice to create an article on how to deploy a Group Chat Server with Compliance which is connected to an x64 SQL Server 2008 RTM Back-End Server.

This article series is to guide you through the entire OCS Group Chat deployment process from scratch. Part1 will include the necessary pre-work that is required in order to begin the installation states of the Chat Server. This includes:

  1. Creating our SQL Database
  2. Creating our Group Chat Services and assigning the necessary permissions on SQL and our Group Chat Server

Part 1

Part 2

Lab Setup

Guest Virtual Machines

There will be two new virtual machines being introduced into the same lab I set up for my OCS R2 Article series which is located here.  The same exact lab set up you see in that article series still exist in this lab environment.  The only difference is one out of my two Domain Controllers is running Server 2008 R2 Beta.  The Certificate Services Domain Controller is still running Server 2008.

Two new virtual machines will be introduced.  Two Server 2008 Enterprise (Standard can be used) x64 (x64 required) Member Servers.  One server will contain Group Chat and the other server will contain the Compliance Service.  The Compliance Service requires a dedicated server; something I hope changes in the future.  Both servers will contain a single NIC.

Assumptions

  • 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.
  • You have at least SQL 2005 SP2 server installed. We will be using SQL 2008 installed on Server 2008 Enterprise.
  • You have a copy of Office Communicator (OC) 2007 R2 Group Chat. We will be installing our copy of Group Chat client on our Exchange CAS.

Computer Names

OCS R2 Group Chat Server – SHUD-OCSPG1

OCS R2 Compliance Server – SHUD-OCSPG2

Configuration of OCS 2007 R2 Group Chat Server

Processor: 4

Memory: 512MB

Network Type External NIC

Configuration of OCS 2007 R2 Compliance Server

Processor: 4

Memory: 512MB

Network Type External NIC

IP Addressing Scheme (Corporate Subnet)

IP Address – 192.168.1.x

Subnet Mask – 255.255.255.0

Default Gateway – 192.168.1.1

DNS Server – 192.168.1.150 (IP Address of the Domain Controller/DNS Server)

Group Chat SQL Database Creation

We will be using the same database for both Group Chat Server as well as the Compliance Server.  It is possible to use a different database for both, but the Compliance Server can also use the Group Chat database.  We will utilizing a single database for both servers.  So let’s go ahead and create our database.

Load up the SQL Management Studio and logon to your instance with someone who has the following permissions (I’m using the Administrator account since it’s a lab):

  • Create Database
  • Create any Database
  • Alter Any database

Right-Click Databases and create a new database.  I called it PG.

We must also ensure the database collation is set to SQL_Latin1_General_CP1_CI_AS by Right-Clicking our database, choosing Properties, going to the Options page, and choosing SQL_Latin1_General_CP1_CI_AS.

Group Chat Service Accounts

Group Chat requires several services which will then need to be manually added to the Local Administrators group.  These accounts then need to be added as SQL Server accounts and be assigned permissions to the SQL Database.

We will be creating 2 services.  You will want to ensure that the Lookup Service is named OCSChat.  The other services can be named anything you want.  Another thing to note, is that if you have multiple Group Chat Servers, OCSChat will be used on all Group Chat Servers as the same Lookup Service needs to be used on all Group Chat Servers.  The Channel Service is unique per server.

OCSChat requires a SIP enabled account.  Because we will need to have an OCS R2 Front End environment already up and running, go ahead and SIP enable the account.  As you can see, I have SIP Enabled this account.

We need to add these two service accounts to our local Administrators group.

SQL Server Accounts and Permissions

Let’s head back into SQL Server Management Studio.  Under Security, we will Right-Click and Create a new Login.  Add both of our OCS Group Chat Service Accounts.  As you can see, both OCSChat and OCSChannel have been added.

We will now need to Right-Click on each Service Account, choose Properties, and choose the User Mapping category.  Select our PG database and assign the service account the role of db_owner.  Do this for both service accounts; both OCSChannel and OCSChat.

Summary

Well folks, that is all for Part 1 of this article. For Part 2, I will go through the OCS R2 Group Chat Server installation as well as the Administrative Tools.

Share

Default Gateways and Multihomed Edge Boxes

I seem to encounter this issue quite often and felt this topic warrants a dedicated blog post.  The basic point of this post is to explain that you cannot have more than one default gateway on separate NICS on a multihomed server!  Well, technically you actually can, but things won’t work correctly. Now I am not saying that you cannot have multiple Default Gateways on a specific NIC as this is quite possible as Windows will assign metrics so one Default Gateway is given priority over another which provides redundancy.  What I am saying is that you cannot have a Default Gateway on one NIC and then assign a Default Gateway on another NIC.

Any time I have seen Multihomed Servers (OCS Edge, Exchange Edge, ISA, Etc.) malfunctioning, the first thing I’ll do is a  ROUTE PRINT. Quite often, I’ll see several lines that display:

0.0.0.0

0.0.0.0

0.0.0.0

0.0.0.0

That instantly tells me that multiple Default Gateways are assigned.  You should only be seeing one line with 0.0.0.0. The entire point of a Default Gateway is it’s the last resort on where to send a packet.  Now with that in mind, does it make any sense to have multiple last resorts?  No!

So please, put the Default Gateway on only one NIC.  For OCS, I typically put it on the Access Edge NIC.  For Exchange Edge/ISA, I put it on the Internet Facing NIC.  Ok, so you may be thinking, well my external router doesn’t allow RDP traffic…  How am I going to manage my box from the inside since the RDP packets will be blocked at the external firewall?  What I always do on an Edge Server (and you should also be doing this on any multi-homes DMZ/Edge Server including ISA), is create static routes so any internal traffic will go to your internal network from your internal NIC.  It’s essentially creating a fake Default Gateway for only specific subnets (your internal subnets) set on your Internal NIC.

So let’s say you’re setting up an OCS Edge Server and it has 4 NICs:

Access Edge – 10.10.10.100 (DMZ Subnet) – Default Gateway Assigned here

Web Conferencing Edge – 10.10.10.101/24 (DMZ Subnet)

Audio / Video Edge – 10.10.10.102/24 (DMZ Subnet)

Internal NIC – 192.168.200.100/24 (Internal Network)

So how can we get all internal traffic to go out directly through the Internal NIC even though the Default Gateway is assigned to the Access Edge?  As stated before, we’ll create a static route.  So let’s say your internal router is 192.168.200.1, we’ll create a static route using the following syntax

route add 192.168.200.0 mask 255.255.255.0 192.168.200.1 -p

So for anything destined to the 192.168.200.x network (due to mask being 255.255.255.0 it will route to the default gateway of 192.168.200.1.  And Windows is smart enough to see that 192.168.200.1 is on the same subnet as your 192.168.200.100 NIC and assign that as the interface it should send it out of.  Problem solved!

Now what if you have a bunch of internal subnets that have similar address ranges?  Simple!  Supernet your internal networks!

route add 192.168.0.0 mask 255.255.0.0 192.168.200.1 -p

This supernet basically says anything that’s 192.168.x.x (only uses 1st 2 octets since you’re using a mask of 255.255.0.0 otherwise known as /16), send it to the 192.168.200.1 gateway.  And again, Windows is smart enough to see that 192.168.200.1 is on the same subnet as your 192.168.200.100 NIC and assign that as the interface it should send out of.  So if you have a 192.168.200.x, a 192.168.199.x, or a 192.168.198.x network, all those packets will route to the 192.168.200.1 router which will then send the packet to the appropriate subnet. Problem solved!

And the -p stands for persistent.  It means that the static route will survive a reboot.

All the above applies to ISA as well.  Let’s say you’re doing LDAPS authentication which uses port 636.  Your external router may not allow 636.  So by creating the static route to your internal network, the LDAPS traffic won’t be going through your external router and be blocked. It instead will go through your internal router which would most likely be allowing it as Internal Routers are more relaxed in their restrictions.

One thing to take into consideration is that if you are in an environment where the Default Gateways are assigned to all NICs and you modify your server to be properly configured with a Default Gateway on one NIC, make sure that any services such as remote backup on your server are allowed to access over the internet over the ports required for these services or things such as remote backup will start failing.

Share

Office Communications Server 2007 R2 Enterprise Deployment – Part 5

Welcome to Part 5 of this article series. So far in this article series, we have deployed an Enterprise Pool, configured our Pool, set up DNS, tested connectivity with Communicator 2007 R2, configured our ISA box, and prepared our Edge Servers.

In this Part, I will go through the part of the configuration of our Consolidated OCS Edge Server using a separate NIC for each Edge Role.

Part 1

Part 2

Part 3

Part 4

Part 5

OCS 2007 R2 Edge Server Installation

When installing an OCS 2007 R2 Edge Server, you would perform the following steps:

Note: Edge Server should not be joined to your Corporate Active Directory.

  1. Install Files for Edge Server
  2. Activate Edge Server
  3. Configure Edge Server
  4. Configure Certificates for Edge Server
  5. Start Services
  6. Validate Edge Server

Install Files for Edge Server (Step 1)

To begin the Edge Server installation process, we can insert our OCS CD (Standard can be used for Edge).  There are some prerequisites for installing OCS such as .Net Framework 3.5 SP1, but this is all taken care of during the installation.

Insert the CD and let’s begin the installation process.  You will be asked to install the Microsoft Visual C++ 2008 Redistributable. Click Yes to Continue.

You will then be asked to install the Microsoft .NET Framework 3.5 SP1. Click Yes to Continue.

Once Microsoft .NET Framework 3.5 SP1 is installed, you will be presented with the Deployment Wizard.  We will want to deploy our Edge Server in a Consolidated fashion..  Click Deploy Other Server Roles > Deploy Edge Server to Continue.

We are now on Step 1 which is to Install Files for Edge Server. Click Install for Install Files for Edge Server to Continue after meeting the Prerequisites (being a local Administrator).

On the Welcome Screen, Click Next to Continue. After fully reading the License Agreement, if you agree, Select “I accept the terms in the license agreement .”  Click Next to Continue.

You will be asked for Customer Information such as Product Key, Name, and your Organization Name.  Enter them appropriately. Click Next to Continue.

Enter the location you want your files to be installed.  I chose the default location. Click Next to Continue.

You are now ready to start the Installation.

Once you completed the File Installation, you should see the Installation Interface update the Step 1 Status showing as Completed.

Activate Edge Server (Step 2)

Click Run for Active Edge Server to Continue.

On the Welcome Screen, Click Next to Continue.

In OCS 2007 R1, you’d be prompted for what roles to install.  In OCS 2007 R2, there are only Consolidated Edge Servers.  Because of this, you will not be prompted for roles to install.

You will now be prompted to specify passwords for your Service Accounts.  I recommend to use long secure passwords.  You can view this and this site which assist in choosing strong passwords.  You will have to do this for several Service Account: RTCProxyService

Once you have set a password, Click Next to Continue.

You are now ready to Activate your Edge Server.  Review your Current Settings.  After satisfied, Click Next to Continue.

When the Activation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

Once you completed the Activation, you should see the Installation Interface update the Step 2 Status showing as Completed.

Configure Edge Server (Step 3)

Click Run for Confingure Edge Server to Continue.

On the Welcome Screen, you will be prompted with a warning recommending that you stop all OCS Services.

Go ahead and stop all services (mine were already stopped). Click Next to Continue.

The next screen asks us if we have a Configuration File to use.  This file is great to use if we are deploying multiple Edge Servers that will be load balanced.  For example, it would be useful if I was going to be deploying two Edge Servers behind a Hardware Load Balancer.  I would configure my first Edge Server, and at the end of the configuration, it would ask me to export the configuration so I can import it on my second Edge Server.  Nifty!

Because this is our first and only Edge Server, Click Next to Continue.

We must choose the Internal IP of our Edge Server as well as its’ FQDN.  We are presented with the following options.

You may be wondering which IP to choose.  Remember back in Part 4 we configured four NICs.  One of these NICs was the Internal NIC which we configured as follows. We also configured a dedicated NIC and IP for each Edge Role.  Here is a list of NIC Names, their associated Edge Role, and IPs associated with them

So in our Edge Configuration, we will want to choose 192.168.1.180 for our Internal NIC.  We will also want to set the FQDN as  shud-ocsedge01.shudnow.net (computername.domain.com).  Because our server is not a domain member, we will need to manually add the DNS record in our Active Directory DNS due to the nature of Active Directory Secure DNS Zones only allowing domain members to add records to our zone. Click Next to Continue.

We now must configure the IPs and FQDNs for all three Edge Roles.  You can refer to the Excel List above to determine what IPs are associated with which role.

When a client connects to the Access Edge Server, the Access Server will return the URLs needed for the client to successfully communicate with services in the OCS organization.  For example, we will configure our Web Conferencing Edge Server to use webconf.exchange.shudnow.net.  Exchange.shudnow.net is our Internet DNS Zone.  So when a Live Meeting Client tries to connect to a web conference, our Access Edge will communicate with the client telling it the FQDN for the web conferencing edge.  The same applies for the A/V Edge Server.

Enter in the IP Configuration and FQDN accordingly.  Click Next to Continue.

We will want to use this Edge Server to allow anonymous users to join meetings as well as enable federation.  If you plan on allowing your users to talk with public IM providers such as AOL, MSN, and Yahoo, select those features as you see fit.

Now let me explain why Allow remote users to communicate with federated contacts is greyed out.  It is possible to set up two Edge Servers and use one Access Edge for Remote User Access and another for Federation and Public IM connectivity.  If you decide to do this, one one Access Edge you’ll disable Federation which will light up the currently greyed out option.  On the second Access Edge, you’ll disable Remote User Access and enable Federation.  Now keep in mind this is optional.  Because we will be utilizing one Consolidated Edge Server, we can choose the options as follows which will enable Remote User Access, Federation, and Public IM Connectivity through our Consolidated Edge. Click Next to Continue.

We want our Edge Server to be able to talk to the internal OCS Servers.  We have a few options.  If we are using a Standard Server as our next hop, we would enter the Standard Pool FQDN which would be the server’s FQDN.  If we deployed a Director, we would enter the Director (or FQDN of hardware load balancer). Because we deployed an Enterprise Pool, we will use the FQDN of the Enterprise Pool. Enter the Enterprise Pool FQDN OCSPool.shudnow.net. Click Next to Continue.

Because our SIP Domain will be exchange.shudnow.net, that is what we will choose when specifying what our Authorized Internal SIP Domains are.  Click Next to Continue.

We will then want to enter our internal OCS Pool Name for Authorized Internal Servers.  If you have more than one Pool or Standard Edition Server, enter them here.  Click Next to Continue.

You are now ready to Apply your Edge Server Configuration.  Review your Current Settings.  After satisfied, Click Next to Continue.

You are now ready to apply your configuration.  Review your Current Settings.  After satisfied, Click Next to Continue.

When the Configuration is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.  This is also where you’ll have the change to export your configuration if you’re deploying a second Edge Server for Hardware Load Balancing.

Once you completed the Configuration, you should see the Installation Interface update the Step 3 Status showing as Completed.

Configure Certificates for Edge Server (Step 4)

Click Run for Configure Certificates for the Edge Server to Continue.

On the Welcome Screen, Click Next to Continue.

I’m going to skip through a lot of this section as it consists of how to obtian a Certificate which I already went through in Part 4 when we discussed configuring our ISA Server.

I will be obtaining three certificates.  One is for our Internal NIC that consists of the FQDN of our Server (shud-ocsedge01.shudnow.net).  The second certificate will consist of  the names of our Access/Web external edge roles. The third certificate will be our A/V Authentication certificate.

Now you may be thinking, well, can’t I just use two certificates?  One for internal and A/V edge.  Well in our case, probably.  If you have multiple servers, no.  This is because each certificate for the internal interface will be unique due to the name of every server being different.  The A/V Authentication name will be the same and exported/imported on multiple servers.  Also, Microsoft considers it to be insecure by using the same certificate for both the Internal and A/V Authentication services.

Certificate One (Internal Interface):

CN = shud-ocsedge01.shudnow.net

Certificate Two (Access/Web Server Roles):

CN = sip.exchange.shudnow.net

SAN = sip.exchange.shudnow.net

SAN = webconf.exchange.shudnow.net

Note: Microsoft’s Official Support Policy requires you to have a separate certificate for each interface.  A SAN certificate for both will work though.

Certificate Three (A/V Authentication)

CN = av.exchange.shudnow.net

Now keep in mind the reason the namespaces our different is because the internal NIC is connected to our internal infrastructure and will be utilized internally only.  Because of that, we will be using our internal namespace that is also used as our default SIP routing domain.  Our edge servers will be contacted using the external DNS namespace.  If you are using split-DNS where your internal namespace is hosted on external DNS, you can use either namespace.

For purposes of this lab, I will obtain all certificates from our internal CA.  Because our Edge Server is not a domain member, you have to ensure it contains the Root Certificate from our Internal CA.  You will also have to submit the request, approve it, and submit the .cer file manually and import it manually due to our Edge server not being a domain member.

Note: In a production environment, you will be requesting your Access/Web Conferencing Certificates from a Third Party Vendor.  Both your A/V Authentication and Internal Interface NICs will be provided by your Internal CA.  The A/V Edge role doesn’t need an Internet Facing Certificate.

We will first choose to Create a new Certificate.  One you have done this, you will want to make sure you select only your Edge Server Private Interface.  Click Next to Continue.

You will want to go through the rest of the configuration which includes entering your Organization Name, Company Name, Etc…  As I said, when you are at the screen which consists of what FQDN to use, you will use the CN of shud-ocsedge01.shudnow.net.

Once you are finished preparing the request, you will see the Step being partially finished.  Click Run again to Continue.

You will now want to go through the motions of taking the .Cer file you obtained from your Certificate Authority and binding it to your request.

Follow this procedure with the remaining certificates.  Refer to the certificate CN/SAN names above as to what entries should be on your certificate.

Your Access/Web Conferencing Edge Certificate request will look like:

Your A/V Certificate request will look like:

Once you completed the Certificate Configuration, you should see the Installation Interface update the Step 4 Status showing as Completed.

Remaining Steps

I will not be going through the remaining steps.  It consists of Starting Services and Validating your Configuration.

The only remaining steps are to enable users, configure federation, and enable your Front End Servers to talk with your Edge Servers.  All this information is out of the scope of this article.  If you are interested in doing this (and you will have to connect your Front End Servers to your Edge Servers), visit this site here.

TIP: To adminster the Edge Server, type Start > Run > Compmgmt.msc.

Summary

Well folks, that is all for not just Part 5, but the entire article series. Hopefully these articles have helped you understand more on how the deployment of OCS works.  There is a lot more to the configuration of OCS and especially the deployment when you get into load balancing.  Much more than what I went into.  But hopefully the article gave you enough knowledge to know where to look and how the overall deployment process works.

Share

Office Communications Server 2007 R2 Enterprise Deployment – Part 4

Welcome to Part 4 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is how to deploy a single Enterprise Edition OCS 2007 R2 Server which is connected to an x64 SQL Server 2008 Back-End Server. We first discussed what the lab setup is going to be using Hyper-V, and then proceeded to the configuration of our Enterprise Certificate Authority. In Part 2, we went over the Environmental Preparation for our OCS 2007 R2 environment.  In Part 3, we went over the remaining steps required to deploying our Front End Server in an Enterprise Pool Deployment.

In this Part, I will go through the installation of our Office Communicator 2007 R2 client and get it connected through OCS by configuring DNS. I will then begin preparation of our Edge Servers followed by configuring our ISA 2006 Server.

Part 1

Part 2

Part 3

Part 4

Part 5

Front End OCS 2007 Server Installation

When installing OCS in a consolidated Enterprise Edition deployment, you would perform the following steps:

  1. Prepare Environment (Completed in Part 2)
    1. Prepare Active Directory (Completed in Part 2)
    2. Create Enterprise Pool (Completed in Part 2)
    3. Deploy Hardware Load Balancer (Completed in Part 2)
    4. Configure Pool (Completed in Part 2)
  2. Add Enterprise Edition Server to Pool (Completed in Part 3)
    1. Add Server to Pool (Completed in Part 3)
    2. Configure Certificate (Completed in Part 3)
    3. Configure Web Components Server Certificate (Completed in Part 3)
    4. Verify Replication (Completed in Part 3)
    5. Start Services (Completed in Part 3)
    6. Validate Server and Pool Functionality (Completed in Part 3)

Microsoft Office Communicator (MOC) 2007 R2

Installing MOC

Installing MOC is a rather straightforward process.  I won’t go over the installation steps as it is like installing any other application.

Logging onto MOC

In Part 3, we talked about holding off on DNS additions so when we install MOC, we can see what DNS is required to allow our client to log on.  So let’s try logging on with one of the users we created in Part 3.  The user we will log on as is OCS User 1 that has a SIP Address of ocsuser1@exchange.shudnow.net.

When we try to log on, we will get the following error message:

So let’s start adding DNS by entering our DNS MMC by going to Start > Administrative Tools > DNS.  We will then create a host record for our Pool (ocspool.shudnow.net).

Note: If you have multiple Front End Servers and are deploying behind a hardware load balancer, the IP Address in this host file will be pointing to your hardware load balancer.

After that host record has been created, we will need to create an SRV record so MOC clients can find DNS and automatically locate the OCS Front End Server.  But because we are using a separate namespace of exchange.shudnow.net, we will need to create either a new Primary DNS Zone for exchange.shudnow.net or by creating a new domain called exchange within our shudnow.net zone.  I elected to create an entire new zone.

Once your exchange.shudnow.net zone is created, we will then need to create a host record inside our new exchange.shudnow.net zone for sip.exchange.shudnow.net.

Create an SRV record within the exchange.shudnow.net zone that contains the following information.

Note: Internal clients can connect using either TLS or TCP while external clients can only connect to TLS.  If you want to allow your clients to connect to TCP, change the above to _SipInternal and change the port to 5060.

So let me explain what is going on here.  We created our DNS Pool record in our shudnow.net zone.  OCSPool.shudnow.net points to 192.168.1.163 which is the IP Address of our Front End Server.  Because our users are SIP Enabled for exchange.shudnow.net, we needed to create a new zone.  Typically, if you would have SIP enabled them for shudnow.net, we would just create our OCSPool A Record, and then create the SRV record to point to OCSpool.shudnow.net.

If you recall, when we retreived our certificate, it had DNS names of OCSpool.shudnow.net and sip.exchange.shudnow.net.  Because SRV records have to point to a DNS name within its own domain, we created our sip.exchange.shudnow.net A record within the exchange.shudnow.net zone.  We then created the DNS SRV record for automatic client logon to point to the sip.exchange.shudnow.net name which is a name in our certificate request.

So essentially the following happens in order:

  1. Client logs on using automatic logon
  2. Client looks for an SRV record for _sipinternaltls._tcp.SIPDomain (in our case _sipinternaltls._tcp.exchange.shudnow.net)
  3. DNS Server successfully returns sip.exchange.shudnow.net as the service from the SRV record
  4. Client connects to sip.exchange.shudnow.net and resolves that to 192.168.1.163
  5. Client is successfully enable to start communications with the Front End Server

Adding Distribution Groups to MOC

I have created a universal distribution group named Sales.  Our Sales distribution group was created within Exchange. A user named Simo notified me that a distribution group doesn’t necessarily have to be created within Exchange.  As long as the distribution group has the e-mail attribute filled in, OCS expansion will function.

Searching for Sales, we will see that it will display our Sales group.  We can add this group to our contacts list and we can expand the group information.

Your Communicator client will refresh the membership information every 24 hours against the web farm FQDN and update the cache file located at the following directory: %LocalAppData%\Microsoft\Communicator\sip_user@domain.com\.

For those that do not know, the Address Book files is what allow our clients to search for SIP enabled users and Distribution Groups.  It also providers other functionality such as Phone Number Normalization when doing Remote Call Control.  This information gets stored on our client as GalContacts.db in “%userprofile%\ Local Settings\Application Data\Microsoft\Communicator\.”  The Address Book gets updated in OCS every 24 hours which can be expedited by navigating to the following directory and running the following commands:

Preparation of OCS 2007 R2 Edge Node

Network Interface Card (NIC) Configuration

In Part 1, I put the Internal NIC on our VMNet8 which is our NAT Network.  I stated that I would put all other NICs on VMNet7.  When bringing up this server, I put all NICs on VMNet8 to ensure that there is IP Connectivity all around.  The reason for this is I don’t have VMNet7 and VMNet8 routed with each other. In a production network, I would following the OCS Planning Guide to ensure your networks are configured properly.  For example, your Internal NIC would be placed on your Internal Network while external adapters would be on a separate subnet such as a DMZ.

The first thing I always do is rename the NICs appropriately so you know what NIC you are working with.

On our Internal Edge NIC, we want to configure the IP Configuration as follows.  This NIC will contain the default gateway and DNS Settings.  Becuase of this, we will later ensure that this NIC is at the top of the binding order.

Our Audio/Video Edge NIC will be configured as follows.

Our Access Edge NIC will be configured as follows.

Our Web Conferencing Edge NIC will be configured as follows.

Binding Order

Set the Internal NIC to be at the top of the binding order.  This is because this is our internal corporations communications NIC.  It is the NIC that has DNS applied to it and will be talking to the rest of the internal servers.

ISA 2006 Configuration

Root Certificate

The first thing we will want to do is take the root certificate from our internal CA and place it into the Root Computer Certificate Store on ISA.  If your ISA box is part of the domain, if your CA is an Enterprise Root CA, your ISA box will automatically retrieve this certificate upon rebooting.  For any other type of CA configuration, you must manually obtain the Root Certificate.  The reason we we need this Root Certificate is because when we Bridge our external connection to our internal connection via SSL, we will need to trust the internal FQDN which has a certificate requested from our internal CA.

To do this, go onto any domain joined server that has been rebooted since your CA was created.  I am doing this on the SHUD-OCSFE1 server.  Open the Certificates MMC by going to Start > Run > MMC.  Go to File > Add/Remove Snap-In > Add > Certificates > Computer Account.

Go to our Trusted Root Certification Authorities and find our Root Certificate.  Once you find it, Export the Certificate and transfer this exported certificate to ISA 2006.

Back on our ISA Box, open the Computer Certificates Snap-In just as we did on our CA.  In the same location (Trusted Root Certification Authorities > Certificates), we will import the certificate that we exported on our CA.  Once you choose Import, navigate to the location of the exported certificate and import it.

External Web Farm Certificate

Now let’s go ahead and get a certificate that matches the external Web Farm FQDN that we specified when deploying our Pool.  This name is ExtWebFarm.shudnow.net.  To do this, I installed IIS on ISA to request the certificate.

In IIS, go onto your Default Website > Properties > Directory Security Tab.

You will see a section entitled Secure Communications. Click Server Certificate to begin the process of requesting a certificate.

Choose Create New Certificate. Click Next to Continue.

In a production environment, you will choose to Prepare the request now, but send it later and submit the request to a 3rd party certificate authority such as Entrust.  This is because you’ll want internet clients to be able to automatically trust this certificate.  For purposes of this lab, I will just choose to Send the request imediately to an online certificate authority to expedite the process. Click Next to Continue.

Note: I left the Prepare the request now, but send it later selected by default.  If you are doing a lab scenario like I am, feel free to select the second option (like me) to expedite the process.  The rest of the screenshots will be using the second expedited method.

By default, the Certificate Name will be set to your web site name.  Change this to the FQDN of the External Web Farm FQDN. Click Next to Continue.

Note: The Certificate Name is not the Subject Name (SN) / Common Name (CN) of the certificate, but I always match the SN / CN of the certificate to the Certificate Name.

You will be asked for your Organization information.  Enter it appropriately. Click Next to Continue.

You will now be asked for your SN / CN.  Specify the name to be ExtWebFarm.shudnow.net Click Next to Continue.

You will be asked for your Geographical information.  Enter it appropriately. Click Next to Continue.

Since we specified the OCS Certificate Request to send the request immediately to an online certificate authority, OCS will search for an Issuing CA. The name of our CA (not server name but the name of the CA) is OCS-ROOTCA, OCS will display this server as the CA to use.  Choose OCS-DC1.shudnow.net\OCS-ROOTCA as our CA. Click Next to Continue.

Now in a production environment where you submitted your CSR to a vendor such as Entrust, they will provide you some text information back.  You will take this text, place it into a text file, and save the file as a .cer file.  You will then go back into IIS and Assign the .cer file to your request.  What essentially happens is when you create your CSR, you create a private key on your IIS Server.  The vendor will take some information appropriate to your private key and create a public key that associates itself with your private key.  When you assign your certificate, you essentially bind your public/private key to form a certificate.

Once the certificate is properly assigned, you will see the View Certificate button light up.

If you click on View Certificate, you will see the certificate has a CN of ExtWebFarm.shudnow.net

If you performed these procedures on an IIS instance located on a server that is not your IIS Server, you must ensure you export the certificate with its private key and import it into the Local Computer Certificate Store on ISA.  This will allow you to attach the certificate to the web listener we will be creating.  The procedures for importing a certificate are listed above.  The only difference is the store you import it into.

Once you are finished with your certificate request, if IIS is still enabled on ISA, make sure you turn it off (uninstall) otherwise ISA will fail to proxy due to a port conflict between IIS and the Web Listener.

ISA Configuration

We will need to configure ISA to proxy requests for the following three functions:

  • To enable external users to download meeting content for your meetings
  • To enable external users to expand distribution groups
  • To enable remote users to download files from the Address Book Service
  • To enable Communicator Phone Edition to connect to the Software Update Service (documentation says Software Update Service but it’s actually been renamed to Device Update Service) and update themselves

The Web Components Server will use the following directories to allow external clients to connect through using the External Web Farm FQDN.

To start creating the configuration for ISA, we will want to create a Web Site Publishing Rule.  We will name it OCS External Web Farm.

Select Allow. Click Next to Continue.

Select Publish a single Web site or load balancer. The reason why we only publish a single website is because the server we connect to will be our pool name (Ocspool.shudnow.net).  This will essentially load balance our ISA request to both of our Front End Servers. Click Next to Continue.

Select Use SSL to connect to the published Web server or server farm. Click Next to Continue.

Enter our Internal Site name which is the Internal Farm FQDN we specified when we created our Enterprise Pool.  This internal site name should match our pool name. Enter the IP Address for our Enterprise Pool.  Since we only deployed one Front End Server, this IP Address is the address of our Front End.  If we are deploying multiple Front End Servers behind a Hardware Load Balancer, this IP Address would be the Virtual IP (VIP) of our Hardware Load Balancer. Click Next to Continue.

We will want to use /* for our Path so we can create one rule to allow us to proxy all data destined to our External Web Farm FQDN to our Front End Server. Click Next to Continue.

We will want to enter our External Web Farm FQDN as our Public Name. Click Next to Continue.

We are now prompted to select a Web Listener.  Because we haven’t created one, go ahead and select New. Name this Web Listener OCS External Web Farm. Click Next to Continue.

We will definitely want to require SSL secured connections with clients. Click Next to Continue.

Select External since we will allowing Internet Clients to use this listener in which the DNS will be pointing to the Selected IP Address for our External connection.  To select the IP Address for our External connection, Click the Select IP Addresses button.

Select the IP Address that we will be using for our External NIC.  The reason why it doesn’t show the IP Address for our 192.x.x.x address is because our 192.168.1.x network is selected as our Internal Network.  You select your internal subnets when installing ISA. Click OK and then Next to Continue.

We must now choose our ExtWebFarm.shudnow.net certificate for this listener.  Choose Select Certificate and choose our ExtWebFarm.shudnow.net Certificate. Click OK and then Next to Continue.

No Authentication will be used. Click Next to Continue.

When back in the rule configuration, you will want to ensure that you select No Delegation, but client may authenticate directly. Click Next to Continue.

All the remaining options should be left at default.  All you need to do now is configure a HOST (A) record on your external DNS solution so ExtWebFarm.shudnow.net points to the IP Address of your ISA Server whether that is with a public IP Address directly on ISA or through a NAT’d Address.

The last modification we need to make is to go into the properties of our rule (not listener) and go to the From Tab.  Remove Anywhere and add External.  Click OK to Finish.

Note:  Again, if IIS is still enabled on ISA, make sure you turn it off (uninstall) otherwise ISA will fail to proxy due to a port conflict between IIS and the Web Listener.

Summary

Well folks, that is all for Part 4 of this article. For Part 5, I will go through the installation and configuration of our Consolidated OCS 2007 Edge Server.

Share

Office Communications Server 2007 R2 Enterprise Deployment – Part 3

Welcome to Part 3 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is how to deploy a single Enterprise Edition OCS 2007 R2 Server which is connected to an x64 SQL Server 2008 Back-End Server. We first discussed what the lab setup is going to be using Hyper-V, and then proceeded to the configuration of our Enterprise Certificate Authority. In Part 2, we went over the Environmental Preparation for our OCS 2007 R2 environment.

In this Part, I will go over the remaining steps required to deploying our Front End Server in an Enterprise Pool Deployment. This includes going through the initial configuration of the pool, certificates, and adding our Front End Server to our newly created pool that uses a SIP namespace (exchange.shudnow.net) that is separate than our AD Namespace (shudnow.net). We will begin the steps needed to validate our configuration to make sure the Front End OCS Server is healthy.

Part 1

Part 2

Part 3

Part 4

Part 5

Front End OCS 2007 R2 Server Installation

When installing OCS in a consolidated Enterprise Edition deployment, you would perform the following steps:

  1. Prepare Environment (Completed in Part 2)
    1. Prepare Active Directory (Completed in Part 2)
    2. Create Enterprise Pool (Completed in Part 2)
    3. Deploy Hardware Load Balancer (Completed in Part 2)
    4. Configure Pool (Completed in Part 2)
  2. Add Enterprise Edition Server to Pool
    1. Add Server to Pool
    2. Configure Certificate
    3. Configure Web Components Server Certificate
    4. Verify Replication
    5. Start Services
    6. Validate Server and Pool Functionality

Add Enterprise Edition Server to Pool

Add Server to Pool (Step 1)

Because we are using Server 2008, our IIS version will be 7.  Kernel Mode Authentication runs under the context of a computer account.  OCS runs its services under the context of a user account.  With Kernel Mode Authentication enabled, Kerberos tickets will fail.  Because of this OCS 2007 R2 disabled Kernel Mode Authentication on IIS during installation.

Instead of disabling kernel mode authentication in IIS, you can configure IIS to use the Web application pool’s identity for internal virtual directories used by OCS.  We can do so by modifying Windows Authentication on the Default Website of the Web Components Server using the ApplicationHost.config File.  Open the %windir%system32inetsrvconfigApplicationHost.config file in a text editor. For all folders under the Default Web Site location path, set the value of the WindowsAuthentication element and the useAppPoolCredentials attribute to true. For example:

<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled=”true” useAppPoolCredentials=”true” />
</authentication>
</security>
</system.webServer>

When I went to look for the above (from the OCS R2 docs), I didn’t find any useAppPoolCredentials but I did see windowsAuthentication and set it to true which you can do via the IIS Manager.

We are now on Step 1 which is to Add Server to Pool. As a prerequisite, you’ll need to install IIS by following the instructions here for Server 2003 and here for Server 2008.  For Server 2008, make sure you install Windows Authentication and all IIS 6 Management Compability Role Services. You may also need your SP2 binaries and CD1 of your Server 2003 Installation CD. Once IIS has been installed, you will have to restart Setup. Once back at the Deploy Pool in a Consolidated Topology, Click Run to Continue.

On the Welcome Screen and Licensing Information (after reading all the licensing information and choosing that you agree if you agree with the licensing terms), Click Next to Continue.

Specify where you want OCS to be installed.  We will use the default location. Click Next to Continue.

We are ready to Add our Server to our Enterprise Pool. You can review your Current Settings.  When satisfied, Click Next to Continue.

The configuration will now commence which will install all of the OCS roles onto this Front End Server due to it being Consolidated Front End.

Once the roles have been installed on your Front End Server, you will have to specify what Pool we want to join this server to.  Considering we only have one pool, leave the selection (don’t have much of a choice) at OCSPool.shudnow.net. Click Next to Continue.

You will now be prompted to specify passwords for your Service Accounts.  I recommend to use long secure passwords.  You can view this and this site which assist in choosing strong passwords.  You will have to do this for several Service Accounts:

  • RTCService
  • RTCComponentService
  • RTCGuestAccessUser

Once you have set a password for all three accounts, Click Next to Continue.

We are ready to Activate our Components. You can review your Current Settings.  When satisfied, Click Next to Continue.

The server will go through a procedure which activates each OCS Server role on our Front End Server. When the Activation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

Configure Certificate (Step 2)

We are now on Step 2 which is to Configure our Certificate. Click Run to Continue.

On the Welcome Screen, Click Next to Continue.

The next screen will be familiar to many of you.  It’s going through the process of creating a certificate request.  Since we have not created a certificate for our Front End Server, we will want to Choose to Create a new certificate. Click Next to Continue.

Because we have an internal CA installed, we can send the request immediately to an online certificate authority. Click Next to Continue.

By default, the Certificate Name will be set to your server name.  Change this to the FQDN of the Enterprise Pool. Click Next to Continue.

Note: The Certificate Name is not the Subject Name (SN) / Common Name (CN) of the certificate, but I always match the SN / CN of the certificate to the Certificate Name.  On a Standard Edition Server, this would be the FQDN of the server’s computer name.  When deploying OCS in an Enterprise Pool, this would be the FQDN of the pool name, not the server name.  You would then export this certificate after you have obtained the certificate and place the certificate on all other Front End Servers.

You will be asked for your Organization information.  Enter it appropriately. Click Next to Continue.

You will now be asked for your SN / CN.  As stated previously, because we created an Enterprise Pool, we want this name to be the FQDN of our Enterprise Pool.  Because we will be using a second SIP domain (exchange.shudnow.net), we will need to add a Subject Alternative Name (SAN) for sip.exchange.shudnow.net (sip.SIPDomainName.TLD).  The SAN should automatically be filled in for you due to Step 4 which is when we Configured our Pool. Click Next to Continue.

You will be asked for your Geographical information.  Enter it appropriately. Click Next to Continue.

Since we specified the OCS Certificate Request to send the request immediately to an online certificate authority, OCS will search for an Issuing CA. The name of our CA (not server name but the name of the CA) is CA, OCS will display this server as the CA to use.  Choose SHUD-DC2.shudnow.netCA as our CA. Click Next to Continue.

We are ready to Request our Certificate. You can review your Current Settings.  When satisfied, Click Next to Continue.

We should now have our certificate.  Choose Assign certificate immediately. Click Next to Continue.

You can continue through the remaining prompts to finish the certificate request and assign it to your server

Configure Web Components Server Certificate (Step 3)

We are now on Step 3 which is a really straight forward manual step.

It consists of opening IIS (Start > Control Panel > Administrative Tools > Internet Information Services Manager).

Go to the ServerName > Sites > Default Website >IIS > Authentication > Select Bindings from the Action Pane.

Choose https and select our Pool Certificate.  Make sure IP address is set to All Unassigned.  Click Ok then Close to Continue.

Note: The reason why you want to assign the certificate to IIS is because the Address Book is a part of the web components server.  Remember setting up the share for this?  Because clients access this Address Book via SSL and the ABS folder within IIS is set to use SSL, we need to make sure IIS uses a certificate to grant SSL access to ABS.  If you don’t, clients won’t be able to access the ABS and will get an ABS error when using Communicator.

Verify Replication (Step 4)

We are now on Step 4 which is to Verify Replication. This is a manual step that I will not go over. Click Help to see the LCSCMD commands used to verify replication.

Start Services (Step 5)

We are now on Step 5 which is to Start Services. Click Run to start the OCS Services.  I will not provide screenshots of this process as it is extremely straightforward.

Note: I did notice an issue with the Monitoring Agent not being able to start.  I then noticed in the Event Viewer that this service is for QOE and it can’t start because it can’t create an administrative message queue.  Because we didn’t choose to deploy QOE, I have disabled this service.  If QOE is needed in the future, you can set up QOE and re-enable this service.

IMPORTANT UPDATE: As I said, I disabled the service but do not do this.  Make sure you install Message Queuing as an OCS April Update doesn’t work properly and will try to mess with this service and render your OCS Server in an unworkable state.  Future patches such as ones after June state that they don’t have this problem.  So if you plan on installing June update or later, you can safely disable this service and patch your servers without worry (hopefully.) You can read more about this issue here.

Validate Server and Pool Functionality (Step 6A)

We are now finally on our final Step, Step 6 which is to Validate Server and Pool Functionality.  This step helps us ensure that our environment is working properly.  I am dividing this step between 2 steps; Step 6a and Step 6b.  Part of this, is to go through with the validation, DNS needs to be set up.  But because, as I stated earlier, I want to not to DNS yet so we can go through the Communicator logon step by step without DNS and see how to get automatic client logon working, we will finish Step 6 in the next Part.

Server and Pool Validation requires you to have a SIP enabled user account.  To do this, we must use Active Directory Users and Computers on our OCS server.  To do this, go to Start > Control Panel > Administrative Tools > Active Directory Users and Computers.

So now that ADUC is open, go ahead and create a couple accounts.  For these user’s, I also mailbox enabled them after creating a new Accepted Domain for exchange.shudnow.net and setting up a new e-mail address policy so they obtain a primary e-mail address domain of exchange.shudnow.net.

I created the following two users:

  • OCS User 1 (username of ocsuser1)
  • OCS User 2 (username of ocsuser2)

Once these users are created, Right-Click the User and choose Enable users for Communications Server.

Tip: One of these options is to Move a User from one pool to another.  If you do this while the source server is up, the user will retain all user configuration/settings that are stored on the server.  For some reason if you have a catastrophic failure on one server, you can move the user to another pool without the source server being up, but that user will lose all of its server stored configuration/settings.

On the Welcome Screen, Click Next to Continue.

We now must choose what Pool we want to assign this user to.  Considering we only have one pool, leave the selection (don’t have much of a choice) at OCSPool.shudnow.net. Click Next to Continue.

Here is where we can assign the user as either shudnow.net or exchange.shudnow.net.  We only specified exchange.shudnow.net to allow for automatic sign-on so we will want to make sure we assign our users as exchange.shudnow.net.  You can use the shudnow.net name as long as you set those users to manually log on and you configure DNS appropriately.  You can allow shudnow.net to allow for automatic logon by re-running the previous wizards.

For purposes of this lab, I will use the user’s e-mail address since they are mailbox enabled and I don’t want users to have to know more than two sets of login usernames (one for Exchange/AD and a different one for OCS). Click Next which will begin the OCS-Enable process.  Once this is complete, click Finish to Finish.

But let’s say you wanted some users to have a different OCS SIP Address than their Exchange address.  Or even if you wanted to use the shudnow.net domain for SIP.  You could choose the following  option although you can e ither choose only firstname.lastname@SIPDomain or sAMAccountName@SIPDomain.

I would now go ahead and OCS enable your second user.  Once finished, you can refresh ADUC and verify these users have a Communications Server address.

Summary

Well folks, that is all for Part 3 of this article. For Part 4, I will go through the installation of our Office Communicator 2007 client and get it connected through OCS by configuring DNS. I will then begin preparation of our Edge Servers followed by configuring our ISA 2006 Server.

Share

Office Communications Server 2007 R2 Enterprise Deployment – Part 2

Welcome to Part 2 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is how to deploy a single Enterprise Edition OCS 2007 R2 Server which is connected to an x64 SQL Server 2008 Back-End Server. We first discussed what the lab setup is going to be using Hyper-V, and then proceeded to the configuration of our Enterprise Certificate Authority.

In this Part, I will go over the Environment Preparation.

Part 1

Part 2

Part 3

Part 4

Part 5

Front End OCS 2007 R2 Server Installation

When installing OCS in a consolidated Enterprise Edition deployment, you would perform the following steps:

  1. Prepare Environment
    1. Prepare Active Directory
    2. Create Enterprise Pool
    3. Deploy Hardware Load Balancer
    4. Configure Pool
  2. Add Enterprise Edition Server to Pool
    1. Add Server to Pool
    2. Configure Certificate
    3. Configure Web Components Server Certificate
    4. Verify Replication
    5. Start Services
    6. Validate Server and Pool Functionality

Note: We will not be able to go over all the steps in this Part 2 due to the amount of steps and sub-steps required to perform.

Prepare Environment

Prepare Active Directory (Step 1)

Our Domain Controller with Windows Server 2008 SP1 is installed and fully functional.  To begin the Active Directory preparation process, we can insert our OCS CD.  There are some prerequisites for installing OCS such as .Net Framework 3.5 and Microsoft Visual C++ 2008, but this is all taken care of during the installation.

Insert the CD and let’s begin the installation process.  You will be asked to install the Microsoft Visual C++ 2008 Redistributable. Click Yes to Continue.

You will then be asked to install the Microsoft .NET Framework 3.5. Click Yes to Continue.

Once Microsoft .NET Framework 3.5 is installed, you will be presented with the Deployment Wizard.  We will want to begin preparation of our Environment.  Click Prepare Environment to Continue.

We are now on Step 1 which is to Prepare Active Directory.  If you previously had OCS 2007 installed, you will see that the preparation of Active Directory is partially done.  Click Prepare Active Directory to Continue.

We are now presented with sub-steps to perform to complete our Active Directory Preparation.  These sub-steps include:

  1. Prepare Schema
  2. Verify Replication of Schema Partition
  3. Prep Forest
  4. Verify Replication of Global Settings and Global Catalog
  5. Prep Current Domain
  6. Verify Replication of the Domain
  7. Delegate Setup and Administration

Click Run for Prepare Schema to Continue.

If you are installed OCS 2007 R2 on a Server 2008 machine and are using this machine to Prepare AD, you will need to install the Remote Server Administration Tools due to the nature of the modular design of Server 2008.  You will be quite aware of needing this installed if you encounter the following screen.

You can take care of this easily by opening a Command Prompt and typing ServerManagerCMD -i RSAT.  This will require a reboot.

Now that RSAT has been installed if you have Server 2008 and your server is rebooted, let’s restart the installation and get back to the Prepare Active Directory section. Click Run for Prepare Schema to Continue.

On the Welcome Screen, Click Next to Continue. Select “Default: Schema files are located in the same directory as Setup.”  Click Next to Continue.

You are now ready to Prepare the Schema.  Click Next to Begin Schema Preparation.

When the Schema Preparation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

We are brought back to the Deployment Wizard.  The Prep Schema step has been complete as is shown next to the Run button.

We will skip through all the Replication Steps (Verify Replication of Schema Partition, Verify Replication of Global Settings and Global Catalog, and Verify Replication of the Domain) due to the fact we have only 1 Domain Controller in this lab.  In a production environment where you have more than one Domain Controller (hopefully), I highly advise you to ensure replication for each step has completed successfully before continuing.

We are now ready to run the Prep Forest step. Click Run for Prep Forest to Continue.

On the Welcome Screen, Click Next to Continue.

You are presented with two options:

  • System Container in the Root Domain
  • Configuration Partition

To decide which option to choose, follow this diagram provided in the OCS 2007 R2 documentation with more detailed information about each selection process.

In my OCS RTM article series, I chose System container because the lab contained only one Domain Controller.  My existing lab which had OCS RTM was deployed using the Configuration Partition.  Because of this, we are presented with the following screen.

As you can see, since we deployed OCS RTM previously, we are unable to choose an option.  If you chose System Container in a previous deployment, Microsoft has provided a tool to migrate System Container over to a Configuration Partition configuration.  This tool is availabile here.

If this is a pristine environment you are deploying OCS R2 in, you can choose either option.  I would highly recommend choosing the Configuration Partition.  This is to ensure availability of your OCS Data in your environment and not having to worry about 100% connectivity to your system container in your root domain to ensure OCS availability.  Click Next to Continue.

We will want to store our Universal Groups in our shudnow.net domain.  In the case of this lab, we will have to due to the fact that this is our only domain.  Select shudnow.net and Click Next to Continue.

We will use our Active Directory domain name shudnow.net for OCS routing.  Click Next to Continue.

You are now ready to Prepare the Forest.  Click Next to Begin Forest Preparation.

When the Forest Preparation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

We are brought back to the Deployment Wizard where we will now run the Prep Current Domain.  This step should be run in any domain that will contain users that will be OCS (SIP) enabled.

Click Run for Prepare Current Domain to Continue.

On the Welcome Screen, Click Next to Continue.

On the next screen that provides Domain Preparation Information, read the excerpt provided and Click Next to Continue.

You are now ready to prepare the domain.  Because we have only 1 domain and are running this step in our shudnow.net domain, our current settings will display as shudnow.net. Click Next to Continue.

When the Domain Preparation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

The final step is to Delegate Setup and Administration.  Because we are doing everything using a Domain/Enterprise/Schema Administrator account, we will not have to configure Delegation.

Creating File Shares

Because our Universal Groups have been created, we can now create file shares that are necessary for the following functions:

  • Presentations – Meeting presentations to be downloaded or streamed by conference attendees.
  • Metadata – Meeting information (metadata) that is used internally by the Web Conferencing Server component for the pool.
  • ABS – Address Book information that is used by the Address Book Server, which is included with the Web Components Server, in order to provide global address list information to Office Communicator 2007 and Office Communicator 2005 clients on a daily basis.
  • Applications – Application files that are used internally by the application server component for the pool.
  • Updates – Files used by the client version control mechanism to update Office Communicator clients and by the Device Update Service to update devices.
  • MeetingCompliance (optional) – Meeting activities and content uploaded during meetings.  We will talk about how to enable Meeting Compliance in a future Part.

These shares can be created on a File Server in your environment.  We will be creating these shares on our OCS FE Server which means that our OCS Server will also be our Web Components Server.

We will create a folder called C:\OCS on our OCS Server.  Within those four folders, we will create the following six folders:

  • Presentations
  • Metadata
  • ABS
  • Updates
  • Applications
  • MeetingComp

As you can see, the above folders have been shared out.  This is a requirement.  We will use a share name that matches the folder name for simplicity sake.  Grant Full Control on each of these shared folders to the Administrator, the RTCUniversalServerAdmins group, and any other user or group responsible for creating pools. Remove Read permission from the Everyone group except for Presentations since all users will need to read this folder to download Live Meeting Content and Upload Presentation Data.

Make sure you provide both RTCUniversalServerAdmins and Administrators Full Control via NTFS permissions as well.  Because our folders are in the OCS folder, we can add these permissions on C:\OCS and they will flow down to our sub folders through inheritance.  In production, I would assign them manually to each folder as each folder requires a different set of permissions.

Create Enterprise Pool (Step 2)

The guidance on what server you create the pool is different from R2 than it was with OCS Release 1 RTM.  On OCS Release 1 RTM, if you are using an x64 SQL Server, we’d create the pool on an x86 system which would be our OCS Server most likely. In OCS Release 2, if you are using a 64-bit version of SQL Server, we need to log on to our OCS Back End Database server as a member of RTCUniversalServerAdmins and DomainAdmins group and create the pool there.. If you are using a 32-bit version of SQL Server, create the pool by using the computer that you plan to use as the Front End Server.

Because we are running SQL Server 2008 x64, we will need to create our pool on our SQL 2008 Server.  Also, when using SQL 2008, we need to modify the Windows Firewall.  We can d this by going to Start > Control Panel > Windows Firewall with Advanced Security.

Right-Click Inbound Rules and choose New Rule.  Select Port and click Next to Continue.

Select TCP and specify 1433 as a local port.  Click Next to Continue.

Select Allow the Connection. Click Next to Continue.

Select Domain and Private and Clear the checkbox in Public. Click Next to Continue and go through through the rest of the options such as giving the rule a name.

We are now on Step 2 which is to Create an Enterprise Pool.  This is where you will definitely need to have your SQL Back End fully configured. You can use SQL Server 2005 (x86 or x64) with SP1+.  You can also use SQL Server 2000 SP4+. Click Run to Continue.

On the Welcome Screen, Click Next to Continue.

We must now decide what we want our Pool Name to be.  On an OCS Standard Edition Server, your Pool name is the name of your server.  But since we are using Enterprise Edition, we must select a name that won’t match any other existing records currently housed in DNS.  We will use the name, OCSPool.  Our SQL Server was installed using the Default Instance.  Because of that, all we will need to do is ensure we are logged on with an account that is a member of Domain Admins, RTCUniversalServerAdmins, and has permissions to create and manage SQL Databases. Click Next to Continue.

On both your SQL 2008 and OCS 2007 R2 server, make sure that File Sharing is enabled.

We can now proceed to creating our Pool.  Just an FYI, as stated earlier, the documentation states that since we are using an x64 SQL Back End, that we should be creating the Pool on our SQL Server.  I did initially try to run all of this on the Front End and encountered issues.  So as the documentation states, since it’s an x64 Back End, create the pool on the SQL Server.

We will want to leave our Internal web farm FQDN alone.  This should be the pool name.  If you are going to be installing multiple Front End Servers behind a Hardware Load Balancer, the OCS Pool DNS would be pointed to your Hardware Load Balancer Virtual IP Address which would then direct the traffic to one of your Front End Servers.

The External Web Farm FQDN is used by your ISA Server.  It allows you to reverse proxy (publish) your Address Book, Web Conferencing Meeting Content, as well as expansion of Exchange Universal Distribution Groups.  I would recommend configuring this during the install as you cannot modify this through the OCS Administrative GUI.  You can use the guide here to modify the External web farm FQDN should you decide you don’t want to set this FQDN during install or wish to change it at a later time. Click Next to Continue.

Note:  I used the FQDN of ExtWebFarm.shudnow.net.  Taking a look at this from a perspective of a production environment, the shudnow.net name is my AD Domain.  If you do not have split-dns, you can use the same namespace that you will be SIP enabling users.  For example, our SIP Domain is exchange.shudnow.net.  So I can easily just do ExtWebFarm.exchange.shudnow.net.

I am selecting to overwrite any existing database since I did use my SQL Server for a previous OCS installation.

OCS is smart enough to detect whether SQL has any volumes that are now the system volume.  When it does detect these separate volumes, it will try to optimize the locations as much as possible.  Because I do have a separate LUN/volume on my SQL Server, OCS automatically used the E:\ volume to separate the RTCDYN log from everything else.  Make any changes here as you wish.  As OCS comes closer to release, public documentation on Database storage guidance will become available.  I will link to it as it does become available. Click Next to Continue.

The time has now come to specify the location of the shares we created above.  These should be:

  • Presentations – \\SHUD-OCSFE1\Presentations
  • Metadata – \\SHUD-OCSFE1\Metadata
  • ABS – \\SHUD-OCSFE1\ABS
  • MeetingComp – \\SHUD-OCSFE1\MeetingComp
  • Applications – \\SHUD-OCSFE1\Applications
  • Updates – \\SHUD-OCSFE1\Updates

Make sure you test all of the Universal Naming Convention (UNC) paths work prior to proceeding.  If they do work, enter the UNC paths as is displayed in my screenshot. Click Next to Continue.

Configure the remaining UNC Paths as follows. Click Next to Continue.

Since we will not be enabling Archiving , CDR, or QOE in our environment, leave the following settings unchecked. Click Next to Continue.

We are finally ready to create our Enterprise Pool!  Review your Current Settings.  When satisfied, Click Next to Continue.

When the Pool Creation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

Deploy Hardware Load Balancer (Step 3)

If you are going to be doing any type of redundancy, you will need to use a Hardware Load Balancer such as an F5 BIGIP with the LTM Module.

The steps required to configure a Load Balancer is out of the scope of this article as we are deploying a single Front End server which does not require a Hardware Load Balancer.

The hardware load balancing planning information will be linked to as documentation becomes available.

The hardware load balancing deployment information will be linked to as documentation becomes availble.

Note: One thing that is important is that DNAT is no longer supported on a Front End Pool configuration.

Configure Pool (Step 4)

We are now on Step 4 which is to Configure our Pool and Configure DNS.  You can resume your OCS installation on your Front End Server.  Click Run to Continue.

As stated previously, we will be using a SIP domain that is different from our Active Directory domain.  This SIP domain is called exchange.shudnow.net.  The reason I am doing this is to show you how you can set up your SIP namespace to be different from your Active Directory domain which is not uncommon.  For example, in many organizations, their domain may be domain.local while their SMTP namespace will be domain.com.

The method I am using would be the same thing.  You would have an Active Directory domain, and then use a different namespace for SMTP/SIP.   In the case of our lab, I am only using Exchange to show distribution group expansion within OCS.  But in a production environment, you can use the same namespace for both Exchange and OCS.  This is the actually recommended.

Note: A person by the name of Simo notified me that Exchange is not required for group expansion.  As long as your distribution group has a value in the “mail” attribute field, group expansion will work.

So just to ensure you understand, let me show some examples:

Example 1:

  • Active Directory Domain Namespace- shudnow.net
  • OCS Namespace – shudnow.net
  • Exchange Namespace – shudnow.net

Example 2:

  • Active Directory Domain Namespace- shudnow.net, shudnow.local, staff.shudnow.net, staff.shudnow.local, etc…
  • OCS Namespace – exchange.shudnow.net (can be different from Exchange Namespace)
  • Exchange Namespace – exchange.shudnow.net (can be different from OCS Namespace)

On the Welcome Screen, Click Next to Continue.

You will then be prompted to install the Core Components since no other OCS components installed on this server. You don’t have much of a choice here and you must install these tools. Click Next to Continue which will begin the installation process of the Core Components.

We now must choose what Pool we want to configure.  Considering we only have one pool, leave the selection (don’t have much of a choice) at OCSPool.shudnow.net. Click Next to Continue.

The following four options are dependent on what services you will be deploying in your environment.  The first two Conferencing options are utilized when using Dial-in Audio Conferencing.  The Response Group Service is used if you want to route calls to multiple participants.  The Outside Voice Control is used to allow Communicator Mobile Edition access to Voice which is used if you want capabilities such as Single Number Reach, Least Cost Routing, Etc…

We are now presented with the SIP domains in our environment.

Since we will be using exchange.shudnow.net, we will need to add that in there.  Do not remove shudnow.net as a SIP domain.  If you recall, when we did our Forest Prep, we chose our Active Directory domain for SIP Routing.  Because of this, we will have two SIP domains; one for routing and one for user access.  You will then want to type in exchange.shudnow.net and click Add. Click Next to Continue.

When you set Communicator to connect to your OCS pool, you can configure it to automatically connect or to manually connect.  We will configure OCS to allow for automatic client logons.  If we had multiple pools and we wanted users who connected to this Pool to be redirected to another Pool, we would ensure that “Use this server or pool to authenticate and redirect automatic client logon requests” is checked. Click Next to Continue.

Since we are enabling our Pool to allow automatic logons, we must specify which SIP domains will be allowed for automatic logons.  Choose exchange.shudnow.net and then Next to Continue.

Note: We will not be doing the actual DNS configuration to support our new SIP namespace until we get to the part where will be connecting via Communicator.  This way, you can see step by step what fails and how to rectify the failure to ensure a successful automatic logon.

We do not have our Edge Topology up and running.  The recommended method of deploying a new OCS organization is to bring up your internal servers and then your Edge Servers.  If you are migrating from OCS, you can configure external access as an OCS R1 Edge Server can proxy data to an OCS R2 Front End Server.  In fact, the migration strategy for OCS R2 is inside out. Select, “Do not configure for external user access now” and then Next to Continue.

We are finally ready to Configure our Enterprise Pool, you can review your Current Settings.  When satisfied, Click Next to Continue.

The configuration will now commense which will be pretty quick.  In fact, it’s too quick for me to grab a screenshot.  When the Pool Configuration is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

Summary

Well folks, that is all for Part 2 of this article. For Part 3, I will go through the initial configuration of the pool, certificates, and adding our Front End Server to our newly created pool that uses a SIP namespace (exchange.shudnow.net) that is separate than our AD Namespace (shudnow.net). We will begin the steps needed to validate our configuration to make sure the Front End OCS Server is healthy.

Share

Office Communications Server 2007 R2 Enterprise Deployment – Part 1

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

Part 1

Part 2

Part 3

Part 4

Part 5

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.

Assumptions

  • 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

OCS Edge Server – SHUD-OCSEDGE1

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 – 255.255.255.0

Default Gateway – 192.168.1.1

DNS Server – 192.168.1.150 (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 – 255.255.255.0

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 192.168.1.170/24. The IP for the Public NIC is 10.10.10.153/24 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

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.

Update 1/17/2009 – I used to have a recommendation to use Method #1.  This worked just fine out of the box with Windows 2003 and still does.  Windows 2008 and using Windows 2008 R2 (not yet supported) both use the new Strong Host networking model which introduce some complications when using Method #1.  There are some security differences with the Strong Host model than what the Weak Host model used.  For example, if traffic comes in on one interface, it’s going to leave back out that same interface.  But with Windows 2003 networking, you can only have one default gateway.  So there are some tricks to do with multiple NICs such as assigning multiple Default Gateways and tweaking your Windows routes.  Jeff Schertz, OCS MVP, details this on his blog article here.  Generally, Method #1 will give you greater performance benefits but with how OCS scales and its sizing guidance, 2 NICs are fine.  I’ve generally been using Method #2.

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 192.0.2.1 which then NAT’s to the private IP on the Audio/Video Edge NIC of 10.10.10.1.  The same happens outbound except for SNAT being used instead of DNAT.  The incoming DNAT and outbound SNAT is a requirement.

Summary

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.

Share

« Prev - Next »