RSS Subscription 167 Posts and 2,643 Comments

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

30 Responses to “Office Communications Server 2007 R2 Enterprise Deployment – Part 4”

  1. on 19 Jan 2009 at 11:10 amRichard

    Where did you find the 2007R2 client? (at work I’ve downloaded OCS2007R2 in preperation for upgrading to R2 but haven’t seen the R2 client on microsoft’s volume site?)

  2. on 19 Jan 2009 at 12:05 pmElan Shudnow

    If you’re company is not in the Technology Adoption Program (TAP) for OCS R2, you’ll have to wait till it’s readily available.

  3. on 19 Jan 2009 at 2:01 pmRichard

    will communicator 2007 work with 2007R2 server?

    we’re able to download OSC2007R2 and because of software assurance we can legally use it.

  4. on 19 Jan 2009 at 2:26 pmElan Shudnow

    Yes, it will work as long as you’re patched for it.

    Give my coworker’s blog a read and he explains what versions you have to be patched to for all the 2007 R1 clients in order for there to be connectivity to an OCS 2007 R2 pool.

    http://blog.tiensivu.com/aaron/archives/1822-For-smooth-upgrade-client-experience-going-from-OCS-2007-R1-to-OCS-2007-R2-update-the-Office-Communicator-R1-client-to-v2.0.6362.111-December-2008-release-KB-957465.html

  5. on 19 Jan 2009 at 2:36 pmRichard

    Thanks I look forward to upgrading to R2
    also is there any issue with R2 and Bes4.1.6
    currently we have 2007 working with BES 4.1.6 is there such a big change in the web api that this could break?

  6. on 19 Jan 2009 at 4:33 pmElan Shudnow

    Are you talking about the Communicator Client for Blackberry phones that’ll connect to OCS? If so, I’m not sure if that’s compatible.

  7. on 19 Jan 2009 at 4:37 pmRichard

    Currently there is a client on BB’s that works with the BES server and on the BES it colaberation service is configured to point to the CWA server

    if the CWA is so differant is it possible to use a R1 CWA server with a R2 OCS (meaning 2 CWA servers one R1 and one R2)

  8. on 19 Jan 2009 at 4:39 pmRichard

    a couple typos and it won’t let me edit

    BB->BES->Colaberation Service->CWA->OCS

  9. on 19 Jan 2009 at 6:07 pmElan Shudnow

    Ya, you need to register to be able to edit.

    I’m not sure if that will work. Let me know if it does though.

  10. on 20 Jan 2009 at 1:02 pmRichard

    well currently its
    BB->BES\Collaboration service->CWA-R1->OCS2007-R1
    I’m hoping the following will work
    BB->BES\Collaboration service->CWA-R1->OCS2007-R2

  11. on 20 Jan 2009 at 4:33 pmRichard

    Microsoft has now released the Client to their volume license site

  12. on 14 Mar 2009 at 8:22 amcofd

    I have a problem with distribution group:
    When I login use OCS Web, I can search distribution group and expand it.
    When I login use Communicator, it say “No result found” when I try to search distribution group.
    Can you help me fix the problem?

  13. on 14 Mar 2009 at 8:59 amElan Shudnow

    Sounds like a problem with Address Book Generation. Research the following:
    1. Address Book
    2. Web Components
    3. The need for ISA
    4. Internal Web Farm FQDN
    5. External Web Farm FQDN

  14. on 05 Apr 2009 at 3:42 pmJummy

    Hi Elan,

    Thanks a million for this article, so far it has been very helpful

  15. on 06 Apr 2009 at 3:30 pmMarc

    Hi Elan, I’m not using a separate DNS name space for the front end server, just our usual naming convention OCS.domain.local. So, when I’m trying to update our DNS server SRV record, I’m still getting that error. Also, our email FQDN is name@domain.com which I tried to Enable use of and that seems to not work either. based on a standard install, I must be doing something wrong with the way the SRV is configured. Thanks for the help!

  16. on 07 Apr 2009 at 11:11 amElan Shudnow

    If you try to enable your E-mail Domain, that’ll be your SIP Domain which you’ll need to use an SRV record for. This is the exact same scenario that I am using in this lab with using a separate SIP Domain that matches your e-mail domain and how to set up DNS accordingly. I’d re-read through that part of the article.

  17. on 09 Apr 2009 at 1:21 pmPaul

    I am having issues with the MOC clients pulling down updated versions of the address book. I have run the abserver.exe commands, and the dabs and lsabs files are updated on the ocs server itself. However, the ONLY way to get my MOC clients to update the info (and thus be able to search for newly enabled users) is to sign out, delete the galcontacts.db file, and then log back in. Then the client downloads the address book and recreates the galcontacts.db file. Has anyone else seen this behavior, or does anyone have any troubleshooting steps I can try?

    btw, great article, elan. this has helped me tremendously.

  18. on 13 Apr 2009 at 2:37 pmElan Shudnow

    Sometime’s I’ve seen the absserver update not fully update the file but letting it run its 24 hour server update and 24 hour client update will successfully update it. Also, the absserver -syncnow just updates the server side copy. Make sure you’re also doing absserver -regenur to force user replication regeneration. That should force the client to update the galcontacts.db. If that doesn’t work, that’s when you can either just dlete the galcontacts.db or wait the 24 hour period.

  19. on 21 Apr 2009 at 10:01 amScott

    I have a question regarding the Communicator Web Access and how it searches the addressbook. I have locked down the Address Book so you can only search within your own OU. However, if you launch CWA you can search everything. Is this by design or is there something that is “flawed” with CWA? Any information would be great. running windows 2008 enterprise and OCS 2007 R 2.

  20. on 28 Apr 2009 at 7:45 amJan-Erik

    Hi, it there a way to authentificate without UID/PW by using a hardware certificate stored on a smartcard? In that case the smartcard and the pin are enough to log on — the certificate has to be stored in the AD, I know.

  21. on 02 Jun 2009 at 4:47 amVolker Dose

    Hi,

    I do understand your ISA-Settings to work as a reverse proxy for the front-end server. What I do not understand is, how the hostname extwebfarm.shudnow.net is available for the client. I though, for this there must be a srv-record in the shudnow.net-zone or is this external hostname hidden somewhere in the active directory?

    With kind regards,
    Volker

  22. on 02 Jun 2009 at 6:51 amElan Shudnow

    It’s a reverse proxy for the web components role. When you configure your pool, you configure the FQDNs for your Web Components Role. This allows you to download Address Book, expand distribution groups, etc…

  23. on 06 Jun 2009 at 8:20 pmRichard

    I said
    “Is it possible to have a R1 cwa talk to a R2 OCS”
    Elan said
    “I’m not sure if that will work. Let me know if it does though.”

    Yes it works but requires the domain to be R1 preped

  24. on 11 Jun 2009 at 9:55 pmDan

    I want to know if there is a way to configure this without ISA (just hange the old edge server out there) or as a 2nd place option ISA 2004?

  25. on 12 Jun 2009 at 8:35 amElan Shudnow

    http://blogs.technet.com/toml/archive/2008/11/04/ocs-address-book-publishing-without-isa.aspx

  26. on 13 Jul 2009 at 1:45 pmJose Osorio

    Hi Elan,

    I deployed OCS 2007 R2 Front-End and Edge. I followed your steps to publish Reverse Proxy.

    On web listener i put No Authentication and on Web Publishing Rule I put No delegation, but client may authenticate directly.

    But when i want to access to https://ExternalFQDN/GroupExpansion/ext/service.asmx it does not work. I receive this:

    Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)

    Can you help me please?

    Thanks

  27. on 22 Jul 2009 at 11:32 amElan Shudnow

    Well, the steps I posted are correct. All I can say is turn on ISA logging as well as OCS logging and troubleshoot what’s going on.

  28. on 22 Jul 2009 at 11:43 amElan Shudnow

    You can have them on the same subnet if you want. If you have one Consolidated Edge, you can NAT the A/V. This of course is not best practice, but it will work.

  29. on 17 Feb 2010 at 10:35 pmpochacco

    I also experiencing this problem,

    Access to https://ExternalFQDN/GroupExpansion/ext/service.asmx it does not work. I receive this:

    Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)

    I followed your notes and still the issues:

    OCS Client gets: Distribution Group services could not perform this issues. Contact your system Admin to investigate the problem.

    Any idea?

  30. on 19 Jul 2010 at 1:21 pmAnil

    Very good post for beginner like me for OCS

Trackback this post | Feed on Comments to this post

Leave a Reply