What you Should Not Do With Your VMware Lync Deployment

 

TO begin,  let me share an article that articulates what may of you have gone through to get to this point. Many of you started at lync 2010 and are now on Skype for Business. Are you using the same hardware? If so, your problems have come from the past to haunt you.

*Disclaimer: I use Lync and SFB and Skype for business, all to refer to the general term of Lync or Skype. I believe we are all moving to just Skype, but it would be nice if MS just rolled it all to just Skype! one word please!

Untitled

This article is written for a customer I have in a nearby nation, to the United States. He has a well used Lync 2013 Deployment. He has also had a lot of trouble. From having calls fail on Fridays, to having the Web sites fail on Wednesday, every week, for several weeks in a row.

I had some time to look at this case from a distance, after being very close to the situation for several weeks in a row. As a series of chance activities, this customer ended up going to the VMware department, instead of Lync. This was a very good route! As it turns out, The VMware agent caught the Virtual Machine with 4GB of ram!.

What a coincidence! I had caught the same customer changing his resources myself! That was all it took. All the pieces were clear.

I need to express in no uncertain terms, how vigilant you must be if you decide to Virtualize Lync or Skype for Business! While there may be some issues with Lync and Hyper-V, I am being honest, when I say that most of the virtual issues have been with VMware. Now I know I may take flack for that statement. I am a Microsoft Support Agent, so I do have a bias. I don’t make that statement to support my own brand. I am a Lync Professional and I am telling you my honest experience over 7 years with Lync and Skype for Business.

 

Untitled

 

With that said, let me break it down for you, as much as I can. Let me first bulletize what the supported Lync Server would look like on ESX:

Skype Server on ESX

  • 1. The VHDX needs to be fully expanded, and should not be an remote disk- ISCSI disk.
  • The Ram must not be dynamic, and must be a minimum of 24GB of ram. 32 or more is recommended.
  • The processors must not have NUMA complications, and Hyper threading should be disabled. The ESX should only be presenting physical processors on a machine where SFB is installed.
  • Networking is in flux. I think this is where some issues are still being resolved. Let me say that I recommend you use a dedicated physical nic to the VMware VM, which ever Nic type that is. VMXnet3 nics seem to have an issue, but please keep reading the documentation. Example and Example
  • The Balloon Driver needs to be disabled completely.
  • A Lync/SFB machine should not be moved, or migrated from host to host, even for maintenance.
  • Vms should be left alone to run, and cannot stand having resources change at all. This is a real time application, and cannot be live migrated like many machine types can.
  • Do not use snapshots on Vmware, as this will just cause an issue, if you ever tried to roll back. Just full back up, and restore if necessary.
  • Do not install Antivirus or threat protection on Lync systems.
  • Rely on the security provided by an Edge and reverse proxy server.

I suppose I could keep going. So there I said it! I don’t know if your getting the feeling that Lync should be on a physical machine? I have seen many VM lync deployments, and I wont go so far as to say that. I will say, If you choose SFB and you deploy to ESX, you must remain committed to the best practices. You cant even slip once. I guarantee you will see problem.

*******************************************

EDIT Due to Feedback from another Skype Fan

I was called out on the fact that I cannot maintain the Skype cannot be virtualized. In todays market, we must be able to function with any kind of Hypervisor. I do not disagree with that position. Believe me, I did not want to come off that way. So let me clarify, to say Virtualization is not the problem, so much as Resource control. I am not back tracking much. I am saying that your are not likely  going to be  free to just move a Lync server around, if you don’t want interruptions. The SDP protocol, is not built to be live migrated! My commenter below rightfully said that all three of the technologies I mentioned worked. I don’t disagree. The issue with real time voice, is in those parts of the day when things are busy, and you find you need to move resources around, or you have automation to move resources around. This not going to work with SKYPE! Skype needs dedicated resources, and you should not change them!

I hope it is clear what my intentions are!! I love VMware and I love Hyper-V. However, all of my problem environments are with VMWare. This is on Lync, not VMware! I can say simply that Skype is not very happy with resources that are changing dynamically. So now.. back to your article!

 

