Thomas Lee's collection of random interesting items, views on things, mainly IT related, as well as
the occasional rant

Saturday, October 26, 2013

Starting up the Lync Test Drive VM Farm

I wrote recently about the Lync 2013 Test Drive set of Virtual Machines. These are pretty neat, although they are a large download, and expand to a very large size. But worth it for the ease of use. In testing it, I found it uses a lot of RAM, so if you want to run all of the VMs at once, I found I needed 32 GB of RAM. But even then, starting up 7 VMs even on my Precision 7400 box takes a lot of time.

If you just start all the VMs at once, they all grind very slowly to life. It seems to take 15-20 minutes to get it all started – I usually start the VMs and go off and make coffee! A big downside to this approach, and one I regularly confront in the classroom, is that Exchange, Lync and the Certificate Services sometimes do not start or start fully. It tends to be the Lync and Exchange services that fail to start. And while the AD Certificate Services starts up OK, it can end up unable to issue a certificate if requested by Lync’s installation package.

Now this is NOT new. I’ve been seeing it in my classrooms since OCS 2007 days. There are a couple of simple solutions to this problem (and probably more):

First, just start VMs up more slowly – waiting a few minutes between starting each one. If you wait until you can login to the DC, for example, before starting anything else, issues like authentication from remote machines (e.g. the remote machines wants to take advantage of the DC before the DC’s netlogon service is fully up and able to accommodate) just go away. Sufficient staggering of the startup of each VM eliminates the risks of services not starting.

Second, you could create a simple start-up script for each machine that slept for, say 10-15 minutes, then started any un-started services. Once you create the script you could then apply it using local group policy. That way when the three systems start, they wait (till the server calms down a little after boot) and just start any services that do not run. This is more effort than the first. I’ll post that script in another blog post.

The use of this script does mean it takes 20 minutes to start up the farm, but that’s time I’d probably spend any way waiting for the VMs to start up and then troubleshoot things to fix what is not working. Since I tend to work with these VMs for several hours at a time, the overhead of the script is minor, and I can easily work around the 20 minutes it takes!

Note also that we looked into the two known troublemakers and saw that all but UM was up and running. Given I’m not yet played with the UM part of the VMs, I’m OK with this for now. Maybe a bit more tweaking.

If you use the script above, test it out in your environment and adjust the sleep times to reflect how long things take on YOUR hardware.