RSS Subscription 168 Posts and 2,769 Comments

Archive for July, 2008

Phone Numbers not displaying for some Communicator 2007 Users

So in my organization, we’ve had Enterprise Voice with Office Communication Server (OCS) 2007 set up for quite a while and we have been adopting the usage of it more and more as time goes on. So I told someone to call my Mobile Phone number via Communicator 2007 and they said they didn’t see my Mobile Phone number.  I definitely thought this was odd as Active Directory (AD) has me configured for Home Phone, Mobile Phone, and Business Phone.  My Mobile Phone number and my Home Phone number are the same numbers while my  Business Phone number is different.

So it will help to give you a little background on how phone numbers show up to Communicator 2007 clients in relation to how my account is configured in our production AD environment.

In Office Communicator 2007, I am going into the Options > Phones Tab.  You will see that my Work Phone, Mobile Phone, and Home Phone are all greyed out.  This is because OCS 2007 is integrated with AD.  My AD account has Work Phone, Mobile Phone, and Home Phone all set.  As stated earlier, my Mobile Phone and Home Phone are the same while my Work Phone is different.

All Work, Mobile, and Home phone numbers are visible to all contacts in an AD environment if they have either Company, Team, or Personal Access Levels which you can assign to someone by Right-Clicking this individual within your Contacts list.  Because my phone numbers are published in AD, Communicator 2007 does not provide the ability to modify the phone numbers.

For contacts not in your Active Directory environment, you have more flexibility with who sees what phone numbers.  For example, if I am federated with another organization who also has OCS 2007, those contacts are not part of our Active Directory.  Because of that, the same rules in the previous paragraph do not apply.  They do not see my Work, Mobile, and Home numbers if they have either Company, Team, or Personal Access Levels to which I associated with their contact.

Instead, these contacts go by the following Access Levels ONLY if I selected to publish my phone numbers.  As you can see, I have all three of my phone numbers set to be published.  Because of that, all federated contacts can see my phone number information if I give them the proper Access Levels to do so.  By default, all new contacts are provided Work Access Levels which means federated contacts will only be able to see your Work Phone number by default.  Again, remember, if the contact is a part of your AD environment, they will be able to see all your phone numbers if they have either Company, Team, or Personal Access Levels which they will be default.

So what’s the issue?  Well it’s very simple.  If your Mobile Phone number and your Home Phone number are the same as mine are, your Mobile Phone number will not show up to others.  Only your Home Phone number will which I find to be very odd.

So because my Home Phone number and my Mobile Phone number are the same but my Business Phone Number is different, if someone goes to Communicator 2007 to select a phone number to call, they will only see Home Phone number and Business Phone number.

I have verified that this works the same way in a couple of OCS 2007 environments using Communicator 2007 and I don’t see any options to change this behavior.  You would think that all three options would display or that Mobile Phone number would have preference as the display number as Home Phone number.  After all, Communicator 2007 is a business tool.  Would you rather contact someone on their Mobile Phone number or their Home Phone number?  I would say most likely the favored choice would be the former.

Unfortunately, I haven’t seen an option to change this behavior but I have been told my another in my company to which I informed that they have notified the OCS Team.  So hopefully sometime in the future, Microsoft will modify this behavior or provide a method to which the behavior can be changed.

Share

Office Communications Server 2007 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 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 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 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 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 (Partially Completed in Part 3)
  5. Add Server to Pool (Completed in Part 3)
  6. Configure Certificate (Completed in Part 3)
  7. Configure Web Components Server Certificate (Completed in Part 3)
  8. Verify Replication (Completed in Part 3)
  9. Start Services (Completed in Part 3)
  10. Validate Server and Pool Functionality (Partially Completed in Part 3)

Microsoft Office Communicator (MOC) 2007

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.119.151 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.119.151
  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 so often to determine for distribution group modifications.  After some messing around with this, I see this is separate from the Address Book syncing as I attempted to manually syncronize the Address Book service and even went as far as deleting the GalContacts.db file on our client to force a re-download of the Address Book files.

I did some research and found this post here.  Unfortunately others are seeing the same and no answer has really been provided on how the distribution group information gets updated or how to force it; if even possible.

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 command:

Preparation of OCS 2007 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 your the Certificate Authority (CA) Server.  Our OCS-DC1 server is our CA.  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

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.119.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 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 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.

Share