I have been working with individuals and teams implementing both VDI and SBC infrastructures for going on 20 years now. Over the last 8 years with Unidesk and now Citrix Consulting, it has been intense, working with many customers on a weekly basis. I have spent a significant portion of this time concentrating on how to best configure the Windows OS to get the best user experience with the highest user density per physical host. Luckily for everyone likely to be reading this blog post, there are many talented folks also working on this same goal.

For many years the guys at Project VRC, headed by Jeroen van de Kamp and Ruben Spruijt, have been doing great work on this. They have moved on for now, but the work is still worth reviewing. Mark Plettenberg, who was also part of that team, has posted a review of the new Citrix Optimizer, as has Chris Twiest.

When working with customers new to VDI, I am often asked whether it is important to tune the OS at all. I guess it’s not obvious to everyone as to why there would be a need for this. But, if you think about it a little, you will come to see why it needs to be done. Normally, Microsoft and other application vendors are assuming users are working on pretty powerful single user desktops with plenty of CPU and RAM to spare. In VDI and SBC, we have many, many users and computers sharing the same physical host, so having things like extraneous services that each use an extra 1% CPU at the VM level make a large impact when magnified 100-fold on the underlying physical hardware.

Similarly, take a service like SuperFetch, which is designed to set up a local cache with all available unused memory. Leaving this service enabled would cause significant memory bloat if allowed to be used on a host with 80 desktops. For me, the worst offense is that often, tasks and processes are kicked off when no users are logged on or active; these spike CPU for tens of minutes or even hours, which can seriously impact user experience in the shared environment. The benefit of optimizing will depend on the OS and services that are required for your use case. All the analyses point to the optimizations enhancing session density between say 8% and as high as a 20% with a markedly better user experience. If you’re interested in analysis check out the Project VRC “Windows 10 VDI First Analysis and Performance Best Practices.” It is quite detailed.

That said, this post is not about whether or not you should optimize; you should. It’s about how you should optimize Windows when also using Citrix App Layering.

Where to Optimize

When using Citrix App Layering, the first decision that needs to be made is where to implement the optimizations.  I wish I could just say, “always run the optimizations in the OS layer or the platform layer,” as that would be the easiest solution, everyone would do it the same way, and a standardized approach is easier to troubleshoot.  However, it’s not quite that easy.  We need to understand what each optimization does and how it is impacted by placement within different types of layers.

Part of understanding what layer you want to make optimization changes in, is first to think about how the changes are made and how the changes are handled in Citrix App Layering.  For example, if you are disabling a Windows service, that can be done in any layer, as it will modify the HKLM registry and that change will be merged into the image.  Let’s take a look at the type of optimizations that are typically recommended and what layer it can be changed in.

Universal Apps on Windows 10

NOTE: as of version 4.10 of Citrix App Layering this is no longer a requirement.  However, if you do not need store apps logons will be faster if you do not have any.

If you are using Citrix App Layering with Windows 10, then you must remove all Windows Universal Apps.  In the work our engineering team did to test version 1703, it was determined this would be a requirement. With version 4.7, the engineering team includes a script in the App Layering Gold Image Tools called “RemoveStoreApps.ps1”.  This script will do the following:

  • Turn off Microsoft Consumer Experiences
  • Turn off Automatic Download and Install of updates for the Windows Store
  • Disable all apps from Windows Store
  • Turn off the Store application
  • Remove All Windows Store bundled applications

Removing Windows 10 Universal Apps must be performed in the OS layer. Even though this is now required, you probably would have wanted to do it anyway because this optimization is very important to minimize logon times.  This is because Universal Apps are installed at first logon, and on a non-persistent machine, every logon is a first logon unless you implement persona management of some type. I usually recommend finding a “normal” application to replace the Universal App you were trying to use.

Universal Apps must be removed in the OS layer because they are integrated into the Windows Store.  Therefore, if we were to remove them in any other layer where the Store is not captured, then there would be a mismatch between what Windows has installed versus what the Store thinks is installed.

Note: if you remove Universal Apps from the OS layer after creating an Office layer, you will have to recreate the Office layer because our Office Recipe makes a backup of the Store, and we need to make sure that backup has the apps removed as well.

Services, Scheduled Tasks, and HKLM Settings

Most Windows optimizations fall into this category – these are grouped together because as described above, disabling services and scheduled tasks are really just HKLM modifications. The idea here is that you are removing any unnecessary services, tasks, and functionality that uses extra memory and CPU.  Doing these will help you achieve the best density and user experience with your VDI or XenApp deployment.

Some examples of these settings are:

  1. Disable SuperFetch
  2. Disable any unused services
  3. Disable the Start Component Cleanup Task
  4. Increase Disk IO Timeout to 200 ms

These types of modifications can go in any layer but must be included in the published image.  At the end of the day, they are all registry settings that will be merged properly between layers. Keep in mind that many, if not all, of these items can be configured by Group Policy if that’s your organization’s preference (keep in mind that you may need to boot your master image with the corresponding Group Policies deployed, depending on what you’re optimizing).

User Specific Optimizations

There are several often-used optimizations that change HKCU settings.  In Citrix App Layering, HKCU modifications are never transferred to a user logging on.  The changes are made to the local administrator’s profile used for packaging, but there is no way for us to transfer that to a user logging on.  Example of HKCU optimizations include:

  • Reduce Menu Show Delay
  • Don’t show window contents when dragging
  • Don’t show window minimize/maximize animations
  • Disable visual effects

