• The first step is to bring up the new Edge and reverse proxy servers that you want to use in the new load balanced environment. Until you change Domain Name System (DNS) entries, all users continue to use the existing non-load balanced servers. This allows you to test the new servers individually by using a few host file changes, ensuring minimal downtime and service-level agreement (SLA) risk. Because Edge servers are assigned at a pool level you need a test pool availability to validate the new Edge environment. (This could be a Standard Edition server because you are only using it for testing purposes.)
  
  
• After you have validated the individual Edge servers, the next step is to configure the load balancer VIPs in front of these new servers. Again, the corporate and public DNS records have not been touched, so end users are still using the existing Edge infrastructure. With some additional host file record changes, you can now test the load balanced environment and validate behavior associated with testing failover on each of the Edge servers.
  
  
• After you have validated the load balancing behavior, you can cut over to this new environment by removing the host file entries and changing the correct DNS entries in your production environment. The benefit of this methodology is that you can fully validate the load balanced environment before it goes live and have the option of quickly reverting to the non-load balanced servers in case something goes awry after the cut over. When the new configuration is operating smoothly, you can decommission the non-load balanced servers. The rest of this section describes each phase of this process in detail.
  
  

One thing you need to consider is whether it is absolutely necessary to load balance the reverse proxy. This depends on the types of services being exposed by the reverse proxy. For instance, if the reverse proxy is only exposing the Office Communications Server web components, a temporary outage would impact the download of address book, DL expansion, and meeting content. Your end users may not notice a temporary outage of these services. However, if the reverse proxy is exposing Communicator Web Access and Exchange services, high availability is probably more critical. Evaluate your company’s needs and decide accordingly.