Microsoft Office Communications Server 2007 R2 – Part II

Once you have set up Office Communication Server 2007 R2 to provide IM within the organisation, the next stage is to provide full telephony by setting up the OCS Mediation Server and the OCS Edge Server to connect 'outside' the organization, and escpecially to a SIP trunk provider of Internet phone services.

In my previous article I explained about OCS in general and we started with installing the OCS Front-end server. Now we will continue with the OCS Mediation Server and the OCS Edge Server to create connectivity to the Internet.

Below an overview of the environment:


Figure 1 Overview of  environment

In the previous article we added the OCS 2007 Standard Edition to the current environment so now we have:

  • OCSDC, which is the domain controller for the ocs.local domain;
  • OCSIS, the ISA server which protects the corporate network;
  • OCSSTD, the Front End server of OCS.

Keep in mind that when you would like to use OCS on the internet your the  domain must be public and not an internal domain such as .local.

OCS Mediation server

The next server which we are going to install is the mediation server. The installation is not very hard but the configuration which needs to be done after the installation is a lot of work. So let’s start the setup on our mediation server called OCSMED.

Once the setup is started select the “deploy other server roles” option which will give you some additional options.  In the list you will find the mediation server, select this one it to continue the installation of the mediation server.

Before you begin the “real” installation make sure you are a member of the domain administrators group at a minimum and click install to start the installation. As said earlier the setup is not that difficult because you don’t have to specify anything besides the directory where to install the files.

When the setup is completed, activate the mediation server. During activation a service account and AD objects are created. The service account will be created only if necessary, in most cases it will exist because you already created it during the installation of the Front End server. In that case, provide the password which is used for the account and click next continue the setup.

After a few minutes the setup is finished and will let you know if it succeeded or not.

The third step is to configure the mediation server. You can find the MMC snap-in in the administrative tools section on the Front End server.


Figure 2 OCS Administrative tools

As you can see, both the Standard Edition Server and the Mediation server are listed in the administrative tools.

You might experience problems getting the status of the services running on the mediation server. In this case you can modify the firewall settings and set exceptions for the Remote Event log and WMI application. Adding these acceptions can be done via the Networking and Sharing Center and then select the option Windows Firewall. This will open a new Window which gives you the option to Allow a program or feature through Windows Firewall. In the list of programs and features you will find both the Remote Event log and Windows management Instrumentation (WMI) option, add an exception for these to only for the domain column. Refresh the view in the administrative tools and you will be able to see the correct status.

You may think you’re ready now, but when you have a look at the status of the Office Communications Mediation service you will see that it hasn’t started yet. This is normal behavior as we didn’t have configured the mediation server. Configuration needs to be performed before you can start the service.

Configuring is divided in two parts: the Forest voice properties and the mediation server. We will start with the Forest voice part because some things we configure here are needed to configure the mediation server. Let’s start with an overview of what we need to configure:

  • Location profiles;
  • Phone Usage;
  • Policy;
  • Routes.

Location profiles

Each location profile contains a set of normalization rules. These rules are used to translate regular phone numbers to the E.164 standard. It’s recommended to create a location profile per geographic location. So for Thunderbirds Inc. we will create a location profile called Amsterdam because their office is in Amsterdam.

But which normalization rules do we need to create, in the table below an overview of created normalization rules:


In both the pattern and translation you can use .NET regular expressions.

Let’s explain the Amsterdam national rule, in the Netherlands number to national calls would like be  020-1234567 . The first three digits are the city you are calling to and always will start with a 0.

Since we need to dial a 0 to get an external line, it means that when we call to for example someone in Utrecht we need to dial 00301234567. What all numbers have in common is that they will start with 00, using the ^ we will tell OCS that it needs to apply the rule Amsterdam national when a user dials a number starting with 00.

After the 00 there are 9 numbers left, 20-1234567, by specifying the \d{9} we tell OCS that there will follow 9 digits after the two zero’s. Using the $ sign we tell OCS that this is the end of the pattern.

