During the deployment of an OCS Communicator Web Access Server there is a setting that is not covered in much detail in the documentation: the Communication Server Listening Port. No default or suggested value is given, as shown by this screenshot of the virtual server creation wizard:
This port is used by the Communicator Web Access Server to listen for inbound communications from other OCS servers. When an additional Virtual Web Server is added to the same host, as is common when both Internal and External types are setup on the same server, the new virtual site’s listening port must be on a different port then what the initial site is configured for, otherwise the following error will appear:
This is also a common error when attempting to use a standard OCS port (like 5061) when CWA has been installed on an OCS Front-End server (such collocation is unsupported) . Since the Front-End services already occupy that port then an unused port must be specified. If CWA is installed on a separate server (as it should be) and the first, internal virtual site activation accepts 5061 as a value but the second virtual site activation does not, then it can be a bit confusing since one might think that there should not be a port conflict if the second site is configured on it’s own IP address.
Even though both virtual sites should be setup on different IP addresses, so that the default TCP 443 value can be used for the IIS site, all back-end OCS server communications still happen on the host’s primary IP address, which is what is resolved by DNS for the server’s FQDN. It’s common practice to set the first virtual site configured during the initial CWA deployment to 5061, and additional sites can be set for values of 5062, 5063, etc. There is no requirement on what port is used, except that it can’t already be in use on the host server.
For example, assume a CWA Server is configured with both an Internal and External virtual site, using the following configuration:
|Communicator Web Access Host Server||ocs02.schertz.local||192.168.207.14|
|Virtual Web Server 1 – Internal||https://im.schertz.lab||192.168.207.14||443||5061|
|Virtual Web Server 2 – External||https://im.schertz.lab||192.168.207.15||443||5062|
The way that the settings are displayed in the Communicator Web Access management console, it almost appears as if those listening ports are associated with the same IP address that the virtual web site is:
But that is not the case. There are a couple ways to verify exactly which IP address each Listening Port is actually listening on by using either simple netstat command or by capturing traffic on the server. The following diagram shows the basic traffic flow of two separate conversations, one between Workstations 1 and 2, and another IM session between Workstations A and B. The workstations on the left-hand side are typical Office Communicator users while those on the right-hand side are using Communicator Web Access with a web browser. Workstation B is located outside the corporate network and is directed through the firewall to the External CWA site running on the second IP address.
Below is a screenshot of a Network Monitor session with captured traffic from the two separate IM conversations:
Instant messages sent from Workstation 1 to Workstation 2 appeared on the CWA server as coming from the OCS Front-End server (OCS01) and were directed toward the CWA server (192.168.207.14) to port 5061.
Instant messages sent from Workstation A to Workstation B also came from the same Front-End server and were directed to the CWA server on the same primary host IP address (192.168.207.14), but were sent to port 5062, and not to the external virtual site’s IP address of 192.168.207.15.
Additionally, a netstat command can be issued at the same time to validate that the listening ports (5061 & 5062) are only established on the same, primary IP address. (This only displays active connections so if no users are currently using CWA then the ports won’t be listed.)
Changing the Listening Port
Unfortunately the Communicator Web Access management tool does not offer the ability to change the configured listening port after the virtual site has been created. The only port values which can be modified in the virtual server’s properties are: the client-connection port (which appears on the Connectivity tab and is typically set to 443) and the next-hop connection port (shown on the Next Hop tab, usually 5061). The latter is actually the remote listening port on the Front-End server that CWA will attempt to connect to. Nothing here about listening port that CWA itself is using for each virtual site.
The only way to change this setting is to manually update the TrustedServiceListeningPort WMI property.
- On the CWA server run wbemtest.exe to access the Windows Management Instrumentation Tester application.
- Click Connect.
- Clear the ‘Namespace’ field and enter rootdefaultrtccwa_repository and then click Connect.
- Under ‘IWbem Services’ click on Open Class.
- In the ‘Get Class Name’ window enter MSFT_CWASiteSetting for the Target Class Name.
- Click Hide System Properties to help filter the list a bit.
- Click on Instances to see a list of installed CWA Virtual Servers.
- Double-click on the desired instance to view the properties. To identify the instances compare the ‘Description’ property value with the description name shown in the CWA administrative tool, as shown below:
- Highlight the property TrustedServiceListentingPort and click Edit Property.
- The configured value is stored in both decimal and hexadecimal so be careful changing the value to insure that the format is not altered incorrectly. Simply update both values (use the Calculator in Programmer mode to validate both formats are equal).
For example, change the port from 5062 to 1975 (7B7 in hex) and click Save Property.
- Click Save Object. at the ‘Object Editor for MSFT_CWASetting.Name’ window.
- Click Close, Close, Exit.
- Refresh the CWA Management console window and the new port setting should be displayed.
- Issue a Restart on the specific virtual site in the CWA management console to complete the change.