The internally-facing segment contains a dedicated internal private Class A IPv4 addressing scheme that is routed without the use of any Network Address Translation (NAT) to all of the internal servers. The network configuration used for this environment leverage the best practice model of two separate perimeter networks on different IP address subnetworks. In fact these two new servers are not joined to any domain and are simply in the default Workgroup mode. The key difference is that these two servers are located in a Perimeter Network or Demilitarized Zone (DMZ) and thus are not joined to the same Active Directory domain that the rest of the internally-located server roles are.
Two virtual servers will be used for this deployment and have already been installed with Windows Server 2012 R2 and prepared using the same methods as the other servers in the environment. A future article will cover this topic in some capacity. To support the myriad of newer clients and platforms the Lyncdiscover service will need to be published using a reverse proxy model of some sort. This role will be addressed after the completion of Edge server deployment, but leveraging some of the legacy behavior that is still supported in even the latest Skype for Business clients will allow for at a minimum of external connectivity from Windows Desktop clients and many IP desk phones. But if desired, it is officially supported (albeit a bit unorthodox) to mix a resilient Edge Pool with a single Standard Edition Front End Server.Ī Reverse Proxy solution is also not covered yet. The Edge Server article mentioned above is meant for environments built specifically to those articles, while this article basically assumes that there is already at least one Skype for Business Enterprise Edition Front End Pool deployed in the environment. Note that following those articles verbatim only covers the deployment of a single Standard Edition Front End Server, which actually is sufficient to perform this deployment.
This means successfully completing the configuration detailed in at least these three articles: Part 1, Part 2, and Part 3. BackgroundĪ functional Front End server deployment is required before one or more Edge servers can be deployed into the environment. Nearly all of the guidance in this article related to network configuration and server preparation holds true for either scenario. Basically this article is the production deployment reference guide and the other is the lab quick reference guide. This article covers in-depth best practices and explanations of each step along the way to deploying a pair of servers in an Edge Pool leveraging a more realistic scenario using public IP addresses and third-party certificates. The Server deployment article linked above only covers the unique, individual steps to quickly deploy an Edge Server in a lab with private certificates. The driving force for selecting that topology was primarily that the much-improved official documentation from Microsoft already covered the deployment of an Enterprise Edition Front End server pool.įor those following along with these deployment articles to create a lab environment then a simpler companion article entitled Skype for Business 2015 Edge Server Deployment is also available which quickly addresses adding a single Edge Server to this example environment.īut for this article a different, much more verbose approach has been taken. These articles have all focused on a simple Skype for Business topology starting with a single Standard Edition server deployment. This server role, from a deployment and architecture standpoint, is basically unchanged from previous Lync Server product releases.
Moving on with this series of deployment articles the next major component of the core Skype for Business (SfB) infrastructure to address is the Edge Server role.