During the past week, I was required to prepare a proposal for a Lync deployment in a medium-sized enterprise.

The final document is substantially different from this draft, but I want to share the logic I use during the first steps of a similar work and to hear what other people do and think in a similar scenario. Thus, this post is titled “Getting started with proposing a deployment for a small Lync implementation.”

Scenario

Required services

IM, Video call and conference call

There is a legacy telephone exchange but enterprise voice is not required at the moment.

Users

Around 50 users in the central site and a series of branch offices with less than 20 users

Available connection

There is no direct connection between the central site and the branch office.

Central site has a really good Internet connection (fixed public IPs are available).

Branch offices have an Internet connection too

Existing domain infrastructure

Linux with LDAP authentication for the clients

Existing hardware and network infrastructure

The deployment includes the purchase of new hardware (to install one or more hosts to work as hypervisors)

Lync and the related services will be installed on a brand new VLAN isolated with a firewall from the existing one

Design Logic

1. The costs have to be as low as possible

2. All the servers in the deployment will be virtual machines. There is no good reason to use physical server for this design.

3. An Active Directory infrastructure is required for Lync. Starting from scratch it could be a good idea to use Windows 2012 as AD DS.

4. Usually a domain with a single D.C. is too risky, however given the scenario, a second D.C. would be welcomed but is not mandatory

5. DNS service for the domain will be collocated on the D.C. servers. An external maintainer will be required for the public records of Lync

6. The public name server must be able to manage A, CN and SRV records

7. The deployment will be based on split brain DNS, so that the internal DNS will resolve public names on internal IPs

8. No high availability solution is required for Lync (especially because there is no enterprise voice deployment)

9. The Lync deployment will be made with Lync 2013

10. A single Standard Edition will be enough for the Front End deployment

11. Lync will be used only from “external users” because there is no client in the Active directory domain where Lync will be hosted

12. An edge server is required (see point 11)

13. A reverse proxy solution will be used for the “web services” of the Front End server

14. The reverse proxy will be an IIS or Apache solution, no need for a something complex like TMG or UAG here

15. A server dedicated to Office Web Apps is required for PowerPoint presentations in Lync Online Meetings

16. Lync mobility is not in the list of the required features. This is something to verify, my design will include access from mobile devices given the scenario

17. A solution with at least two virtualization hosts and high availability, fault tollerance and VMotion (or Live Migration) features would grant protection from hardware failures. Again it is a matter of costs if this kind of continuity will be available or not

18. A backup and snapshot mechanism is required to recover from system failure and human error. The selected method depends on the hypervisor that will be used

High Level Overview Of The Proposal

Sizing the hardware for Lync 2013

At the moment there is no “Lync planning tool” for Lync 2013.

We can start from a couple of TechNet articles “Running Lync Server on Virtual Servers” http://technet.microsoft.com/en-us/library/gg399035.aspx and “Server Hardware Platforms” http://technet.microsoft.com/en-us/library/gg398835.aspx

Lync Server Standard Edition (Front End)

- 64-bit dual processor, hex-core, 2.26 gigahertz (GHz) or higher

- 32 gigabytes (GB)

- Disk: a 100 Gb vdisk for the operating system, a 300 Gb vdisk for Lync deployment 1 Gbps network adapter

- 1 Gbps network adapter

Lync Server Standard Edition (Edge)

- 64-bit dual processor, hex-core, 2.26 gigahertz (GHz) or higher

- 32 gigabytes (GB)

- Disk: a 100 Gb vdisk for the operating system, a 300 Gb vdisk for Lync deployment 1 Gbps network adapter

- 2 x 1 Gbps network adapter

Domain controller

- 64-bit single processor, hex-core, 2.26 gigahertz (GHz) or higher

- 8 gigabytes (GB)

- Disk: a 100 Gb vdisk for the operating system

- 1 Gbps network adapter

Reverse Proxy

- 64-bit single processor, hex-core, 2.26 gigahertz (GHz) or higher

- 8 gigabytes (GB)

- Disk: a 100 Gb vdisk for the operating system

- 1 Gbps network adapter

Office Web Apps

- 64-bit single processor, quad-core, 2.26 gigahertz (GHz) or higher

- 12 gigabytes (GB)

- Disk: a 100 Gb vdisk for the operating system

- 1 Gbps network adapter

SSL / TLS certificates requirements

A SAN certificate is required (wildcards are a good choice only for web / reverse proxy services).

For the deployment eight alternative names (in addition to the base name of the certificate) will be requires, in a certificate released from a public Certification Authority

- 1 for web services (see option 2 “Understanding Simple URLs In Lync “ http://social.technet.microsoft.com/wiki/contents/articles/15396.understanding-simple-urls-in-lync.aspx

- 3 for edge services

- 1 for the Front End server

- 1 for the edge server

- 1 for the reverse proxy

Note : third party certificates including internal domains that are not published to the Internet, are no longer available (see the blog post on Inside Lync http://blog.insidelync.com/2012/12/upcoming-restrictions-on-public-certificates/ ).

Available options are :

1. deploy and internal C.A. (stand-alone or enterprise) and have two different kind certificates on our deployment (the certificate released from the internal C.A. and the other one released from the public C.A.) assigned to the appropriate interfaces
2. deploy only the certificate released from the public C.A.  and use a split brain configuration on our internal DNS so that the FQDNs of the public domain are resolved to the internal IPs

Public IPs

Four public ip addresses (static) will be required for the deployment, three for the edge services and one for the web services.

Although it is possible to deploy edge services with a single public address, an high number of external users behind a firewall will have a lot of complications because the aforementioned solution requires to open “non standard” ports from the client