Recently the FSLogix team was working with a customer, and was posed with a dilemma about whether their toolset would solve a problem with large address book latencies in VDI and Skype for Business.  Essentially the problem is that the Skype address book would download every time a user opened Skype for Business which was very, very slow.  A huge problem for the end-user just trying to do their job.  The customer is committed to their non-persistent VDI configuration due to the benefits of this design, but needs a resolution to make this tolerable to its business users.

Researching Options

After some investigation, it was quickly learned that native toolsets within the product platforms would not offer any resolution.  So, they talked to FSLogix about FSLogix options due to familiarity with their option for Office 365 and Exchange cache mode, but testing and validation were important to be certain that this would work.

So, how do you solve a problem where a 180,000-seat enterprise with a 2.8 GB Skype for Business address list must cache every single time it’s opened in a non-persistent VDI?  Let’s look and find out what needs to be unraveled, and whether or not this will work as expected.

Technical Groundwork

Before any form of testing could begin we needed an environment to test this out.  So, it was time to build a lab.  The lab was built on a cloud-based virtualized platform, and in the end consisted of the following setup –  Active Directory, DNS/DHCP, Microsoft Exchange, Skype for Business, a Certificate Authority, RDSH configuration, and an RDS server.  The lab build took around 10 hours for full configuration, and once complete we were running Skype for Business as needed to test this out.

The next step to proving out this process was to install the FSLogix software on the RDSH and RDS servers.  I wasn’t sure I was going to include this in detail, but thinking about it some more I realized that showing you the simplicity of their installation process would prove to be valuable.

So let’s get started!

• Create two file shares on redundant storage, to house your VHD on a central server (*Windows 2008 R2 or later). One for FSLogix ODFC Containers, and one for FSLogix profiles.

• Install the FSLogix Software. Once you have the product key, its next, next, next and then on your way.  Installed in minutes.

• Once complete, there are also a few registry keys that you will want to check for. Just confirm that these exist and align with the settings you are expecting to be in place.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\FSLogix\ODFC]”Enabled”=dword:00000001    }  –> Enable or Disable the FSLogix product

“IsDynamic”=dword:00000001     }  –>  Setting that allows the VHD to grow automatically to the max size bellow.

“SizeInMBs”=dword:00007530     } –>  Max size for VHD – follows the  Microsoft VHD and VHDX sizing support model.

“VolumeType”=”VHD”   } –> Sets the volume type to VHD or VHDX

“VHDLocations”=\\SERVERNAME\SHARE\FSLogix.ODFC   } –>  The file path of the network accessible fileshare 

** FYI Dynamic profiles are profiles as we know them, but within the FSLogix software platform.

• The FSLogix Containers product will then create a windows Virtual Hard Disk VHD for each folder intercept that you create for your users. Again, one for ODFC Containers, and the other for the profiles that FSLogix requires.

Note:  They will appear local, but they aren’t.  When you look at the way your disks are presented on the server appear as shown below.

• Next it’s time to go to the local server groups, and make sure the following groups exist. You can also nest Active Directory groups into these groups if you are looking for more centralized control over permissions across your servers.

So that is all that there is to it, the FSLogix software is very straight forward and simple to install.

Drumroll Please!

So did this work, or is there more work to do?  In the end this process worked very well, and as expected.  For our use case we used a 1.1GB Skype Address book.  Our findings showed that with native tools it took 15.5 seconds to open Skype for Business with 9.4 seconds for the data transfer of the address list to complete.  Once FSLogix was installed it took 3 seconds for Skype for Business to open, and only .01 seconds to connect to the VHD for access to the Skype Address List.

So it’s clear that the FSLogix solution does address Skype for Business address book latencies, and will allow their customer to provide exceptional performance to their customers!

So Why Does this Solve Problems with Large Address Book Latencies?

Let’s take a look at the larger enterprise that is rolling out non-persistent desktops.  Every time a user logs in they are ultimately transferring the Skype for Business address book to the local image, and every time they log out that process is repeated on the next login.

Let’s look at the math on that, if you Skype Address book is 1GB in size it would have to be transferred across the network every time the user logs in.  Not only is this a tax on the network, it’s a tax on IOPS on the infrastructure (Exchange, VDI, etc).  Effectively, this tax results in a minimum of a 2X tax on IOPS just to continue to use non-persistent desktops.

Also within VDI with write cache enabled, you will gain an additional value add.  Since FSLogix technology uses a intercept, the Skype Address Book will note not ever hit the write cache.  This means that the write cache can be used for more important things also ensuring greater performance benefits.

With FSLogix, the Skype address book is committed one time, then FSLogix reconnects to the user VHD container with the existing GAL in place.  The benefit is the 1GB data transfer is eliminated, so is the IOPS tax, and the write-cache is bypassed.  All ensuring a better user experience.

Overall, Very Nice!

Sponsored by:

To learn more about what FSLogix offers for your Citrix XenApp and XenDesktop deployments be sure to click their logo above.