*******************************************************************

 

Untitled

So before you go looking for where I am incorrect in these statements, Please start with the requirements for todays SFB server. Requirements for SFB server, are not small. and then, I don’t mind if you jump into the fire. Here let me supply some oxygen for you! Below find ways to enter the battle:

I think that is enough to get you started. So no matter what you think about Lync, it all boils down to two things, Compute resources, and the network. If either of those is a fail, then your lync deployment is a fail. Microsoft puts it more eloquently:

Lync Server is designed to consume the full capabilities of a physical server and will perform poorly if the required compute resources are not available when needed. To help the virtualization of Lync Server 2013 to be successful for your organization, follow the guidelines provided in this white paper

Untitled

My friends, you came to this sight, perhaps to find out what not to do with your Lync Server. Look at the statement above. My experience is if you have been having issues for month’s, then there is a 69% chance your answer is in the blue text above. My chances of being right are much lower if you deploy your Lync server like the bullet points at the top of this article.

Fuel? Check. Oxygen? Check. Do you need a light?

 

Good evening all and I hope your VMS are tuned and your Free memory is abundant!

Louis

Advertisements

2 thoughts on “What you Should Not Do With Your VMware Lync Deployment

  1. rob says:

    you can’t just keep telling people to put their real-time communications on physical servers. it’s not a reasonable stance anymore.

    you can’t just keep telling people not to install anti-virus or threat tools on their skype servers. they will get their exception requests rejected by their security teams and then what… no skype?

    you can’t just say “no numa, no vmxnet3, 24GB is the bare minimum” when I’ve seen scenarios of all 3 operating properly.

    what you SHOULD do is tell people to proceed incrementally and cautiously. they should be pulling KHI throughout pilot tests and after each user migration. they should be re-running their server wizards after each resource change. they should be living in statsman throughout the coexistence period and continue spot checking it any time an incremental change is performed.

    do you need to have more knowledge about potential “gotchas” when virtualizing skype? yes. does that mean “just go physical, you don’t have to know as much about things” is a reasonable stance? not in my opinion.

    Like

    • So strictly speaking you are correct! I love what you wrote. Furthermore, I don’t Disagree with you! You may be surprised. The problem is in the planning, execution and scale of the product. I wrote this article to the 99% out there. There is a 1% group who could plan, execute and scale virtualized voice. however, the problem is that we leave, when we are finished. This leaves the Maintenance to the 99%. Unfortunately, that is where I live. My findings are that maintaining Skype under VMware is most of my virtualization support traffic. Not for reasons that you think.

      The main reason is that non Skype admins are flip flopping resources and I find out, down the line, that the customer had issues getting calls, because the VM had 4GB of ram. I can tell you that resource contention, and deprivation of resources is the main problem for VMware. I am not picking, but the difference in Hyper-v is the Ram is static. this does help Skype.

      I am sure that you (yourself) would provide for kind of difference. Maybe you set dynamic resource scheduling, etc… the problem is, that 99% doesn’t know what DRS is! So this article is more for that crowd.

      So to be honest, I see I have oversimplified. I agree. However, the precision required to run with Live Migration, and failover ability, with a real time protocol is just not perfect for virtualization. It is not that it wont work. Its that there is an exponential cost in getting your resources to that level of speed, to be able to handle it.

      What I am saying is another 99/100 ratio. 99 to every 100 customers has a virtual environment, where they skimped in at least one area. The other issue, which I didn’t discuss, is that you have to have the fasted hardware, across the board, to be able to make this a reality. This is the reason Azure is not supporting a Lync Deployment yet. It is close!! as SSDs get cheaper, along with 10 and 40GB nics, we are going to start seeing these voice deployments fly. for the 99%, just be patient. You may have a few issues right now. I can assure you, its not Lync’s fault! However, change is coming fast!

      I just used my azure VM today! That thing is faster then my Server virtual machines! Soon we will all be running Skype in the Cloud, and all this will be old hat. Accept, we will be running on Hyper-V! I swear I like VMware too! You can just tell what I am used to!

      L

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s