The address range assigned to MDM Gateway Server can be a public range of addresses, or a range of addresses from the RFC1918 ranges. The address range must be able to pass through the internal firewall and must be routable on the company network. To enable addresses to have the desired access and to be suitably routable, you must configure the internal firewall to allow for managed device traffic to carry over the IP ports as described in the tables of ports listed in MDM Deployment Worksheets.

In addition, you must enable the managed device range to route as needed within a company network to make sure that the managed device session can establish with the target LOB hosts.

Active Directory® Domain Services–integrated Domain Name System (DNS) is the recommended DNS. The DNS to which devices resolve must be able to forward queries and lookups. This requirement is because hosts external to the enterprise, such as Web sites on the Internet, have to be resolved in addition to the DNS that resolves addresses of internal hosts.

Each MDM Gateway Server must have two sets of DNS names: one is the Internet-facing name and the other faces the intranet. The Internet name is published in your publicly-facing DNS servers. All servers running MDM Gateway Server should share a single public DNS name, to enable load-balancing based on that DNS name.

When you use multiple MDM Gateway Servers for redundancy or load balancing, you must associate the external interface for each MDM Gateway Server to the same DNS name. DNS servers associate the IP address of each external interface to the DNS name that is provisioned as MDM Gateway Server in the devices.

The intranet-facing DNS name is published in the internal DNS server that the Device Management server accesses. Every MDM Gateway Server must have a unique internal DNS name and that name must match the subject name of its machine certificate.

As a best practice, you should direct managed devices at a secure internal DNS that you cannot ordinarily access from outside the enterprise. You should never directly resolve to resources that are located within the company enterprise by an untrusted external client.

In order for users to enroll their devices over the air (OTA), you must publish public DNS <A> records. Public DNS <A> records allow enrollment to work correctly through the Web proxy server for Windows Mobile devices so that devices can connect to MDM.

Note:
You should not modify the memberships for any groups manually unless instructed to so, for example, to troubleshoot a problem. If you modify memberships manually, it can interfere with regular system operation.

You must follow these network configuration requirements for MDM Gateway Server:

• Placing MDM Gateway Server behind an NAT is not a supported scenario for MDM. Doing so essentially masks the identity of MDM Gateway Server, which prevents MDM from working properly.
  
  
• Every computer that is running MDM Gateway Server must not have a private IP address but should have a public IP address on its external interface.
  
  
• Every computer that is running MDM Gateway Server must have a discrete, nonoverlapping IP address pool.
  
  
• The IP address pool subnet cannot intersect with the internal subnet on MDM Gateway Server. Otherwise, network traffic from the company network to MDM Gateway Server will not be routable.
  
  
• The IP address pool subnet cannot intersect with the internal subnet on your internal company network. Otherwise, network traffic from the internal network to the managed devices will not be routable.
  
  
• Do not use teamed network adapters on computers that are running MDM Gateway Server.
  
  

When you issue a device management command, such as a Wipe request, MDM Device Management Server instructs MDM Gateway Server to send a specially formatted data packet to the managed device, instructing the device to request a Group Policy refresh immediately.

The MDM Alerter agent running on the managed device compares the endpoint IP address of the server running MDM Gateway Server to which it connects with the IP address that is embedded in the data packet. The IP address to which the device connects is the external IP address of the NAT. The IP address embedded in the message is the address bound to the external interface of the server running MDM Gateway Server that sent the data packet. Since the addresses do not match, the managed device ignores the packet and does not connect to MDM Device Management Server until the regularly scheduled refresh interval.

By using source-based routing, MDM Gateway Server can direct IPsec tunneled traffic from managed devices to a different, non-MDM gateway server.

The following shows the benefits of source-based routing:

• You can configure MDM Gateway Server with an Internet public IP Address on the external segment and maintain the ability to redirect tunneled traffic that is destined for the Internet through a content filter firewall.
  
  
• You can deploy MDM Gateway Server in the perimeter network without changing the perimeter network topology.
  
  
• MDM can support managed device Internet access for all kinds of network traffic and protocols.
  
  
• You can support Internet access for legacy applications that do not use connection manager proxy settings.
  
  
• You do not have to configure the proxy server separately.
  
  

To configure source-based routing for MDM Gateway Server, use the Add MDM Gateway Wizard from MDM Console. To edit the settings for source-based routing, from the MDM Console, choose the Propertiesmenu. For instructions about how to enable this feature, see Step 5g: Running the Add MDM Gateway Wizardin the MDM Deployment Guide.

After you install MDM Gateway Server, computers that are running MDM Gateway Server listen externally on the ports that are listed in MDM Deployment Worksheets. Unless otherwise hardened as described later in this section, the internal interface listens on all standard TCP/IP ports.

If you enable the Windows Firewall client on computers that are running MDM Gateway Server, you must configure ports as described in MDM Deployment Worksheetsfor successful operation of the MDM system.

You must use the following security configurations:

• A domain-joined MDM Gateway Server defeats the purpose of separation of duties and is an unsupported implementation.
  
  
• Microsoft VPN Gateway must be always running. This service should be set to start automatically at system boot.
  
  

We recommend the following best practices for security:

• You should make sure that MDM Gateway Server is part of the enterprise infrastructure and include it in all update-management processes to keep it up to date with security and operating system updates.
  
  
• You should deny the IP address of MDM Gateway Server permission to start sessions through the internal firewall. However, you should enable it to respond to sessions that MDM Console and MDM Device Management Server start. You should also configure the IP address of MDM Gateway Server to respond to sessions initiated by the software update, antivirus, and other management mechanisms in the enterprise. This additional precautionary step can hinder malicious attacks if the system is compromised.
  
  

Harden the server before you install it in a potentially hazardous environment, such as the perimeter network. You can harden the server by using the Security Configuration Wizard included with Windows Server® 2003 SP1 and in later versions.

MDM Gateway Server checks network packets to make sure that packets that come in on one network interface will route back through the same network interface. For security reasons, MDM Gateway Server will drop the packets if the two interfaces do not match.

To make sure that packets route correctly, follow these steps when you configure MDM Gateway Server:

• Do not have more than one network interface that faces the same subnet
  
  
• Do not have two default gateways of last resort that point to different network interfaces