Don’t let your user-experience be a “Spectre” of itself after “Meltdown”

Bust your ghosts not your user experience

The names Spectre and Meltdown invoke feelings of dread in even the most seasoned IT engineer.  To those uninitiated, let me get you up-to-speed quickly.

Spectre is a vulnerability that takes advantage of “Intel Privilege Escalation and Speculative Execution”, and exposes user memory of an application to another malicious application.  This can expose data such as passwords.

Meltdown is a vulnerability that takes advantage of “Branch prediction and Speculative Execution”, and exposes kernel memory.  A compromised server or client OS running virtualized could gain access to kernel memory of the host exposing all guest data.

Both vulnerabilities take advantage of a 20-year-old method of increasing processor performance.


As a result, code will need to be updated to address these vulnerabilities at OS and OEM-manufacturer levels, at the expense of system performance.

On their part, Microsoft reluctantly admits that performance will suffer.  “Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance,” wrote Terry Myerson, Executive Vice President for the Windows and Devices group.

According to Geek Wire, these two vulnerabilities which take advantage of a 20-year-old design flaw in modern processors can be “mitigated;” the word we’re apparently using to describe this new world in 2018, in which servers lose roughly 10 to 20% performance for several common workloads.

This affects not only workloads executed against local, on-site resources but even those utilizing services, such as AWS, Google Public Cloud or Azure.

cpu_utilReader submission @ The Register showing CPU before / after patches

We’ve heard from some of our insiders who use Login VSI to validate system performance that they’re seeing a reduction of 5% in user-density after performing Microsoft recommendations. Knowing that the vulnerability wasn’t solved by OS updates alone we, at Login VSI, wanted the ability to test the impending hardware vendor firmware / BIOS changes.

Now is the time to capture your baseline performance

How do you know how much of an impact the fixes for Spectre and Meltdown will be if you don’t have anything to compare it to? Keep in mind that these patches will need to be installed on a number of systems in your solution including server hardware, operating systems, storage subsystems and so on.

Many of our customers perform tests where they compare a known good solution, or a baseline, with changes that have been made. This gives them the ability to accurately assess the performance impact of that change, which in turn allows them to compensate with more hardware, or further tuning of the applications and OS. The patented methods used by Login VSI provide a quantifiable result for determining the impact of a change in virtual desktop and published application environments.

Using Login VSI

If you wish to test the changes before pushing them into your production environment, then use Login VSI to put a load, representative of your production users, on the system. This will objectively show how much more CPU will be used as a result of the Spectre or Meltdown patches. It is expected that the end users will incur increased latency to their applications and desktops as a result of the higher CPU utilization.

Using Login PI

While it is not recommended, if you are planning on pushing the patches into your production environment to “see how it goes”, then install Login PI now to get an accurate representation of performance related to user experience. This will give you the ability to then compare to that same experience after the patches have been installed. We expect that you will see latency to the end user increase as a result of higher CPU utilization. If you already struggle with CPU utilization in your solution, there is a good chance you’ll be also using Login PI to test your availability.

As we complete our testing we will be sharing our findings in a series of articles.

If your computer has a vulnerable processor and runs an unpatched operating system, it is NOT SAFE TO WORK WITH SENSITIVE INFORMATION”. – Security Experts who discovered Meltdown / Spectre 

If sensitive data is part of your business (Such as ours!) patching is not a matter of if, but when.

Ask yourself:

How long can you afford to have your company’s data exposed to malicious intent?  Do you want to be the next Equifax or Target?

In this article series, we will provide some insight from our lab environments. Be aware your results may vary based upon individual workload and configuration.

Microsoft has released a Security Advisory

The vulnerability affects both the client and server OSs of Windows.  This is compounded when dealing with large-scale published application and desktops deployments.  The advisor can be found at the following location:

The specific details addressed in the security update and Windows KB are outlined in the Common Vulnerabilities and Exposures database.

Included are:

To completely protect yourself there are two phases of patching this vulnerability.

1 – Windows OS updates

2 – OEM device manufacturer firmware updates (not yet available)

Microsoft acknowledges addressing these vulnerabilities from a software perspective is limited, and therefore, without the OEMs providing updates the loop is not closed.

In the interim we can start measuring the impact of the Microsoft fixes.

They offer guidance for both Desktop and Server OSs:

Desktop –  January 2018 Security Update. Security Advisory: Click Here!

