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.”
IM, Video call and conference call
There is a legacy telephone exchange but enterprise voice is not required at the moment.
Around 50 users in the central site and a series of branch offices with less than 20 users
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
Linux with LDAP authentication for the clients
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
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
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”
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)
- 2 x 1 Gbps network adapter
- 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
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 “
- 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 :
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
Conference calling is listed as a requirement but you have not included an Office Web Application Server in the Topolofy to enable sharing of content within conference calls (ie PowerPoint sharing). If this is required an extra server will be required, external IP addresses and an extra SAN name on the certificate used on the reverse proxy.
Point #3, Exchange (unless it is 2013) does not currently work with AD DS 2012, if it is a green environment, 2013 would obviously work best with Lync 2013, but until SP3 comes out, if the client currently has Exchange 2010, it does not work with Exchange 2013, so I would recommend a Windows 2008 R2 based AD DS.
@Gavin : you are 100% right. Office Web Apps server is necessary for PowerPoint presentations in Lync Online Meetings. I will add this in the outline and in the post.
@Luke I agree, but in this scenario there is no Exchange deployment required. If they decide to use Exchange in the future, I suppose they will start with Exchange 2013 :-)
Not to nitpick, but for #16 VMotion/Live Migration doesn't help against server failures as both hosts need to be up to move the VM. For a small deployment, the RAM usage may be a bit much. The RAM guidance on Technet is for several thousand users in a pool. There will be 80GB needed just for these 5 VMs (88 if you give Office Web App 8GB). I don't think the edge needs 300GB HDD as there's no data stored on it, and without archiving or persistent chat I don't think the front end needs that much either. I've been thinking a lot about Lync deployments for smaller environments, as everything seems to be larger now. (Including the increase in licensing) I think the resource requirements are an area which there can be some flexiblity in order to reduce the sticker shock some.
I agree with Juan Rhodes. I have an office of around 80 people that I setup in 2012 Hyper-V with full Enterprise Voice, I configured the Lync 2013 servers using 6Gb RAM, 4 CPUs for the redundant FE servers.
Looking at monitoring, I have the following info: Total PSTN (SIP Trunk) voice minutes being 5630 minutes this month, as well as over 10,000 A/V conferencing minutes (64,820 Total PSTN participant minutes). The total conference failure rate was 0%, with only 1 failed audio call. (.37% failure rate)
That tells me even 4Gb RAM is way more than sufficient for IM/Conferencing. (I'm using 4Gb for the Edge servers)