So I thought it might be interesting to see the difference Workspace Environment Management has on the logon experience with VDI.
Note: Both of these examples mapped 5 drives, mapped 3 printers, used a 500MB roaming profile and executed a single logon script that queried a single AD Group.
Improving logon time is a fun topic because the experience is oftentimes so bad. I heard (and I’ve complained) about the horrible experience. On the opposite side, I’ve also heard many others bragging about how fast their logon times are. What’s your logon time? Excited to share or afraid to say?
As we saw in a previous blog, Microsoft added new default apps into the base operating system of the Windows 10 Build 1703 (Creator Update). These updates will have an impact on the user experience, especially in a VDI implementation.
Many of the new capabilities with the latest builds of Windows 10 also implements new Windows services. With each release, the number of services has steadily increased.
Build 1507: 196 Services
Build 1607: 212 Services
Build 1703: 223 Services
History has shown that optimizing Windows services can improve logon time and server density. It is recommended to review the list of services and disable those that are not necessary for the users.
To see a list of Windows services, run the following PowerShell command: Get-Services
The table below shows the state of each service (Stoppped or Running). Only services with a green, orange and red shading should be considered for disabling.
Green: A currently running service; consider disabling
Orange: A stopped service that will run when requested; consider disabling
With the release of Windows 10 Build 1703 (Creator Update), Microsoft added new capabilities into the base operating system that will have an impact on the user experience in a VDI implementation.
Microsoft expanded the list of default applications that come pre-installed within the base OS.
With each release, the number of default apps increased.
Build 1507: 24 Apps
Build 1607: 26 Apps
Build 1703: 31 Apps
As shown in previous tests, leaving these apps part of the base operating system directly impact user logon time and overall system density. It is generally recommended to review the list of apps and uninstall those that are not necessary for the users.
To see a list of default Windows apps, run the following PowerShell command: Get-ProvisionedAppXPackage -Online|Select DisplayName
As you might have read, I recently ran a few XenServer PVS Accelerator tests to determine a starting point for the cache size. This initial investigation looked at Windows 10 and Windows 2012R2 for boot and logon operations.
Looking back, I determined that I want to include three additional items
Impact of a larger cache size – Increase from 2GB to 4GB RAM cache
Impact of applications
Impact of Windows 2016
Before I get into the results, let me explain the graphs.
The blue, green and orange line denotes boot, logon and steady state operations. The first time those colors appear depicts the first VM; the second time the colors appear depicts the second VM. These colors are linked to the axis on the right showing percent of cache used.
The solid red area graph depicts the amount of network traffic sent from the Provisioning Services server to the host. The line should initially be large and then diminish as the cache is used. It is linked to the left axis with bytes per second.
With that understanding out of the way, let’s look at the results.
When it comes to operating system optimization, I have two sides battling with each other. Although optimizing does improve single server scalability, I believe the more you mess with the OS the greater your chances are that you will break something.
Unlike Windows 10, which had numerous default apps that increased user logon time, Windows Server 2016 is free from such additions.
Many of the services we disabled in Windows 10 are already configured as manual startup in Windows 2016. Looking deeper, it would appear that many of these services are either started based on a request by an application or based on a scheduled task.If a manual startup service is disabled, then any application or system component that tries to interact with the service will fail. This will result in application/system issues, support calls and long troubleshooting times.Based on that , the only service that you think about disabling is:
How large should we make our PVS Accelerator cache? Too large and we waste resources. Too small and we lose the performance.
Let’s take a step back and recall our best practice for sizing the RAM on Provisioning Services. We would typically say allocate 2GB of RAM for each vDisk image the server provides. This simple recommendation gives the PVS server enough RAM to cache portions of the image in Windows system cache, which reduces local read IO. So for a PVS server delivering
1 image: we would allocate 2GB of RAM (plus 4GB more for the PVS server itself)
2 images: we would allocate 4GB of RAM (plus 4GB more for the PVS server itself)
4 images: we would allocate 8GB of RAM (plus 4GB more for the PVS server itself)
Let’s now focus on the XenServer portion of PVS Accelerator. If we use RAM as our PVS Accelerator cache, how many GB should we allocate?