Script

[This is pre-release documentation and subject to change in future releases. This topic's current status is: Milestone-Ready]

Topic Last Modified: 2010-07-16

To enhance Edge Server performance and security, as well as to facilitate deployment, apply the following best practices when you deploy your perimeter network and Edge Servers:

• Deploy Edge Servers only after you have tested and verified operation of Microsoft Communications Server 2010 inside your organization.
  
  
• Deploy Edge Servers in a workgroup rather than an internal domain. Doing so simplifies installation and keeps Active Directory Domain Services (AD DS) out of the perimeter network. Locating AD DS in the perimeter network can present a significant security risk.
  
  Although you can deploy Edge Servers in a workgroup or a domain, we strongly recommend that you not deploy Edge Servers in your internal domain. You may want to deploy them in a perimeter domain for maintenance purposes.
  
  
• Deploy your Edge Servers in a staging or lab environment before you deploy them in your production environment. Deploy them in your perimeter network only when you are satisfied that the test deployment meets your requirements and that it can be incorporated successfully in a production environment.
  
  
• Disable all services that are not essential to the Edge Server.
  
  Run only programs that embody routing logic and that are written in Microsoft SIP Processing Language (MSPL) with the Communications Server API.
  
  
• Enable monitoring and security auditing on the computer as early as possible.
  
  
• Use a computer that has two network adapters to provide physical separation of the internal and external network interfaces. The internal and external adapters should be on two different subnets.
  
  
• Deploy the Edge Server between an internal firewall and an external firewall in order to ensure strict routing from network edge to the other, as well as to protect your internal deployment behind two levels of firewall.
  
  
• Deploy Directors in the internal network to relieve Enterprise pool servers from the overhead of performing authentication of external users and SIP redirection to the home pool of the user (if multiple pools are in use), as well as to help insulate home servers and Enterprise pools from malicious traffic such as denial-of-service attacks; if the network is flooded with invalid external traffic in such an attack, this traffic ends at the Director, which minimizes any performance impact on internal users.