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” 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)
- 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
Reverse Proxy
Office Web Apps
- 64-bit single processor, quad-core, 2.26 gigahertz (GHz) or higher
- 12 gigabytes (GB)
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 :
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
Carsten Siemens edited Revision 10. Comment: Added tags: en-US, has comment
SMS Bradley edited Revision 1. Comment: edits
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)
@Juan I have modified the point #17 so that fault tollerance, high availability AND live motion features are all in the wish list :-)
@Luke and @Juan
I agree with your point on the hardware, and it is obviously oversized.
I am looking forward for the Lync 2013 planning tool to be available, because the TechNet articles are sized for an environment much larger than the one I am planning.
However we are talking about a virtualized environment, so RAM and CPU overallocation is not a big issue.
For sure everyone will downsize the requirements to meet his/her real world scenario.
300 Gb for the Lync Edge is a lot of space (also if we are going to keep a lot of logs and diagnostic informations) but disk space is very cheap at the moment.
Another advantage of using virtualization is that the virtual disk could be a dynamic one ;-)
One think to consider on the cost side, with the virtualization scenario, is the fact that there is no Windows 2012 "enterprise" license, so you need a lot of standard editions or a relly costly datacenter version to have the same virtualization rights you had buying few Windows 2008 R2 Enterprise editions.
Ensure the AD domain name is verifiable, otherwise you will have trouble obtaining a third party certificate. If you use a non-publicly routable namespace for the internal domain, you may have trouble obtaining a third party certificate due to recent changes with the CAB (see this article for more details: blog.insidelync.com/.../upcoming-restrictions-on-public-certificates). You could include a stand-alone CA in the environment to issue internal certificates, or add another DC and include an Enterprise CA.
@Jason : that is a good point. I have added a note on the SSL/TLS paragraph to include your observations and the blog post you have pointed out.
Pardon my ignorance, but would you care to explain:
14. The reverse proxy will be an IIS or Apache solution, no need for a something complex like TMG or UAG here
How would IIS or Apache replace TMG or some other reverse proxy solution?