OCS 2007 R2 – External Audio/Video Conferencing Issues

The successful implementation of external audio/video conferencing in Microsoft OCS 2007 R2 appears to be an issue that many people face when deploying the product. I too have experienced this issue and this post will detail both the errors and resolutions put in place to enable external A/V conferencing on an OCS 2007 R2 Standard Edition deployment with a Consolidated Edge server. The implementation item’s listed in this post assume you have a firewall product in front of the Consolidated Edge server that is performing both resverse proxy and NAT features.

1. External A/V Conferencing – Errors

When testing multiparty A/V conferences I experienced the following errors. These errors were produced when adding a third participant to an existing two party (peer to peer) A/V conference.

Cannot perform the selected action. This action may not be permitted by the conferencing service. Please try again. If the problem persists, please contact your system administrator.

The call was disconnected because you stopped receiving audio from [email protected]. Please try the call again.

An error occurred while trying to take the call off hold. If the problem persists, contact your system administrator. More details (ID:500)

An error occurred while trying to start the conference. More details (ID:52031)

As you can see, there is not a single persistent error that is produced which unfortunately makes troubleshooting slightly more difficult. After spending some time performing SIPStack traces and reviewing Communicator logs via the Snooper Tool, I narrowed the errors down to a firewall and consolidated edge server configuration issue.

2. External A/V Conferencing – Resolution Items

The item’s listed below resolved the external A/V conferencing issues I was experiencing. These steps are also included in the official Microsoft production documentation for Consolidated Edge server deployments.

A/V Edge Service Name Resolution– Configure the Edge Server to resolve the FQDN associated with public A/V Edge service to the publicly routable IP Address, not it’s internal NAT’d IP address. For example, if your A/V Edge service has a public IP address of 100.200.255.255 and a NAT’d IP address of 10.45.16.5, if you run a command prompt from the Edge Server and type ping av.externaldomain.co.uk it must return 100.200.255.255. A good way of achieving this is making a hosts file entry on your Edge Server to force the FQDN to resolve to the public IP address.

A/V Edge Service NAT– Assuming you have a firewall product (ISA/TMG) in front of your Consolidated Edge server that is performing NAT, configure the A/V Edge service to support NAT by checking the “External IP address is translated by NAT” checkbox. This setting can be found under the Edge Servers properties dialog box.

Firewall Access Rules– Configure your firewall product with the following protocol definitions to allow A/V traffic to be passed to your Consolidated Edge server. Once you have performed this, create a new server publishing rule that targets your Consolidate Edge server and utilises the protocols you have just created.  Please note the below protocol definitions target ISA/Forefront TMG deployments specifically. A very useful article on performing this can be found here.

Protocol nameAV TCP In
Protocol typeTCP
DirectionInbound
Port Range50000-59999
Protocol nameAV UDP in
Protocol typeUDP
DirectionReceive/Send
Port Range3478, 50000-59999

Testing Access – If you are using internal clients to perform multiparty A/V testing then ensure those clients have unrestricted access through your internal firewall. I experienced an issue where outbound traffic from my test clients was being blocked by my internal firewall, which in turn created additional issues. Ensure you have complete outbound access for your test clients and then scale back access from there.

I hope this assists your external A/V conferencing implementation.

OCS 2007 R2 – Public IM Provisioning

I recently had to assist a customer with public IM provisioning for OCS 2007 R2, and while there are some relatively good guides on how to perform this on the internet, I haven’t found any that actually show you the provisioning form itself. Here are the steps to take in order to provision your SIP Domain(s) for public instant messaging connectivity.

1. Navigate to the Microsoft PIC provisioning website at the following URL: https://ocspic.livemeeting.com/ and sign in with your Windows Live ID.

2. Once logged in with your Windows Live ID you will be presented with the following screen:

Microsoft OCS 2007 R2 PIC Provisioning License

On this screen you will need to select your organisations Microsoft Licensing Agreement type, and hopefully you have already purchased the public IM CAL’s you need to federate with Yahoo!, MSN and AOL. Select the appropriate agreement radio button for your organisation, check to agree to the terms of service and you will then be asked for your Microsoft Agreement Number. If you do not supply this number, you will be unable to proceed with the provisioning process.

3. On entering your agreement number you will also see a small area of information that will be required later on in the provisioning process as shown below:

Information Required For The PIC Provisioning Process

In our case, we need to pay particular attention to the information listed under the “Initiation of new service” section. Once you agreement number is entered click Submit, and you will then be asked for your contact details. Please ensure these are correct, as Microsoft uses these details to send you information on the status of the provisioning process. Once you have filled in your contact details click Next.

4. Select the “Initiation of new service” link and you should then find yourself at the most important screen of the process, this is the area where you specify the FDQN of your Access Edge server and the SIP Domain names you wish to utilise. It is very important both of these values are correct, if the FQDN you specify in the provisioning form is different to that of the subject name specified in your public SSL certificate for your Access Edge service, federation with public IM providers will fail. Likewise this will also occur if you specify the wrong SIP domain names.

