Elan Shudnow’s Blog

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 Server which is connected to an x64 SQL Server 2005 SP2 Back-End Server. We first discussed what the lab setup is going to be using VMware Workstation, and then proceeded to the configuration of our Enterprise Certificate Authority.  In Part 2, we went over the preparation and installation of a Front End OCS 2007 Server Pool which were the first few steps in deploying OCS in an Enterprise Deployment.

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 Server Installation

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

1. Prepare Active Directory (Completed in Part 2)
2. Create an Enterprise Pool (Completed in Part 2)
3. Configure a Load Balancer (Completed in Part 2)
4. Configure Pool / DNS
5. Add Server to Pool
6. Configure Certificate
7. Configure Web Components Server Certificate
8. Verify Replication
9. Start Services
10. Validate Server and Pool Functionality

Configure Pool / DNS (Step 4)

We are now on Step 4 which is to Configure our Pool and Configure DNS. 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 Administrative Tools if they have not been installed already.  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 Administrative Tools.

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.

I would make sure you fully understand the differences between choosing SNAT Vs DNAT.  In a previous Part, I posted two links which provide you with the information you need to understand load balancing for OCS.  One of these guides was the planning document for hardware load balancing which you can view here.  It is recommended not to change this setting after OCS has been installed.  So please make sure you understand the differences and make your choice appropriately.

Choose SNAT as the method of load balancing. Click Next to Continue.

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 LCS, you must deploy your new Edge Topology first since an LCS Access Proxy cannot proxy to an OCS organization whereas an OCS Access Edge can proxy to both LCS and OCS. 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.

Add Server to Pool (Step 5)

We are now on Step 4 which is to Configure our Pool and Configure DNS. As a prerequisite, you’ll need to install IIS by following the instructions here. 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 6)

We are now on Step 6 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 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.

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.  Click Assign to ensure that OCS begins to use this certificate. Click OK and Finish to Continue.

Configure Web Components Server Certificate (Step 7)

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

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

Go to the Default Website > Right-Click > Choose Properties.

Click on the Directory Security Tab.

In Directory Security, you will see a Secure Communications Section. Click Server Certificate to Continue.

On the Welcome Screen, Click Next to Continue.

Since we already have a certificate on this Front End Server, we will choose to Assign an existing certificate. Click Next to Continue.

Since the certificate is installed on this server already, it’ll find this certificate automatically.  If you are deploying a second Front End Server, you’ll need to make sure you import the certificate with its’ private key into the Local Computer Certificate Store. Click Next to Continue.

The last prompt through this wizard will be for what SSL port to use.  Leave the default at 443. Click through the remaining prompts to finish assigning the certificate.

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 8)

We are now on Step 8 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 9)

We are now on Step 9 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.

Validate Server and Pool Functionality (Step 10A)

We are now finally on our final Step, Step 10 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; Step10a and Step10b.  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 10 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 > Run > Type dsa.msc and Click OK.  If you are running a 64-bit OCS Server, you would do this by typing “dsa.msc -32″ in the run field.  64-bit OCS servers are only allowed for specific roles.  An Enterprise Front End is not one of them, so we will not have to use the -32 option.

For a list of OCS roles that support 64-bit using Windows on Windows 64 (OCS 32-bit installed on Windows x64), download the OCS planning guide here which I find to be more accurate than the Technet version in regards to 64-bit information.

So now that ADUC (dsa.msc) 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.

Elan Shudnow :: Jul.07.2008 :: OCS, Server 2003 :: 2 Comments »

Trackback this post | Feed on Comments to this post