VMware

Cold Starting and/or Hydrating Your Applications To Improve Their Startup Times

by

In the End User Computing (EUC) space we know that after the first time the application starts post reboot, the next time is faster. The first startup is referred to as a cold startup and all subsequent runs are warm startups. The first time the application starts, components of the application, such as the EXEs (executables) and DLLs (dynamic link libraries) need to be loaded from disk, which can delay the startup time. All subsequent runs will then read the data from the file system cache, which is memory managed by the Operating System.

Hydrate and Cold Start your applications

The way we prepare a system for a user is to cold start (pre-launch) the applications when the system starts. We do this by starting and then terminating each process, such as winword.exe.

Read more

Best Practice for the Windows Client Side Caching (CSC) kernel driver in VDI workloads

by

It’s been a best practice for a long time to disable Offline Files in both RDSH and VDI workloads. However, this has only ever been based around the Offline Files (CscService) service and some registry tweaks.

What people don’t realize is that you must properly disable Offline Files in all VDI workloads by also disabling the Windows Client Side Caching (CSC) kernel driver as outlined by Ned Pyle here.

Even with the Offline Files (CscService) service disabled, the Windows Client Side Caching (CSC) kernel driver is still loaded at Windows startup, creating unnecessary noise and potentially impeding performance when users access a network share.

The following example is a screen shot of Process Monitor monitoring a zpaq64.exe process extracting a file to a network drive. Note how it’s continually attempting to access the CSC (Client-Side Caching) area before the network share, even though Offline Files is disabled. This creates a large number of NAME NOT FOUND errors, and adds a potential delay to the execution time.

Read more

Best Practice for the Windows Time (W32TIME) Service for RDSH and VDI workloads

by

When using image deployment mechanisms for RDSH and VDI workloads, such as Citrix PVS, Citrix MCS and VMware View Composer, it’s extremely important to reconfigure the Windows Time (w32time) Service to ensure that the LastBootUpTime is accurate. If it’s not accurate, it effects monitoring, the correlation of log data, event triggers, etc.

The default Manual trigger of the Windows Time service is based on domain membership, which seems to cause issues as the image boots and changes name to the correct target name. Without having a deep enough understanding on the inner workings of these technologies, I can only assume that the default trigger of the Windows Time service is not compatible with the way the imaging mechanisms work on boot up to change the computer name and join to an Active Directory computer object. There may be a point during startup where Windows detects that it’s not domain joined and therefore stops the Windows Time service, which seems to throw the time out.

Read more