Most Windows optimizers implement these types of optimizations by modifying the Windows default profile. However, changes that affect the default profile, which is implemented in Windows as a set of files, are problematic when using app layering, because if you modify a registry setting in the default profile in two different layers, then when the layers are merged, the layer with the highest priority will win and the other layers’ changes will be lost.  So, if we are modifying the default profile, we have a few options:

  1. Modify the default profile in the OS Layer before any other layer is created. This way, any new layer will inherit those changes when it modifies the default profile.  This can be problematic when you want to make changes later and is not recommended.
  2. Modify the default profile settings in the Platform Layer. The Platform Layer is the highest priority layer when a published image is created.  Making the changes here will ensure they make it to the published image.  This can be more work, as the platform layer is frequently recreated (as multiple Platform Layers are required to deploy on different hypervisors/clouds/provisioning mechanisms).  Then, the changes must be made with every new Platform Layer.
  3. Script the changes and apply them on boot of the target devices.
  4. Use Citrix Policies or GPOs.

I like number 4 the best – using Citrix Studio policies for this (and Group Policy to apply other user configurations you wouldn’t put in the default profile).  These policies will be applied on logon and therefore they are very easy to change if your organizations requirements change.  Also, now you don’t need to worry about layer priority and what layer to use for these types of changes.

Recommended Locations

So now that you have a basis for deciding what layers to use for optimizations, here are my key recommendations:

  1. Add a version to your OS layer so that you have a version to fall back on that has never been optimized. Run your desired optimizations. Don’t include any HKCU optimizations –  leave those for Citrix profiles or GPOs.  The advantage to optimizing in the OS layer is that your packaging machines will have the optimizations. and if an application won’t work with one of the optimizations, then you will be able to find out while packaging.
  2. Always keep the original OS layer without optimizations, just in case. It can be very hard to back out of optimizations you’ve applied.  This allows you to go back to that version, add a new version, and set up the optimizations again.
  3. If you have optimizations that are not the same for all images, then you can change those settings in an App Layer and add the App Layer to the image template. This assumes we are not talking about removing Universal Apps, which as stated above, have to be removed in the OS layer and as of App Layering 4.7 you have to remove all of them.

How to optimize

We have discussed where to optimize; now, I know that many of you are going to ask how should I do it.  You will find that there are lots scripts and a few tools out there to use for optimizing Windows.  At Unidesk, I wrote a tool (which is still available) called the “Unidesk Optimizer,” a HTA file stored in the c:\windows\setup\scripts folder when the App Layering tools are installed.  This tool still works and it implements most of the relevant optimizations, but it is no longer what I recommend using.  If you do want to use it, you run the .hta “as administrator,” select the desired optimizations, and at the bottom, click Save.  This will create a script file called optimizations.cmd that you can run “as administrator” to apply the optimizations.  While this tool was great for its time, I prefer the new Citrix Optimizer developed by a team of very talented individuals at Citrix.

Download the Citrix Optimizer.

What I like about this optimizer is that it is very extensible and third parties (and other Citrites like me) can create their own templates to use with the optimizer. It also has a journaling and undo feature. If you find that you made a mistake, it’s much easier to back the changes out.  Of course, you can also use other tools like scripts and Group Policy – at the end of the day, it’s your choice based on organizational standards and what’s easiest for you.

What Settings to Use

We have talked about where to optimize and what tools to use, but the most important part of optimizing is actually understanding what settings you are applying.  Not all optimizations work for all use cases. Some applications will require that certain Windows services are running and you have to make sure you have not disabled the ones you need. For example, you might want to disable the Telemetry service in Windows 10, but if you need to defer updates, this service is actually required.  Some optimizations drastically change the look and feel of Windows, which may or may not be what your organization is looking for.  So, whatever tool you use to optimize, make sure you review all the settings and agree with them before using them.  If you don’t know what they do, err on the side of caution and leave them alone.  For the most part, every optimization provides a small benefit.  When taken as a whole though, the benefit can be great as mentioned earlier.

For Citrix App Layering specifically, there are some optimizations that are important to make and some that you need to skip.

Dos

These are required for App Layering:

  • Disable System Restore
  • Disable Shadow Volume Copy Service
  • Disable Volume Shadow Copy Provider
  • Disable Hibernation in Windows

These are suggested if you use PVS:

  • Disable TCPIP v6

These are helpful:

  • Device Manager Show Hidden Devices
  • Disable Network Location Wizard

Don’ts

These are used by Citrix App Layering and should not be disabled:

  • Do not disable 8.3 Name Creation – Update 1-31-2019 I was also informed by engineering that this setting can be set either enabled or disabled but its important that it be the same in all layers or that will  cause issues.
  • Do not disable NTFS Last Access Time Stamps Updated 12/19/2018 I have thought this was required since 2011 but I was just informed by one of our developers this is not the case and this setting will not affect App Layering.  We do use the Last Access Time Stamps but we can set them whether or not this is set.

Updated 6-24-2019

For App Layering, I created a supplemental template for the Citrix OptimizerV2.5 to make these optimizations easier to set.  The supplement is now available on the community marketplace started by Ryan Butler.  This can be accessed using the following link:

Citrix Optimizer Community Marketplace

If you add this marketplace to your optimizer then my templates will become available.

I hope this helps all the customers who have asked how optimization should be performed in the forums.  Unfortunately, I can’t cram all my tips and tricks on optimization into a single blog, so keep your eyes peeled for further material.

Until next time,

Rob
Rob Zylowski, Senior Architect Citrix Consulting Services

Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.

Click here for more TechBytes and subscribe.

Want specific TechBytes? Let us know! tech-content-feedback@citrix.com