PIC Provisioning Form

For example, if my Access Edge SSL certificate had been generated with the subject name of sip.mycompany.com, the FQDN I would enter in the form would be sip.mycompany.com. In turn, my SIP domain would then be mycompany.com, this is assuming you had configured this external domain name as an additional SIP domain on your Front-End and Consolidated Edge servers.

5. Once you have completed all the required information, click Next and your all done. The lead time on completing public IM provisioning is 30 days, as Microsoft will need to submit this information to both AOL and Yahoo! if you have chosen to federate with the providers as well.

More information on the prerequisites for public IM and completing the provisioning process can be found at the following URL: http://go.microsoft.com/fwlink/?LinkId=155970

OCS – Deploying Office Communicator via GPO

Utilising Group Policy Object’s (GPO) to deploy software has always been a favourite of mine, the ability to deploy software packages to thousands of workstations in what can be a few clicks of a mouse. This method is certainly no exception when deploying Office Communicator 2007 R2 in your environment. Below is method I have used to both deploy the software and ensure it is running the latest Communicator hotfix.

1. On your workstation download a copy of the Office Communicator 2007 R2 installation package, which is commonly named communicator.msi. Also, download yourself a copy of the latest communicator hotfix (KB2028888), this file will be named communicator.msp. Save these files to the root of your workstations C:\ drive.

2. On your workstation create a new folder on your C: drive called “Communicator”, we’ll use this folder in a few steps time.

3. The first thing we need to do is to unpack the Communicator.msi file so that we can patch it’s content using the latest hotfix. Open a new command prompt window and navigate to the root of your C:\ drive where the Communicator.msi and Communicator.msp files were stored. So for example at the command prompt enter, without quotations:

“cd c:\”

Once you have changed directory to the communicator folder, you can then run the msiexec command to un-package the communicator installation to the “Communicator” folder we created in step 2. Type the following in the command prompt to perform this action, without quotations:

“msiexec /a communicator.msi TARGETDIR=C:\communicator”

 4. What you should now find, is that in the “Communicator” folder there are two sub-folders (PFiles & Windows) and a communicator.msi file. These are the extracted contents from the original package. Now we have these contents we can patch them with the latest hotfix. In the same command prompt window we used in step 3, run the following command without quotations.

“msiexec /p communicator.msp /a c:\communicator\communicator.msi”

Once this is complete, the files in the “Communicator” folder have now been patched. You should notice that the communicator.msi file in the folder will have grown slightly in size when the patch is applied.

5. Now that we have the patched package content, copy the entry “Communicator” folder to a network share that is accessible to all users. You may already have a network share for GPO packages, however if you do not you will need to make sure that everyone has at least read permissions on the folder in order for the software to install.

6. You can now proceed and create a new Group Policy Object in the Group Policy Management  Console (GPMC) for the communicator. Once you have created a new GPO with a name of your choice, perform the following steps.

7. Right click and select edit on your created GPO. In the GPO Editor window, select either the “Computer Configuration” or “User Configuration” nodes depending on your preferred deployment method.

8. Expand “Software Settings” and then right click “Software Installation” and select “New Package”.

9. In the New Package dialog box, browse to the UNC path of the shared folder you created in step 5 and select the Communicator.msi file and click ok.

10. Link the created GPO to the organisational unit of your choice and instruct your end users to reboot their workstations for the changes to take affect.

 You can find additional information on Communicator client installations at the following URL: http://technet.microsoft.com/en-us/library/dd637160(office.13).aspx

OCS 2007 R2 – CWA Presence Shows As Offline

I recently assisted with a deployment of Office Communications Server 2007 R2. During the deployment I experienced an issue with Communicator Web Access. When signing in via CWA, either internally or external, my SIP enabled accounts presence always showed as offline, even if I explicitly told the web access client to sign me in as available. The strange thing was, when I viewed the account signed in through CWA on a Communicator Client, the presence was correctly shown as available. After a lot of testing and investigation it turned out this was an issue related to deploying the Communicator Web Access role on Windows Server 2008 R2. To resolve the issue I performed the following actions:

1. On your CWA server download and install the latest July 2010 Communicator Web Access patch which is included in Microsoft KB 968802. This can be downloaded from the following location, however please note you will need to scroll down the article and download the cwamain.msp file.

Microsoft KB 968802: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4

2. Perform the following actions as detailed in KB 982021:

– Start secpol.msc on a Windows Server 2008 R2 operating system server.

– Click to select Local Policies and then click Security Options node.

– Make sure that the following values of the policies are set to “No Minimum.”

– Network Security: Minimum session security for NTLM SSP based (including secure RPC)

– Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers

3. Reboot your CWA server to ensure the security policy change takes affect.

4. Testing signing into CWA and ensure you presence status is correct.

For more information on deploying OCS 2007 R2 server roles on Windows Server 2008 R2 please see the following URL: http://support.microsoft.com/kb/982021