Some blog articles that talk about this include:

http://www.tincupsandstring.com/2009/12/01/forcing-address-book-download/

http://www.markc.me.uk/MarkC/Blog/Entries/2009/12/17_Force_Downloading_the_Address_Book_in_OCS.html

Now I’m sure you are asking yourself why I am creating this entry?  Is it just to repeat information that’s already out there?  Of course not!

So, Communicator 2007 R2 is a 32-bit (x86) application.  That registry entry works perfectly fine on x86 systems.  But, if you are running on a x64 system, it won’t.  Why?  Well, because when you run x86 applications on a x64 based system, it utilizes a system in Windows called Windows on Windows (WOW64).  WOW64 has its own section within the registry called Wow6432Node.

So let’s say we take the registry key for our Communicator x86 (Communicator x64 not available) and run it on an x86 system.  The following registry key works fine:

But let’s say we have an x64 system.  The above registry key will not work.  We need to utilize the WOW6432Node part of the registry.  The following registry key works for x64 systems:

Please make sure you back up your registry before making changes as making changes to the registry can be harmful to your system if not done properly.

The following data will ultimately need to be backed up:

1. Global Config
2. Pool Config
3. Machine Config
4. SQL Databases
5. Standard Edition File Shares

The first command specifies the /level to be global and pool.  The second command specifies the /level to be machine.  What we will do is create a batch file (.bat) and place both commands in this .bat and have them run against the server every 6pm using scheduled tasks.

Our Servername is SHUD-OCSFE01.  The folder to store the backups is C:\OCSBackup.  We’ll also be running the batch file from the C:\OCSBackup.  Because the folder which contains lcscmde.exe is not a part of the system variables, we’ll have to specify the entire path for lcscmd.exe. Taking this information into consideration, our two commands for our batch file will be:

After executing this .bat file, we can see the two files have been created.

SQL Databases

The following is the list of SQL Databases that an OCS Standard Edition Front End uses:

Because we are utilizing SQL Express, we will have to find some other method other than a backup agent to automate the backups. Much of the SQL Backup information is provided by the SQLDBATips Blog.  The following article I utilized is located here.

Create a file with the extension of sql in our OCSBackup folder.  Also, create a new folder called C:\Reports for script reporting. I created a file C:\OCSBackup\ocssqlbackup.sql with the following text:

exec expressmaint
@database      = ‘ALL_USER’,
@optype        = ‘DB’,
@backupfldr    = ‘c:\ocsbackup’,
@reportfldr    = ‘c:\reports’,
@verify        = 1,
@dbretainunit  = ‘days’,
@dbretainval   = 1,
@rptretainunit = ‘weeks’,
@rptretainval  = 1,
@report        = 1

exec expressmaint
@database      = ‘ALL_USER’,
@optype        = ‘LOG’,
@backupfldr    = ‘c:\ocsbackup’,
@reportfldr    = ‘c:\reports’,
@verify        = 0,
@dbretainunit  = ‘days’,
@dbretainval   = 1,
@rptretainunit = ‘days’,
@rptretainval  = 1,
@report        = 1

All of our OCS Databases are User Databases, not System Databases.  We can see this using SQL Server Management Studio which is not installed by default but can be downloaded from here.

Note: Keep in mind that we’re not using the default SQL Express instance of SQLExpress.  The OCS Front End Standard install will create and utilize an instance of RTC.

We now have our .SQL file created.  We’ll go ahead and create a new .bat file called ocssqlbackup.bat.  This batch file will run the following command:

This won’t work just yet.  You can see in the .SQL file, it’s calling the stored procedure “expressmaint.”  We need to create this stored procedure within SQL.  SQLDBATips has the vbscript code in order to do that here.  You take this code and save it as storemaint.sql.  Then run the following code:

Note: The website that shows these instructions specify the -S.\ as -S.\SQLExpress.  Again, we’re not using the SQLExpress instance, but rather the RTC instance.

You can delete the expressmain.sql file now.  This is a permanent change in our instance and we won’t need to run the expressmain.sql script again.

We should now be able to run our SQL backup batch file as our .sql command that specifies our databases and logs has been created and our batch file to call sqlcmd.exe to execute our .sql file has been created.

We can see our ocssqlbackup.bat file successfully runs and creates backups of our databases.

Scheduled Tasks

