To assess or not to assess, is that even a question?

I’m currently working on the first design project after becoming VCDX. And so it is a great opportunity to use my newly developed skills to design the world’s most awesome Digital Workspace. I might write some more around this project in the next coming months. The project involves basically the whole VMware Workspace ONE Suite and on top of that NSX Enterprise for Desktops and some other security-related solutions for AV integration and behaviour analysis. But one of the first phases in this project is the assessment of the current environment so we can get some insights for the new solution. Assessing a customer should be part of every design project that one does. Because building something based on assumptions could work, but wil eventually end up in a shit storm.

VDI assumptions

This post is dedicated to help you set up your assessment and will give you some insights in what to look for during the assessment. I did some great work with Liquidware Stratusphere FIT, so I will explain the assessment options based on this solution.

What to assess?

First things first. What should you assess? The consultancy answer would obviously be: It depends. And of course, it totally does. There are some questions you need to get answered before you can decide what to assess.

  • Are you going to migrate from an old to a new VDI platform?
  • Are you migrating physical endpoints to a VDI platform?
  • Are you aiming for an Operating System migration (i.e. Windows 7 to Windows 10)?
  • Are you going to support Windows desktops only?
  • Are you going to migrate specific use cases or everything?

Depending on the answer to these questions, your assessment might look different in these scenarios. What isn’t different, is the duration of the assessment. On an average, we try to assess at least 5 weeks. Certain users might execute certain programs once a month for invoicing or other calculations. The longer the assessment, the higher your accuracy will be.

Old VDI platform migration to a new one

Let’s start with the easy scenario. Migrating from an old to a new platform. Based on the current workload and possible complaining users you should have a good idea of what an average desktop should look like. But still, in this case it is wise to run an assessment in the current VDI to get the actual facts like resource usage, application usage and user experience (login times, application start times, etc).  Requirements might have changed in the past years since you deployed the first VDI solution. Also, OS requirements might have changed (we all know that Windows 10 uses more resources and might even require a GPU to perform normally).

Migrating physical endpoints to a new VDI platform

The original use case for VDI assessments. And it’s fairly simple. You basically assess all physical machines that you would like to centralize and consolidate on the VDI platform. Liquidware Stratusphere FIT will collect data on a very regular basis from every machine and sends it to a central monitoring appliance. Again, try to collect data for at least 5 weeks. In the FIT application, you can see the collected information and run all sorts of queries and reports on that data. Things like performance data (CPU/MEM/Disk/Network/etc), application data (what applications are used and by whom) and user data (logon times including a breakdown, logon storms, etc) are essential data when you are preparing a migration or designing a new VDI environment. FIT has a couple of reports that are included in the suite that you might want to check out: 112 and 114 are my personal favorites.

The following figures are an example of the information that FIT could gather and which are really usable in the design phase of a project. Please note that these figures do not relate to each other in terms of the same assessment.

This figure shows average assessment data which can be used to calculate the appropriate sizing.
This figure shows aggregated assessment data with a proposed sizing for the new VDI solution.

Next to general performance information, FIT could also be used to gather specific data, such as information on applications.

assess application data
This figure shows the top list of applications based on their usage count.

Next to user count, applications can also be listed, based on specific metrics such as memory usage, CPU usage and graphical intensity.

GDI assessment
This figure shows the graphical intensity of applications and sorts them based on the most intense.

As you can see, with this gathered information you are able to start sizing your new platform or scale out your existing one.

Multiple use cases

Everyone who works with VDI knows that not every user is the same. There is a big chance developers and call center employees do not have the same resource and User Experience requirements. So a proper use case definition needs to be done as well to be able to get the right information for the specific use cases. In a post I wrote a while ago, you can read how a use case definition could be done.

Querying your assessment data to display the data for specific use cases can be done by creating views. To create a view, it is wise to know what the specifics of a certain use case are:

  • Are the users in a specific Active Directory group?
  • Do the users connect from a certain location?
  • Do the users run specific applications?
  • Do the users work within specific business hours?
  • Do the users have specific end points such as specific HP laptops (like lightweight ones used by  sales people)?

If you have an answer to these questions, you will be able to create a proper sizing for your different use cases.

I hope this post gave you an idea what the importance of a proper assessment is. In future posts I will dig some deeper into assessments and what to look for in specific situations (like a Windows migration) or User Experience improvement.

Johan van Amersfoort

Johan van Amersfoort

Johan van Amersfoort is a Technical Marketing Architect and EUC specialist at ITQ Consultancy. More about Johan can be found on the about page.
Johan van Amersfoort