Logo
HOW TO
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

Microsoft Lync Server 2010 : Planning for Deploying External Services - Edge Server Preparation

8/6/2013 9:19:11 AM
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.

Figure 1. Edge Server Dual Network Adapters

Figure 2. Edge Server Quad Network Adapters

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.

Figure 3. Edge Server Gateways and Routing

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.

Figure 4. Weak Host Model

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.

Figure 5. Strong Host Model

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.

Other -----------------
- Microsoft Lync Server 2010 : Planning for Voice Deployment - Devices, Response Groups
- Sharepoint 2013 : Expanding My Tasks settings
- Sharepoint 2013 : Using SkyDrive Pro, Using the timeline feature for tasks, Mentioning a colleague feature
- Sharepoint 2013 : Adding a thumbnail to a video
- Exchange Server 2007 : Using OWA Mail Features (part 3)
- Exchange Server 2007 : Using OWA Mail Features (part 2)
- Exchange Server 2007 : Using OWA Mail Features (part 1)
- Windows Server 2012 Group Policies and Policy Management : Policy Management Tools (part 2)
- Windows Server 2012 Group Policies and Policy Management : Policy Management Tools (part 1)
- Windows Server 2012 Group Policies and Policy Management : Group Policy Policies Node
 
 
REVIEW
- First look: Apple Watch

- 10 Amazing Tools You Should Be Using with Dropbox

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
 
VIDEO TUTORIAL
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
 
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Popular keywords
HOW TO Swimlane in Visio Visio sort key Pen and Touch Creating groups in Windows Server Raid in Windows Server Exchange 2010 maintenance Exchange server mail enabled groups Debugging Tools Collaborating
Top 10
- Microsoft Excel : How to Use the VLookUp Function
- Fix and Tweak Graphics and Video (part 3) : How to Fix : My Screen Is Sluggish - Adjust Hardware Acceleration
- Fix and Tweak Graphics and Video (part 2) : How to Fix : Text on My Screen Is Too Small
- Fix and Tweak Graphics and Video (part 1) : How to Fix : Adjust the Resolution
- Windows Phone 8 Apps : Camera (part 4) - Adjusting Video Settings, Using the Video Light
- Windows Phone 8 Apps : Camera (part 3) - Using the Front Camera, Activating Video Mode
- Windows Phone 8 Apps : Camera (part 2) - Controlling the Camera’s Flash, Changing the Camera’s Behavior with Lenses
- Windows Phone 8 Apps : Camera (part 1) - Adjusting Photo Settings
- MDT's Client Wizard : Package Properties
- MDT's Client Wizard : Driver Properties
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro