Office Communications Server Edge Server on Windows Server 2008: Understanding the Strong Host Model
Published May 20 2019 02:37 PM 1,524 Views
Brass Contributor
First published on TECHNET on Sep 13, 2010

This article describes how to correctly configure the Microsoft Office Communications Server Edge Server role on the Microsoft Windows Server 2008 platform when three or more network interfaces are used. In a basic Edge Server deployment, only two network interfaces are used (one is internal-facing and the other is external-facing). But when multiple interfaces are dedicated for external-facing communications, changes in the networking behavior of Windows Server 2008 R2 and Windows Server 2008 can limit proper traffic routing, preventing Web and A/V Conferencing features from working for external Microsoft Office Communicator clients.

Author: Jeff Schertz

Publication date: August 2010

Product version: Microsoft Office Communications Server 2007 R2, Office Communications Server 2007, Microsoft Windows Server 2008 R2, and Windows Server 2008



I originally wrote this article in 2009 for my blog after I started seeing the first few production deployments of Microsoft Office Communications Server 2007 R2 on Microsoft Windows Server 2008. Until then, most companies were still standardized on Windows Server 2003 and had only just started moving new deployments to systems that were based on Windows Server 2008.

During the first deployment of a large-scale Office Communications Server 2007 R2 Edge Server on Windows Server 2008, I discovered that the previous best practices didn’t seem to apply in this scenario. After configuring the Edge Server in the same manner as I had many times before, the Conferencing traffic was failing to route correctly between the server and external clients. I began to investigate what had changed in Windows Server 2008 that prevented the Communications Server 2007 R2 Edge Server role from functioning correctly. It turned out that the use of multiple external network interfaces was the key, which in turn uncovered an important change in the default networking behavior between Windows Server 2003 and Windows Server 2008.






Let us first revisit a proper configuration of an Edge Server when using multiple external interfaces.


Although this example is using private IP addresses with a single consolidated Communications Server 2007 R2 Edge Server (with a static network address translation (NAT)-compatible external firewall) the scenario still holds true if publicly routable IP addresses are used.


Figure 1 shows an example configuration for an Edge Server based on system requirements and best-practices by using two separate perimeter TCP/IP networks located between separate external and internal firewalls.


Figure 1. Edge Server network interface layout


!--src=[..localbf7a94dd-4677-43ac-92d7-41a5ad634f71.jpg]-->


Table 1 shows how the various IP version 4 (IPv4) network properties are configured on each interface in this sample scenario. The following standard best practices are adhered to:



  • Setting the default gateway on only one interface (see Table 1).

  • Network routes to internal hosts are configured by adding static, persistent routes in Windows Server (see Table 2).

  • Setting the DNS server addresses on an interface that faces the network where the DNS servers are located.

  • Preventing each external interface from registering its IP address with a DNS server.


Table 1. Edge Server TCP/IPv4 network configuration for Windows Server 2003



































Edge Interface IP Address Subnet Mask Default Gateway

Internal interface



10.1.1.30



255.255.255.0



!---->



Access Edge Server



172.16.1.31



255.255.255.0



172.16.1.1



Web Conferencing Edge Server



172.16.1.32



255.255.255.0



!---->



A/V Edge Server



172.16.1.33



255.255.255.0



!---->






The default gateway is defined on one of the external network interfaces and not on the internal network interface. Additionally, a static route is defined to route traffic to the internal 192.168.1.0 subnet as shown in Table 2.


Table 2. Edge Server TCP/IPv4 persistent routes

















Network Address Netmask Gateway Address Metric

192.168.1.0



255.255.255.0



10.1.1.1



1






Not only do the front-end servers and other servers that are running Communications Server need to communicate directly with the Edge Server’s internal network interface, but so do any internal Microsoft Office Communicator client workstations. For example, A/V sessions between internal and external clients travel directly through the Edge Server, not through the internal front-end server. This underscores the best practice of publishing the Edge Server’s internal fully qualified domain name (FQDN) in the internal DNS zone and not just defining it on the front-end server as a HOSTS file entry.


Because of this behavior, the route definition needs to include more than just the front-end server—it should include the entire routable internal network space. If multiple subnets are used internally, either a larger mask would need to be used (if all the networks are contiguous in the same IP numbering scheme) or multiple static routes would need to be added to include any and all networks where Communications Server hosts, clients, and devices may reside.


For this example, only the internal 192.168.1.0 network needs to be configured. This is performed by using the following route command on the Edge Server. The IP address of the internal-facing router (10.1.1.1) is where all traffic for internal networks should be directed. The –p switch adds the route persistently so that it’s retained—even after a server restart.


route add –p 192.168.1.0 mask 255.255.255.0 10.1.1.1


The primary and secondary DNS server settings should be defined on only an interface that is facing the network where those DNS servers are located. Usually, private internal DNS servers are used for the Edge Server’s name resolution duties that would be located on the intranet or perimeter network. As a result, the best location for storing those settings is in the internal interface’s IPv4 properties. But if public DNS servers (located in a perimeter network or the public Internet) are used, configure the DNS server settings on the external interface.


