For as long as software versioning has existed, application vendors have given specific application releases an End of Life (EOL) date, after which the codebase is “frozen” with no more updates available. That time is fast approaching for a number of products you may have delivering your service right now. You need to understand the timescales involved, what it means to you and the risk of doing nothing.
Let’s take a look at products are we talking about here. There are a few but the key items I’m focussing on are:
|Product||End of Life|
|Citrix XenApp 6.5||30th June 2018*|
|Citrix XenDesktop 7.x on Server 2008/2012||30th June 2018**|
|VMware Horizon View 5.x||14th September 2018|
*That’s if you have Subscription Advantage/Active Maintenance. If you don’t, it was 24th August 2016!
**This does not include Long Term Service Release (LTSR)
So what does this mean to you? Well, if you are running any of these solutions to deliver desktops and applications remotely to your business, you have around 12 months to migrate those workloads to a newer version of the solution, consider alternative approaches, or take the choice to operate your solution without the availability of security fixes for those products should a vulnerability be found. In some industries governed by compliance regulations this last choice is not available as most compliance regulation requires you to run in a “supported” environment.
However, you are not alone. According to the latest “State of VDI/SBC Union Survey” carried out by our friends at VDILikeAPro, almost 20% of organisations surveyed are running XenApp 6.5 or older.
So, let’s assume you don’t want to be left on an environment no longer receiving security fixes (WannaCry anyone?) What do we need to think about right now to fix this? If we look at the path to the future there are a number of key points you need to consider:
Do not underestimate the impact of applications on your time to transition.
If you are moving to a new version of Citrix XenApp/XenDesktop or VMWare Horizon take into account the length of time it will take you to migrate is directly proportional to the number of applications you have.
Take into account application consolidation (how many pdf reader apps are in use, for example)
Make use of appropriate Software as a Service (SaaS) solutions to reduce your local application footprint and reduce the complexity of your migration.
Consider App Layering/Masking to deliver admin efficiency – in addition to third-party solutions both Citrix and VMware have mature layering options where administrators can deliver application sets more cleanly than installing different applications to different users.
User Experience is THE most important consideration to those consuming your solution.
We have come a long way since you implemented the solutions you are currently sitting on, and the improvement in user experience metrics has been enormous – make it part of your design and testing. Measure user experience before and after – it makes a massive impact when you can show the success of the project through the productivity of those using it.
If you are altering how applications are delivered, test them in the proposed environment.
Making changes to how services are delivered can have a significant but often unexpected impact on user experience. One common example is migrating Microsoft Exchange to Office 365 in a virtual desktop scenario. At first you see nothing but benefits - your upgrade cycle goes away, you reduce data centre footprint, you get a bazzillion goggle-bytes of free storage, what is not to love? However, if you take a little time to think, you’ll see that one of the impacts of this is that the users mailbox will move from the server next door to a data centre ‘00’s of miles away. This will not be great for performance. In a non-persistent environment, the mail-file will need to be downloaded each time a user initiates their outlook client in a new session. One thought would be to cache their mailbox locally, but in a shared hosted environment or a non-persistent VDI scenario, this is simply not viable. There are solutions to this such as FSLogix Office 365 Containers but you need to be aware of the problem before you go searching for the right solution.
Don’t assume your performance requirements are the same.
When moving to a new Operating System and/or application version during this migration, do not assume you can just move over with the same infrastructure. Throughout benchmarking tests (and real-world experience) the team at LoginVSI showed a 15% decrease in user capacity when simply replacing Server 2012 R2 with 2016 OS. With Microsoft Office, the difference is even more marked. Again, according to LoginVSI, the migration from Office 2007/2010 to Office 2013 used 25% more resource to handle the same number of connections. Dan Feller from Citrix states that moving from 2013 to 2016 can reduce session density on a server by 25% on top of this. This is a significant difference and something to take into account. Dont fall into the trap of making new purchasing decisions based on your current resource usage – you have been warned.
Don’t underestimate the needs of your web browser.
As more services are delivered via SaaS and the browser takes more prominence, more attention is paid to the performance impact of the most launched application your business is using today. Performance requirements of the browser – particularly if left un-optimised - can be very significant. Simple things like enabling ad-blockers could decrease your future hardware spend on VDI by 30%. I’d strongly recommend you read the article published by LoginVSI specifically on this subject here.
If you POC a new solution, make sure you include your complex use cases.
Before you choose a solution, make sure it has the capacity to meet your most demanding scenarios. There is rarely a “one-size-fits-all” here, so do not try to squeeze everyone into one method of delivery. Too many organisations I talk to come across migration issues because they have carried out a lightweight test on a solution they like the look of, but which later stalls the project due to use cases not tested which don’t fit within the solution scoped. My rule of thumb is: Test the difficult use cases first, then migrate them last.
Let’s cut to the chase here. You don’t have that long from now until your virtual desktop solution becomes end of life. There is a decent amount of preparation needed to get yourself in shape to migrate cleanly.
Don’t wait around thinking this is a spare weekend job – there are a lot of moving parts here. Desktop migration is not an isolated IT project; it is a business productivity project. Treat it as such and engage the whole business in the evaluation and testing of your next move.
Use cloud services if they are right for you; consume a managed service if that is what will best help your business move forward, keep everything in-house if it is the best use of your time and money. That is all up to you. The most important thing to do is to make a decision and make start. Good Luck!