A good deal of preparation work goes into making an
Edge Server ready for deployment, and the actual installation of Lync
Server is probably one of the easiest parts after a server is correctly
configured. This section discusses some of the configuration
requirements and considerations an organization must make when preparing
an Edge Server.
Domain Membership
There are pros and cons to joining an Edge Server to
an internal Active Directory domain. From a security perspective, it is
undesirable because an Edge Server behaves identically whether it is
joined to a domain or not. By not joining the Edge Server to the domain,
the attack exposure is limited and there is no way a compromised Edge
Server has any Active Directory information.
From a management perspective, though, having an Edge
Server or multiple Edge Servers in a workgroup configuration creates
some additional issues, such as security policy enforcement and
patching. Administrators must manually account for patching these
servers, changing local security policies instead of using Group Policy
and Windows Server Update Services (WSUS). By not being part of the
domain, these servers can potentially be left unpatched with security
vulnerabilities.
There are workarounds to these issues, such as using
registry keys to point servers at an internal WSUS server or allowing
Edge Servers to automatically update patches. However, organizations
might block the ports required for WSUS to a perimeter network or not
want servers to apply patches without being tested first.
Tip
Generally, it is recommended to not join an Edge
Server to the domain. However, if that creates more of a problem for
managing the servers, it is acceptable to join the servers to the
domain. Alternatively, if an organization has deployed a separate forest
within the perimeter network specifically for management purposes, an
Edge Server can be joined to that domain instead of the internal domain.
If the Edge Server is part of a workgroup
configuration, be sure to define a primary DNS suffix for the machine
and use that fully qualified domain name in the Topology Builder and for
any certificates using the internal server name.
Note
If the Edge Server is a workgroup member, it most
likely is not able to register its own name to the internal DNS servers.
Be sure to manually create the Edge Server host records so that
internal servers can resolve the names.
Network Adapter Configuration
Setting
up IP addresses, DNS servers, and gateways on the Edge Server adapters
can be a point of confusion in a deployment because of the requirement
for dual network adapters. To begin with, an Edge Server must have a
minimum of two separate network adapters: one that is internal facing
and one that is external or public facing. The internal adapter should
have a single IP address and the external adapter should have three
separate IP address associated—one for each Edge service.
Organizations can also choose to use a separate
network adapter for each public-facing IP address, which requires four
network adapters. Both are valid choices and these two configurations
are detailed in Figures 1 and 2.
Note
In most cases, two adapters are sufficient unless an organization requires separation of the traffic.
Keep in mind that saturating a gigabit NIC exceeds
the recommended capacity planning and that using two adapters simplifies
the Edge Server configuration. If using a dedicated adapter for each
external IP address. Also,
it always helps to name the network connections descriptively instead of
leaving the “Local Area Connection <Connection Number>” name on
the adapter. Naming the interfaces “Internal” and “External” makes a
clear distinction about what function each adapter serves.
Tip
Using the first entered or primary IP address for the
network adapter as the Access Edge service IP address helps ensure
reliable routing.
Default Gateways and Routing
Another point of confusion when configuring the network adapters is where to place the default gateway.
Tip
A rule of thumb to follow is that a server can have
only one default gateway. This means that no matter how many network
adapters a server has, only one of those should have a default gateway.
Many administrators try to place gateways on both
network adapters, which causes extremely unreliable traffic flows. It
does not matter if the adapters are all on the same or different
subnets; only one adapter should have a default gateway assigned.
The next decision is where to place the default
gateway. For an Edge Server, always place the default gateway on the
network adapter associated with the Access Edge Server IP address. This
applies whether a single external adapter is used for all three roles or
whether multiple adapters are used. This ensures that all requests the
server does not know how to route are passed out through the Access Edge
IP address.
A question that inevitably comes up is, “How does an
Edge Server communicate with the internal network through an adapter
that has no default gateway defined?” The answer to that question is,
“With static routes.” The gateway associated with the internal adapter’s
IP address is still used, but it won’t be the default
gateway. Routing is something generally associated with network
devices, but in the case of a multi-homed server, an administrator must
configure the routing table to act appropriately. For a Lync Server Edge
role, the administrator must manually enter route statements to use
that internal adapter for internal subnets. Figure 3
shows how the external adapter has a default gateway associated, but
routing statements for internal networks make use of the internal
adapter.
Note
Remember that any internal client or server must be
able to route directly to the internal network adapter of the Edge
Server. To be able to respond to the request, the Edge Server must have a
route statement for that subnet telling it to use the internal-facing
network adapter. If not, the request is routed out the interface
associated with the default gateway and either not routed or dropped by
the server.
Adding Static Routes
Static routes can be added via a command prompt either through the older route command or with the newer netsh command set.
First, identify the internal-facing network adapter’s
name. If it was named descriptively, such as “Internal,” this
information is already known. Open a command prompt with elevated
administrative privileges and type each route statement with the
following syntax:
netsh interface ipv4 add route <IP address /mask> <Interface Name> <Gateway>
As an example, assume there are three internal
subnets—10.0.1.x, 10.0.2.x, and 10.0.3.x—that are all /24 subnets where
servers and clients exist. The internal-facing adapter of the Edge
Server is named Internal, the adapter’s IP address is 172.16.0.20, and
the gateway for that subnet is 172.16.0.1.
The following commands should be entered on the Edge
Server to tell the server to use the internal-facing adapter and gateway
to reach those subnets:
netsh interface ipv4 add route 10.0.1.0 /24 "Internal" 172.16.0.1
netsh interface ipv4 add route 10.0.2.0 /24 "Internal" 172.16.0.1
netsh interface ipv4 add route 10.0.3.0 /24 "Internal" 172.16.0.1
Alternatively, if an organization uses all 10.x.x.x
IP addressing for internal subnets, those statements can be reduced to a
single line that accounts for all three subnets listed and possibly any
new subnets added later.
The following example uses a /8 bitmask to route any traffic destined for a 10.x.x.x address through the internal adapter:
netsh interface ipv4 add route 10.0.0.0 /8 "Internal" 172.16.0.1
To recap the procedure, first identify the internal
subnets where clients and servers are located. Next, try to summarize
those subnets to minimize the amount of route statements required.
Finally, enter the route statements on the Edge Server.
Note
In
some cases, the internal- and external-facing adapters are on the same
subnet in a perimeter network and might even still have to route through
the same gateway IP address. It is still necessary to assign only the
default gateway to the external-facing adapter and then define the route
statements for the internal adapter. Even though the same gateway might
be used, the route statement ensures the traffic originates from the
correct adapter and IP address on the Edge Server.
DNS and Network Adapter Binding Order
Being able to resolve DNS queries correctly is
absolutely critical to making an Edge Server functional. At a minimum,
an Edge Server must be able to resolve the names of internal pools and
servers, so be sure to enter an internal DNS server IP address on the
internal adapter’s network configuration.
It’s also important that an Edge Server resolve
external DNS queries for federation or public IM scenarios. These
queries can be answered by internal DNS servers, or an Edge Server can
use a public DNS server to resolve queries if entered on the network
adapter configuration. In a single Edge Server deployment where the A/V
Edge is behind NAT, the service must be able to resolve its own publicly
addressable name and IP address.
The binding order of the network adapters is not
critical to an Edge Server operation, but can have an effect on how an
Edge Server resolves DNS queries. Servers use the DNS servers entered on
an adapter starting with the adapter listed first in the binding order.
The impact is if a split-DNS namespace is in place
where internal and external queries can return the same name with
different IP addresses, the Edge Server might resolve names incorrectly.
For example, if the external adapter is listed first in the binding
order, the Edge Server might be unable to resolve the name of an
internal pool correctly because that name is not registered in the
public DNS.
Tip
To avoid this issue, enter the IP addresses of the
internal DNS servers on the internal adapter, and then place the
internal adapter highest in the binding order. If internal DNS lookups
are not allowed, a host file can be used.
If this configuration still does not make DNS lookups
succeed and resolve correctly, it might be necessary to use a host file
for resolving internal names. Usually only a few internal pool and
server names need to be entered, so it is fairly quick to configure, but
be aware, this option exists when troubleshooting name resolution
issues.
Note
Disable
all unused network adapters and move them lowest in the binding order
priority list. This ensures active adapters are always accessed first.
Plus, if a cable is ever plugged in to a disabled adapter, it can’t
affect the server without being enabled by an administrator.
Strong Host Model
A possible Edge Server option discussed earlier uses a dedicated network adapter for each external Edge service.
Note
Just like with a two-adapter configuration, name the
different network interfaces descriptively, such as “Access Edge,” “Web
Conferencing Edge,” and “AV Edge.”
Something to be aware of with this option is that
both Windows Server 2008 and Server 2008 R2 utilize the strong host
model for the network adapters, which means that traffic sent outbound
from a source IP address must always be sent from the network adapter
associated with that IP address. Now that might seem like common sense,
but Windows Server 2003 and earlier allowed outbound traffic to be sent
from any network adapter regardless of which adapter had the source IP
address assigned.
To provide the relation to Lync Server, this meant
that when the Web Conferencing Edge or A/V Edge service needed to
respond to a request, it used the Access Edge service adapter and
default gateway to respond. This doesn’t happen by default in Windows
Server 2008 or Windows Server 2008 R2 where each adapter must use its
own gateway or route configuration. Figure 4
shows the weak host model where outbound Web Conferencing and A/V
traffic was able to be initiated through the Access Edge adapter.
With the Strong Host Model, the Web Conferencing Edge
and A/V Edge adapters need a static route to respond to unknown
networks such as Internet clients. Figure 5 shows how the outbound Web Conferencing and A/V traffic now is initiated from the dedicated adapter.
The impact of this change to an Edge Server
deployment is that if the Access Edge interface has the default gateway
assigned, the Web Conferencing Edge and A/V Edge technically don’t know
of a default gateway because there is not one associated with their
interfaces. This ends up causing Web Conferencing Edge and A/V Edge
traffic to fail because the server cannot respond to external clients
without knowing where to send that traffic.
Tip
The best solution for these types of deployments is
to add static routes for both the Web Conferencing Edge and A/V Edge
interfaces to the external gateway. These routes are identical to a
default route with the exception that they are a higher metric or
priority than the default route associated with the Access Edge service.
To do this, first check the metric of the Access Edge
default gateway. The metric for the other two services should be higher
or less preferred, so all federation and Public IM Connectivity traffic
continues to flow out the Access Edge interface.
Open a command prompt with elevated administrative privileges and type each route statement with the following syntax:
netsh interface ipv4 show route
Find the default route and metric in the routing
table. It is the route with prefix 0.0.0.0 and should point at the
Access Edge adapter’s default gateway already.
Publish Type Met Prefix Idx Gateway/Interface
No Manual 256 0.0.0.0/0 12 192.168.1.1
Now add a route statement for the Web Conferencing Edge and A/V Edge with metrics both higher than the Access Edge.
netsh interface ipv4 add route 0.0.0.0/0 "Web Conferencing Edge" 192.168.1.1 metric=258
netsh interface ipv4 add route 0.0.0.0/0 "AV Edge" 192.168.1.1metric=260
When viewing the routing table again, all three routes should be visible. The index value differentiates the interfaces.
Publish Type Met Prefix Idx Gateway/Interface
No Manual 256 0.0.0.0/0 12 192.168.1.1
No Manual 258 0.0.0.0/0 14 192.168.1.1
No Manual 260 0.0.0.0/0 16 192.168.1.1
This issue doesn’t exist when a single adapter is
used for external services because all three IP addresses are associated
with the same physical adapter that already has the default gateway. As
you can see, using two adapters is a significantly simpler
configuration. With gigabit speed network adapters, the need for
separating the adapters for bandwidth purposes diminishes, and a better
solution for the extra adapters is to team the interfaces for failover
redundancy only and not throughput.