For each external interface’s Advanced TCP/IP Settings property sheet, ensure that Register this connection’s addresses in DNS check box is cleared as shown in Figure 2.


Figure 2. Windows Server 2003 Advanced TCP/IP Settings property sheet


!--src=[..local8a9ae070-bd9d-498c-b26d-06ec1192fb12.jpg]-->


This overall server configuration works on Windows Server 2003 because the operating system adheres to what is called the Weak Host Model in networking. This means that all outbound traffic leaves the server on a loosely defined primary external interface . In our scenario, the Access Edge network interface would hold this title because it has the default gateway defined on it. The other externally-facing interfaces don’t have a default route defined. Network traffic from external clients that are inbound to the Edge Server and reach any of its network interfaces would complete its outbound trip out of the single primary interface. Here, that interface is the Access Edge. It is shown in Figure 3.


Figure 3. Weak Host Model network traffic routing with multiple external interfaces


!--src=[..local8ef91a68-b628-406d-b06e-6957addf2a5f.jpg]-->










Windows Server 2008 by default now uses the Strong Host Model. This model no longer specifies the requirement of a primary interface role among the multiple network interfaces. For more details about the Strong Host Model, see Strong and Weak Host Models .


When traffic enters a specific interface, the response traffic will always be sent back out through the same source interface as shown in Figure 4.


Figure 4. Strong Host Model network traffic routing with multiple external interfaces


!--src=[..localba63f4a5-d333-4e1a-ac4f-cab55492bf83.jpg]-->


The initial benefit that can clearly be seen is that traffic is now segregated and bandwidth more efficiently utilized than with the Weak Host Model. External Office Communicator clients can sign in and federation will function, but external Web Conferencing, A/V, and Desktop Sharing won’t work. This behavior also makes it easier to design routing and firewall policies. As a result, return traffic can be predicted correctly. Similar communication rules can be bound together in the same firewall policies.


Using the same configuration as on Windows Server 2003 no longer works for Windows Server 2008.


In Windows Server 2008, when external Web Conferencing Edge or A/V Edge traffic is routed to the Edge Server on a specific interface, the return traffic will exit the same interface the inbound connection arrived on. If no default gateway is configured on these additional network interfaces (that is, A/V Edge or Web Conferencing Edge), outbound traffic from those network interfaces fails to find the default gateway, thus the server cannot properly route the outbound traffic. It’s easy to verify this behavior by observing traffic on the external firewall and by capturing packets on the Edge Server because return traffic is dropped when no available outbound route can be found for the network interface.










There are actually two ways to resolve this problem in Windows Server 2008. Either modify the network configuration to allow traffic to correctly route out of any external interface or revert Windows Server 2008 back to the Weak Host Model.







The first approach is to set the same default gateway on each of the external interfaces. This would usually go against best practices to define multiple default routes on the same Windows Server when connected to IPv4 networks. With multiple network interfaces connected to the same network, each adapter must have a valid next-hop route defined in order for the Strong Host Model to function.


The changes in Table 3 have set the same default gateway on each of the external network interfaces. It is important to make sure a default gateway is not set on the internal interface, though, because the previously defined static route is still applicable.


Table 3. Edge Server TCP/IP network configuration for Windows Server 2008






































Interface Role IP Address Subnet Mask Default Gateway

Internal Edge



10.1.1.30



255.0.0.0



!---->



Access Edge



172.16.1.31



255.255.255.0



172.16.1.1



Web Conferencing Edge



172.16.1.32



255.255.255.0



172.16.1.1



A/V Conferencing Edge



172.16.1.33



255.255.255.0



172.16.1.1









In this approach, any of the three external interfaces could be used for initiating outbound connections from the Edge Server to external hosts. Viewing the route table with the route print command after setting the default gateway on all the external network interfaces shows that all three default routes have the same metric value (10) as shown in Figure 5.


Figure 5. Windows Server 2008 TCP/IPv4 Active Routes


!--src=[..local3fc409ea-d906-4c22-b3ff-2d6ea5ad90a7.jpg]-->


For responses to inbound traffic, this is not a problem. The Strong Host model dictates that the response leaves through the network interface that the initial request entered on. Because there is a route defined, the traffic successfully locates the external router and the external firewall sees the return traffic originating from the same IP address that the request was sent to. Therefore, communications should function as expected.


However, when initiating an outbound connection, (that is, an internal user starts an IM conversation with a Federated or Public Instant Messaging Connectivity (PIC) user) this network traffic needs to travel out of the Access Edge network interface to match the traffic profile that the external firewall would be configured for (TCP 5061 outbound). If the external firewall was configured to allow outbound traffic to access the Internet on all TCP/UDP ports from each external IP addresses of the Edge Server, the outbound connections would work regardless of the chosen interface.


But often the external firewall would be configured to allow only inbound and outbound traffic over the ports defined in the Edge Server deployment documentation. For example, outbound Federation traffic over 5061 would only be allowed from the Access Edge IP address and not from either of the Conferencing interfaces. If this traffic was to leave from a different interface, the external firewall would drop this traffic because it would not be originating from the expected port and IP address.