As told earlier all numbers need to be converted to the E.164 standard, for example:  +31201234567 . So in this example we need to add +31 before the number the user dialed. After the country number simply add $1, this tells OCS to paste the number dialed after the country number and will make it E.164 compliant.

Microsoft has a very useful site which explains how you can create these rules complete with some examples.

Phone usages and Policy

The Phone usages and policy are related to each other. Using phone usages and policies you can restrict users dialing specific numbers or limit calls to numbers outside your country, configuring them is mandatory. The default phone usage and the default policy which will be assigned to all users contains no restrictions.

Policies can be set on Forest level or per user, depending on the rules of a company.

Before you can create a policy you must create phone usages, once created phone usages can be added to the policies.

Below an example of how you can configure them:



Using routes you define how numbers are routed and which phone usages may use this route.  A route exists of a few parts:

  • name, the name of the route;
  • description, the description of the route;
  • target phone numbers, to which phone numbers must this route be applied;
  • gateways, which gateway(s) may be used to place this call;
  • phone usages, which users are allowed to use this route.

Just as the normalization rules Microsoft has also a page which will help you setting up the routing.

Combining all together can be very complicated, that’s why Microsoft developed the Routehelper tool which is part of the OCS 2007 R2 resource kit. With this tool you can test your complete configuration before bringing it in production.

The routehelper utility is installed in the Reskit directory below the Microsoft OCS  directory. When opened, you will see the configuration which the utility retrieves from the Front End server. Here you will find the location profile(s), normalization rules, policy/policies and phone usage(s) just configured.

There are multiple options in these tools which can be divided in two parts:

  • ad-hoc  testing;
  • testing using test cases.

Using the adhoc testing method you have three options:

  • manual, can be used to test a policy works as you planned;
  • user, can be used to test if the settings for a specific user are correct;
  • gateway, can be used to test a specific gateway.

For all these methods you will need to provide the information which you would like to test, for example, you would like to know how a call is routed when a user dials 00301234567. So we fill this in in the dialed number field. The user is working in Amsterdam so we select the Amsterdam.ocs.local location profile and the user is assigned to the unrestricted policy.

We fill in the information on the custom tab and press the test button to start the simulation.


Figure 3 Output Routehelper using ad-hoc testing

Above you will see the result of the just performed test:

  • the number will be normalized using the national normalization rule;
  • the number will be routed to the PSTN via OCSMED which is our mediation server.

The ad-hoc method is nice when you would like to test just a single number. But in test environments it can be very useful if you can run a bunch of tests which will test every possibility, for example:

  • dial local numbers;
  • dial national numbers;
  • dial international numbers;
  • dial the emergency number.

These four options can be tested with different policies so you can also test if calls are blocked if a user is not permitted to call a number. If a call is blocked you will see the following message in the results box: Unable to route. Response code 403 will be returned.

Before you can start testing using the test cases you will need to specify the following information:

  • dialed number, the number which you like to dial;
  • CN, client side normalization performs normalization on the client side before submitting it to the server;
  • location profile, which location profile should be used;
  • policy, which policy would you like to apply;
  • expected translation, how is the number being normalized;
  • expected phone usage, which phone usage will be used to place the call;
  • expected route, which route is being used to route the call to their destination.

In the example below we used the phone numbers:  020-1234567  and  030-1234567  using different policies. As you can see the first line has only the local policy assigned to it, this should prevent the caller to dial a number outside of Amsterdam. That’s why the expected phone usage and expected route both are empty.


Figure 4 Output Routehelper using test cases

When your testing is done and the tests have passed you can continue configuring the OCS Standard Edition server. This can be done by getting the Front-end properties of the Standard Edition server and selecting the voice tab. Here you will need to select the default location profile which is used by the server.

OK now everything is configured for voice we can return to the mediation server as it was not configured yet. Just get the properties of the mediation server and you will see this:


Figure 5 Properties of mediation server