We obviously want to keep backing up our databases every night in case something goes wrong.  We’ll create two scheduled tasks.  One that runs ocsbackup.bat for our global, pool, and machine specific information.  And the other that runs our SQL Backups.

I am launching the Task Scheduler from Server Manager (I am using Server 2008 but you can access Task Scheduler on Windows 2003 by going to Control Panel).

Create a Basic Task and give it a name.  We’ll name this OCS Backup.  Click Next to Continue.

Specify how often you want the task to run.  I typically run it Daily. Utilize whatever method works best for your organization. Click Next to Continue.

Choose what time the Daily Task will run.  Again, choose whatever time works best for your organization. Click Next to Continue.

We’ll want to run the script.  Because of this, choose “Start a program.” Click Next to Continue.

Specify the path to our batch file. Click Next to Continue. Review the Settings and then Click Finish.

You can then forcefully run the Scheduled Task to ensure it runs.

Now don’t forget to create the second scheduled task to run the batch file for SQL Backups!

Your OCSBackup folder should look something like this after your scheduled tasks run and your data is backed up.

Backing up your data to a remote Backup Server

Now what good is having all this data backed up onto the OCS File System if OCS crashes?  No good!  We’ll still want to take your backup system and back up all these files including the OCS Standard Edition File Shares.  Now keep in mind that you will want to back up all of these files at some time after your batch files are set to run in Scheduled Tasks.  For example, my Scheduled Tasks are set to run at 8pm.  The batch files do not take long to run.  You can have your backup set to run at 8:30pm or 9:00pm.  Be sure to test and validate this is working as intended and you are getting successful backups.

The Standard Edition File Shares you will want to backup include:

So to sum it up, you will want back up all the above file locations and your OCSBackup folder.  Backing up your Reports folder is optional. But again, keep in mind you will want to run this file level backup after all your Scheduled Tasks are successfully run.

If we take a look at the F5 documentation for OCS 2007 R2 here, we see the following configuration requires for the Response Group Service (RGS):

What this is saying, is that our client will be connecting over 5071 TCP to our Load Balancer in order to communicate with the RGS.  This is incorrect!  5071 TCP is indeed used for Response Group Service communication, but this is only for Front End to Front End server communication.  The RGS has something called a matchmaking service.  The service on the client is just a website that communicates to the Load Balancer over port 443.  So, the million dollar question… Why do we get a service unavailable?

When you’re dealing with the RGS, each Front End Server has a Matchmaking service.  From the Technet Documentation:

Each Front End Server has a Match Making service, which is an internal service that is responsible for queuing calls and finding available agents. Only one Match Making service per pool is active at a time–the others are passive. If a Front End Server with the active Match Making service becomes unavailable, one of the passive Match Making services becomes active. The Response Group Service does its best to make sure that call routing and queuing continues uninterrupted. However, there may be instances when active calls are lost as a result of the transition. Any calls that are in transfer when the service transition occurs are lost. If the transition is due to the Front End Server going down, any calls currently being handled by the active Match Making service on that Front End Server are also lost.

The Match Making service is what utilizes 5071 TCP.  But as stated earlier, this is only for Front End Server to Front End Server communication.  Our Front End Servers need to be able to communicate with each other without traversing the load balancer.  This means that that each server must be able to contact DNS, get the IP of the other server, and then communicate with that IP over 5071.  This is key as to why we’re encountering the issue.

Sometimes, depending on the environment, servers behind load balancers will have multiple IPs assigned.  One for connectivity from the load balancer and another IP for other server operations such as management.  These Front End Servers had their default gateways set to the F5 and each Front End IP that was used for the F5 were on different segments.  The problem here is when one Front End tried to communicate to the other Front End, it would query DNS and get the IP and it would route to the F5.  The F5 would then route it back but the Front End Server saw it coming from the load balancer and think it’s an unauthorized server for RGS requests.  This is why Communicator would see the service as unavailable.

There are a few ways to fix this issue:

• Modify hosts file on each Front End Server so they are communicating to the correct IP which are on the same segment
• Rework your load balancing configuration so the Front End Servers only use 1 IP which is where the load balancer sends the traffic and have the Front End IPs be able to directly talk to each other.
• Modify DNS so all the traffic destined to the FQDN of the Front End Server would go directly to the Front End IP which is on the same segment as the other Front End IP.
• If you must keep both Front End Servers on separate subnets and have them route through the load balancer, if possible, modify the load balancer so the requests appear to be coming from the original host that sent the request instead of the load balancer.

