Best Practice

Priming a Non-persistent Windows Image using an Autologon Process with an Auto Logoff Timer

by

Several years ago, and inspired by an article written by George Spiers to reduce login times, where “the second logon is quicker”, together with some code from Maurice Daly, I created a methodology and scripts that is designed to Autologon a non-persistent Session Host (both VDI and RDS), and then log it off again before another script will Start the Citrix Desktop Service (BrokerAgent).

It has been working flawlessly for years. However, I was never 100% happy with it because the process was using a domain (service) account for the Autologon process. The main challenge here was trying to change the password on a regular basis to stay compliant when managing multiple images. You cannot realistically do it without an outage. And in a 24×7 environment, it becomes difficult and onerous. I also felt that using a domain account can be “heavy” during a boot storm as you need to ensure you are excluding this account from profile management and policies where possible. Sometimes that is easier said than done. There is a level of risk here, as someone can easily make a change that will cause issues. The ability to roll the password and stay compliant was my biggest concern and where I got stuck for quite some time.

Read more

What happened to the Citrix DaaS Remote PowerShell SDK Global Variables?

by

If you are used to checking, verifying, or even leveraging the Global variables, such as XDAuthToken, XDSDKAuth, XDSDKProxy and XDSDKUser, created by the Get-XDCredentials cmdlet, Citrix has made changes to the way these cmdlets store and use this data. They have now moved these 4 values into the new NonPersistentMetadata property of the Get-XDCredentials cmdlet output.

But of course there is no documentation to explain this change or even make us aware of it. In fact all their documentation still refers to the global variables. Very frustrating!

Read more

Best Practice for the Active Setup StubPath value

by

It’s been a best practice for a long time to clear the Active Setup StubPath value per application to avoid the Active Setup processes from running at logon, impacting the user experience. This is a challenge we constantly have with Vendors and packaging teams. But blindly clearing the StubPath value could lead to application issues. So what happens when you need to go back and troubleshoot an issue with an application that may be related to what “should have” run via the Active Setup process. How do you know what the StubPath value was originally set to? Do you record it somewhere?

I’ve been running a script for years over my builds that simply renames the existing StubPath value to StubPath.Backup and time stamps it. This way you can always review what it should be, and make the necessary changes to allow for this.

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