This is post 10 of the twelve post series, to see an index of all twelve posts, click here.
On the 10th day of Lync’mas my UC Team gave to me: 10 Lync Internal Server Roles!
On the surface (No PUN intended), Lync 2013 is, or at least was upon release, widely perceived to not be much of a change over Lync Server 2010 and was more of a simple refresh. “Ho Ho Hoooo-boy!”…This simply couldn’t be further from the truth once you dive into each of the different roles of Lync Server 2013. Rather than use this blog post to deep dive into those roles, I will highlight all the servers and the roles associated with Lync Server 2013, in contrast to Lync Server 2010. Don’t forget that these roles do not necessarily require their own separate servers, as they can be co-located.
The core of any Lync Server 2013 deployment continues to be Enterprise Edition Pool “EE” servers, or a single Standard Edition “SE” server. With Lync Server 2010 and Lync Server 2013 there were multiple servers and roles associated with a deployment. These servers/roles include:
Mediation Server (Used for Signaling and Media translation):
Lync Server 2010: Deployed as a collocated role on EE and SE or deployed as a stand-alone server or a pool of servers Lync Server 2013: No Change
Director Server (Used for authenticating user requests):
Lync Server 2010: Deployed as a stand-alone server or pool of servers. Could not be collocated Lync Server 2013: No Change but officially noted as an “Optional” server
A/V Conferencing Server (Used for on-premise A/V conferencing):
Lync Server 2010: Deployed as a collocated role on EE or SE or deployed as a stand-alone server or pool of servers Lync Server 2013: Can only be collocated to “EE” or “SE” as a role
Monitoring Server (Used for CDR and QoE reports)
Lync Server 2010: Deployed as a stand-alone server. Could be collocated with Archiving Server Lync Server 2013: Can only be collocated to “EE” or “SE” as a role
Archiving Server (Used for archiving IMs for compliance)
Lync Server 2010: Deployed as a stand-alone server. Could be collocated with Monitoring Server. SQL Database only for archived data Lync Server 2013: Can only be collocated to “EE” or “SE” as a role. Optional archiving stores can be either Exchange 2013 or SQL Database
Persistent Chat formerly Group Chat (Used for multi-party persistent rolling chat rooms)
Lync Server 2010: Group Chat was its own environment which integrated to Lync Server Lync Server 2013: Now called Persistent Chat - Can be collocated with “SE” but must be deployed as a separate server when deploying “EE”
Office Web Apps Server – Non Lync Server (Used for rendering PowerPoint)
Lync Server 2010: N/A Lync Server 2013: Used as the engine for delivering PowerPoint presentations in conferences using DHTML
Exchange Server Unified Messaging – Non Lync Server (Used as Voicemail Solution)
Lync Server 2010: Seamless integration to Exchange 2010 UM and Exchange 2007 UM Lync Server 2013: Seamless integration, however, Exchange 2013 UM is re-architected as a series of components spread across the CAS and MB servers
Standard Edition Server
- Workload
- All roles, minus the Director, are still collocated on a single server using the Standard Edition “SE”. No change there!
- Persistent Chat, as stated above, is now a co-located role. This is great news. Previously with Lync Server 2010 and OCS 2007 R2, Group Chat really sat in its own separate environment and felt like somewhat of a “bolt-on”. With this role now delivered seamlessly within Lync Server 2013 we believe it will become a much more widely adopted collaboration solution in the marketplace.
- Monitoring and Archiving roles are still very much collocated roles with SE as well. Don’t forget: although these roles are collocated, they still require their own SQL Database on a full version of SQL Server. If this makes you sad, don’t worry Lync 2013 has a surprise for you: the Archiving role can now utilize integrated storage with Exchange 2013 for a single repository of all messaging archives – e-mail and IM in one spot. To learn more about this feature at a deeper level, please reference the Lync Server and Exchange Server integration Technet page. This change may seem subtle in nature, but is actually a much needed archiving improvement for the Lync Server family.
- Capacity
- When we are asked “How many users can a Lync Server SE handle?” the Lync community is famous for our first response; “Well, it depends”. Because Lync can be deployed in a million different ways, there isn’t a single answer to that question. Assuming your organization is looking to deploy Lync Server 2013 in all its UC glory as you should, the supported number and good rule of thumb is 5000 users. This of course is not a concrete number until we determine how you plan to deploy and utilize the server, workloads, virtualization, etc. This where we recommend a very important design session to nail down these requirements.
- HA/DR
- A single Standard Edition server does not provide HA, but Lync 2013 can deliver more robust DR.
- Please refer to Matt McGillen’s Day 2: Lync Paired Front End Pools from the Lync’mas series to understand how wonderful Microsoft has developed these capabilities.
- Is the SE right for you?
- “Well, it depends”. Ha ha. I can speak only for Perficient here, but we absolutely believe in the improvements of the Standard Edition Server. Prior to Lync Server 2013, the Standard Edition had a very niche play in your environment because of the lack of redundancy. Even with a user count under the supported maximums, we would have a hard time recommending the SE. We believed the importance of uptime in your environment should trump the small server foot print. With the DR improvements of Lync Server 2013, we expect to see more use cases taking advantage of the small footprint.
Enterprise Edition Pool (3 Servers recommended in a pool…expect to hear this during designs)
- Workload
- My, oh my how this has changed. First off, please reference Day 6 of the Lync’mas series to get a quick snippet of Lync Server 2013 hardware requirements needed for the Front End Servers. Those requirements make sense after understanding the workload now on the “EE” pool.
- Front End “EE” Servers databases are now the primary store for user and conference data, including the very intensive database writes required by IM and Presence updates. While this was offloaded to SQL backend with Lync Server 2010, SQL Server on the Back End now plays sort of a “back-up” server to the SQL data now stored on the Front Ends.
- If you have deployed Lync Server 2010 for an on-premises replacement for your expensive hosted conference bridges, you probably quickly learned that breaking out the A/V role to its own server pool was highly recommended to support the heavy traffic loads. That was recommended to keep the existing “EE” Front Ends from suffering. With this traffic now collocated, the “EE” servers have more demanding hardware requirements to accept this heavy lifting.
- Although Monitoring can be lighter in nature, it nonetheless is an added workload that is now collocated (it never was before), which adds to the workload of the “EE” Servers.
- As mentioned above, Archiving is now collocated as well which adds to workload that didn’t exist in Lync Server 2010.
- Although Persistent Chat has to be deployed on its own server if you are using “EE” Servers, the “EE” Servers still provide some functionality for the Persistent Chat servers such as Persistent Chat Web Services for Chat Room Management and Persistent Chat Web Services for File Upload/Download.
- Capacity
- A lot. A pool of “EE” Servers can scale out to 12 servers and home a total of 80,000 users spread systematically across these servers. This is assuming all users are enabled for everything UC. If not all roles are enabled for all users, the numbers once again can vary.
- HA/DR
- It’s very much improved, mostly due to the above-mentioned “decoupling” of the Front Ends from the SQL Back End.
- Once again please refer to Matt McGillen’s Day 2: Lync Paired Front End Pools from the Lync’mas series to understand how this model has changed for DR, and Scott Middlebrooks’ Day 3 post on SQL Mirroring for local redundancy.
- Is Enterprise Edition right for you?
- Although the server requirements seem a bit stiff with a recommended 3-server pool and mirrored SQL Back End, we still believe it is very much warranted. Lync Server 2010 pilots (or POCs) often ran with a single “EE” simply because it was a good starting point but would let the environment eventually scale. However, with Lync Server 2013, we are recommending an immediately-scaled approach right out of the gates with almost 6 times the requirements of Lync Server 2010. To really leverage that investment, it’s worth evaluating your UC strategy to make a strong push toward Lync immediately and bypass the lingering “pilot” stage. With the improvements over Lync Server 2010, especially in regards to HA and DR and the rapid maturation of Lync Server as a UC solution, we believe it is absolutely right for you.
Conclusion
What I outlined in this post was strictly Lync Server internal server roles, with the exception of the Web Apps Server and the Exchange UM role. There are additional components and servers that must be considered when rolling out the full UC stack, this includes the perimeter network Edge servers, TMG/reverse proxy, SQL Databases and possibly media gateways to name a few. For a visual aid view the Reference Topology for Medium Organizations.
Staying true to the form of the 12 days of Lync’mas, you’ll quickly see there is a total of 10 Servers associated with this reference. I hope this helps shed some light on the changes in Lync Server 2013!
Happy Holidays!