Server –  KB405690. Security Advisory: Click Here!

NOTE – Certain AV solutions are not compatible with the security update released by Microsoft. As such, unless an AV vendor has a registry flag, QualityCompat, they will not receive the January Security update and will still be vulnerable

With the upcoming OEM hardware patch releases we expect to be able to produce a variety of interesting and informative results.  Please stay tuned for the next articles!

Reference materials:



This article will cover how to install the Citrix Studio component.  For those of you who are unfamiliar this will act as your centralized point of control for your Citrix environment.  You can also interact with it as you’ve seen in previous examples through command line operations as well.

In order to install the Studio for management the process is straight forward.  Run the executable with a few switches –

[C:\Downloads – “Your download location”]\x64\XenDesktop Setup\XenDesktopServerSetup.exe /PASSIVE /NOREBOOT /CONFIGURE_FIREWALL /COMPONENTS DESKTOPSTUDIO

Once your Studio component is installed, you can validate the installed components by reviewing their accessibility form your server where the command was executed.


Next up would be installing your StoreFront component.  This will provide front end access to your delivered applications and desktops.


The process is the same.  Utilizing your Citrix installed, you will call the following executable with the following switches:

[C:\Downloads – “Your download location”]\x64\StoreFront\CitrixStoreFront-x64.exe -silent -logfile “%am_logpath%\StoreFrontSetup.log”

For adding additional Storefront servers to a load balanced group, you can utilize a variety of different scripts to determine if the server is already part of a group, and if not join it.

Creates a script to review if the Citrix services are running on the server where the scripts are executing, and if so join the new StoreFront sever to a group. If not create a group of its own.

Set a conditional statement to evaluate the value of this being returned, and execute one of the following scripts.

For Creating:

Set-DSInitialConfiguration -hostBaseUrl [Hostname]-farmName [FarmName] -port [ListeningPort] -transportType [TransferType] -sslRelayPort [RelayPortforSSL] -servers [ServerToAdd] -loadBalance [LoadBalancer] -farmType [FarmType] -clusterId [ID]


Or, For Joining an Already Existing:

Obtain the passcode and store value –


$Passcode = (Get-DSClusterJoinServicePasscode).Response.Passcode

and finally join,


Start-DSClusterMemberJoin -authorizerHostName $ExistingNode -authorizerPasscode $JoinPass


The final portion would really only be interesting if you were automating the same process over and over again.  This is where a product like Login AM which organizes your scripts, and variables would become handy.  If you are interested in any information about Login AM or automation of Citrix Deployments please reach out and let me know or drop and comment I would like to have meaningful conversations about automation, and increase my understanding of the products as well.

Automation of a XenDesktop/XenApp deployment

There are many pieces involved in deploying Citrix XenDesktop/XenApp.  For simplification purposes while discussing automation, let’s focus on a single feature of a Citrix deployment- the Delivery Controller.

The Delivery Controller is responsible for delivery of either applications or desktops to end users.

The components of a Delivery Controller are:

  • Database – SQL – Pre-requisite
  • Application – Citrix Delivery Controller

Installing each of these components individually is straight forward.  The applications are packaged in such a way that you can utilize a few switches to install the software.


Example – C:\{Location}\setup.exe /QUIET /IACCEPTSQLSERVERLICENSETERMS /ACTION=install /FEATURES=SQL,Tools /INSTANCENAME=MSSQLSERVER /SQLSVCACCOUNT=”NT Authority\Network Service” /SQLSYSADMINACCOUNTS=domain.local\Administrator /AGTSVCACCOUNT=”NT Authority\Network Service”

This will install SQL on a Windows Server OS silently, and create a database named MSSQLSERVER.

The same can be done with the Delivery Controller.

XenDesktop/XenApp Delivery Controller

Example – C:\{Location}\x64\XenDesktop Setup\XenDesktopServerSetup.exe /PASSIVE /NOREBOOT /CONFIGURE_FIREWALL /COMPONENTS CONTROLLER /NOSQL

This will install the Delivery Controller portion of a XenDesktop/XenApp silently, deferring the reboot and not installing SQL. You can run this string as many times as you would like and the end result will be the same.

Now, let’s get fancy.

In order for the Delivery Controller to function a “Site” must be present.  A site contains all of the data necessary for a Delivery Controller to function, and is stored in your SQL database; this includes configuration and logging information.

A site is the first step necessary to deliver resources with Citrix for your end users.  With PowerShell you can configure this without user interaction, thus enabling you to automate the deployment process.

You will need 3 databases:

  • “Site”
  • “Configuration”
  • “Logging”


You can utilize PowerShell to create these with the “New-XDDatabase” command.  This is a function of the “Citrix.XenDesktop.Admin.V1” PowerShell snap-in.  This will enable you to create the three database necessary for a “Site” to function properly.  Once the databases are created, you can create your “Site”.

You can utilize PowerShell to create your “Site” with the “New-XDSite” command.  This is a function of the “Citrix.XenDesktop.Admin.V1” PowerShell snap-in as well.


Combining packages from Microsoft, Citrix and PowerShell, you are able to automate the process of creating your first “Site” for a critical component of your Citrix deployment, the Delivery Controller.

There are many platforms for managing, and executing your collection of automation frameworks.  Some of the popular ones are Chef, Puppet and Login AM.  It creates a logical organization structure for doing so, variables necessary and provides an interface for management.

If you are interested in finding out more about this, please get in touch with me.

Also, if you have any neat tricks with PowerShell please share them in the comment section.  Happy automating.

I will be following this post up with articles about the remaining components of Citrix.

Article 2 in the series is now live! See it here – Automation of a XenDesktop/XenApp deployment – Part 2

Article 3 online – Automation of a XenDesktop / XenApp Deployment – Part 3


Citrix AppDisk – All that you need to know!!

AppDisk is an awesome technology from Citrix but it comes with its own quirks which admins/consultants should be aware of. Below are some of the items that i thought are important to know about the technology and how to set it up.

There are a few things to keep in mind before attempting to create an AppDisk.


AppDisk additional permissions

  • when you specify a size for the AppDisk, you wouldn’t be able to utilize all the size that you allocated. for eg, for an AppDisk size of 5 GB only, 3.66 are useable so always give some extra when creating appdisks
  • Don’t create snapshots of the machine prior to creating the AppDisk when using MCS Catalogs
  • There is currently no way to resize the AppDisk from within the Studio. PowerShell is the way to go.
  • There is NO versioning built into AppDisks at this stage. All that you are doing when clicking on “Create New Version” is creating a clone of the existing AppDisk which could be used to edit and update the AppDisk
  • Enable both the Shadow Copy and Microsoft Software Shadow Copy Service Provider services.
  • Some of the commands that you will find useful when working with AppDisks are as follows

To get a list of all the active tasks running, run the below

>Get-AppLibTask -active $true

To stop a particular task, run the Get-AppLibTask and take a note of the task ID


The above stop command will not remove the failed task from the Studio console. to remove it completely from the studio, run the following command

  • In many cases, AppDisks work on different OSs. For example, you can add an AppDisk that was created on a Windows 7 VM to a Delivery Group containing Windows 2008 R2 machines, as long as both OSs have the same bitness (32 bit or 64 bit) and both support the application. However, Citrix recommends you do not add an AppDisk created on a later OS version (such as Windows 10) to a Delivery Group containing machines running an earlier OS version (such as Windows 7), because it might not work correctly.
  • Finally, the link here from Citrix is a MUST READ as it covers a lot of information on MCS type and PVS type deployments

Creation Process

  • Boot the reserved VM into the Maintenance environment and leave it at the login screen
  • Head to the Studio console and select the AppDisk node. Click Create AppDisk
  • Specify the size of the disk and a name of the AppDisk in the wizard.
  • As soon as the AppDisk creation begins, the VM will be restarted. Boot the VM back into the Maintenance vDisk
  • Now wait for the process to complete
  • In the mean time, you would be able to see a drive mapping with label (Citrix) being created on the VM with the specified disk size of the AppDisk (5 GB in my case)drive-map
  • Refresh the Studio console to ensure that the VM is powered ON and is
  • Be patient as this could take while to complete.
  • If the process gets stuck at “Creating…..” state, run the command
    Get-AppLibTask -active $true

    Check the value of TaskProgress and if it is at 95%, its time to restart the VM. studio

  • Once restarted, boot the machine back into the Maintenance disk
  • Ensure that the VM is registered. Login to the VDA now and make sure that the AV agent isnt running (I have seen that logging into the server helps speed up things)
  • The AppDisk creation process should now be complete.
  • Its time now to install the applications- Right click the AppDisk name and select Install Applications
  • Once you are happy with the app install, its time to seal the disk
  • Right click and select “Seal AppDisk”
  • When the sealing process is started, the VM will restart. Just ensure that the VM restarts back into the maintenance disk
  • Once the server is back up, log into the server to speed up the sealing process. if there are AV agents running, temporarily disable it
  • The VM will restart again
  • choose the maintenance disk again and boot into it
  • it is at this stage, it will start AppDNA disk analysis (assuming that you have AppDNA integration configured)importappdiskdna
  • Refresh the Studio now and you can see the Appdisk is at Ready(AppDNA:Capturing) state
  • Soon the process should complete. The AppDisk should now be ready for app delivery readystate
  • Head on to the PVS console and delete the Maintenance vDisk that was initially created for AppDisk . Once the AppDisk is sealed, you MUST boot into the vDisk version before the Maintenence version to be able to see the applications installed on the AppDisk. Strange but true 🙂
  • If you need to edit(add more apps) a Sealed Appdisk, create a fresh Maintenance vDisk and continue with the updates. The older Maintenance vDisks will not work once sealed and should be removed from PVS console (Versioning)