Force the Access Edge network interface to be the primary default route network interface by configuring the default gateway on only the Access Edge network interface. The route command is then used to configure and specify custom metric values for the additional routes. Instead of adding the same default gateway value to the other two network interfaces (A/V Edge and Web Conferencing Edge), create a static route and assign a metric of a higher value to each of them. This ensures that the Access Edge network interface is used to initiate outbound connections. When the Edge Server initiates external network connections, it will route the outbound traffic through the Access Edge network interface.


You must configure these additional routes from the command line. Modifying the metric value isn’t possible in the Default gateway setting in the Network properties interface.







Confirm that the Access Edge network interface is the only external interface that is configured with a default gateway as shown in Figure 6.


Figure 6. Windows Server 2008 TCP/IPv4 Properties page


!--src=[..localf6c2ae93-354a-4bda-978f-ee7e253d2cd0.jpg]-->


From a Command Prompt window run as an administrator, run route print to identify both the assigned metric for the Access Edge interface’s default route entry and the defined indexes for each external network interface. In Figure 7, the Index values are 16, 15, and 14 for the external network interfaces. The default route’s metric is 276.


Figure 7. Output from the route print command


!--src=[..local67d8a4aa-a523-4165-af26-d901e5770727.jpg]-->


Alternatively, the netsh interface ipv4 show interface command can be used to identify the interface indexes as shown in Figure 8 (but not the default route metric as shown in Figure 7).


Figure 8. Output from the netsh interface ipv4 show interface command


!--src=[..localc7c7a40a-4350-478c-a736-b4f3ac1f3989.jpg]-->


After the default route metric and individual interface indexes are known, issue the following route commands to set higher metric values for the additional external interfaces.


route add –p 0.0.0.0 mask 0.0.0.0 172.16.1.1 metric 277 IF 15


route add –p 0.0.0.0 mask 0.0.0.0 172.16.1.1 metric 278 IF 16













An alternative approach would be to disable Strong Host functionality, and then configure Windows Server 2008 to use the Weak Host Model. This would allow the same single-external Default Gateway definition, but has some inherent drawbacks. Especially now with Communications Server 2007 R2, a consolidated Edge Server can more easily host all external roles on the same physical interface (because NAT restrictions have been eased). As such, the benefits of using multiple physical interfaces for each external role are increased bandwidth and segregated traffic. Reverting the Edge Server to a Weak Host Model could inherently negate those benefits. However, an Edge Server that handles a lot of A/V communications (requiring more bandwidth than other types of traffic) by using Weak Host would effectively offer a dedicated network interface for internal A/V with outbound A/V travelling over the “primary” Access Edge interface. This balances A/V traffic across two interfaces. Because of the differences in implementation of interface and switch port features (such as duplex modes and traffic handling capabilities), actual benefits may vary because the two streams are traveling in opposite directions.







Use either the route print or the netsh command as shown in Figure 7 to identify each interface’s index value.


Verify each adapter’s current Weak Host settings by listing the IPv4 details for a specific interface by using the netsh interface ipv4 show interface 14 command. The output is shown in Figure 9. The Access Edge interface’s settings are shown in Figure 7.


Figure 9. Output from the netsh command


!--src=[..local98528d5d-c883-499d-8160-31a0d7833808.jpg]-->


Issue a pair of commands, show as follows, for each interface to enable Weak Host sending and receiving.


netsh interface ipv4 set interface 14 weakhostsend=enabled


netsh interface ipv4 set interface 14 weakhostreceive=enabled


netsh interface ipv4 set interface 15 weakhostsend=enabled


netsh interface ipv4 set interface 15 weakhostreceive=enabled


netsh interface ipv4 set interface 16 weakhostsend=enabled


netsh interface ipv4 set interface 16 weakhostreceive=enabled


Verify the setting changes again on each adapter with the netsh interface ipv4 show interface 14 command as shown in Figure 10.


Figure 10. Output from the netsh interface ipv4 show interface 14 command to verify setting changes


!--src=[..locale1a77023-3baf-4c1d-bb12-549f8e58e75a.jpg]-->
















Using the Strong Host Model in Windows Server 2008 R2 and Windows Server 2008 affects external traffic routing from the Edge Server. The Weak Host Model in Windows Server 2003 allows outbound traffic routing to function normally without any additional configuration. Take this into account when you are planning to deploy or are deploying the Edge Server role on Windows Server 2008 or Windows Server 2008 R2.


To properly route outbound traffic, use the option that is most appropriate for your specific network design. Your solution is typically most dependent on external firewall configuration. In most scenarios, however, either option can correctly route traffic, but factor into your decision how you intend to use the different Edge Server features. The two options allow traffic to be either balanced or segregated between separate external network interfaces.


Defining multiple routes by using ordered metrics is usually the desired approach to properly route external outbound traffic. This approach is also typically the most flexible because the external firewall is often handled by different personnel. As such, the firewall may not be customizable beyond the documented Edge Server requirement due to corporate policies or hardware limitations.













  • Visit the Communications Server main page at


Version history
Last update:
‎May 20 2019 02:37 PM
Updated by: