Building a standalone Lync server, or, how to write UCMA applications on a plane

One of the difficult things about writing applications using UCMA is the fact that you need to connect to Lync in order to run or debug any of your code.  In fact, since you can’t connect UCMA applications through the edge server, you need direct access to the front end, which probably means VPN connectivity for any remote work.  On top of that, if you want to be able to provision and debug things on the server side, you’ll need administrative access to the Lync server, so it’s likely that there’ll be a separate development lab environment set up apart from your company’s everyday Lync deployment.  In the ideal case, each developer would have access to their own personal Lync sandbox, since then they could write and test whatever they needed to without impacting anyone else. 

Over the past few years, I’ve run into a few people that have built monster laptops that ran Hyper-V and a full Lync stack, but I’d never tried putting one together myself.  Last week though, I finally got the chance, and while it does work, there are a few pitfalls that I found while trying to get everything going. 

First, the hardware.  For this application, I picked up a Samsung 700G7A gamer laptop from Best Buy for about $2200.  I needed something that had a decent processor (Core i7) enough memory (16 GB) and a bunch of hard disk space (1.5 TB).  Having built a few Hyper-V servers before, I probably wouldn’t go with much less than 16GB of memory, especially if you want to run Lync, Exchange, perhaps SharePoint, and then do development on top of that.  The dual hard drives are also probably optional, but you will need a lot of storage for something like this, so 500 GB is probably a good minimum.

Once I got my hands on the hardware and did a quick check to make sure that nothing was broken from the factory, I proceeded to wipe out all of the OEM software and disk partitions and install Windows Server 2008 R2 (Standard) as the new host OS.  Since all of the servers you’ll need to run are 64 bit only, that means running Hyper-V, since Windows Virtual PC can’t run an x64 guest.  We’ll also need a domain controller for Lync, so the host, in addition to being the main development server will also be the DC. 

The initial install of the server OS was fairly straightforward, but once it finished, I ran into the first problem.  Most of the time, after installing a new server, connecting to Windows Update will manage to grab all the relevant signed drivers for a system.  In this case though, there was a whole list of known and unknown devices in the device manager that had no drivers, including the graphics card, Bluetooth module, and wireless adapter.  I suppose we’ve been spoiled by having easily updated drivers from a central location for a few years now, since it wasn’t that long ago that every piece of hardware had its own install disc, so the solution here was to search the web for all the relevant drivers.  For the most part, the Windows 7 drivers did work on Server 2008 R2, but in a few cases there were no drivers available.  Fortunately, enough did end up working that I don’t think it’ll be a major issue-the only major features on the laptop that aren’t working as advertised now are the mute key and the wireless toggle.  The takeaway here though is that before installing a server OS on a consumer laptop, take careful inventory of the hardware, and have as many drivers handy as possible.

As for features on the host OS, another discovery was that even with the driver installed, Windows Server will not connect to a wireless network out of the box.  Under the server manager, you need to add the “Wireless LAN service” feature to enable it.  While you’re at it, add “Desktop Experience”, “.NET 3.5.1” and “Telnet client” to the system (Telnet is still useful for troubleshooting connectivity). 

Once those are installed, it’s time to start with roles on the main OS.  First, install Active Directory Domain Services (you’ll need to do this on its own) and create a brand new domain, which in my case was “icedemo1.local”.  Once this role is set up, you can also go ahead and make sure that Web Server, DNS Server, Active Directory Certificate Services, and HyperV are all installed on the host.  This will probably take a bunch of reboots, so it’s a good thing to do while you have something else to keep busy with.

Eventually, after all the roles are installed, patched, and ready to go, you can start with the virtual machines.  I created three guest servers to start with-a Lync Standard Edition front end, a UCMA application server, and an Exchange server with Unified Messaging.  Creating those is fairly standard HyperV/Lync deployment-install the server OS, join the new domain (icedemo1.local), and then follow the Lync/Exchange install guides-so I won’t go into too much detail, but what is interesting about this isolated scenario is the way that networking is set up.  Since I wanted to have everything on its own isolated subnet (I created IPs in the 10.0.146.X range), I assigned static IPs to all my guests and created entries in the host DNS.  I still wanted the host (and guests) to be able to connect to the internet if it was available though.  Since my host was a DC, it needed a static IP (10.0.146.1), and I could easily assign an extra static IP to connect to the internet, but the catch would be manually reconfiguring this IP for every network that I wanted to get access to.  Ideally, I wanted to have a connection set up with DHCP for the internet, as well as a static IP for the virtual machines, which I managed to do using internet connection sharing.

Set up the main adapter (wired or wireless) for DHCP.  Then, in Hyper-V, create a new virtual network with the “Internal Only” option, assign this new virtual network adapter the static IP address, and connect the VMs to this adapter.  Note that this virtual adapter should also have the preferred DNS server set to the static IP address (e.g. 10.0.146.1) and not the default localhost (192.168.0.1)-if you don’t do this, then DNS queries on the host OS will fail if you’re not connected to a network.  Finally, on the main adapter, allow internet connection sharing with the virtual network-on the Sharing tab, check off both “Allow other network users to connect to the internet though this computer’s Internet Connection” and “Allow other network users to control or disable the shared Internet connection”.  Unfortunately, enabling connection sharing on one connection/adapter disables it on others, so it’s not simple to flip between wired and wireless networks, but other than this one limitation, everything appears to work as expected. 

After setting up Lync and Exchange, as well as some client software on the host OS, I had a small isolated domain that I could finally run UC apps against.  The Lync client on the host server could place a call into a UCMA application, and I could send IMs between two virtual clients.  Multiple voice endpoints, however, were another matter.  If you need to be able to have two users in a voice call at the same time, it may not work as well as you’d expect.  While there are options in remote desktop now to redirect microphone and speakers from a remote machine, I have never been able to get this to work with a virtual machine on Hyper-V.  Windows Virtual PC on Windows 7 has a great feature where USB devices can be redirected to a VM, so I’ve been able to have two USB speakerphones dedicated to different Lync instances that way, but this feature doesn’t exist on Hyper-V yet.  I also tried a couple of different USB sharing utilities, but none of them were able to share my Jabra conference phone to a virtual machine. 

So far, the only way I’ve managed to get two endpoints on an audio call at the same time is to log two users into the host operating system and switch between them.  This mixes the audio from both calls through the same device though, so it won’t sound great, even if you have each session’s Lync using a different audio device.  Still, if you only need to get the users in a particular state to test a scenario, then this will suffice. 

In the end, this is a great way to set up a simple Lync development or demo environment that can run off the grid, and also a good training tool to give to someone to learn Lync configuration in a sandbox environment.  It’s not that much of a stretch to include a connection to an external gateway to make and receive PSTN calls, and you could probably even set up an edge server and federate to other domains (although without a DMZ).  As for improvements, USB redirection would be great to have, as would a better solution for sharing internet connectivity between the host and guests (although this may just be something I haven’t found yet).  I’d also be interested to try again with a high end machine from Dell or Lenovo to see if the driver situation is any better, since the Samsung I’m using was obviously never intended to run a server OS. 

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Building a standalone Lync server, or, how to write UCMA applications on a plane

  1. Chris Tart says:

    For using audio on multiple Lync clients, try just installing a Windows 7 VM and then using RDP. For some reason the server OS’s don’t accept the Remote Audio by default, but the desktop OS’s will. You can get the remote audio to work on a server OS by installing the Remote Desktop services, but that requires setting up a licensing server as well.

  2. Pingback: Building a standalone Lync Server part 2-Windows 8, HyperV, and a domain joined laptop | Chris Bardon

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