Assigning an AppDisk

As previously stated, AppDisks require a machine catalog that isnt assigned to any delivery groups. So naturally the first step after creating an AppDisk is to create a delivery group and attach the AppDisk to it.

Updating an AppDisk

  • Create a Maintenance vDisk from the PVS Console
  • Change the VM type to Maintenance in the PVS Console (Device Collections)
  • If the Prep machine is already a member of a Delivery group, remove it from the delivery group.
  • Boot the Prep VM into the Maintenance vDisk and leave it at the login screen
  • Go to AppDisk node in Citrix Studio and select the AppDisk that needs to be updated.
  • Choose Create New Version
  • Give it a name and select the Machine catalog name where the prep machine resides
  • Click Create New Version
  • At this point, it creates a Control Disk


  • The Prep VM will now restart. the next step is to “Reserve” the Virtual machine
  • Boot the VM back into the Maintenance vDisk


  • It then proceeds with the Layer creation and completes it. It would say ready to install applications in Studio
  • Proceed to install applications as you would normally do
  • Seal the Appdisks when completed.
  • Delete the Maintenance version from the PVS console and change the VM type to Production from Maintenance


Diagnosing issues with AppDisk

AppDisks come with a logging tool that could be found here at C:\Program Files\Citrix\personal vDisk\bin\CtxAppDisksDiag.exe

Run the above tool as an admin and select the folder where you would like to see the log files and click OK


Importing an AppDisk

There are times you will need to import a pre-created AppDisk to the Studio. This method will also work for the manually built virtual machines.

Carl Stalhood has detailed the process to import AppDisks in his blog post here

The curious case of NetScaler access with error message ” The Connection to “Desktop” failed with status (Unknown client error 1110)”

I was pulled into to look at a problem for one of our customers with their Netscalers which stopped the user connections intermittently throwing a very “helpful” error message ” the connection to the desktop failed with status (unknown client error 1110).

The customer description was “it only started to happen a few weeks ago and these days its quite impossible to land a successful connection from the outside of our corporate network”

I managed to get a couple of screenshots of error messages from the users and they appeared like below. When queried, the internal access via Storefront is working fine.


Looking at the error message, there are a multitude of reasons why you would get that and i am outlining the common areas to look in such cases.

  • Check if the Root certificates and intermediate certificates are available on the client devices. If frequently patched, the client will most probably have the latest and update Root CA’s from various public CAs. Check the IE’s / Other browsers’ certificate store to verify the Root and Intermediate CA SSL certs
  • If using non-IE browsers for connectivity, switch over to IE to see if it connects. IE is the safest bet when it comes to connectivity to Citrix environments.
  • Check for SSL ciphers attached to the NetScaler Gateway vServer. If high security ciphers are used, this issue may occur. relax the cipher suites to see if that makes a difference. Again, if cipher suites are an issue, the issue will occur every single time when you connect and not sporadically.
  • Check the STAs on the NetScaler and ensure that it matches with the STAs configured on the  WI/Storefront. This is one of the most important setting to check and probably the first one to check if the issue occurs only sporadically. There is a high possibility of an STA mismatch as it turned out to be in my case.
  • Check the FW from the NetScaler to the VDA – As the title says ensure that the Citrix ports to the VDA are open from the Netscaler