When it comes down to it, you just need to make sure that when 1 Front End Server talks to another, it needs to appear that it is coming from the other Front End Server instead of the load balancer so that it is an authorized host for RGS requests over 5071 TCP.

Media Ports and Restricting Amount of Ports Being Used

The first thing to understand is that in OCS 2007 R2 (the same applies for R1), when a user attempts to activate any type of audio and/or video, they first attempt a peer to peer session.  The ports utilized here are TCP/UDP 1024-65535.  You can see what ports are used for OCS 2007 R2 here and here.  This port range is utilized mainly for users who are internal to the network.  If you want users to utilize peer to peer audio while internal to the network, you must ensure that this port range is open even if users are in different sites.

But what if you don’t want this entire port range open between your sites?  You can utilize Group Policy to limit the amount of ports that are being used.  These two settings include:

• PortRange/MaxMediaPort
• PortRange/MinMediaPort

The above group policy settings modify the following three registry keys:

• HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\Enabled REG_DWORD 1
• HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\MaxMediaPort REG_DWORD 40039 (for example)
• HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\MinMediaPort REG_DWORD 40000 (for example)

Note: Both clients must have these registry keys set in order for the modified port range to take effect.

You must have at least 40 ports open which is an IETF Interactive Connectivity Establishment (ICE) protocol requirement to ensure that Audio/Video port negotiation works for peer to peer while internal to the network.  ICE is a protocol that provides a mechanism for firewall or NAT traversal.  The RFC draft for this protocol can be found here.

Audio/Video Connectivity Scenarios

Two Users Internal to the Network (media ports open)

When these two users are internal , they will attempt peer to peer.  Because they can successfully connect to each other, they utilize peer to peer media.  This is why OCS scales pretty high; because a lot of connections are one to one which means that peer to peer media connections are never bridged through the server.  Because these users connect directly to each other for media, they have no need to connect to the Edge.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Audio/Video through the Web Conferencing Server

When users are connected through On-Premise Web Conferencing and activate Live Meeting (when internal or external… doesn’t matter), they are connecting directly through the Front End’s Conferencing MCU’s.  Because of this, even when it’s two users, the user’s are still connecting to the Front End MCUs.  If both user’s are external, they still connect through the Front End MCUs but are proxied through the Edge Server.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Two Users Internal to the Network and Any Users External to the Network

As previously stated, any time you have more than two users, peer to peer is no longer utilized and users always connect directly to the MCU on the Front End Servers.  This means that both users internal to the network will connect to their Front End server(s) and the external user will connect to the Front End server as well utilizing the Edge Server for proxying to the Front End.  There is absolutely no peer to peer connectivity in this situation.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Two Users on the Internet

When these two users are external , they will attempt peer to peer.  Because they can successfully connect to each other, they utilize peer to peer media.  This is why OCS scales pretty high; because a lot of connections are one to one which means that peer to peer media connections are never bridged through the server.  Because these users connect directly to each other for media, they have no need to connect to the Edge for Audio/Video.  You will still see the user connected to the Access/Edge over port 443 and/or 5061 (if these are your remote access port and federation port if you are using federation).  When users are connected through On-Premise Web Conferencing and activate Live Meeting, they are connecting directly through the Front End’s Conferencing MCU’s.  The Front End will have a certificate that contains the Pool Name and will/can contain SAN names for additional SIP domains that you may contain.  Because of this, SAN names are supported on Front End Servers.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Two Users Internal to the Network (media ports closed)

When these two users are internal , they will attempt peer to peer.  During their ICE negotiation, as previously stated, they will know the Internal Edge NIC in case their peer to peer connectivity fails. Because they fail to connect to each other, they will connect to the internal Edge NIC over either UDP 3478 or TCP 443.  ICE has a mechanism where it will test a lot of candidates to see where connections should be made.  ICE will test UDP 3478 and TCP 443 in parallel and if UDP 3478 works, the client will receive UDP 3478 due to it having less overhead.  If UDP 3478 does not work, the client will receive TCP 443.   If you anticipate on blocking ports between your users, make sure your Edge Server can scale high enough to deal with the amount of Audio/Video connections it will be handling.  To block one of your sites from doing peer to peer with other sites, block the peer to peer port range (discussed at the beginning of this article) from that site and block that site from communicating over UDP 3478 and TCP 443 to the Edge Server.  This will prevent clients from doing any type of media communication from user’s outside of their own site.  If you want to allow them to do peer to peer for users in some sites, modify the firewall ACLs accordingly for those sites.