Ensure that you fill in the following field: communications server listening IP address, gateway listening IP address, default location profile. The A/V Edge Server can’t be configured yet because we don’t have one. To finish the configuration using the administrative tools click the next hop connections. On this tab you will configure what the mediation server has to do when a call is placed to a number outside the OCS environment and which gateway handles incoming calls. As we only have one mediation server this will be the gateway for incoming calls and when your press the arrow from the drop down menu you will only see one.  For outgoing calls you will need to specify the FQDN/IP-address of the VOIP gateway used to place calls to the PSTN. Since R2 this can also be a Sip trunk delivered by a provider.


Figure 6 OCS environment with direct SIP trunk

When everything is configured press the apply button to close the window and go back to the mediation server where we will perform the last step of configuring the mediation server.

The last step is to create the certificate request and assigning it to the server. The steps are exactly the same as for the Front-end so a quick recap:

  • generate a .CSR file using the create new certificate task;
  • send the .CSR file  to the Certificate Authority;
  • once the certificate is received from the Certificate Authority install the certificate using the “process an offline certificate request and import the certificate” option;
  • ensure you get the message that the certificate is installed correctly.

And now the time has come to start the mediation server services. You can do this on the mediation server itself by going to the services.msc MMC snap-in and starting the Office Communications Mediation Server.

Edge Server

To complete the OCS environment we only need to install the Edge server to be able to communicate with the outside world and give internal users the possibility to logon when they are working at a customer site.

Before starting it make sure you have configured your ISA server correctly according to this article.

If you did not configure an external url during the wizard, then create one know using the following command:

The lcscmd can be found in c:\Program Files\Common\Microsoft Office Communications Server\

When done start the setup on the Edge server by selecting deploy other server roles followed by deploy Edge server.

Select the option to install the files and follow the wizard to install the necessary files for the Edge Server. When ready continue with the next step, activate the Edge server, this will create a service account which is used to run the necessary services and is called RTCProxyService.

When everything is OK we can continue to configure the Edge server. Before starting this ensure that the Edge services are stopped, the wizard will also tell you this. The next question the wizard will ask you is if you like to import settings from a file. This option may very use full when you have multiple Edge servers behind a load balancer. For now we just leave it as it is and go to the next step.

After configuring the internal interface and fqdn it’s time to configure the Access Edge, Web Conference Edge and A/V Edge.  But first a short explanation because this is very import to configure this correctly.

The Edge server needs three external IP addresses. These addresses need to be assigned to the external NIC. In our test environment we use one NIC for all roles but in a production environment I recommend to use one NIC per role.  The IP address for the A/V Edge must be a publicly routable address, this means that you will need to connect your NIC used for the A/V Edge directly to the internet in most cases. Another option is to use a firewall which lets you directly route public IP addresses through it.

But why does the IP address of the A/V Edge must be publicly routable? This is a question you may expect from a person who’s responsible for the network security. This is because the A/V Edge uses both Interactive Connectivity Establishment (ICE) and Simple Traversal of User Datagram protocol (UDP) through network address translators (NAT), STUN for short. As stated in RFC 3489 it’s a requirement of this protocol that the IP address must be publicly routable.

Let’s continue configuring, please ensure that you select the correct ip-address and fqdn for the correct role. These ip-addresses and fqdn’s must be configured in your external DNS so users from the outside can connect to your OCS environment. Let’s give a short example:

We have the following external IP addresses available:


Since we have three roles we need to create three records in our external dns which point to this IP addresses:Edge:

  • Webconference:
  • A/V Edge:

If you would like to IM with users from Hotmail then now it’s time to configure this. In the screen below you can see the options which you can configure for federation and remote user access. For now we only select that remote users may access the network, this will give users the possibility to use the Microsoft Office Communicator MOC from outside.


Figure 7 Configure Edge Server Wizard

Next steps will ask you for the name of the pool server and for the SIP domains which are in use.  If you’ve got multiple Standard Edition servers add them all when asked to provide the authorized internal servers.

Once all required information is gathered the wizard will configure the Edge server and after several seconds the configuration wizard is completed.