Note: Diffserv markings for Quality of Service (QoS) are lost through an Audio/Video Edge Server.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

One User External and One User Internal

When one user is internal and one user is external , they will attempt peer to peer but not in the same sense as in two internal users. The external user will hit TCP 5061 to the Access Edge Server and will be provided with either UDP 3478 or TCP 443 for the Audio/Video Edge.  As stated earlier, UDP 3478 is preferred even if the connection test for TCP 443 and UDP 3478 were successful in testing.  If you attempt a telnet edgeserver.domain.com over the Internet, telnet will fail to connect.  This is because telnet uses TCP.  You can do a netstat -an to see your server listening on UDP 3478 and utilize a different program such as netcat which can attempt telnet to UDP by using netcat -u host 3478.  More information on netcat here.

Moving on… we see that the user will connect to the A/V Edge over UDP 3478 or TCP 443, but what about the internal user?  Because this is technically peer to peer, the internal user will NOT connect to the MCU on the Front End but will instead connect directly to the A/V Edge Server’s Internal NIC over UDP 3478 or TCP 443 as well.  The Front End A/V MCU will not be used in this scenario.  When you add a 3rd person to the conversation, the external user will connect to the Front End Server’s A/V MCU in which the A/V Edge will proxy this data for the user, and the internal users will connect to the Front End A/V MCU instead of the Internal Edge NIC.

Note: Diffserv markings for Quality of Service (QoS) are lost through an Audio/Video Edge Server.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Issue to be aware of

Certain certificate vendors like to add www automatically to the CN of your certificate request with consent from the person requesting the certificate.

So for example, our certificate request for a regular certificate (non SAN) was CN=Servername.domain.com.  These vendors provided the following certificate:

• CN=Servername.domain.com
• SAN=www.Servername.domain.com

Now this is where you can run into an issue when doing peer to peer and falling back to the internal Edge NIC or when one person is on the Internet and one person is internal while using Communicator.  Some certificate vendors like to assign a www as a SAN name to your regular (non-SAN) cert.  So if you requested a CN of Servername.domain.com, these vendors will automatically add www in front of your CN.  This messes up peer to peer audio/video negotiation.

This is important to remember when getting a 3rd party certificate for the Internal Edge NIC.  It is not supported to have anything other than a CN for this certificate.  The reason why is ICE negotiation will not work properly.  Because the www.servername.domain.com will be there as a SAN, the client will be provided the www.servername.domain.com name for ICE connectivity to the internal Edge NIC which will obviously fail.  Because of this, the scenarios above which utilize the Internal Edge NIC will fail.  To recap, the following two scenarios end up using the Internal Edge NIC:

• One user internal to the network and one user external to the network
• Internal users attempting to do peer to peer (media ports being closed) and falling back to the Internal Edge NIC

There are a few ways to fix/workaround the problem:

• Use a Windows PKI implementation for Internal Edge NIC
• Deal with the SAN name but use a CNAME for www.servername and redirect that to the servername HOST/A record using Internal DNS to do this as you are dealing with the Internal Edge NIC.
• If the vendor doesn’t add www to their SAN certs, you can get a SAN cert only with the CN filled out
• Go with a different vendor that doesn’t automatically add www to their regular certificates.

If you look at the OCS R1 requirements for deploying an Enterprise Pool, it tells you the following:

• If you are using a 32-bit version of SQL Server, log on to your Office Communications Server Back-end Database server as a member of the Domain Admins group.
• If you are using a 64-bit version of SQL Server, create the pool by using a computer with a 32-bit processor, such as the computer that you plan to use as the Front End Server. Log on to the 32-bit processor computer as a member of RTCUniversalServerAdmins and Domain Admins group and with user rights to create and modify SQL Server databases.

If you look at the OCS R2 requirements for deploying an Enterprise Pool, it tells you the following:

• If you are using a 64-bit version of SQL Server, log on to your Office Communications Server Back-end Database as a member of RTCUniversalServerAdmins and DomainAdmins group.
• 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. Log on to this computer as a member of RTCUniversalServerAdmins and Domain Admins group and with user rights to create and modify SQL Server databases.

As you can see, it’s a complete 180 between R1 and R2.  To make it easier to digest, here’s an easier format to see what you should do:

OCS R1 with SQL 32-bit – Create Pool on SQL
OCS R1 with SQL 64-bit – Create pool on OCS FE

OCS R2 with SQL 32-bit – Create Pool on OCS FE
OCS R2 with SQL 64-bit – Create Pool on SQL

The reason why it’s a complete 180 is because Microsoft wants you to run the installer on the native platform of the installer.  OCS R1 is 32-bit so you always want to run the installer on a 32-bit machine.  OCS R2 is 64-bit so you always want to run the installer on a 64-bit machine.

But the million dollar question is, is it really necessary to run it from the Backend?  Does that mean you have to insert your OCS CD, install .Net Framework, Visual C++, etc….  Well, you could, but you  can use LCSCMD to configure your pool instead.  LCSCMD is on your CD and you can just open a cmd prompt, navigate to your cd-rom, and run the LCSCMD command with the appropriate settings to configure your pool without needing to install at the tools the installer GUI would require.  LCSCMD would also bypass the requirement from running the installer on the same processor platform (x86/x64.) You can refer to the following article here for information on how to use LCSCMD to create an Enterprise Pool.

But, that doesn’t really explain why it is recommended running it on the Backend. After talking with Ken Alverson from Microsoft about this, I learned a few things.  The reason they recommend to create the pool on the SQL Server is to minimize the possibility of firewall/permissions from interfering.  The Create Pool requires access to both SQL as well as WMI.  You can technically open up all the ports to SQL as well as WMI and run Configure Your Pool from your OCS Server.  This is what I did but instead of opening it completely, I  ran Network Monitor to determine what ports to open.  You could also disable your Windows Firewall on your SQL Server to ensure access to your SQL Server.  Never disable the firewall service on Server 2008 as this disrupts proper communication.  Either turn the firewall off or go into the advanced firewall in the administrative tools and open everything up.

So in short, you have the following options with OCS R2:

1. Turn off firewall on SQL (don’t disable firewall service) and install from OCS Server (lowers security but easiest to do.)  After the pool is created, you can re-enable your firewall as long as you follow the OCS documentation (installation guide for Enterprise Edition) and open the necessary ports.)
2. Allow SQL Ports and WMI to traverse SQL Firewall (more secure than #1 but less easy to do)
3. Run Create Pool from SQL Server via the GUI Installer (more secure than #1 and #2 but not an option I like due to it installing GUI prerequisites)
4. Run Create Pool from LCSCMD via the CD which will install a SQL prerequisite I believe (most secure option but requires knowledge of the LCSCMD command.)  You can refer to the following article here for information on how to use LCSCMD to create an Enterprise Pool.

I would appreciate if readers can make a quick comment on what method you use.

In this Part, I will go over the installation of our Group Chat Server and Administrative Tools.

Part 1

Part 2

Group Chat OCS 2007 R2 Server Installation

When installing OCS R2 Group Chat  and running the setup executable, you will be asked to install several pieces of software to prepare the environment.

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.

You will then be asked to install the Microsoft Unified Communications Managed API 2.0 Core Redist 64-bit version.  Click Yes to Continue.

Once Microsoft Unified Communications Managed API 2.0 , you will be presented with the Welcome screen which will begin the installation process.  Click Next to Continue.

The next screen is the licensing screen.  Make sure you fully read the entire agreement!  Once you have done so (and I know you will, right?) Click Next to Continue.

Enter your Username and Company information. Click Next to Continue.

Enter the installation path you want the binaries installed to. Click Next to Continue.

When the feature screen appears, you have 2 choices which are both selected at the same time.  Keep in mind, that you must disable one of the options.  You cannot have both the Chat Server and the Compliance Server collocated on the same box.  Make sure the Chat Server is selected and the Compliance Server is not selected.  We will be installing the Compliance Service in the next Part.  Click Next to Continue.

Confirm your installation.  Click Next to Continue.

Installation is ready to proceed.  Click Next to Continue.

During the installation, you will see the Server Configuration wizard appear.  Because we chose the Chat Server to be installed, you will see three Server/Service roles being installed:

• Lookup Server
• Channel Server
• Web Service

Click Next to Continue.

We now want to specify what SQL Instance we want to use.  One thing to keep in mind is to take a look at the collocation technet article to see how databases can be collocated on the same SQL box.  You can find this article here.  You can see the following databases can be on the same SQL Box:

• Archiving database
• Monitoring database
• Group Chat database
• Compliance database (for Group Chat)

One thing to keep in mind here, is that for each database, it requires its own instance.  In the case of Group Chat database and the Compliance Database, the Compliance Database can be a dedicated database or it can be the same database as the Group Chat database.  In Part 2, we will be using the Group Chat database as the Compliance database.

As you may recall from the OCS R2 Enterprise article series here, we’re using a SQL 2008 x64 Back End.  Make sure port 1433 is allowed inbound.  Instructions on how to do this are documented in that article series.

Specify your Server\Instance and Database.  As stated, I’m just using the default instance for everything since it’s a lab.  Specify your settings accordingly.  Click Next to Continue.

The next screen will just notify you that your databases are empty and that it will create the schema information.  Click Next to Continue.

We will want to specify a Super User.  It’s pretty obvious what this user is.  It’s essentially the Administrator account in AD.  The first time you create AD, you will log in with the Administrator account and start creating other Administrator accounts from there.  The Super User is the same thing.  Because this is a lab, I am using the Administrator account to manage everything.  So in the User name field, I specified my Administrator account and clicked Add. Click Next to Continue.

Specify the name of your pool and the MTLS Certificate that will be used by your Group Chat Server.  You will need to create this certificate beforehand by using LCSCMD, CertSRV website for an internal CA, or using the OCS Administrative Tools.  Click Next to Continue.

Remember I said the Lookup Service is the one service that will be utilized across all Group Chat Servers and that it also needs to be SIP Enabled?  Well now is the time to enter in the Lookup Service credentials and SIP information. Click Next to Continue.

Do the same for your Channel Service. Click Next to Continue.

On the next screen, we’ll be asked for our Compliance settings.  Because this is the first Group Chat Server and we have not yet deployed our Compliance Server, we’ll leave these settings blank and re-visit the configuration later.  Click Next to Continue.

Specify the  directory that will be used for uploads to the Web Service.  You will want to use a UNC path, especially if you’re using multiple Group Chat Servers.  I created a shared folder called WebService.  You will need to ensure your Channel Service has read/write to this share (both Share and NTFS permissions.) Click Next to Continue.

Review your settings. Click Finish to Continue. When finished installing, Click Close.

You will want to ensure that Anonymous Authentication is enabled in IIS on your MGCWebService directory in your Default Web Site.  After doing so, you will want to use your Channel Service account as the credentials used for Anonymous Authentication.  It doesn’t have to be the Channel Account, but just an account that has RTCComponentUniversalServices permissions because the account needs to access the file repository and Message Queuing.

Group Chat OCS 2007 R2 Administrative Tools

As most of the other client and administrative tools installations, I won’t go over the installation procedures as they’refairly straightforward.  So go ahead and install the Administrative Console.  I have installed it on our SHUD-PG1 Server which is the server we installed the Group Chat Server on.

Once installed, go to Start > Programs > Microsoft Office Communications Server R2 > Microsoft Office Communications Server R2, Group Chat Administration Tool

Once you open it, Group Chat Administration will always be set to do an Automatic Logon and use the existing signed on account.

You may have trouble getting this part to work properly.  This is my 2nd time installing and getting Group Chat to work so I’ve went through the pain to get everything to work properly and seamlessly off the bat.  The trick is, during Group Chat installation, you gave it a super user.  You’ll want this to be your Administrator account you’re using to install Group Chat and the system that you will be loading the Administration Tool.  Only a super user can load up the Administrative Tool.  So if you set your Administrator account that you log onto which is also SIP enabled as the Super User, and are logged onto that account when loading up Administrative Tool, everything will just work.

If Automatic Configuration does not work, you can set the Account to Manual Configuration and manually configure the account to use for log-on, DC to use, etc…

You can now create new Chat Rooms on the left, add new Super Users, Chat Room Managers, etc..

Summary

Well folks, that is all for Part 2 of this article as well as the 2 part article series.  Hopefully it helps you plan and deploy Group Chat.

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.

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.

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.

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.