Then it’s time for the certificates again, OCS will need them to perform secure communication with the clients and server-to-server communication. Below an overview of the certificates and configuration of them:







External / Access Edge
and if your server hosts other SIP domains also list them here

External  / Web Conference


External / A/V Edge


Once all certificates are installed we can start the services by pressing the run button.

After installing the Edge server don’t forget to update the server with the latest patches. If you won’t do this you may get problems while performing the validation tests. One of them is that you can’t perform the validation of A/V Conferencing this will check if a user can authenticate. This is due to a bug when the RTCProxyService has locale settings other than en-US/409, this bug is fixed April 2009.

Now we have our Edge server we must tell the Front End server that our environment has an Edge server. For this we will need to get the global settings of our OCS Forest, these can be found when right clicking on the Forest – in the administrative tools.

This will open a new window where you will see several tabs, select the Edge Servers tab and add the internal FQDN of the Edge server, in our case OCSEDG.ocs.local. When adding the A/V Edge Server you also need to provide a port number which is 5062. Once configured the settings click on OK to close the Window.

Go to the Federation tab and select that you want to federate with other organizations and add the internal FQDN of the Edge server, press OK to close the Window.


Figure 8 OCS  Server Global properties

When we configured the settings on forest level next step will be to configure the settings on server level.  Right click the server name, in our case OCSSTD, and select the Pool Properties option. Here you will find the A/V authentication service, when pressing the arrow of the pool down menu it will display all A/V authentication servers. Select the one which you like to use for authentication and press OK to close the Window.

Next option will be to configure the Edge properties for Web Conferencing. Get the Web Conferencing Properties and add the internal and external fqdn of the Edge using the add button.

When all settings are made on the server restart all the OCS services using the stop all running services and start all running services. This will ensure that new settings will be applied immediately.

To finalize the configuration get the properties of the mediation server and select the OCSEDG as A/V Edge server from the dropdown menu.

Now our OCS environment is completed it’s time for some testing. These tests are available after running the installation from the setup menu but you can also run then from the administrative tools by right clicking the OCS Standard Edition and select the option validation followed by the test you would like to perform.

This will start a wizard which will guide you through the steps. Let’s validate the configuration of the Front-End server.


Figure 9 Validate Front End configuration

This will give us a few options:

  • validate local server configuration, as the name already tells you this option will check the configuration of your Front End server;
  • validate connectivity, will also perform configuration checks and will perform some connection checks such as can DNS resolution be performed, can it connect on the MTLS port and some other things;
  • validate SIP logon, will check if the specified users can logon and will give you the option to test communication when you have federated with another company. As an extra test you can enable the option to test client auto-logon. This will test if a user can logon using the SRV records created in the DNS;
  • validate IM Conference, this check will test if users can send Instant Messages to each other.

Once the test is completed it will tell you if everything is OK or if errors were found. If there are errors you will have the option to review the log file. This will be displayed using Internet Explorer and you can collapse the items by pressing the + sign.

For the Edge these tests can be performed by opening the computer management and expand the services and applications node. Here you will find one item called Office Communications Server 2007 R2, right click it and select the validation option followed by the test.

The test which can be performed on the Edge is the same one as on the Front End with one exception, you won’t have the option to validate IM Conference.

During the validation of the local server configuration, connectivity and SIP logon the Edge will check the configurations of all Edge servers and will try to contact several services. When the test is completed it will tell you if there were any errors or not.


In these two articles I tried to explain how to install OCS 2007 R2. Initially to offer an Instant Messaging and presence solution and in this article I explained how to create a complete voice solution. Next steps can be to connect to an Exchange 2010 Unified Messaging Server, or maybe to connect to a Cisco Call Manager solution for example. Great topics for future articles. If you have any questions please do not hesitate to contact us.

This article was commissioned by Red Gate Software, engineers of ingeniously simple tools for optimizing your Exchange email environment.
Learn more about Exchange Server Archiver and PST Importer.