The Interactive Session metric recorded by Citrix Director has always confused those trying to investigate why logon times are so high.

In this post I’ll explain how you can cut Interactive Session time by more than 60% immediately. You can reduce the time to as little as 3 seconds. This allows Citrix Director logon time reporting to become much more accurate.

For more logon time reduction tips see http://www.jgspiers.com/citrix-director-reduce-logon-times/

What is Interactive Session Time?

From https://www.citrix.com/blogs/2016/08/19/interactive-session-of-logon-duration-in-citrix-director-explained/

It is the time taken to handoff keyboard and mouse control to the user after the profile of the user is loaded for a session.

Event ID 2 is initially logged on the VDA shortly after a desktop/application icon is clicked within Receiver client or Receiver for Web. This event triggers the Interactive Session timer which ends once Event 1000 is logged to indicate that the session is ready for use. Event ID 1000 is logged by the Citrix Profile Management service.

So whilst Director records logon times, it is important to understand that this is the time taken from clicking to launch a resource until the machine is actually usable even though the actual logon may have completed some time before that. This produces innacurate results in Director for true logon times.

The Interactive Session time is calculated once Event ID 1000 is logged on the VDA. The faster the UPM Event User Message runs the quicker Event 1000 is logged and the calculation is complete.

So ideally we want UPMEvent.exe (or UpmUserMsg.exe for VDAs prior to v7.7) to run once we see that desktop wallpaper as that is when the logon is complete. By default, it instead runs some time after the profile has loaded.

What is faster than startup applications specified within the Run key? A log on Scheduled Task.

Open your gold image or Citrix App Layering Platform Layer (the Platform Layer should contain your VDA software). Launch RegEdit and navigate to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Delete the Citrix UPM UserMsg string. Finalise the image.

Now using Group Policy, create a new GPO which applies to all users logging on to the VDA.

Within the GPO expand User Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks -> New -> Scheduled Task (At least Windows 7).

On the General tab specify a name. Keep the task running under %LogonDomain%\%LogonUser%. Set Configure for to Windows 7 or the highest available OS.

On the Triggers tab click New.

For Begin the task choose At log on and for Any user. Click OK.

On the Actions tab click New.

Under Action select Start a program. Under Program/script enter “C:\Program Files\Citrix\Virtual Desktop Agent\upmEvent” and beside Add arguments (optional) enter wait. Click OK.

Click OK to finish creating the Scheduled Task. When users log on to a VDA the UPMEvent.exe program launches via Scheduled Task immediately when the desktop shell has loaded.

With UPMevent.exe being started now by the Scheduled Task the average logon time has dropped to 13 seconds. Notice the Interactive Session times are all at 3 seconds, more than 50 seconds lower than a default XenDesktop 7.13 installation I ran my testing on. These results are on a non-persistent VDA which is rebooted between each logon.

Director is logging much truer logon times and our future reports will be much more accurate.

Note: In VDA versions before 7.7, upmEvent.exe was called upmUserMsg.exe.

The release of XenApp and XenDesktop 7.11 gives administrators the ability to publish various types of content to StoreFront that can be consumed directly by end-users. There was previously a similar feature in IMA versions of Citrix XenApp.

The type of content that can be published include:

• HTML web sites.
• Documents such as PDF, DOCX, JPEG, XLS from FTP servers, web servers or file servers.
• Directories on FTP servers.
• Directories on file servers.

Such content is published using the StoreFront PowerShell SDK at the current time and consumed either by using Receiver client or Receiver for Web. The option to publish content through the Studio GUI may come in a later release. You can also publish the same type of content using Citrix Clouds XenApp and XenDesktop Service.

To get started launch PowerShell, connect to a Delivery Controller and load the Citrix snap-ins. To add an HTML webpage as published content run command New-BrokerApplication -ApplicationType PublishedContent -Name YourAppName -CommandLineExecutable YourWebAddress -DesktopGroup YourDeliveryGroupName.

Once complete you’ll be presented with the PublishedContent application settings.

The Pulbished Content application will appear under Applications in Citrix Studio as normal. There are some properties you can change if you right-click on the application and select Properties.

You can specify keywords just like you can with any other published application.

You can change the web address later down the line if for example the address changes.

You can also limit the application to certain groups or users. By default what is set at the Delivery Group defines which users can access the application.

You’ll notice that by default the Published Content application is set with an icon. That icon will probably not be one you want to use going forward, but you cannot change the icon via the GUI. To change the application icon, you first need to upload the icon and then associate that icon with the Pulished Content application using PowerShell. To upload an icon click Add Applications.

Create a dummy application, before you finish adding the application click on Properties within the Applications screen.

Click on Delivery -> Change.

Check Choose an icon from a file on a representative machine and click Browse.

Browse for an add the icon of your choice. The icon can be in JPEG, PNG format for example as most pictures are.

Click OK.

Finish off adding the application by clicking Finish. Doing this will upload the icon to the Citrix site database.

Now you should delete the dummy application as it is no longer needed.

Launch PowerShell and run command Get-BrokerIcon | fl Uid. The highest Uid number will be the icon you just uploaded. In my case, Uid 8.

Since we now have the Uid number, run command Set-BrokerApplication -Name YourAppName -IconUid YourIconUidNumber.

Refresh Applications within Citrix Studio and your Published Content app will display the new icon.

Log on to StoreFront and you’ll also see the new Published Content application and desired icon. Click on the app to launch.

The application will launch within your own local browser and browse to the website you specified. If you want to add a document Published Content application run command New-BrokerApplication -ApplicationType PublishedContent -Name YourAppName -CommandLineExecutable \\yourshare\yourfile.extension -DesktopGroup YourDeliveryGroup.

If you want to add a share as Published Content run command New-BrokerApplication -ApplicationType PublishedContent -Name YourAppName -CommandLineExecutable \\yourshare -DesktopGroup YourDeliveryGroup.

Note: If you receive a Only HTTP and HTTPS URLs can be opened error when launching file shares from Citrix Receiver, enable the Receiver policy setting Allow/Prevent users to publish unsafe content. Download the latest Citrix Receiver ADMX files to view this setting within Group Policy.

This post covers several recommendations that increased by logon times by more than 75%, even on non-persistent machines where the user profile is not permanently cached.

♣ What is Interactive Session Time?
♣ My testing environment
♣ Non-optimised image vs optimised image – logon time results
♣ Serialize/StartupDelayInMSec – logon time results
♣ Autologon account/the second logon is quicker – logon time results
♣ UPMEvent – logon time results – Saving the best to last

Citrix Director is great at recording logon times per session and logon averages over periods of time. We can even produce logon reports and show them off to managers or other teams within the organisation to show them how good (or bad) the virtual workspace performs! Though without any effort you’ll likely be wowing everyone for the wrong reasons until you put in the background work to get logon times down to a low number. Citrix unfortunately doesn’t magically make logons quicker than any other desktop.

Many of the logon friendly optimisations and best practices out there today are straight forward and common sense and help to get you started:

• Keep GPOs at a minimum (don’t be GPO happy).
  • Keep close control of Group Policy incuding monitoring – http://www.jgspiers.com/audit-group-policy-changes/
• Don’t map tonnes of drives, especially to users who do not need them.
• Don’t map tonnes of printers. Joe who prints to two printers doesn’t need 13 printers mapped to his machine.
• Avoid using logon scripts, these are only going to add time to the logon.
• Move Group Policy settings to Citrix WEM.

There are more, and I’ll cover off some additional ones in this post to really reduce logon times. If you’re interested in some more tips, see http://www.jgspiers.com/citrix-tips-tricks-tweaks-suggestions/

Also, if you’re interested in finding out more about the logon process see http://www.jgspiers.com/digging-in-to-citrix-logon-process/

So you’ve performed all of the above and more, you’re timings tells you that logon times are no longer than 20 seconds. You look at Director and the logon times are double. Why? There is still one recorded metric that:

1. Not everyone knows what exactly it is and or struggles to understand it.
2. Takes a bit of work getting the metric value to reduce, although once you know what it does it’s easier to shave the seconds off.

That metric is: Interactive Session Time.

What is Interactive Session Time?

From https://www.citrix.com/blogs/2016/08/19/interactive-session-of-logon-duration-in-citrix-director-explained/

It is the time taken to handoff keyboard and mouse control to the user after the profile of the user is loaded for a session.

Event ID 2 is initially logged on the VDA shortly after the desktop/application icon is clicked within Receiver client or Receiver for Web. This event triggers the Interactive Session timer which ends once Event 1000 is logged to indicate that the session is ready for use. Event ID 1000 is logged by the Citrix Profile Management service.

So whilst Director records logon times, it is important to understand that this is the time taken from clicking to launch a resource until the machine is actually usable even though the actual logon may have completed some time before that. This produces innacurate results in Director for true logon times so let me show you how you can almost eliminate Interactive Session times, get overall logon times reduced and get Director logging much more accurate data.

My testing environment

For the following logon tests, I used XenDesktop 7.13, running PVS 7.13 and a 7.13 VDA configured with 2GB RAM and 2vCPU. The VDA runs Windows Server 2016 with no optimisations to start however as you will see later it does become optimised and improves logon times. The Target Device Write-Cache is configured as RAM w/overflow to HDD (which is on SSD storage).

Note: The following configurations can be applied to both Server and Desktop OS in persistent and non-persistent environments. You don’t have to implement all of them, consider each one individually. Logon times will also fluctuate based on factors such as load (busy periods), VDA performance and underlying hardware used.

Non-optimised image vs optimised image – logon time results

I built a brand new Windows Server 2016 VDA streaming from PVS. Nothing else was performed on the image. Logged on three times. The average logon time is 68 seconds. That time has advantages such as being able to go and make coffee or produce a logon time report from Director to show your boss, which probably won’t go down all that well. Add applications, larger profiles, Group Policies in to the mix and more seconds get added.

So I’ve gone and optimised my image using the Server 2016 optimisation script. You know optimising an image brings a great sense of satisfaction, not to mention the average time is now down to 38 seconds! That is 20 seconds shaven off just by optimising the image.  Notice also that the Interactive Session time has been greatly reduced, that is because the image is a lot more leaner and can get a session ready more quickly.

Serialize/StartupDelayInMSec – logon time results

It was blogged about here https://xenappblog.com/2016/optimize-logon-times/. Windows Server 2012 and Windows 8 introduced a startup delay for applications which has a negative effect on Interactive Session times. By disabling this delay we can start the applications immediately, not an issue if you have only a few. On the write-mode PVS/MCS gold image or Citrix App Layering OS Layer, launch RegEdit -> HKEY_USERS -> File -> Load Hive.

Load the default user hive by navigating to C:\Users\Default and double-clicking NTUSER.DAT.

Give the hive a name and click OK.

Within the hive navigate to SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer and create a new key called Serialize.

Create a new DWORD 32-bit value within the Serialize key.

Give the value a name of StartupDelayInMSec and a data value of 0x0.

Click File -> Unload Hive.

Click Yes. Finalise the image.

Note: You could have done this through Group Policy, but since it applies to all users we want to reduce the need for Group Policy processing and extra logon processing.

The results of this optimisation show logon time averages down to 27 seconds. An 11 second drop. Remember that each logon here is on a non-persistent machine. The machine is restarted between each logon so as to mimic a first-time session logon (post restart) to VDA where no profile is cached. These current logon times look a lot better and are good for a first-time logon after VDA restart.

Autologon account/the second logon is quicker – logon time results

When a VDA restarts as part of scheduled reboots for example or when non-persistent desktops reboot to reset, the first logon is generally always the longest. So I thought of the idea to use an auto-logon account to be the guinea pig and be the one who first logs on when a VDA restarts. This works well particularly in server OS since the autologon account when it logs off doesn’t trigger any sort of restart to the VDA.

You can use Autologon as pointed out by Chris in the comments. This tool easily configures an autologon account and encrypts the password. https://technet.microsoft.com/en-us/sysinternals/autologon.aspx

When launching autologon, enter the credentials to your autologon account and click Enable.

Click OK. The Winlogon Registry Key will be configured with DefaultUsername/DefaultDomainName string values and so on however the DefaultPassword will not be present and is encrypted.

Restart the VDA. If autologon does not work the first time run through the Autologon tool again and it should work on second attempt.

You can now configure the logoff procedure as described below.

For an alternative method of autologon (this section includes the autologoff procedure):

Open the gold PVS/MCS image again or the OS Layer (Citrix App Layering). On the C:\ drive, create a batch file and call it something like AutoLogon.bat.Within the batch file, enter the following:

call reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "DefaultPassword" /f
call logoff

Now open RegEdit and navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrrentVersion\Winlogon.

Set the AutoAdminLogon value to 1.

Set DefaultDomainName to your domain name as below.

Set DefaultUserName to a user account (service account) which has rights to log on to each VDA. This user account should be secured with a strong password and be a Domain User only. If this DefaultUserName REG_SZ string does not exist, create it.

Set DefaultPassword to the password of the autologon account. Click OK.

Right-click the Winlogon key and select Permissions.

Click Add. Search and add the autologon account.

Give Full Control permissions. This allows the autologon account to delete the DefaultPassword string after each logon. Finalise the image.

Now using Group Policy, create a GPO which is filtered to the autologon account as below. Edit the Group Policy obejct.

Expand User Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks -> New -> Scheduled Task (At least Windows 7).

Under General specify a name. Specify Run only when user is logged on and run the task under the autologon account. For Configure for choose Windows 7 or the highest possible OS.

On the Triggers tab click New.

For Begin the task choose At log on. Check Specific user or group and select the autologon account. Click OK.

On the Actions tab click New.

For Action choose Start a program. Under Program/script enter the path of your batch file which resides on the gold image. Click OK.

Your scheduled task is now created.

Now when the VDA boots up, an autologon occurs. The Scheduled Task runs a batch file which deletes the DefaultPassword string immediately for security and then logs off. The machine is then ready for real user logons.

As a result, the average logon time has dropped to 20 seconds. A 7 second drop. Interactive Session times are a lot lower than when we started these optimisations, over a 40 reduction!

UPMEvent – logon time results – Saving the best to last

If you had implemented what I am about to show you first, you probably could have cut Interactive Session time by more than 60% immediately.

The Interactive Session time is calculated once Event ID 1000 is logged on the VDA. The faster UPMEvent.exe runs the quicker Event 1000 is logged and the calculation is complete.

So ideally we want the UPMEvent.exe to run once we see that desktop wallpaper screen as that is when the logon is complete. By default, it instead runs some time after the profile has loaded.

The StartupDelayInMSec key added earlier simply speeds up when run keys (startup applications) are started. Hence why the Interactive Session time is decreased becaue UPMEvent.exe is started quicker since we removed the startup delay.

So what is faster than startup applications specified within run? A log on Scheduled Task.

Open your gold image or Citrix App Layering Platform Layer (the Platform Layer should contain your VDA). Launch RegEdit and navigate to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Delete the Citrix UPM UserMsg string. Finalise the image.

Now using Group Policy, create a new GPO which applies to all users logging on to the VDA.

Within the GPO expand User Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks -> New -> Scheduled Task (At least Windows 7).

On the General tab specify a name. Keep the task running under %LogonDomain%\%LogonUser%. Set Configure for to Windows 7 or the highest available OS.

On the Triggers tab click New.

For Begin the task choose At log on and for Any user. Click OK.

On the Actions tab click New.

Under Action select Start a program. Under Program/script enter “C:\Program Files\Citrix\Virtual Desktop Agent\upmEvent” and beside Add arguments (optional) enter wait. Click OK.

Click OK to finish creating the Scheduled Task. Now UPMEvent.exe will be run by the Scheduled Task immediately when the desktop shell has loaded.

With UPMEvent.exe being ran now by the Scheduled Task the average logon time has dropped to 13 seconds. A further 7 second drop. Notice the Interactive Session times are all at 3 seconds, more than 50 seconds lower than when we first started. Director is logging true logon times and our future reports will be much more accurate.

Note: In VDA versions before 7.7, upmEvent was called upmUserMsg.

If you are upgrading or installing the Desktop or Server VDA and getting either of the below error messages then read on.

Installation of MSI File ‘IcaTS_x64.msi’ failed with code ‘InstallFailure’ (1603).

Installation of MSI File ‘IcaWS_x64.msi’ failed with code ‘InstallFailure’ (1603).

I recently got this message when upgrading the VDA within a Citrix Platform Layer (Citrix App Layering). In this example, access to read the LoggedEvents registry key was denied.

Upon receving the error message, click on Why did this fail?

Confirm the error relates to the installation of IcaTS_x64.msi or IcaWS_x64.msi.

Go to Event Viewer. Within the Application log you’ll see why exactly the install failed. Notice that the LoggedEvents key could not be opened.

Open RegEdit and browse to the key manually (HKLM\Software\WOW6432Node\Euem\LoggedEvents). You’ll get an Access is denied error.

Right-click the Euem key and select Permissions.

Click Advanced.

Check Replace all child object permission entries with inheritable permission entries from this object -> Apply.

Click Yes. If you get an error, set yourself as the owner of the LoggedEvents key and re-run the above steps. 

Now you’ll be able to read the key, and install the VDA.

If you are getting the 1603 installation error due to a different issue than what is described above, try these three possible fixes:

• Run the VDA cleanup utility
  • https://support.citrix.com/article/CTX209255

• Reset performance counters
  1. Open CMD as an administrator
  2. Run command lodctr.exe /R
  3. Restart the machine

• Rebuild WMI repository
  1. Open CMD as an administrator
  2. Run command sc config winmgmt start=disabled
  3. Run command net stop winmgmt
  4. Run command winmgmt /salvagerepository %windir%\System32\wbem
  5. Run command winmgmt /resetrepository %windir%\System32\wbem
  6. Run command sc config winmgmt start=auto
  7. Restart the machine

Version 4.8 of Citrix Receiver for Windows comes with automatic update functionality which is enabled by default. There are a couple of different ways to control the behaviour of the auto-update feature.

Note: Receiver for Mac 12.6 also has the auto-update ability.

There may be times when you want to disable auto-update, especially on clients where Skype for Business is used with the RealTime Optimization Pack. Since RTME is installed on the client, this component may auto-update and become newer than the RealTime Connector with the risk of cleints entering into fallback mode. For more information see http://www.jgspiers.com/skype-for-business-xenapp-xendesktop/

You may also want to use auto-update but adjust the default behaviour. The ways of configuring auto-update related settings is described below.

Things to note

• Outbound proxies must be configured with an exception to the Receiver auto-update Signature service https://citrixupdates.cloud.com and the download location https://downloadplugins.citrix.com
• By default auto-update is disabled on Session Host, Remote PC and VDI VDA machines.
• Auto-update is disabled on machines that have Desktop Lock installed.
• Machines must be connected to the internet for auto-update to work
• Receiver for Web users cannot download the StoreFront policy automatically. You have to add or refresh the StoreFront account manually through Receiver.

The first method is GPOs. Download the Receiver for Windows ADMX templates from Citrix and import them on to your Domain Controllers. Edit/create a GPO and navigate to Computer Configuration -> Policies -> Administrative Templates -> Citrix Components -> Citrix Receiver -> AutoUpdate. You have two configurable settings.

The first setting Set the Delay in Checking for Update can be set to Fast, Medium or Slow. This allows for staged upgrade rollouts.

The second setting Enable or Disable AutoUpdate Policy is used to set auto-update to disabled, auto (default) or manual (user checks manually for updates). You can also specify if only LTSR Receiver versions are offered for upgrade and set a defer count. The defer count can be set as a value of -1 to 30. -1 means no limit is set on the amount of defers a user can perform. A value of 3 would allow 3 maximum defers for example. A value of 0 means the remind me later option is not displayed.

The second method is to disable auto-update via command line when installing Receiver. A couple of new switches exist to control the behaviour of the auto-update feature.

• /AutoUpdateCheck – Configure auto-update to be on, off or manual. Values accepted are AUTO, MANUAL and DISABLED.
• /AutoUpdateStream – Control if auto-updates are for LTSR versions only or Current Release versions. Values accepted are LTSR or Current.
• /DeferUpdateCount – Allows you to specify the number of times you can defer an update notification. Values accepted are -1 to 30. -1 means the user can defer any number of times.
• /AURolloutPriority – Specify the speed of which a rollout of an upgrade will be performed. Values accepted are Auto, Fast, Medum and Slow.

For more information on a command line install of Receiver for Windows see http://www.jgspiers.com/command-line-install-citrix-receiver-for-windows/

The third option is using Preferences. This setting is per-user and user defined settings will be written to HKCU. Right-click on Receiver and click Advanced Preferences.

Click on Auto Update.

Choose your desired setting.

The fourth option is using StoreFront by modifying the web.config file found in wwwroot\Citrix\Roaming.       Find the text beginning <account id. Scroll down a couple of lines until you see:

<properties>

<clear />

</properties>

Enter lines as below, modifying to suit your needs.

The fifth option is using CitrixReceiverUpdater.exe after Citrix Receiver has been installed. CitrixReceiverUpdater.exe can be found in %ReceiverInstallLocation%\Citrix\ICA Client\Receiver.

This script documents Workspace Environment Management configuration settings into a single easy to read HTML file.

Script author: James Kindon @james_kindon

Contributions made by: George Spiers @JGSpiers

Tested working on OS version: Windows Server 2016, Windows Server 2012 R2, Windows 10 (although not officially supported).

Tested working on SQL version: SQL Server 2016, SQL Server 2014.

Tested working on WEM version: WEM 4.3, WEM 4.2.

Description: This script collects all the configured settings within Workspace Environment Management and formats them in to a easy to read HTML file.

Note: This script does not perform any writes to the WEM database.

Instructions: To avoid failure, run PowerShell as an administrator. The user account you use (SQL or Windows Authentication) must be able to connect to the WEM database and Read/Query the database. This could be the SQL vuemUser account or WEM Broker account.

Requirements: This script attempts to detect and install Windows Management Framework 5.0 if SQL Management Studio and SSMO modules are not present on the machine you are running this script from. If SQL Management Studio is installed then the modules provided by SSMO are used. If not, WMF 5.0 is installed. The installation of WMF 5.0 has been successfully tested on Windows Server 2012 R2 and Windows Server 2016. Windows 10 is not supported. To install WMF 5.0 you must have a connection to the internet on the machine you are using to run this script. If you do not have a connection to the internet, download from another machine that does and install this software manually.

For more information on Workspace Environment Management see http://www.jgspiers.com/citrix-workspace-environment-manager/

Download (click below):

WEM Document Script (18 downloads)

An overview of Citrix Smart Tools, one of the Citrix Cloud services previously known as Citrix Lifecycle Management. This services allows you to automatically provision, manage and monitor Citrix workloads running on private and public clouds.

♣ Citrix Cloud Status Portal
♣ Citrix Smart Tools Portal
♣ Licenses
♣ Smart Tools Agents
♣ What information does Smart Tools have on your site?
♣ Add users (administrators) to Smart Tools
♣ Create a Resource Location (Hyper-V) and install the Smart Tools Connector Agent (example)
♣ Enrol site to Smart Tools when installing Delivery Controller (7.14+)
♣ Citrix Smart Build

• ♣ Smart Build: Automated deployment of Citrix XenDesktop farm (example)
• ♣ Create a template machine for Blueprint deployment
• ♣ Pausing or retrying failed Blueprint deployment steps
• ♣ Troubleshooting a failed Blueprint Deployment
• ♣ How to delete a Deployment Profile:

♣ Citrix Smart Check

• ♣ How does Smart Check work?
• ♣ What data does Smart Check collect?
• ♣ Smart Check System Requirements
• ♣ What checks does Smart Check perform?
• ♣ Add Site to Smart Check
• ♣ Smart Check Schedules
• ♣ Upload Site Diagnostics to CIS via Smart Check
• ♣ Install Smart Tools Site Agent on Multiple Delivery Controllers
• ♣ Remove Site from Smart Check
• ♣ Smart Check Log Files

♣ Citrix Smart Migrate
♣ Citrix Smart Scale

• ♣ Smart Scale Requirements
• ♣ Add Site to Smart Scale
• ♣ Create Smart Scale schedules and load scaling
• ♣ Enable/Disable Smart Scale error event notifications
• ♣ Remove Site from Smart Scale
• ♣ Troubleshoot Smart Scale

Smart Tools consists of the following features to date (July 2017):

• Smart Build – Allows you to automate Citrix deployments on-premise or in the cloud using blueprints that are created by you or by way of pre-built templates.
  • Templates exist for XenApp, XenDesktop, Secure Browser, NetScaler, Active Directory and XenMobile.
  • Everyone gets rights to deploy pre-configured blueprints to their resource location.
• Smart Migrate – Assists with the migration from XenApp 6.x to XenApp or XenDesktop 7.x. Includes assistance for migrating applications, desktops and policies.
• Smart Check (new and currently in preview) – Provides health monitoring for your Citrix envrionment.
  • You get notifications about recommended fixes and issues found in your environment during regular health checks and health check reports.
  • Manage updates to your environment including which updates are pushed out and when.
• Smart Scale – Usage and schedule based scaling on-premise or in the cloud helps to ensure that machines especially in the Cloud are only running when they are needed to avoid charges. You control resource availability and capacity during peak and off-peak times.
  • Smart Scale can run on Azure and AWS, or on-premise.

Note: For a list of what’s new to the Citrix Smart Tools suite, see https://manage-docs.citrix.com/hc/en-us/articles/212715303-What-s-new

The Citrix Cloud Status Portal

The status of all Citrix Cloud services and in our interest Smart Tools can be found at http://status.cloud.com/ – This is a live page that updates in real-time.

You have the option of subscribing to all alerts or specific ones by email, SMS, slack, or by other webhooks.

The Citrix Smart Tools Portal:

You’ll see a number of tabs when logged on to the portal:

• Resources & Settings – Shows existing and allows you to add additional Resource Locations. Allows you to edit administrator roles.
• Blueprint Catalog – A catalog of Blueprints which you can search for and add to your library.
• Smart Build – From here you kick off the deployment of Blueprints. You can also create new Blueprints, edit existing ones, create scripts, share or clone Blueprints, add your your own custom alerts to the Smart Check Alerts Database. This is where your Library is located. If you are a member of multiple Citrix Smart Tools accounts, you’ll have a library for each account.
• Manage – This tab allows you to manage deployments and servers that have been provisioned to your Resource Location during Blueprint deployment. You can also scale deployments or tear them down.
• Smart Migrate – Provides assistance in migrating application and policy settings from XenApp 6.x or VDI in a box 5.4 to XenApp or XenDesktop 7.x.
• Smart Check – From here you can view existing sites, or add new Citrix sites. You can upload site diagnostic data to Citrix Insight Services, perform health checks for example site checks or apps and desktops health checks, perform update checks, perform LTSR checks (Preview) and and view health reports.
• Smart Scale – Enable scaling. Define if you want to scale based on schedule, based on load or both. You can specify to scale based on the Load Index of VDAs or based on session count. Create schedules and more.

Licenses:

The Smart Tools features (Smart Build, Migrate, Check, Scale) are available for:

• XenApp and XenDesktop service customers are entitled to all tools.
• Citrix Workspace service customers are entitled to all tools.
• XenApp/XenDesktop customers with Customer Success Services – Select (previously Software Maintenance) are entitled however only Platinum customers are entitled to Smart Scale.
• XenMobile customers with Customer Success Services – Select (previously Software Maintenance) are entitled to everything but Smart Build.
• NetScaler customers with Customer Success Services – Select (previously Software Maintenance) are entitled to everything but Smart Build.
• Citrix partners are entitled to the tools.

Smart Tools Agents:

There are a couple of different agent types available. Agents can be installed automatically during Blueprint deplyoment or manually on machines that already exist in your Resource Location that you now want Smart Tools to manage. You can also install the agent manually at the end of a 7.14+ Delivery Controller installation (more on that later).

• Smart Tools Agent – Can be installed manually or automatically when Blueprints provision machines. If installed manually, you add the machine to Smart Tools afterwards. The agent is there to perform configuration tasks such as installing SQL, installing XenDesktop, creating a Citrix Site, perfoming scaling activies, data gathering and so on.
• Smart Tools Connector Agent (Connector) – When you create a Resource Location, you manually install a Smart Tools Agent on machines in your Resource Location and then promote those machines to Connectors. Machines that are designated as a Connector will broker communication from Citrix Cloud/Smart Tools to your Resource Location. If you have multiple Resource Locations for example XenServer and vSphere, a Connector on XenServer can act as the Connector for the vSphere environment also providing the connector can communicate with machines from both Resource Locations. If you have a Resource Location that is accessible from the Internet, you don’t need a Connector.
• Smart Tools Site Agent – This type of Connector is installed on one or more (for high availability) Delivery Controllers in your site. One agent will always be active on a Controller in a Citrix Site and others will be passive. The Site Agent allows Citrix Smart Tools to monitor the Citrix Site performing health checks, searching for applicable updates and scaling the environment.

The Smart Tools Agent can be installed on Windows 7 through to Windows 10 desktop OS (excluding Windows 8.1) or Windows Server 2008 through to Windows Server 2016 server OS. It can also be installed on a mixture of Linux OS.

When a Blueprint installs Smart Tools Agent, port 22 (SSH) should be open on Linux devices and TCP port 3389 (RDP) on Windows devices. These ports must be open to facilitate agent deployment but can be closed once the blueprint deployment is complete. HTTPS port 443 is used for communication to Citrix Cloud thereafter.

Note: There have been some instances where Windows UAC has caused agent installs to fail. If you encounter a Failed to install agent error during blueprint deployment try disabling UAC on the template VM before.

If an Agent stops communicating with Smart Tools after a reboot, check to make sure the Smart Tools Agent Service is running. If it is, restart it and then check if communication is restored.

What information does Smart Tools have on your site?

Communication always flows from the Connector Agent on your Resource Location to Citrix Cloud. Because all machines reside in your Resource Location, Citrix Cloud does not store any sensitive data on their side. Smart Tools does however store the following information:

• Delivery Group and Machine Catalog GUIDs and names.
• Master VM names.
• Delivery Controller FQDNs, product version and IP addresses.
• VDA DNS names, UUIDs, the Load Index, Maintenance Mode status and power state of VMs to perform power management duties via Smart Scale.
• Site data uploaded to CIS by the customer through Call Home in XenApp and XenDesktop, Smart Check or through Citrix Scout.

The above data is stored in separate database instances for each customer.

The Citrix Cloud and Smart Tools service also stores other information, including passwords and usernames for authentication to Citrix Cloud, access to Resource Locations such as AWS and deployment of Blueprints to your Resource Location.

• Citrix Cloud credentials – The credentials you use to authenticate to Citrix Cloud are sent to the Citrix Online system. This process generates a one-time signed JSON Web Token and grants access to Smart Tools using this token.
• Resource Location Passwords and Secret Keys – Passwords (for on-premise) and Secret Keys (for cloud) needed for authentication to Resource Locations are stored, encrypted and salted in the Citrix Cloud service database. Citrix own the keys used to encrypt these credentials. After a customer enters a password or secret key through the Smart Tools portal, the password or key is masked and cannot be rendered in plain text.
• Credentials used in Blueprints – Blueprints can store credentials as an input parameter. These credentials are stored, encrypted and salted in the Citrix Cloud service database. Citrix own the keys used to encrypt these credentials.
• Citrix Site Administrator credentials – If you use Smart Scale and/or Smart Check on your Citrix Site, you are required to provide credentials to a Citrix Full Administrator account from that site. This allows Smart Tools to perform health checks, perform scaling actions and apply fixes and updates to Delivery Controllers and Machine Catalogs on your behalf. These credentials are stored, encrypted and salted in the Citrix Cloud service database. Citrix owns the keys used to encrypt these credentials. After a customer enters the password through the Smart Tools portal, the password is masked and canot be rendered in plain text.
• AWS key pairs – If AWS EC2 is one of your Resource Locations, Smart Tools prompts you to create a key pair if one does not exist. This key pair enables you to access any Smart Tools Blueprint provisioned resource. The public key is stored in your AWS account while the private key is managed by the customer and should be kept somewhere safe. Smart Tools does not store the private key.
• Machine image credentials – When deploying a Blueprint, the local administrator credentials you supply from the image template are stored in Citrix Cloud if you create a Deployment Profile. Smart Tools stores these credentials in a separate database instance for each customer. All encryption used by Citrix use standard-based encryption algorithms.

Note: Note that whilst some operations require credentials or keys, you do have the option of provisioning your own machines and using existing machines in the Resource Location when deploying Blueprints. Using existing machines will reduce the need to supply such information to Smart Tools if you prefer. Make sure each machine has the Smart Tools Agent installed before deploying a Blueprint. To download the Agent, visit Resources & Settings, begin to add a Resource Location but after downloading the Agent, cancel the Resource Location creation.

Adding users to Smart Tools

Firstly navigate to Identity and Access Management and then invite users of your choice. If invited users do not have a Citrix Cloud account they will be asked to create one.

Type an email address and then click Invite. You can integrate Citrix Smart Tools with Azure AD. In this case you would have the ability to invite other Active Directory users. For a how-to see http://www.jgspiers.com/azure-active-directory-authentication-citrix-cloud/

Once the invited user has signed up to Citrix Cloud they will be given the Admin role in Smart Tools. To change this, within Smart Tools navigate to Resources & Settings -> Users -> select a user and under Actions click Edit.

From there select the role of Admin, Architect or Operator. Click Save.

To remove a user from Citrix Cloud, navigate back to Identity and Access Management.

Create a Resource Location (Hyper-V) and install the Smart Tools Connector Agent (example):

As mentioned before, a number of pre-created templates (Blueprints) are available from Citrix Cloud that you can use to deploy full Citrix farms among other deployments. If a pre-created template doesn’t suit, you can customise it or create your own. In this example, I’ll show you how to configure a Deployment Profile, and use a pre-created Blueprint to deploy a fully configured Citrix farm. The farm consists of one VDA and one StoreFront/DDC bundled together server.

Log on to Citrix Cloud and under Smart Tools click Manage.

You’ll first need to deploy a Resource Location. The Resource Location is where your VDA and Citrix infrastructure servers will reside. The Resource Location can be on public (Azure/AWS) clouds or private clouds running Hyper-V, XenServer or vSphere. You can have multiple Resource Locations.

Click on Resources & Settings.

Click Add Resource Location.

Check your hypervisor or cloud. In my case, Hyper-V.

Click on Next.

Click Download Agent. This downloads the Smart Tools Agent which you install on a dedicated machine within your resource location which will act as the connector. For high availability deploy pairs. These machines being connectors will broker communication from Citrix Cloud/Smart Tools to your Resource Location over HTTPS.

If you have multiple Resource Locations for example XenServer and vSphere, a connector on XenServer can act as the connector for the vSphere environment also providing it can communicate with machines in both Resource Locations.

The Smart Tools Agent can be installed on Windows 7 through to Windows 10 desktop OS (excluding Windows 8.1) or Windows Server 2008 through to Windows Server 2016 server OS. It can also be installed on a mixture of Linux OS.

Note: Also keep in mind that every machine the Citrix Cloud Smart Tools service has management over (machines deployed via Blueprints or manually added) will have a copy of the Smart Tools Agent installed. The agent is there to perform configuration tasks such as installing SQL, installing XenDesktop, creating a Citrix Site, running health checks for monitoring, gathering information and so on.

The installation instructions and requirements will be displayed. Along with a Waiting for you to install the Agent message.

Within your Resource Location, on a connector machine, launch CitrixLifecycleManagementAgent.exe

Accept the License Agreement and click Install.

Click Finish.

A log file is produced in case you need it. Return to the Citrix Cloud portal.

At this stage Smart Tools should detect that a connector agent has been installed. You can now click Next.

The new machine displays. To make it a connector, click on Use Selected Machine as Connector. A couple of additional scripts will be ran on the selected machine to promote it to a connector.

Making machine a connector. Please wait displays.

Once done enter Resource Location information. This includes a host (can be a connection to System Center Virtual Machine Manager/vCenter for example) or single host. Enter a username/password and domain name for an account that has permissions to manage the Resource Location. Click Add.

Once the Resource Location has been added, click Done.

The Resource Location will always appear as below and can be edited. You can also add additional locations.

Enrolling site to Smart Tools when installing Delivery Controller (7.14+):

When installing a 7.14 or newer Delivery Controller, you are offered the option of joining Smart Tools at the end of the installation. This installs the Smart Tools Site agent and is not the same as the Site Agent connector you just installed previously when creating a Resource Location.

Before connecting to Smart Tools, disable IE ESC (IE Enhanced Security Configuration) for users and administrators via Server Manager. Once the Delivery Controller is connected to Smart Tools it is recommended to turn IE ESC back on.

Select I want to connect to Smart Tools and Call Home. (Recommended) and click Connect.

Enter your Citrix Cloud credentials and click Sign In.

Once you see the success message, click Next. Finish the Delivery Controller install as normal, the site should now appear in Smart Tools.

Citrix Smart Build:

Using “Blueprints”, Smart Build allows you to automate the deployment and configuration of XenApp/XenDesktop etc. to various Resource Locations of your choice.

Smart Build: Automated deployment of Citrix XenDesktop farm (example):

Now that we have a Resource Location, we want to build out a Citrix XenDesktop Site. To do that we use Blueprints either created by ourselves or via a pre-created template. In this example, I’ll use a simple PoC pre-created Blueprint. Click on Blueprint Catalog and then choose the + symbol next to the Blueprint you want to use. From here forward the guide will reference the (Existing Domain) XenApp and XenDesktop Proof of Concept Blueprint created by Citrix.

You’ll get a message indicating that the Blueprint has been added to your library.

Note: If a new update of a Blueprint is released, Smart Tools displauys an indicator so that you can update the existing Blueprint to the newer version.

To access your library click Smart Build. To start a deployment using the newly added Blueprint click Actions -> Deploy.

Click Start deployment setup.

Enter a Deployment Name. You won’t have any created Deployment Profiles yet however during the next steps you do create one which can also be used in future deployments. Click Next.

Select the Resource Location where you want to deploy to. The Resource Location you choose must be supported by the Blueprint you are deploying. Click Next.

You have the option to configure NetScaler as part of the deployment. Something I am not going to do at this time. Click Next.

A number of pre-deployment checklist points will be displayed to help you prepare for the deployment.

Also the recommended hardware specs for each machine you are deploying will be displayed.

During the deployment, the machines created by the Blueprint are built off a template disk(s) that you create. On your Resource Location, you create a template virtual machine and configure it as per the requirements listed below for Hyper-V. This includes:

• Patching the image with the latest updates.
• Ensuring the WMI service is enabled and started.
• Ensuring outbound connections on TCP 443 are possible.
• Allowing inbound WMI traffic through Windows firewall.
• Ensuring the Hyper-V Integration Services are installed on the machine. Ensuring a local administrator account is created with a password that does not prompt for change on next log on.

As with any automated deployment, a number of parameters are needed for the configuration piece. Using the Export parameter list (.csv) option allows you to fill out any parameters in to CSV format and upload them to the deployment wizard. Instead I will define the parameters during the wizard manually. Before clicking Continue on the wizard, let’s create a template machine.

Create a template machine for Blueprint deployment:

Over on your Resource Location, create a template machine using hardware configurations of your choice. Later in the deployment you’ll be able to choose the hardware specifications for each machine the Blueprint deploys. Also make sure to patch Windows with the latest updates. You can use seperate templates for DDC and VDA if you wish. In my example, I am using a Windows Server 2012 R2 image for both machines.

An example where you would have two is if you are using a different OS for your VDAs, or you want the blueprint to deploy applications on your behalf to Delivery Groups. This would require you install applications on the VDA template machine.

Note: Do not install the Smart Tools Agent on the machine. The Agent is deployed automatically during Blueprint deployment.

Make sure the local admininstrator account is not set to change password at next logon. Also do not join the machine to your domain.

Make sure the Windows Management Instrumentation service is running and automatic.

Check that the Hyper-V Integration Services component is installed and up-to-date. Also make sure the services are up and running.

Launch Windows Firewall with Advanced Security and right-click Inbound Rules -> New Rule.

Under Predefined select Windows Management Instrumentation (WMI). Click Next.

Check all three rules and click Next. The rules already exist but they are disabled. Completing this wizard will enable them for you.

Click Finish.

If you don’t want to run through the wizard, highlight all three rules and right-click then select Enable Rule. Allowing WMI traffic through the firewall allows the Smart Tools Agent to install.

Make sure you have an unattend file created. As an example, the file I used is below.

Example unattend file:

language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
            </OOBE>
            <UserAccounts>
                <AdministratorPassword>
                    <Value>TABpAHYAZQByAHAAbwBvAGwAMAAxAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAUABhAHMAcwB3AG8AcgBkAA==</Value>
                    <PlainText>false</PlainText>
                </AdministratorPassword>
            </UserAccounts>
        </component>
    </settings>
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <ProductKey>D2N9P-3P6X9-2R39C-7RTCD-MDVJX</ProductKey>
        </component>
    </settings>
    <cpi:offlineImage cpi:source="wim:c:/users/g_liv/downloads/install.wim#Windows Server 2012 R2 SERVERSTANDARD" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

Open CMD and change directory to C:\Windows\System32\Sysprep. Run command sysprep /generalize /oobe /shutdown /mode:vm /unattend:c:\unattend.xml. At this stage unattend.xml file will be copied to the C:\Windows\Panther directory, the machine will be sysprepped and shut down. Return back to the Citrix Cloud portal.

Now you can click Continue.

On the scaling screen nothing can be changed when using this Blueprint because the functionality to change has been disabled on this Blueprint. You can edit the Blueprint as previously mentioned to further suit your requirements. Click Next.

Under XenDesktop Delivery Controller choose the Resource Location you had created earlier.

Specify a computer name for the Delivery Controller. Click Next.

Now you have to specify the location to your template virtual disk (.vhd) file that has been prepared for imaging. The Blueprint deployment will make copies of this disk when creating the DDC and VDA. By default copies of this disk will also be stored on E:\ however you can use the Edit button to change this location to elsewhere. Once you have filled out your VHD location, click Get Disk Info. If the disk is found, you’ll be displayed with disk specific information such as Disk Type, Disk Size, Disk Format. Click Next.

Here you get to configure the machine system hardware and a static IP if desired. Obviously a static IP is a must for the Delivery Controller so enter the required information and click Next.

As mentioned before, any machine deployed by a Blueprint will receive an install of the Citrix Smart Tools Agent so that it can be managed. You can see the checkbox towards the top states that an agent will be installed. Enter credentials to the local administrator account of the template machine and click Next.

Review your configuration information and click Finish.

Now you have to perform the same steps for the VDA machine.  Select your Resource Location. As you can probably tell, it is possible to deploy machines to multiple Resource Locations.

Enter the VDA machine name, click Next.

Enter disk information, click Next.

Enter hardware specification, select DHCP. Click Next.

Enter local administrator credentials. Click Next.

Click Finish.

Click Next.

There are some more configuration parameters needing entered before we can start the depoyment.

• Fill out the IP of a Domain Controller.
• FQDN of domain name.
• Administrator account that has the privileges to install XenDesktop on the VDA/DDC and join those machines to the domain.
• XenDesktop site name.
• Computer name for the DDC.
• ISO location of XenDesktop 7.13/7.14 media.

You may also need to enter credentials if you use a CIFS share. Finally the remaining field allow you to change the ComputerName, create a VDI server desktop and change the PowerShell Execution Policy.

The execution policy can be changed on your server VDA to one of the following values. I will leave all values at default. Click Next.

You’ll be asked to specify a Deployment Profile name and to save it. This profile can be used to redeploy this Blueprint at a later time. You don’t have to save it. Enter a name, description and click Save.

Now click Deploy.

As the Blueprint deploys, you’ll see a number of deployment steps being performed containing valueable information. Click each step and you can view the Step Details and Step Output. In this example, the initial task involves making a copy of the template machine disk to accomodate deploying our Delivery Controller.

The Delivery Controller will be created over on your Resource Location, with the disk attached and hardware configuration complete.

The machine goes through a number of configuration steps, one involving the installation of the Smart Tools Agent on to the Delivery Controller. 

As you can see here the Delivery Controller was renamed to BPDDC01. That step took 21 seconds.

The Step Output tab shows the old machine name and the new machine name.

Reboots are a frequent step in the deployment process. Here you can see a reboot and check for successful reboot occuring.

The machine goes through a number other configuration steps such as the configuration of DNS settings and joining to the domain.

Once the machine is ready for a XenDesktop install, the ISO is copied from the share you provided earlier to the machine locally in C:\Installers.

Just to confirm, the XenDesktop 7.13 media shows under the Installers folder on the DDC that is being deployed by Smart Build.

After a number of steps, the Delivery Controller install is complete, a SQL instance (in this case SQL Express) is installed and a Citrix site created along with the require databases. The XenDesktop Delivery Controller machine has at this stage finished installing and is configured with a XenDesktop Site. Next up is the install and configuration of the VDA, it goes through a number of the same steps so I’ll not repeat any of that process.

Once the VDA is complete, the deployment will return as complete. You can now perform a quick check to make sure everything looks OK.

Here are the two machines the Blueprint deployed, showing the correct amount of memory.

Launching Citrix Studio on the Delivery Controller, you can see a BPPOCSite was created (that name was specified in the Deployment Profile) and that a Delivery Group has been created.

Inside the Delivery Group is the VDA, registered successfully.

In this example StoreFront is also installed on the Delivey Controller and an HTTP store created.

To confirm connections can be made, connect to Receiver for Web and check you can successfully launch a desktop.

Pausing or retrying failed Blueprint deployment steps:

If your Blueprint fails at any step, you might want to pause the deployment to correct or retry the same step again. This is just a case of telling the Blueprint what action you want it to take on failure. Navigate to Smart Build, click Actions on your desired Blueprint and click Edit.

Now under Options click on the On failure drop-down box to select your desired outcome. During the deployment you will have more options on how you wish to proceed based on the On failure option you choose.

Troubleshooting a failed Blueprint Deployment:

Citrix have published a number of tips to diagnose deployment issues. See https://manage-docs.citrix.com/hc/en-us/articles/212715043-Troubleshoot-blueprint-deployment-issues

How to delete a Deployment Profile:

To delete a Deployment Profile, click Smart Build and start to deploy a Blueprint until the stage where it asks you if you want to use an existing Deployment Profile. Click the drop-down and click X beside the Deployment Profile you want to delete.

Citrix Smart Check:

Smart Check is a new Smart Tools product that is currently in preview. From a high level Smart Check provides health monitoring for your Citrix environment.

• You get notifications about recommended fixes and issues found in your environment during regular health checks and health check reports.
• Smart Check can manage updates to your environment including which updates are pushed out and when.
• You can schedule a range of health checks, which are then ran automatically.
• View health reports for your Citrix sites and upload diagnostic data to Citrix Insight Services.

How does Smart Check work?:

Smart Check works by running one or more collectors on Delivery Controller(s) within your Resource Location. A collector is no more than a script or tool mostly run within PowerShell which is run by the Smart Tools Agent. The data collected in this step is formatted mostly in JSON files but at times XML files and then uploaded to Citrix Insight Services for analysis. Based on the analysis results, alerts may be generated for a number of conditions.

What data does Smart Check collect?:

JSON files that are generated by Smart Checks are very small in size containing little data other than information to identify your Site, the issues that have been alerted and the names of affected VDAs.

For example the Apps and Desktops Health Check gathers your version of XenApp/XenDesktop, the Site name, any affected VDAs including name, OS version and what errors exist on those VDAs.

Smart Check System Requirements:

Smart Check is supported on the following platforms:

• XenApp and XenDesktop 7.6 LTSR and 7.11.
• XenApp and XenDesktop deployments running on:
  • Azure ARM.
  • AWS.
  • XenServer 6.2 -> 7.1.
  • VMware vSphere 5.1, 5.5 and 6.0.
• Machine Catalogs that use MCS.
• Smart Check is not supported on deployments that use the XenApp and XenDesktop Service in Citrix Cloud.
• To use Smart Check, Delivery Controllers that run the Smart Tools Site Agent must support PowerShell 3.0 and be able to communicate with Citrix Cloud over HTTPS 443.
• Smart Check reports on XenApp and XenDesktop Delivery Controllers, Delivery Groups and Machine Catalogs only.

What checks does Smart Check perform?:

Smart Check runs the following types of health checks:

• Site Health Checks – These checks are run on your Delivery Controllers. It is recommended that you run this check daily. Some of the checks include:
  • Checking that Windows Firewall rules are enabled.
  • Host connection is not in Maintenance Mode.
  • Citrix Monitor Service can access the Monitoring database.
  • Recent database backup exists.
  • Connectivity to core XenApp or XenDesktop services are established.
    • Site Health Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xdsitescout-<timestamp>. Log files are deleted after 5 days.
• Apps and Desktops Health Checks – This check ensures that your Delivery Groups are available to serve applications and/or desktops.
  • Apps and Desktops Health Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xaxdscout-<timestamp>. Log files are deleted after 5 days.
• Update Checks – This check runs on your VDAs and Delivery Controllers to see if they have the latest patches installed. If not, patches are recommended.
  • Update Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xdscout-<timestamp>. Log files are deleted after 5 days.
• LTSR Checks – Checks your Delivery Controllers and VDAs to determine if they are LTSR compliant. This check runs the LTSR Assistant tool against your site – https://support.citrix.com/article/CTX209577. For this check to run successfully, make sure the following conditions are met on your VDAs and Delivery Controllers:
  • PowerShell 2.0 and above is supported.
  • ICMP is allowed inbound through Windows Firewall.
  • WinRM is enabled through Windows Firewall and the service is started (also an Agent requirement).
  • Port 80 is allowed on Delivery Controllers for the XenApp and XenDesktop PowerShell SDK.
  • Port 5985 is allowed on VDAs and Delivery Controllers for Windows RM.

Note: For a list of Citrix provided alerts included in Smart Check see https://manage-docs.citrix.com/hc/en-us/articles/115000817343-Smart-Check-alerts-reference

Add Site to Smart Check:

Note: Sites can be added the following ways:

• A site deployed via Blueprints that has the Register Site step is added to Smart Check for you.
• If you use Call Home or upload Citrix Scout reports to CIS using the same MyCitrix account you use for Smart Tools. Likewise if you upload diagnostic files to CIS via Smart Check (explained later).

Alternatively, you can add an existing site manually.

To manually add an existing site to Smart Check, click Start Check -> Add Site.

Click Download Agent to download the Start Check Site Agent.

Install the Site Agent on a Delivery Controller in the site you want managed. It is recommended to install the Site Agent on multiple Delivery Controller’s in your site for high availability.

Once the Site Agent is installed on a Delivery Controller, return to the Citrix Cloud portal and you should receive the Agent was successfully installed message. Click Next.

Enter credentials to a Citrix Full Administrator account in your site. This account will be used to run health checks and analyse the site for updates. Click Add Site.

After a few moments the site will appear under Smart Check. The site will also be added to Smart Scale. Click on Get Started.

Shortly after adding a site to Smart Check, health checks will be performed.

Note: Make sure your Delivery Controllers are allowed to run PowerShell scripts.

Once you navigate to a Site within Smart Check you’ll see if there are any outstanding warnings and when the next scheduled checks are due to commence. You can also View Reports, perform manual checks, configure the site and more. I’ll go through each section. For my site, 1 warning is outstanding. Click on the > arrow beside 3 Checks set performed for more information.   

You can see that 3 different checks have ran, two completed without issue but the Site Health Checks found an issue.

There will be a display of each component that checks have been run against, the Controllers, Machine Catalogs and Delivery Groups along with errors or warnings. As you can see my Controller has a warning. I can click on it to see what the warning is.

Upon exanding the Delivery Controller, the warning states that no recent backups have been taken of the Site database. Clicking on the right arrow beside the date and time the warning was found displays further information.

The alert displays more information including a recommended fix.

You will also be emailed when issues have been found from Health Checks.

If you want to turn email notifications off, click Resource and Settings -> My Profile -> change Enabled to Disabled beside Smart Check issues summary.

Back over in Smart Check, clicking on a site and then clicking on Site Details displays your Delivery Controllers and gives you the option to synchronise site data, remove the site or change the Full Administrator credentials.

Those same options are available by clicking on the verticle ellipsis. The Sync Site Data option allows Smart Check to detects additional infrastructure that has recently been added to your site. Click on Edit Site Credentials.

You can change credentials to another Full Administrator then click Done.

If you want to perform a manual health check, click Perform Check. You can perform individual checks or all using the Perform all Checks option. I’ve purposely powered off my VDA so I’ll click on Apps and Desktops Health Checks.

Click Perfom Checks Now.

The appropriate checks begin to run.

One error has been found on my Delivery Group. Click the Delivery Group.

The error shows that there is 1 Unregistered VDA against the Delivery Group and that the Delivery Group is not able to serve connections. Click on the > arrow for more information.

Here the additional information displays recommendations to fix and the time the error was found. If you want to hide the alert, click Hide Alert.

Click Hide Alert. Notice that it will not appear again until we restore the alert.

To restore the alert, click on the vertical ellipsis and select Show Hidden Alerts.

The alert will appear back against the Delivery Group, click the > arrow beside the error date and time found and then select Restore Alert.

Smart Check Schedules:

If you want to change Health Check schedules or disable them, click on Configure.

You’ll be given a list of the four checks possible. You can configure the health checks to run on a schedule (or not). By default all schedules apart from LTSR Checks run every day between 12AM and 5AM based on the Time Zone of the first Delivery Controller Smart Check discovers. You can choose to run the checks Every Day or Every Week.

The LTSR Check is not scheduled to run. You can run the check manually. To the top-right, click Return to Health Report.

Click Perform Check -> LTSR Checks -> Perform Checks Now.

Once the LTSR check is complete, if your Site it not compliant, an issue will flag.

The issue found states that Components of target machine incompatible with Citrix LTSR.

More information displays information on what to do. My XenDesktop site is running 7.13, so I’m too far gone at this stage!

You can view a report of the LTSR check by clicking on View Reports. Click Download Report next to the LTSR report.

A number of different files will download in a packages folder. Most of them CSV. I’ll open a couple as examples.

The licenseserver.csv report shows that my License Server version is newer than the required LTSR version.

The same goes for the citrixdirector.csv report.

The ReportHtmlFile.html shows an overall report indicating that the site is not compliant with XenApp/XenDesktop 7.6 LTSR.

The ComplianceReport.csv file lists all components found in the site, their version and the version they should be for LTSR compliance.

Upload Site diagnostics to CIS via Smart Check:

The Smart Check section of Smart Tools allows you to upload diagnostic files to Citrix Insight Services at the request of Citrix support. You can also copy and send Citrix support generated links to your support files. Click Diagnostics -> Upload Diagnostics.

Click Select File to upload a diagnostics file.

As the diagnostics file uploads you should not navigate away from this page.

Click Done.

After the file has been uploaded it is analysed by CIS.

When analysis completes you’ll see some basic information about the file. Click on the > arrow to display more information.

You’ll be presented with slightly more information including a report link to share with Citrix support. Whilst you can upload any type of diagnostics file, Smart Check currently only supports running health checks on XenApp and XenDesktop.

If you were to upload a XenApp or XenDesktop support file, the site if not already known to Smart Check will be added to Smart Check. You can then install the Smart Check site agent on Delivery Controllers in that site to allow health checks to be performed. If you remove a site from Smart Check, make sure the diagnostic data is also removed from Citrix Insight Services or else the site may be re-added to Smart Tools.

If you click View Report against any site added to Smart Check, you can get some site specific information such as the number of Delivery Groups, Controllers and Machine Catalogs in that site.

If you click further into the site components i.e. Delivery Groups, you are presented with the names of each group along with any known issues.

Here you can see both Delivery Group names.

Looking at the Delivery Controller of a particular site displays the product version, name of the DDC and any outstanding alerts.

Install Smart Tools Site Agent on multiple Delivery Controllers:

As mentioned before it is advisable to install the agent on multiple Delivery Controllers for high availability. After you have added your site to Smart Check, if you click on Site Details the Delivery Controller which already has an installed agent displays along with any other discovered Delivery Controllers. You have the option of installing the agent on additional Delivery Controllers from this portal.

Remove Site from Smart Check:

To remove a Site click View Report on the site of your choice, now either click the verticle elipsis -> Remove Site or click Site Details -> Remove Site.

Click Remove.

You can also remove the Site Agent which unregisters the site from Smart Tools. If the unregister operation is not possible due to communication issues with Citrix Cloud then use the above Remove Site method.

 Smart Check Log Files:

Smart Check checks output log files in the following locations:

• Site Health Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xdsitescout-<timestamp>. Log files are deleted after 5 days.
• Update Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xdscout-<timestamp>. Log files are deleted after 5 days.
• Apps and Desktops Health Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xaxdscout-<timestamp>. Log files are deleted after 5 days.

Citrix Smart Migrate:

Citrix Smart Migrate can assist you in migrating XenApp 6/6.5 to XenApp 7.x or VDI in a Box 5.4 to XenDesktop 7.x. For XenApp 6.x migrations Smart Migrate helps by exporting existing farm policies and settings and imports them to your new 7.x site.

You can migrate using an automated fashion by installing the Site Agent on one 6.x and 7.x controller, installing the XenApp 6.5 PowerShell SDK on all 7.x controllers or manually by runnnig migration scripts and uploading policies and settings to Citrix Tools for migration.

For more information see https://manage-docs.citrix.com/hc/en-us/articles/212714903-Prepare-to-migrate-your-XenApp-6-x-or-VDI-in-a-Box-5-4-deployment

To kick off a deployement, in Smart Tools click on Smart Migrate and then Add a Migration Project.

Using the drop-down select the migration you wish to perform.

Upon selecting the migration type (in this case XenApp 6.5 to 7.x) you’ll be presented with some pre-requisite checks so make sure you have completed them before continuing. Click Add.

Select Fully Automated:

or Partially Automated:

If you select Fully Automated you’ll be asked to select your XenApp 6.5 environment and controller. The 6.5 farm should be added to Smart Tools. You can choose to connect an existing deployment at this stage.

If you chose Partially Automated you’ll be tasked with downloading the scripts, running them manually, collecting policies and settings related to your XenApp 6.5 farm and then uploading them back to Smart Tools.

Citrix Smart Scale:

Smart Scale is designed particularly to scale up and down Citrix VDAs per schedule and power manage them to save on the costs of running workloads on public clouds such as Azure or AWS. The amount of VDAs running in a Delivery Group monitored by Smart Scale can be based on session demand of Load Index value. Alternatively you can specify how many VDAs minimum you want running at any given time of the day to ensure adequate availability of resources for your user base.

Smart Scale requirements:

• Smart Scale is supported on Amazon EC2, Azure Resource Manager and Classic, and Citrix XenServer 6.2, 6.5, 7.0.
• You must configure hosting in XenApp or XenDesktop for Smart Scale to work.
• Your Site Delivery Controller(s) must support atleast PowerShell 3.0.
• Smart Scale supports XenApp, XenDesktop, XenApp and XenDesktop Service, XenApp Essentials and XenDesktop Essentials. Up to 2,000 VDAs per Site can be power managed (1,000 per Delivery Group) and up to 120 Delivery Groups can be power managed per Site. Monitoring data collection is supported for up to 5,000 VDAs per Site.
• Smart Scale supports pooled and static persistent VDI desktops but this is currently in “preview” and best to be trialled in testing environments whilst Server OS is fully supported. You should disable any power management functionality within XenDesktop to avoid conflicts with Smart Scale. When using VDI desktops, Load and Load/Schedule based scaling is not supported. When using schedule based only scaling, it is supported but Citrix recommend you use Smart Scale only during times where users log on to machines that are already powered on such as during business hours. When outside of business ours where machies are likely to be powered off, do not use Smart Scale but instead use the XenDesktop built-in power management capabilities. Also with random desktops which power off each time a user logs on, Smart Scale may attempt to power off the machine as well and eventually display an error on the Events and Machine Activity pages.

As the front tile says, “Keep costs of your cloud based deployments under control with usage and schedule based scaling”.

To access Smart Scale, launch Smart Tools and click the Smart Scale tile.

Add Site to Smart Scale:

Any sites you have already added to Smart Tools via Smart Build (agent must be deployed as part of blueprint) or Smart Check will be displayed, including any site with a Site Agent installed on one or more of the Delivery Controllers. XenApp and XenDesktop Service sites do not need added as scaling is directly actioned through the XenApp and XenDesktop Service. If you need to add a site manually, you can always click Add Site. This will allow you to install the Smart Tools Site Agent to one of your Delivery Controllers. The process has been described under Smart Check.

Once your site is added it displays under Smart Scale. Click Get Started.                         

The main page displays each Delivery Group to the left and Delivery Group specific data along the middle pane. Here you can see estimated savings calculated based on the machine running cost per hour. Say for example you have an Azure subscription and run VDAs on machines that cost $1 per hour. If you tell Smart Scale the price, an estimated savings value is calculated based on the amount of time Smart Scale is able to keep a VM powered off. This is the benefit of Smart Scale as it power manages machines when they are not used rather than have all VDAs running at the same time incurring cost. This is quite like the on-premise Power Management capabilities of XenDesktop so nothing new.

In this screen you also have the total amount of VDAs in a Delivery Group, how many sessions are running, how many VDAs are powered on and so on. You also have four tabs below the site name. Smart Scale by default will be disabled on all Delivery Groups so it is up to you to enable on the Delivery Groups of your choice. To enable Smart Scale against a Delivery Group, select a Delivery Group to the left and click Configure.

There is a toggle switch to the right, beside Scaling Disabled. Click the toggle.

The text will change to Scaling Enabled. Scroll down.

Here you can configure capacity management for the Delivery Group.

Using Smart Scale you can control load as follows:

• Load-based and schedule-based scaling – Create schedules and define how many VDAs you want to be powered on at that time and scale VDAs up or down based on session demand.
• Schedule-based scaling only – Create schedules (blocks of time) and define how many VDAs you want to be powered on at that time.
• Load-based scaling only – Based on Session Count or Load Index of the VDAs, scale up or down VDAs to meet demand. Keep in mind that a Delivery Group monitored by Smart Scale must have enough VDAs to meet demand. Smart Scale does not automatically provision and add extra VDAs to Delivery Groups.

By default Load-based and schedule-based scaling is selected with 1 Max session per host. Click the Advanced button.

Here you can adjust the capacity buffer which is by default at 10%. What this means is that if for example you have 20 VDAs in total with 10 users connected on a 1 to 1 basis, an 11th VDA will be powered on (assuming it is not already powered on) to be able to host an 11th session. If you had set the Capacity Buffer to 50%, 15 VDAs should be powered on as 50% of 10 sessions = 5. It is up to you to make sure the Delivery Group has enough VDAs to host session demand. If 100 user sessions are connected, VDA capacity is scaled to support 110 sessions. Click OK.

You can also set the Scale metric to Load Index, the default value is 10000 and cannot be changed. Load Index is only applicable to Server OS. If the Load Index value is reached, VDAs are power managed appropriately. To read up on Load Index see http://www.jgspiers.com/vda-load-index-xenapp-session-load-balancing/

Create Smart Scale schedules and load scaling:

You also have the option of creating new schedules, which dictates the amount of VDAs minimum that should run at any given time. The Default schedule is used at times where a custom schedule is not active, so one VDA will be powered on during this time. The time is based on local time of your Delivery Controller(s). You can also enter the machine cost for estimated savings. By default this value is 0.06. Beside Schedules, click Create New.

Enter a name, a value for how many machines you want to run and when you want to run them. My Delivery Group has 4 VDAs, so I am telling Smart Scale that I want 2 VDAs to be powered on every day between 8AM and 9PM. Outside of these times the Default Schedule will keep just one VDA online and scale based on demand which is optional. Click Create.

The new schedule shows as below. You can create multiple schedules but they cannot conflict with one another.

As a test I will set my Capacity Buffer to 50%.

I will also keep the Session Count at a maximum of 1 session per host.

Click Return to Site Monitoring.

To recap, my Delivery Group has 4 VDAs in total. I have restricted each VDA to only launch a maximum of 1 session and told Smart Scale to keep a minimum of 2 VDAs powered on during 8AM-9PM every day. I have also set the Capacity Buffer to 50% so that when a second session is launched a third VDA is powered on. To show this working, click on Machine Activity. Here you see two VDAs have been powered on to meet my schedule demands. The Machine Activity tab shows which machines have been powered on/off and been placed into maintenance mode.

If you click on the Events tab you will see similar information.

You can change the time range up to a month. The Machine Activity tab allows you to do the same.

Two sessions have now been launched against VDA2 and VDA4.

Shortly after VDA1 is powered on, as the previous two sessions triggered the Capacity Buffer.

As a third session connects to VDA1 and then logs off, VDA1 is placed in Maintenance Mode to prevent anyone else connecting and it is then powered off. Smart Scale selects the VDA with fewest sessions and places in maintenance mode. Once the machine has drained of sessions it is powered off. At this stage if the VDA was hosted in the public cloud we would be saving money.

Note: To ensure machines are adequately drained, create idle and disconnected session policies.

The Site Details tab shows brief information about your site Delivery Groups and Delivery Controller(s) including status as indicated by the green tick. You can force a site data sync, remove the site from Smart Scale or edit the Site Credentials.

Note: Site Credentials must be of an account that is a member of atleast the Delivery Group Administrator role in Citrix Studio and part of the Domain Users group. This account is used to impersonate the Site administrator and execute monitoring and scaling actions.

Using the verticle elipsis you can perform the same actions including turning off Smart Scale for a site. Smart Tools can automatically turn off Smart Scale on your Site if none of your Delivery Groups are configured for power management through Smart Scale or no Smart Scale events such as powering on or off have been generated in the last 30 days.

Smart Scale monitoring data is collected every 5 minutes for a Delivery Group when you enable Smart Scale for that Delivery Group. There may be a slight intial delay in displaying monitoring data when you first add a Site to Smart Scale. If Smart Scale is later disabled, no new monitoring data is captured but you can still view previously collected monitoring data.

Enable or Disable Smart Scale error event notifications:

Browse to Resources & Settings -> Notifications and enable/disable Smart Scale error events.

Remove Site from Smart Scale:

To remove a Site from Smart Scale you can either uninstall the Smart Tools Site agent from your Delivery Controller(s) which unregisters the Site completely from Smart Tools, or you can remove the Site from Smart Scale which also removes the Site from Smart Check but keeps the agent installed on your Delivery Controller(s).

Note: XenApp and XenDesktop Service sites cannot currently be removed from Smart Scale. It is recommended to just disable Smart Scale if you do not want to use it.

To do this click on the Site you want to remove and click Site Details -> Remove Site.

Click Remove.

Troubleshoot Smart Scale events:

For a list of events and troubleshooting tips see https://manage-docs.citrix.com/hc/en-us/articles/115002373886-Troubleshoot-Smart-Scale-events

This post explains how to launch Desktops and Applications in Windowed Mode using specific resolutions or a percentage of the screen.

By default when we launch applications and desktops they launch seamlessly as if running on the local endpoint. If applications and/or desktops behave in a way were seamless does not suit, you may want to consider launching those problematic resources in Windowed Mode instead.

Launching in Windowed Mode is easy and can be set up per resource. You can either define a static resolution or define a percentage of the screen.

On your StoreFront server(s), navigate to C:\inetpub\wwwroot\Citrix\CitrixStore\App_Data.

Note: Your path will be different depending on your Store name.

Now launch default.ica in a text editor.

To set a specific resolution underneath Application= type in brackets [] the name of your application as displayed in Citrix Studio. Underneath type the [Application] name type:

TWIMode=Off

DesiredHRES=

DesiredVRES=

The resolution is up to you.

Save the default.ica file. The next time youu launch a resource it will display as below in Windowed Mode:

To set the Windowed Mode as a percent of the screen, replace DesiredHRES= and DesiredVRES=with ScreenPercent=. This works well especially for published desktops.

A list containing the majority of Citrix support articles collated to make this page a one stop place for you to search for and find information regarding any issues you have with the main Citrix products and their related dependencies.

The page is updated daily with new support articles and information. Articles will change from time and if information here is outdated or incorrect please let me know using the comments. Links may also expire or change so if you find broken links, please let me know. For each issue, known product versions affected are recorded however that does not mean products versions that aren’t listed are not affected.

Each product table has a search box that you can type in to if looking for a specific fault. For example if you have an error code or message, use that to perform a search. You can also use your browsers search feature which will perform a search against the whole page based on the words you enter.

♣ App Layering
♣ AppDNA
♣ Azure, Citrix XenApp Essentials and XenDesktop Essentials
♣ Citrix Cloud
♣ Desktop Lock
♣ Director
♣ Federated Authentication Service
♣ Licensing
♣ Machine Creation Services
♣ NetScaler
♣ NetScaler Management and Analytics System
♣ Profile Management
♣ Provisioning Services
♣ Receiver for Android
♣ Receiver for HTML5
♣ Receiver for iOS
♣ Receiver for Linux
♣ Receiver for Mac
♣ Receiver for Windows
♣ SCOM Management Pack
♣ ShareFile
♣ Skype for Business
♣ StoreFront & Receiver for Web
♣ System Center Configuration Manager
♣ Universal Print Driver & Server, General Printing
♣ VMware ESX
♣ Windows 10
♣ Windows Server 2016
♣ Workspace Environment Management
♣ XenApp & XenDesktop (excluding Machine Creation Services)
♣ XenMobile
♣ XenServer

App Layering:

AppDNA:

Azure, Citrix XenApp Essentials and XenDesktop Essentials:

Citrix Cloud:

Desktop Lock:

Director:

Federated Authentication Service:

Licensing:

Machine Creation Services:

NetScaler:

NetScaler Management and Analytics System:

Profile Management:

Provisioning Services:

Receiver for Android:

Receiver for HTML5:

Receiver for iOS:

Receiver for Linux:

Receiver for Mac:

Receiver for Windows:

SCOM Management Pack:

ShareFile:

Skype for Business:

StoreFront & Receiver for Web:

System Center Configuration Manager:

Universal Print Driver & Server, General Printing:

VMware ESX:

Windows 10:

Windows Server 2016:

Workspace Environment Management:

XenApp & XenDesktop (excluding Machine Creation Services):

XenMobile:

XenServer:

I’ve been meaning to write up about this for a while now ever since creating the original Citrix FAS and SAML related blog posts upon the release of StoreFront 3.9.

One of the Microsoft Active Directory features that can be used to extend the functionality of Citrix Federated Authentication Service is a feature called Authentication Mechanism Assurance.

Using this feature, we can control access to the likes of files, folders and other security controlled objects based on if our logging on users have authenticated with a certificate or not. Since FAS issues certificates to our users and presents those to the VDA, there is very little extra work needed to make use of this.

Think of the scenario which we will follow in this post. We have file shares that should only be accessed by users who have authenticated with a Smart Card. If a user does not have a Smart Card, they use username and password as normal, but they shouldn’t be granted access to the confidential file shares.

Before you begin, you need to deploy Citrix FAS and ADFS. To do that, see http://www.jgspiers.com/adfs-authentication-direct-to-storefront-3-9-using-saml-and-citrix-federated-authentication-service/

Note: This solution uses ADFS. As users browse to StoreFront they are redirected to ADFS for authentication. Once they provide credentials SAML is used to send an assertion to StoreFront which will in turn generate a certificate to our authenticating user which is used to authenticate with the VDA when an application and/or desktop is launched.

Note: In this example I am demonstrating access to a file share. You could use this feature to control access to files, file shares, applications, printers and so on.

Once you have FAS fully working in your environment, you can carry on with the below.

Requirements:

• FAS fully functional including ADFS and Microsoft Active Directory Certificate Services.
• Windows Server 2008 R2 Domain Controllers at a minimum.
• Domain Functional Level set to Windows Server 2008 R2 at a minimum.

Open the Active Directory Certificate Services console and right-click Certificate Templates -> Manage.

Locate template Citrix_SmartcardLogon and right-click Properties. Click the Extensions tab, highlight Issuance Policies and click Edit.

Click Add to add a new Issuance Policy.

A couple are created by default, and you can create your own. For now we can simply use the Medium Assurance policy. Highlight this policy and click OK. 

Click OK.

The next step involves the creation of two scripts. The scripts are called Get-IssuancePolicyToGroupLink.ps1 and Set-IssuancePolicyToGroupLink.ps1. Both scripts are available from TechNet Step 3. Create both scripts on your Domain Controller under C:\.

Now on your Domain Controller launch Active Directory Module for Windows Powershell. 

Type command Get-IssuancePolicyToGroupLink.ps1.

This script will list the Issuance Policies available in your domain and display any that are linked to groups. Just to confirm, there are no Issuance Policies linked to groups at this stage.

To link an Issuance Policy (in our case the Medium Assurance policy) to groups we need to first create a group in Active Directory. The group must be a Universal Security group. This group will then become a part of a user’s kerberos ticket when they log on to the VDA with a certificate. The group will also be granted access to the confidential file share.

Once the group is created return back to PowerShell and this time we will be running the Set-IssuancePolicyToGroupLink.ps1 script. For parameter IssuancePolicyName specify Medium Assurance. For parameter groupOU specify the Organizational Unit name that is home to the security group you just created. For parameter groupName specify the Universal Security group name you just created.

Next create a file share which is locked to only members of the Universal Security group as below.

Click Done. Only members of CitrixFASAuth will be able to access the \\dc\confidential share. Only users who authenticate via Citrix FAS are added to the CitrixFASAuth group using Authentication Mechanism Assurance.

I proceeded to log on to the VDA using FAS. I also was able to access the Confidential file share. If accessing the VDA without authenticating using FAS, I was denied access.

Using whoami /groups when logged on to the VDA I can confirm that my account is added to the CitrixFASAuth group. As soon as a log off, I will not be a member of that group until I authenticate using a certificate again.

Note: If you have issued certificates to users via FAS before configuring Authentication Mechanism Assurance, you will have to remove those cached certificates from FAS to allow new ones to be generates with the Issuance Policy extension included in the new certificate. You can use cmdlet Remove-FASUserCertificate on all FAS servers.

Windows Server 2012 R2 Optimisation Script.

Tested on: Windows Server 2012 R2 build 9600.

Description: This script disables services, disables scheduled tasks and modifies the registry to optimise system performance on Windows Server 2012 R2 running in a Citrix SBC environment.

Note: This script makes changes to the system registry and performs other configuration changes. As such a full backup of the machine or snapshot if running in a virtual environment is strongly recommended. Carry out full testing before introducing the optimised image to production. You should review ALL optimisations this script makes and determine if they fit in to your environment. Not all optimisations will suit all environemnts. To avoid failure, run PowerShell as an administrator before running this script.

Download (click below):

Windows Server 2012 R2 Optimisation Script (122 downloads)

Any problems with the script or if you want to make your own improvement suggestions then comment below.

Open the script using a text editor or PowerShell ISE to see what exactly the script does.

Have you ever wanted to display the client IP on the front page of StoreFront? This can be useful for support purposes when Thin Clients are used to access Receiver for Web, as an example.

We can do this via some JavaScript and ASP.NET. To make something clear, I am not a developer of any sorts! However I did receive this request and dug in for a solution, and would like to share the solution with others if they get the same request.

When load balancing StoreFront via NetScaler as many do, the client IP is infact the NetScaler SNIP. For this reason we have to insert the client IP in a new HTTP header, named X-FORWARDED-FOR. This is the first step we will take.

On NetScaler, locate and edit your StoreFront Service Group.

Under settings check Client IP and under Header insert X-FORWARDED-FOR. Click OK.

Click Done and then save the running configuration.

Log on to your primary StoreFront server, and navigate to C:\inetpub\wwwroot\Citrix\CitrixWeb\Custom where Citrix\CitrixWeb may be different depending on your store name. Create a file called GetClientIP.aspx.

Insert the following text:

<%@ Page Language="C#" %>
<%=Request.ServerVariables["HTTP_X_FORWARDED_FOR"]%>

Example:

Next edit the existing script.js file.

Towards the end of the file under End of example customization enter the following text:

$(document).ready(function() {
    $.ajax({
        url: 'custom/GetClientIP.aspx',
        success: function(data) {
            $(".customAuthFooter").html(data);
        }
    });
});

Example:

Next edit the existing style.css file.

Towards the end of the file under You may add custom styles below this line enter the following text:

.customAuthFooter
{
font-size:15px;
text-align: right;
color: white;
}

Example:

After all three files have been edited and saved, propagate the changes to any remaining StoreFront servers in your Server Group by clicking on Server Group -> Propagate Changes.

Click Yes.

Receiver for Web will appear as below, with the client IP located in the right hand corner.

Setting font-size:30px in style.css increases the font size as below.

You can also center the IP address, and move it to the top of the web page. To do this change text-align: right to text-align: center in style.css and change .customAuthFooter referenced in both style.css and script.js to .customAuthHeader.

With XenApp 6.5 nearing EoL in June 2018, organisations around the world are planning an upgrade to XenApp and XenDesktop 7.x. While the move from one version of 7.x to another could be considered an easy in-place upgrade, the shift from 6.x to 7.x is a full-blown platform migration.

The reason for this is that there are many functionality, configuration and architectural changes in 7.x. This necessitates Citrix administration teams to be educated, trained and prepared to deal with the changes the migration entails. There are many new components introduced in 7.x, replacements in functionality from 6.5 to deal with, and new capabilities and enhancements in 7.x to get trained on. Furthermore, 7.x does not support some legacy operating systems and hypervisors. So, the migration to 7.x will also involve upgrading the supporting infrastructure components. All this makes the migration to 7.x a time-consuming and resource-intensive project.

eG Innovations, in conjunction with DABCC conducted a Citrix Migration Survey between November 2017 and February 2018 to understand how organisations around the world are dealing with this Citrix migration. The results of this survey – containing the insights from 795 Citrix professionals – were prepared as a graphical report and also presented to the Citrix community through a webinar. I was honoured to co-present on this webinar with both Vinod Mohan, Sr. Product Marketing Manager and Srinivas Ramanathan, CEO of eG Innovations.

Read Survey Analysis Report | Watch Webinar Recording

I wanted to use this opportunity to create a helpful FAQ article for Citrix administrators based on the answers to questions that appe

ared during the webinar. If you have any additional questions, use the comments section!

Question 1: How much time should we plan for the entire migration process from 6.x to 7.x?

An answer to this question depends on a lot of factors. Factors to take in to account are:

• How many applications do you have to migrate?
• How many desktops do you have to migrate?
• How many users are there to be migrated?
• How familiar are you already with the new 7.x components?
• Are you deploying new operating systems such as Windows 10 and Windows Server 2016?
• Are you purchasing and building new hardware such as hypervisors or thin clients?
• Are you deploying App Layering and layering all applications?
• How long will your Proof of Concept run for user acceptance testing?

Now you can probably tell why no answer will ever be the same for two organisations.

Question 2: Has anything changed in licensing between 6.x and 7.x?

Subscription Advantage and Software Maintenance has now been included in a new offering for customers called Customer Success Services. The XenApp and XenDesktop licenses remain the same. You can purchase XenApp Concurrent licenses or XenDesktop Concurrent/User Device licenses. Product versions such as Enterprise and Platinum for both XenApp and XenDesktop continue to exist.

It is worth noting that XenApp and XenDesktop 7.14.1 allows you to mix licenses together under the same site, a first in the 7.x platform. This allows you for example to mix XenApp Concurrent licenses with XenDesktop User/Device. It is important to note that the edition such as Platinum or Enterprise must be kept the same and cannot be mixed under a single site.

Question 3: What are the top 5 features of 7.x that we should be taking advantage of?

1. Adaptive Transport – This feature transports the ICA protocol over UDP. I’ve personally tested this myself and from testing found that a 45MB file copy over UDP with 200ms latency completed faster than a 45MB file copy over TCP with just 100ms latency!
2. Adaptive Display v2 – Here you can adjust policy settings so that H.264 codecs are used to compress moving parts of your screen such as video or other animated content, whilst ThinWire+ is used to deliver the solid parts such as text. This gives the best of both worlds because you aren’t compressing the full contents of your screen and consuming more CPU on the Citrix desktop, but you also aren’t forcing your network to send all data uncompressed either.
3. Receiver for HTML5 – Allows you to launch applications and desktops inside of an HTML5 enabled browser and you don’t even have to install Receiver on the machine. This could mean easier management of BYOD devices.
4. In-session watermarks – Released in XenApp and XenDesktop 7.17, this feature provides a way for you to overlay information on top of the Citrix session with details about the user that is connecting. This goes a long way to deterring users from misuse of corporate systems especially when working remotely, providing for a better way to protect your organisations information and data.
5. Remote PC (XenDesktop license only) – If you have a workstation at the office you can install the Citrix VDA software on to it, allowing you to connect to the workstation and make use of all the HDX technologies you normally use with XenDesktop. Being able to connect directly to your work PC from anywhere in the world is an excellent ability that is offered in XenDesktop 7.x.

Question 4: What are the functionalities from XenApp 6.5 that will be lost in XenApp and XenDesktop 7.x?

There isn’t much need to be worried here. In the early days of 7.x there were quite a few noticeable feature differences between 6.5 and 7.x. Today, with the latest release of 7.17, there are as reported by Citrix zero differences in features.

As an added plus, features such as Adaptive Transport, Browser Content Redirection, Receiver for HTML5, Adaptive Display v2, Application Groups, Hardware Encoding and more have all been added and are ready for to you to use, and improve your offering to the end-user!

Question 5: What features are missing in Citrix Director that was available in EdgeSight?

Director initially started off as a helpdesk tool and it was quite useful for monitoring user connection failures, failed servers or desktops, some historical reporting and managing active sessions.

In recent releases though we have witnessed Director evolve to a product that offers some new abilities such as:

• Alerting on failed connections, slow logons, failed desktops and so on.
• Ability to monitor GPU, CPU, RAM, IOPS.
• Ability to monitor processes for utilisation.
• Ability to provide custom reporting.

It is worth noting though that some of the newer features in Director are subject to licensing editions with some features being available under Platinum licensing.

What Director cannot do though is the in-depth monitoring of storage, hypervisors, networks and Citrix infrastructure components such as Provisioning Services and NetScaler. For this, you need third-party monitoring software.

If you want an in-depth review of Citrix Director, I suggest you read my article here.

Question 6: Can Citrix Director monitor NetScaler and components such as PVS and StoreFront?

No. For NetScaler management and monitoring, you need to look at NetScaler Management and Analytics. There is no current ability to monitor StoreFront or PVS.

Question 9: How would you carry out performance assessment to ensure XA/XD performance is not affected during and after the migration?

Question 7: Can we perform an in-place upgrade of 6.x to 7.x?

No, each component must be a new install. You will probably want to take this opportunity to deploy the 7.x components on newer operating systems too.

Question 8: Will I need to deploy new worker servers, or can I use existing ones and migrate them to 7.x?

You can use existing, so long as the 7.x version you are going to supports the operating system the worker servers run. For example, XenApp 7.16 does not support Windows Server 2008 R2.

Question 9: How would you carry out performance assessment to ensure Citrix performance is not affected during and after the migration?

I recommend you establish before and after baselines. Capturing baselines of the current 6.x environment, and then comparing to baselines captured during and after the migration has been completed. This will allow you to determine if user experience is being impacted or not during and after the migration.

Baselines should be focused around:

• Logon times
• Application launch times
• Citrix management server resource consumption
• Citrix desktop resource consumption
• Hypervisor resource consumption
• Network resource consumption
• Storage resource consumption

Question 10: What are the new components in XenApp and XenDesktop 7.x that need to be deployed, which were not available in XenApp 6.x?

The architecture changed in 7.x, however there are some similarities in 7.x. A typical XenApp and XenDesktop 7.x site consists of:

• StoreFront servers – This component is built on IIS and provides a web portal for users to log on to and access their desktops and applications.
  • Similar to Web Interface
• Delivery Controllers – This component speaks to SQL, broker connecting users to desktops and applications, power manage Citrix desktops and so on.
  • Similar to Data Collectors
• License Server – Only one can exist per site.
• Director – This component allows you to monitor user connection failures, monitor desktop or server failures, monitor logon times, produce reports, manage connected user sessions and more.
  • Similar to EdgeSight

Question 11: Do you recommend moving to Citrix Cloud? Does it help with the cost? What are the gains and losses?

I don’t specifically recommend any one route over another as all types of Citrix deployments have their own positives and negatives depending on the type of your organisation and the requirements.

• If you don’t fancy managing StoreFront, Delivery Controllers etc. and having to deal with upgrading and maintaining these components, look towards the XenApp and XenDesktop Service.
• If company policy dictates that you must remain on a single version of XenApp and XenDesktop for several years, look at deploying XenApp or XenDesktop 7.15 LTSR on-premises.
• If you must use Provisioning Services, look at deploying on-premises.
• If you want to host every bit of your Citrix infrastructure in the cloud, look towards Citrix XenApp or XenDesktop Essentials, or the XenApp and XenDesktop Service.

Question 12: I have legacy applications that must run on Windows Server 2008 R2. What is the latest version of 7.x that supports Windows Server 2008 R2?

The latest version of Citrix XenApp and XenDesktop that supports 2008 R2 is version 7.15. This version is also the latest Long Term Service Release version.

If you have any further questions on the topic of migration or need recommendations, please post them in the comments section below.

Here is a useful white paper, co-authored by Citrix and eG Innovations, that details some best practices to be followed while migrating to Citrix XenApp and XenDesktop 7.x and achieve peak performing applications and desktops: https://www.eginnovations.com/Citrix-Migration-Best-Practices

There are a couple of ways to configure VDAs so that they can register with Delivery Controllers in your Citrix Site. Registration from a VDA perspective is a sensitive process, and one you want to get right from the beginning. Also, it is good to know some of the things which can cause registration to fail at any point in time. If VDAs are not registered against a Delivery Controller, they won’t be considered by a Delivery Controller when brokering connections.

There are multiple ways to provide the list of DDCs to a VDA. This step allows the VDA to become aware of which DDCs it must attempt registration against:

1. Through Group Policy.
2. Specifying the FQDN of Controllers manually during installation of the VDA.
3. Letting Machine Creation Services automatically configure Delivery Controller addresses on the VDAs it provisions.
4. Active Directory OU based (legacy option).

Citrix recommend that we use Group Policy to configure the Controller addresses, as this allows the most flexible way to manage the list of DDCs at any time.

When a VDA powers on initially for the first time, it somehow has to determine which Delivery Controller(s) it should make a registration attempt against. If you are using the Group Policy method or you have manually specified controllers during VDA installation, this forms what we call the ListOfDDCs. The DNS names from the initial discovery process are kept in the ListofDDCs, which is a registry string on each VDA. Moving forward, in order to keep the cache up-to-date, a Citrix Studio policy named Enable auto update of Controllers is enabled by default to keep the list of DDCs fresh. The information from auto-update is kept on a persistent cache within each VDA and the VDA uses that cache for future registrations. If a Delivery Controller is added or removed from the Site, auto-update keeps the cache updated.

The registration process itself uses Kerberos, and it is two-way, so the connection from the VDA also ends up routing in the opposite direction. Given that Kerberos is used in the registration process, load balanced addresses front-ending Controllers which sit behind a NetSclaer cannot be used. Time is also important as by default Kerberos cannot handle anymore than 5 minutes of time skew.

To get a feel for each method of configuring Delivery Controller addresses on VDAs, I have explained each method below in brief detail.

Contents:

• Group Policy
• Manually during VDA installation
• Machine Creation Services
• Active Directory OU based (legacy)
• Troubleshooting Registration

Group Policy:

When you are installing the VDA, on the Delivery Controller section choose Do it later (Advanced).

You then use Group Policy to initially configure the ListOfDDCs registry string and auto-update (enabled by default) keeps the cache up-to-date.

If you do not wish to use auto-update and disable it via policy, you’ll have to modify Group Policy if a Controller is added or removed from your Citrix Site before VDAs will become aware of it.

Open Group Policy and the Citrix Policies extension. Create a new Citrix Computer Policy.

Search for the Controllers setting and click Add. Note that as mentioned Enable auto update of Controllers is enabled by default.

Specify one or more FQDNs for each Delivery Controller in your Citrix Site and click OK.

After the VDA picks up the new policy, the ListOfDDCs string will be populated with the values you specified during policy creation. This string exists under HKLM\SOFTWARE\Citrix\VirtualDesktopAgent for 64-bit systems.

This forms the foundations for a VDA to initially register with a Delivery Controller, and then auto-update generates a cache in a persistent location which holds the most up-to-date Controller list going forward.

Manually during VDA installation:

When you are installing the VDA, on the Delivery Controller section choose Do it manually.

Enter one or more Delivery Controller addresses and complete the VDA installation. Again, these values form the ListOfDDCs and auto-update keeps the list of Controllers up-to-date in a persistent location.

To find the persistent location, on a VDA launch PowerShell and run command Get-CimInstance -Namespace “Root\Citrix\DesktopInformation” -Class “Citrix_VirtualDesktopInfo” | select PersistentDataLocation

The persistent data location is only accessible from the SYSTEM account. For this, we can use PsExec. Launch PsExec as SYSTEM and browse to %ProgramData%\Citrix\PvsAgent\LocallyPersistedData\BrokerAgentInfo and open the XML file SavedListOfDdcsSids.xml.

To confirm, auto-update has updated the cache with a second Controller not specified during VDA install, ddc02.jgspiers.com

Machine Creation Services:

When you are installing the VDA, on the Delivery Controller section choose Let Machine Creation Services do it automatically.

Once machines have been provisioned by MCS, there will be a Personality.ini file on the root of C:\ on each VDA.

It is in this file that the Delivery Controller list is kept.

Active Directory OU based (legacy):

I’ll not touch on this method too much. Basically, Citrix don’t recommend you use it anymore. The recommended approach is to use a mixture of Group Policy for initial configuration and auto-update to keep the list updated.

Troubleshooting Registration:

• By default, VDA registration occurs over port 80. If you have not changed this default port, then verify that no process on your VDA machine is listening on port 80 other than SYSTEM. You can use netstat -aon -p tcp to confirm.
• Make sure the VDA and Delivery Controller times are in sync. Since registration uses Kerberos, time is important.
• If you are running in a secure environment that makes use of the Access this computer from the network policy, make sure that VDAs are able to communicate with Delivery Controllers and vice-versa using this policy setting.
• Make sure you are not trying to point VDAs to a load balanced address for the DDCs, this will not work.
• Make sure no typos exist in the DDC names when specified via Group Policy for example.

Windows Server 2016 Optimization Script.

Tested on: Windows Server 2016 build 14393.0.

Description: This script disables services, removes  scheduled tasks and imports registry values to optimise system performance on Windows Server 2016 running in a Citrix SBC environment.

Warning: This script makes changes to the system registry and other configurational change  and as such a full backup of the machine or # snapshot if running in a virtual environment is strongly recommended. Carry out full testing before introducing image to production.

Note: You should review ALL optimisations this script makes and determine if they fit in to your environment. Not every optimisation suits all environments. For example, this script disables key Hyper-V services for use in non-Hyper-V environments. If you use Hyper-V, you must enable these services.

Instructions: To avoid failure, run PowerShell as an administrator.

Download (click below):

Windows Server 2016 Optimisation Script (5127 downloads)

Any problems with the script or if you want to make your own improvement suggestions then comment below.

Open the script using a text editor or PowerShell ISE to see what exactly the script does.

Version 4.8 of Citrix Receiver for Windows comes with automatic update functionality which is enabled by default. There are a couple of different ways to control the behaviour of the auto-update feature.

Note: Receiver for Mac 12.6 also has the auto-update ability.

You may want to use auto-update but adjust the default behaviour. The ways to configure auto-update related settings are described below.

Things to note

• Outbound proxies must be configured with an exception to the Receiver auto-update Signature service https://citrixupdates.cloud.com and the download location https://downloadplugins.citrix.com
• By default auto-update is disabled on Session Host, Remote PC and VDI VDA machines.
• Auto-update is disabled on machines that have Desktop Lock installed.
• Machines must be connected to the internet for auto-update to work
• Receiver for Web users cannot download the StoreFront policy automatically. You have to add or refresh the StoreFront account manually through Receiver.

The first method is GPOs. Download the Receiver for Windows ADMX templates from Citrix and import them on to your Domain Controllers. Edit/create a GPO and navigate to Computer Configuration -> Policies -> Administrative Templates -> Citrix Components -> Citrix Receiver -> AutoUpdate. You have two configurable settings.

The first setting Set the Delay in Checking for Update can be set to Fast, Medium or Slow. This allows for staged upgrade rollouts. Fast means an update is pushed out as soon as it is available. Slow means the update will be pushed out after it has been available and tested for a period of time. Medium is somewhere in between.

The second setting Enable or Disable AutoUpdate Policy is used to set auto-update to disabled, auto (default) or manual (user checks manually for updates). You can also specify if only LTSR Receiver versions are offered for upgrade and set a defer count. The defer count can be set as a value of -1 to 30. -1 means no limit is set on the amount of defers a user can perform. A value of 3 would allow 3 maximum defers for example. A value of 0 means the remind me later option is not displayed.

The second method is to disable auto-update via command line when installing Receiver. A couple of new switches exist to control the behaviour of the auto-update feature.

• /AutoUpdateCheck – Configure auto-update to be on, off or manual. Values accepted are AUTO, MANUAL and DISABLED.
• /AutoUpdateStream – Control if auto-updates are for LTSR versions only or Current Release versions. Values accepted are LTSR or Current.
• /DeferUpdateCount – Allows you to specify the number of times you can defer an update notification. Values accepted are -1 to 30. -1 means the user can defer any number of times.
• /AURolloutPriority – Specify the speed of which a rollout of an upgrade will be performed. Values accepted are Auto, Fast, Medum and Slow.

For more information on a command line install of Receiver for Windows see https://www.jgspiers.com/command-line-install-citrix-receiver-for-windows/

The third option is using Preferences. This setting is per-user and user defined settings will be written to HKCU. Right-click on Receiver and click Advanced Preferences.

Click on Auto Update.

Choose your desired setting.

The fourth option is using StoreFront by modifying the web.config file found in wwwroot\Citrix\Roaming.       Find the text beginning <account id. Scroll down a couple of lines until you see:

<properties>

<clear />

</properties>

Enter lines as below, modifying to suit your needs.

The fifth option is using CitrixReceiverUpdater.exe after Citrix Receiver has been installed. CitrixReceiverUpdater.exe can be found in %ReceiverInstallLocation%\Citrix\ICA Client\Receiver.

This script documents Workspace Environment Management configuration settings into a single easy to read HTML file.

Script author: James Kindon @james_kindon

Contributions made to first iteration of script by: George Spiers @JGSpiers

Note: The script is now fully hosted on GitHub. Please refer here and read the SYNOPSIS for the most up-to-date information.

Tested working on OS version: Windows Server 2016, Windows Server 2012 R2, Windows 10 (although not officially supported).

Tested working on SQL version: SQL Server 2016, SQL Server 2014.

Tested working on WEM version: WEM 4.3, WEM 4.2.

Description: This script collects all the configured settings within Workspace Environment Management and formats them in to a easy to read HTML file.

Note: This script does not perform any writes to the WEM database.

Instructions: To avoid failure, run PowerShell as an administrator. The user account you use (SQL or Windows Authentication) must be able to connect to the WEM database and Read/Query the database. This could be the SQL vuemUser account or WEM Broker account.

Requirements: This script attempts to detect and install Windows Management Framework 5.0 if SQL Management Studio and SSMO modules are not present on the machine you are running this script from. If SQL Management Studio is installed then the modules provided by SSMO are used. If not, WMF 5.0 is installed. The installation of WMF 5.0 has been successfully tested on Windows Server 2012 R2 and Windows Server 2016. Windows 10 is not supported. To install WMF 5.0 you must have a connection to the internet on the machine you are using to run this script. If you do not have a connection to the internet, download from another machine that does and install this software manually.

For more information on Workspace Environment Management see https://www.jgspiers.com/citrix-workspace-environment-manager/

Download (click below):

Citrix WEM Documentation Script

An overview of Citrix Smart Tools, one of the Citrix Cloud services previously known as Citrix Lifecycle Management. This services allows you to automatically provision, manage and monitor Citrix workloads running on private and public clouds.

Citrix Cloud Status Portal
Citrix Smart Tools Portal
Licenses
Smart Tools Agents
What information does Smart Tools have on your site?
Add users (administrators) to Smart Tools
Create a Resource Location (Hyper-V) and install the Smart Tools Connector Agent (example)
Enrol site to Smart Tools when installing Delivery Controller (7.14+)
Citrix Smart Build

• Smart Build: Automated deployment of Citrix XenDesktop farm (example)
• Create a template machine for Blueprint deployment
• Pausing or retrying failed Blueprint deployment steps
• Troubleshooting a failed Blueprint Deployment
• How to delete a Deployment Profile:

Citrix Smart Check

• How does Smart Check work?
• What data does Smart Check collect?
• Smart Check System Requirements
• What checks does Smart Check perform?
• Additional custom health checks (VDA Health Check)
• Add Site to Smart Check
• Smart Check Schedules
• Upload Site Diagnostics to CIS via Smart Check
• Install Smart Tools Site Agent on Multiple Delivery Controllers
• Remove Site from Smart Check
• Smart Check Log Files

Citrix Smart Migrate

• XenApp 6.x Migration Tool

Citrix Smart Scale

• Smart Scale Requirements
• Add Site to Smart Scale
• Create Smart Scale schedules and load scaling
• Enable/Disable Smart Scale error event notifications
• Remove Site from Smart Scale
• Troubleshoot Smart Scale

Smart Tools consists of the following features to date (July 2017):

• Smart Build – Allows you to automate Citrix deployments on-premise or in the cloud using blueprints that are created by you or by way of pre-built templates.
  • Templates exist for XenApp, XenDesktop, Secure Browser, NetScaler, Active Directory and XenMobile.
  • Everyone gets rights to deploy pre-configured blueprints to their resource location.
    • Note: Smart Build will be discontinued in the near future (2018).
• Smart Migrate – Assists with the migration from XenApp 6.x to XenApp or XenDesktop 7.x. Includes assistance for migrating applications, desktops and policies.
  • Note: Smart Migrate will be discontinued in the near future (2018). The XenApp 6.x Migration Tool will continue to be available.
• Smart Check – Provides health monitoring for your Citrix envrionment.
  • You get notifications about recommended fixes and issues found in your environment during regular health checks and health check reports.
  • Manage updates to your environment including which updates are pushed out and when.
• Smart Scale – Usage and schedule based scaling on-premise or in the cloud helps to ensure that machines especially in the Cloud are only running when they are needed to avoid charges. You control resource availability and capacity during peak and off-peak times.
  • Smart Scale can run on Azure and AWS, or on-premise.

Note: For a list of what’s new to the Citrix Smart Tools suite, see https://manage-docs.citrix.com/hc/en-us/articles/212715303-What-s-new

The Citrix Cloud Status Portal

The status of all Citrix Cloud services and in our interest Smart Tools can be found at http://status.cloud.com/ – This is a live page that updates in real-time.

You have the option of subscribing to all alerts or specific ones by email, SMS, slack, or by other webhooks.

The Citrix Smart Tools Portal:

You’ll see a number of tabs when logged on to the portal:

• Resources & Settings – Shows existing and allows you to add additional Resource Locations. Allows you to edit administrator roles.
• Blueprint Catalog (Now renamed Checks and Blueprints) – A catalog of Blueprints and checks which you can search for and add to your library.
• Smart Build – From here you kick off the deployment of Blueprints. You can also create new Blueprints, edit existing ones, create scripts, share or clone Blueprints, add your your own custom alerts to the Smart Check Alerts Database. This is where your Library is located. If you are a member of multiple Citrix Smart Tools accounts, you’ll have a library for each account.
• Manage – This tab allows you to manage deployments and servers that have been provisioned to your Resource Location during Blueprint deployment. You can also scale deployments or tear them down.
• Smart Migrate – Provides assistance in migrating application and policy settings from XenApp 6.x or VDI in a box 5.4 (now removed) to XenApp or XenDesktop 7.x.
• Smart Check – From here you can view existing sites, or add new Citrix sites. You can upload site diagnostic data to Citrix Insight Services, perform health checks for example site checks or apps and desktops health checks, perform update checks, perform LTSR checks (Preview) and and view health reports.
• Smart Scale – Enable scaling. Define if you want to scale based on schedule, based on load or both. You can specify to scale based on the Load Index of VDAs or based on session count. Create schedules and more.

Licenses:

The Smart Tools features (Smart Build, Migrate, Check, Scale) are available for:

• XenApp and XenDesktop service customers are entitled to all tools.
• Citrix Workspace service customers are entitled to all tools.
• XenApp/XenDesktop customers with Customer Success Services – Select (previously Software Maintenance) are entitled however only Platinum customers are entitled to Smart Scale.
• XenMobile customers with Customer Success Services – Select (previously Software Maintenance) are entitled to everything but Smart Build.
• NetScaler customers with Customer Success Services – Select (previously Software Maintenance) are entitled to everything but Smart Build.
• Citrix partners are entitled to the tools.

Smart Tools Agents:

There are a couple of different agent types available. Agents can be installed automatically during Blueprint deplyoment or manually on machines that already exist in your Resource Location that you now want Smart Tools to manage. You can also install the agent manually at the end of a 7.14+ Delivery Controller installation (more on that later).

• Smart Tools Agent – Can be installed manually or automatically when Blueprints provision machines. If installed manually, you add the machine to Smart Tools afterwards. The agent is there to perform configuration tasks such as installing SQL, installing XenDesktop, creating a Citrix Site, perfoming scaling activies, data gathering and so on.
• Smart Tools Connector Agent (Connector) – When you create a Resource Location, you manually install a Smart Tools Agent on machines in your Resource Location and then promote those machines to Connectors. Machines that are designated as a Connector will broker communication from Citrix Cloud/Smart Tools to your Resource Location. If you have multiple Resource Locations for example XenServer and vSphere, a Connector on XenServer can act as the Connector for the vSphere environment also providing the connector can communicate with machines from both Resource Locations. If you have a Resource Location that is accessible from the Internet, you don’t need a Connector.
• Smart Tools Site Agent – This type of Connector is installed on one or more (for high availability) Delivery Controllers in your site. One agent will always be active on a Controller in a Citrix Site and others will be passive. The Site Agent allows Citrix Smart Tools to monitor the Citrix Site performing health checks, searching for applicable updates and scaling the environment.

The Smart Tools Agent can be installed on Windows 7 through to Windows 10 desktop OS (excluding Windows 8.1) or Windows Server 2008 through to Windows Server 2016 server OS. It can also be installed on a mixture of Linux OS.

When a Blueprint installs Smart Tools Agent, port 22 (SSH) should be open on Linux devices and TCP port 3389 (RDP) on Windows devices. These ports must be open to facilitate agent deployment but can be closed once the blueprint deployment is complete. HTTPS port 443 is used for communication to Citrix Cloud thereafter.

Note: There have been some instances where Windows UAC has caused agent installs to fail. If you encounter a Failed to install agent error during blueprint deployment try disabling UAC on the template VM before.

If an Agent stops communicating with Smart Tools after a reboot, check to make sure the Smart Tools Agent Service is running. If it is, restart it and then check if communication is restored.

What information does Smart Tools have on your site?

Communication always flows from the Connector Agent on your Resource Location to Citrix Cloud. Because all machines reside in your Resource Location, Citrix Cloud does not store any sensitive data on their side. Smart Tools does however store the following information:

• Delivery Group and Machine Catalog GUIDs and names.
• Master VM names.
• Delivery Controller FQDNs, product version and IP addresses.
• VDA DNS names, UUIDs, the Load Index, Maintenance Mode status and power state of VMs to perform power management duties via Smart Scale.
• Site data uploaded to CIS by the customer through Call Home in XenApp and XenDesktop, Smart Check or through Citrix Scout.

The above data is stored in separate database instances for each customer.

The Citrix Cloud and Smart Tools service also stores other information, including passwords and usernames for authentication to Citrix Cloud, access to Resource Locations such as AWS and deployment of Blueprints to your Resource Location.

• Citrix Cloud credentials – The credentials you use to authenticate to Citrix Cloud are sent to the Citrix Online system. This process generates a one-time signed JSON Web Token and grants access to Smart Tools using this token.
• Resource Location Passwords and Secret Keys – Passwords (for on-premise) and Secret Keys (for cloud) needed for authentication to Resource Locations are stored, encrypted and salted in the Citrix Cloud service database. Citrix own the keys used to encrypt these credentials. After a customer enters a password or secret key through the Smart Tools portal, the password or key is masked and cannot be rendered in plain text.
• Credentials used in Blueprints – Blueprints can store credentials as an input parameter. These credentials are stored, encrypted and salted in the Citrix Cloud service database. Citrix own the keys used to encrypt these credentials.
• Citrix Site Administrator credentials – If you use Smart Scale and/or Smart Check on your Citrix Site, you are required to provide credentials to a Citrix Full Administrator account from that site. This allows Smart Tools to perform health checks, perform scaling actions and apply fixes and updates to Delivery Controllers and Machine Catalogs on your behalf. These credentials are stored, encrypted and salted in the Citrix Cloud service database. Citrix owns the keys used to encrypt these credentials. After a customer enters the password through the Smart Tools portal, the password is masked and canot be rendered in plain text.
• AWS key pairs – If AWS EC2 is one of your Resource Locations, Smart Tools prompts you to create a key pair if one does not exist. This key pair enables you to access any Smart Tools Blueprint provisioned resource. The public key is stored in your AWS account while the private key is managed by the customer and should be kept somewhere safe. Smart Tools does not store the private key.
• Machine image credentials – When deploying a Blueprint, the local administrator credentials you supply from the image template are stored in Citrix Cloud if you create a Deployment Profile. Smart Tools stores these credentials in a separate database instance for each customer. All encryption used by Citrix use standard-based encryption algorithms.

Note: Note that whilst some operations require credentials or keys, you do have the option of provisioning your own machines and using existing machines in the Resource Location when deploying Blueprints. Using existing machines will reduce the need to supply such information to Smart Tools if you prefer. Make sure each machine has the Smart Tools Agent installed before deploying a Blueprint. To download the Agent, visit Resources & Settings, begin to add a Resource Location but after downloading the Agent, cancel the Resource Location creation.

Adding users to Smart Tools

Firstly navigate to Identity and Access Management and then invite users of your choice. If invited users do not have a Citrix Cloud account they will be asked to create one.

Type an email address and then click Invite. You can integrate Citrix Smart Tools with Azure AD. In this case you would have the ability to invite other Active Directory users. For a how-to see https://www.jgspiers.com/azure-active-directory-authentication-citrix-cloud/

Once the invited user has signed up to Citrix Cloud they will be given the Admin role in Smart Tools. To change this, within Smart Tools navigate to Resources & Settings -> Users -> select a user and under Actions click Edit.

From there select the role of Admin, Architect or Operator. Click Save.

To remove a user from Citrix Cloud, navigate back to Identity and Access Management.

Create a Resource Location (Hyper-V) and install the Smart Tools Connector Agent (example):

As mentioned before, a number of pre-created templates (Blueprints) are available from Citrix Cloud that you can use to deploy full Citrix farms among other deployments. If a pre-created template doesn’t suit, you can customise it or create your own. In this example, I’ll show you how to configure a Deployment Profile, and use a pre-created Blueprint to deploy a fully configured Citrix farm. The farm consists of one VDA and one StoreFront/DDC bundled together server.

Log on to Citrix Cloud and under Smart Tools click Manage.

You’ll first need to deploy a Resource Location. The Resource Location is where your VDA and Citrix infrastructure servers will reside. The Resource Location can be on public (Azure/AWS) clouds or private clouds running Hyper-V, XenServer or vSphere. You can have multiple Resource Locations.

Click on Resources & Settings.

Click Add Resource Location.

Check your hypervisor or cloud. In my case, Hyper-V.

Click on Next.

Click Download Agent. This downloads the Smart Tools Agent which you install on a dedicated machine within your resource location which will act as the connector. For high availability deploy pairs. These machines being connectors will broker communication from Citrix Cloud/Smart Tools to your Resource Location over HTTPS.

If you have multiple Resource Locations for example XenServer and vSphere, a connector on XenServer can act as the connector for the vSphere environment also providing it can communicate with machines in both Resource Locations.

The Smart Tools Agent can be installed on Windows 7 through to Windows 10 desktop OS (excluding Windows 8.1) or Windows Server 2008 through to Windows Server 2016 server OS. It can also be installed on a mixture of Linux OS.

Note: Also keep in mind that every machine the Citrix Cloud Smart Tools service has management over (machines deployed via Blueprints or manually added) will have a copy of the Smart Tools Agent installed. The agent is there to perform configuration tasks such as installing SQL, installing XenDesktop, creating a Citrix Site, running health checks for monitoring, gathering information and so on.

The installation instructions and requirements will be displayed. Along with a Waiting for you to install the Agent message.

Within your Resource Location, on a connector machine, launch CitrixLifecycleManagementAgent.exe

Accept the License Agreement and click Install.

Click Finish.

A log file is produced in case you need it. Return to the Citrix Cloud portal.

At this stage Smart Tools should detect that a connector agent has been installed. You can now click Next.

The new machine displays. To make it a connector, click on Use Selected Machine as Connector. A couple of additional scripts will be ran on the selected machine to promote it to a connector.

Making machine a connector. Please wait displays.

Once done enter Resource Location information. This includes a host (can be a connection to System Center Virtual Machine Manager/vCenter for example) or single host. Enter a username/password and domain name for an account that has permissions to manage the Resource Location. Click Add.

Once the Resource Location has been added, click Done.

The Resource Location will always appear as below and can be edited. You can also add additional locations.

Enrolling site to Smart Tools when installing Delivery Controller (7.14+):

When installing a 7.14 or newer Delivery Controller, you are offered the option of joining Smart Tools at the end of the installation. This installs the Smart Tools Site agent and is not the same as the Site Agent connector you just installed previously when creating a Resource Location.

Before connecting to Smart Tools, disable IE ESC (IE Enhanced Security Configuration) for users and administrators via Server Manager. Once the Delivery Controller is connected to Smart Tools it is recommended to turn IE ESC back on.

Select I want to connect to Smart Tools and Call Home. (Recommended) and click Connect.

Enter your Citrix Cloud credentials and click Sign In.

Once you see the success message, click Next. Finish the Delivery Controller install as normal, the site should now appear in Smart Tools.

Citrix Smart Build (to be discontinued in near Future):

Using “Blueprints”, Smart Build allows you to automate the deployment and configuration of XenApp/XenDesktop etc. to various Resource Locations of your choice.

Smart Build: Automated deployment of Citrix XenDesktop farm (example):

Now that we have a Resource Location, we want to build out a Citrix XenDesktop Site. To do that we use Blueprints either created by ourselves or via a pre-created template. In this example, I’ll use a simple PoC pre-created Blueprint. Click on Blueprint Catalog (now called Checks and Blueprints) and then choose the + symbol next to the Blueprint you want to use. From here forward the guide will reference the (Existing Domain) XenApp and XenDesktop Proof of Concept Blueprint created by Citrix.

You’ll get a message indicating that the Blueprint has been added to your library.

Note: If a new update of a Blueprint is released, Smart Tools displauys an indicator so that you can update the existing Blueprint to the newer version.

To access your library click Smart Build. To start a deployment using the newly added Blueprint click Actions -> Deploy.

Click Start deployment setup.

Enter a Deployment Name. You won’t have any created Deployment Profiles yet however during the next steps you do create one which can also be used in future deployments. Click Next.

Select the Resource Location where you want to deploy to. The Resource Location you choose must be supported by the Blueprint you are deploying. Click Next.

You have the option to configure NetScaler as part of the deployment. Something I am not going to do at this time. Click Next.

A number of pre-deployment checklist points will be displayed to help you prepare for the deployment.

Also the recommended hardware specs for each machine you are deploying will be displayed.

During the deployment, the machines created by the Blueprint are built off a template disk(s) that you create. On your Resource Location, you create a template virtual machine and configure it as per the requirements listed below for Hyper-V. This includes:

• Patching the image with the latest updates.
• Ensuring the WMI service is enabled and started.
• Ensuring outbound connections on TCP 443 are possible.
• Allowing inbound WMI traffic through Windows firewall.
• Ensuring the Hyper-V Integration Services are installed on the machine. Ensuring a local administrator account is created with a password that does not prompt for change on next log on.

As with any automated deployment, a number of parameters are needed for the configuration piece. Using the Export parameter list (.csv) option allows you to fill out any parameters in to CSV format and upload them to the deployment wizard. Instead I will define the parameters during the wizard manually. Before clicking Continue on the wizard, let’s create a template machine.

Create a template machine for Blueprint deployment:

Over on your Resource Location, create a template machine using hardware configurations of your choice. Later in the deployment you’ll be able to choose the hardware specifications for each machine the Blueprint deploys. Also make sure to patch Windows with the latest updates. You can use seperate templates for DDC and VDA if you wish. In my example, I am using a Windows Server 2012 R2 image for both machines.

An example where you would have two is if you are using a different OS for your VDAs, or you want the blueprint to deploy applications on your behalf to Delivery Groups. This would require you install applications on the VDA template machine.

Note: Do not install the Smart Tools Agent on the machine. The Agent is deployed automatically during Blueprint deployment.

Make sure the local admininstrator account is not set to change password at next logon. Also do not join the machine to your domain.

Make sure the Windows Management Instrumentation service is running and automatic.

Check that the Hyper-V Integration Services component is installed and up-to-date. Also make sure the services are up and running.

Launch Windows Firewall with Advanced Security and right-click Inbound Rules -> New Rule.

Under Predefined select Windows Management Instrumentation (WMI). Click Next.

Check all three rules and click Next. The rules already exist but they are disabled. Completing this wizard will enable them for you.

Click Finish.

If you don’t want to run through the wizard, highlight all three rules and right-click then select Enable Rule. Allowing WMI traffic through the firewall allows the Smart Tools Agent to install.

Make sure you have an unattend file created. As an example, the file I used is below.

Example unattend file:

language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
            </OOBE>
            <UserAccounts>
                <AdministratorPassword>
                    <Value>TABpAHYAZQByAHAAbwBvAGwAMAAxAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAUABhAHMAcwB3AG8AcgBkAA==</Value>
                    <PlainText>false</PlainText>
                </AdministratorPassword>
            </UserAccounts>
        </component>
    </settings>
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <ProductKey>D2N9P-3P6X9-2R39C-7RTCD-MDVJX</ProductKey>
        </component>
    </settings>
    <cpi:offlineImage cpi:source="wim:c:/users/g_liv/downloads/install.wim#Windows Server 2012 R2 SERVERSTANDARD" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

Open CMD and change directory to C:\Windows\System32\Sysprep. Run command sysprep /generalize /oobe /shutdown /mode:vm /unattend:c:\unattend.xml. At this stage unattend.xml file will be copied to the C:\Windows\Panther directory, the machine will be sysprepped and shut down. Return back to the Citrix Cloud portal.

Now you can click Continue.

On the scaling screen nothing can be changed when using this Blueprint because the functionality to change has been disabled on this Blueprint. You can edit the Blueprint as previously mentioned to further suit your requirements. Click Next.

Under XenDesktop Delivery Controller choose the Resource Location you had created earlier.

Specify a computer name for the Delivery Controller. Click Next.

Now you have to specify the location to your template virtual disk (.vhd) file that has been prepared for imaging. The Blueprint deployment will make copies of this disk when creating the DDC and VDA. By default copies of this disk will also be stored on E:\ however you can use the Edit button to change this location to elsewhere. Once you have filled out your VHD location, click Get Disk Info. If the disk is found, you’ll be displayed with disk specific information such as Disk Type, Disk Size, Disk Format. Click Next.

Here you get to configure the machine system hardware and a static IP if desired. Obviously a static IP is a must for the Delivery Controller so enter the required information and click Next.

As mentioned before, any machine deployed by a Blueprint will receive an install of the Citrix Smart Tools Agent so that it can be managed. You can see the checkbox towards the top states that an agent will be installed. Enter credentials to the local administrator account of the template machine and click Next.

Review your configuration information and click Finish.

Now you have to perform the same steps for the VDA machine.  Select your Resource Location. As you can probably tell, it is possible to deploy machines to multiple Resource Locations.

Enter the VDA machine name, click Next.

Enter disk information, click Next.

Enter hardware specification, select DHCP. Click Next.

Enter local administrator credentials. Click Next.

Click Finish.

Click Next.

There are some more configuration parameters needing entered before we can start the depoyment.

• Fill out the IP of a Domain Controller.
• FQDN of domain name.
• Administrator account that has the privileges to install XenDesktop on the VDA/DDC and join those machines to the domain.
• XenDesktop site name.
• Computer name for the DDC.
• ISO location of XenDesktop 7.13/7.14 media.

You may also need to enter credentials if you use a CIFS share. Finally the remaining field allow you to change the ComputerName, create a VDI server desktop and change the PowerShell Execution Policy.

The execution policy can be changed on your server VDA to one of the following values. I will leave all values at default. Click Next.

You’ll be asked to specify a Deployment Profile name and to save it. This profile can be used to redeploy this Blueprint at a later time. You don’t have to save it. Enter a name, description and click Save.

Now click Deploy.

As the Blueprint deploys, you’ll see a number of deployment steps being performed containing valueable information. Click each step and you can view the Step Details and Step Output. In this example, the initial task involves making a copy of the template machine disk to accomodate deploying our Delivery Controller.

The Delivery Controller will be created over on your Resource Location, with the disk attached and hardware configuration complete.

The machine goes through a number of configuration steps, one involving the installation of the Smart Tools Agent on to the Delivery Controller. 

As you can see here the Delivery Controller was renamed to BPDDC01. That step took 21 seconds.

The Step Output tab shows the old machine name and the new machine name.

Reboots are a frequent step in the deployment process. Here you can see a reboot and check for successful reboot occuring.

The machine goes through a number other configuration steps such as the configuration of DNS settings and joining to the domain.

Once the machine is ready for a XenDesktop install, the ISO is copied from the share you provided earlier to the machine locally in C:\Installers.

Just to confirm, the XenDesktop 7.13 media shows under the Installers folder on the DDC that is being deployed by Smart Build.

After a number of steps, the Delivery Controller install is complete, a SQL instance (in this case SQL Express) is installed and a Citrix site created along with the require databases. The XenDesktop Delivery Controller machine has at this stage finished installing and is configured with a XenDesktop Site. Next up is the install and configuration of the VDA, it goes through a number of the same steps so I’ll not repeat any of that process.

Once the VDA is complete, the deployment will return as complete. You can now perform a quick check to make sure everything looks OK.

Here are the two machines the Blueprint deployed, showing the correct amount of memory.

Launching Citrix Studio on the Delivery Controller, you can see a BPPOCSite was created (that name was specified in the Deployment Profile) and that a Delivery Group has been created.

Inside the Delivery Group is the VDA, registered successfully.

In this example StoreFront is also installed on the Delivey Controller and an HTTP store created.

To confirm connections can be made, connect to Receiver for Web and check you can successfully launch a desktop.

Pausing or retrying failed Blueprint deployment steps:

If your Blueprint fails at any step, you might want to pause the deployment to correct or retry the same step again. This is just a case of telling the Blueprint what action you want it to take on failure. Navigate to Smart Build, click Actions on your desired Blueprint and click Edit.

Now under Options click on the On failure drop-down box to select your desired outcome. During the deployment you will have more options on how you wish to proceed based on the On failure option you choose.

Troubleshooting a failed Blueprint Deployment:

Citrix have published a number of tips to diagnose deployment issues. See https://manage-docs.citrix.com/hc/en-us/articles/212715043-Troubleshoot-blueprint-deployment-issues

How to delete a Deployment Profile:

To delete a Deployment Profile, click Smart Build and start to deploy a Blueprint until the stage where it asks you if you want to use an existing Deployment Profile. Click the drop-down and click X beside the Deployment Profile you want to delete.

Citrix Smart Check:

Smart Check is a new Smart Tools product that is currently in preview. From a high level Smart Check provides health monitoring for your Citrix environment.

• You get notifications about recommended fixes and issues found in your environment during regular health checks and health check reports.
• Smart Check can manage updates to your environment including which updates are pushed out and when.
• You can schedule a range of health checks, which are then ran automatically.
• View health reports for your Citrix sites and upload diagnostic data to Citrix Insight Services.

How does Smart Check work?:

Smart Check works by running one or more collectors on Delivery Controller(s) within your Resource Location. A collector is no more than a script or tool mostly run within PowerShell which is run by the Smart Tools Agent. The data collected in this step is formatted mostly in JSON files but at times XML files and then uploaded to Citrix Insight Services for analysis. Based on the analysis results, alerts may be generated for a number of conditions.

What data does Smart Check collect?:

JSON files that are generated by Smart Checks are very small in size containing little data other than information to identify your Site, the issues that have been alerted and the names of affected VDAs.

For example the Apps and Desktops Health Check gathers your version of XenApp/XenDesktop, the Site name, any affected VDAs including name, OS version and what errors exist on those VDAs.

Smart Check System Requirements:

Smart Check is supported on the following platforms:

• XenApp and XenDesktop 7.6 LTSR and 7.11.
• XenApp and XenDesktop deployments running on:
  • Azure ARM.
  • AWS.
  • XenServer 6.2 -> 7.1.
  • VMware vSphere 5.1, 5.5 and 6.0.
• Machine Catalogs that use MCS.
• Smart Check is not supported on deployments that use the XenApp and XenDesktop Service in Citrix Cloud.
• To use Smart Check, Delivery Controllers that run the Smart Tools Site Agent must support PowerShell 3.0 and be able to communicate with Citrix Cloud over HTTPS 443.
• Smart Check reports on XenApp and XenDesktop Delivery Controllers, Delivery Groups and Machine Catalogs only.

What checks does Smart Check perform?:

Smart Check runs the following types of health checks:

• Site Health Checks – These checks are run on your Delivery Controllers. It is recommended that you run this check daily. Some of the checks include:
  • Checking that Windows Firewall rules are enabled.
  • Host connection is not in Maintenance Mode.
  • Citrix Monitor Service can access the Monitoring database.
  • Recent database backup exists.
  • Connectivity to core XenApp or XenDesktop services are established.
    • Site Health Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xdsitescout-<timestamp>. Log files are deleted after 5 days.
• Apps and Desktops Health Checks – This check ensures that your Delivery Groups are available to serve applications and/or desktops.
  • Apps and Desktops Health Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xaxdscout-<timestamp>. Log files are deleted after 5 days.
• Update Checks – This check runs on your VDAs and Delivery Controllers to see if they have the latest patches installed. If not, patches are recommended.
  • Update Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xdscout-<timestamp>. Log files are deleted after 5 days.
• LTSR Checks – Checks your Delivery Controllers and VDAs to determine if they are LTSR compliant. This check runs the LTSR Assistant tool against your site – https://support.citrix.com/article/CTX209577. For this check to run successfully, make sure the following conditions are met on your VDAs and Delivery Controllers:
  • PowerShell 2.0 and above is supported.
  • ICMP is allowed inbound through Windows Firewall.
  • WinRM is enabled through Windows Firewall and the service is started (also an Agent requirement).
  • Port 80 is allowed on Delivery Controllers for the XenApp and XenDesktop PowerShell SDK.
  • Port 5985 is allowed on VDAs and Delivery Controllers for Windows RM.
• StoreFront Checks
  • Validates certificates for StoreFront.
  • Validates StoreFront service status, AD connectivity, base URL setting, and IIS Application Pool version.
• Provisioning Services Checks
  • Validates PVS status and checks several aspects of the Provisioning Services configuration.
• Citrix License Server Checks
  • Verifies License Server status, Subscription Advantage eligibility date compatibility and provides license upgrade suggestions.
• Life-cycle Checks
  • Verifies End-of-Life and End-of-Maintenance status on Delivery Controllers and other Site components.
  • Provides LTSR and Current Release update recommendations.

Note: There are some custom checks that can be run such as a VDA health check. This check makes use of the VDA health assistant tool found here.

Note: For a list of Citrix provided alerts included in Smart Check see https://manage-docs.citrix.com/hc/en-us/articles/115000817343-Smart-Check-alerts-reference

Additional custom health checks (VDA Health Check)

You can add custom health checks to Smart Check by way of blueprints. This allows you to add some additional checks on top of the four main checks that are already available. In this example, I’ll add the VDA Health Check blueprint to my list of checks that can be performed via Smart Check. This health check uses the VDA Health Assistant tool.

Browse to Blueprint Catalog (now called Checks and Blueprints), scroll to the bottom and click the + under VDA Health Checks.

Now navigate back to Smart Check and under Perform Check you’ll have the new option to run VDA Health Checks.

When you click to run this check, you can pick and choose which VDAs you want to run it against. Enter credentials and click Perform Checks Now.

Add Site to Smart Check:

Note: Sites can be added the following ways:

• A site deployed via Blueprints that has the Register Site step is added to Smart Check for you.
• If you use Call Home or upload Citrix Scout reports to CIS using the same MyCitrix account you use for Smart Tools. Likewise if you upload diagnostic files to CIS via Smart Check (explained later).
  • Note: Automatic Site Discovery is switched off by default for Call Home or Citrix Scout diagnostics uploads to CIS. Previously, it was enabled by default.

Alternatively, you can add an existing site manually.

To manually add an existing site to Smart Check, click Start Check -> Add Site.

Click Download Agent to download the Start Check Site Agent.

Install the Site Agent on a Delivery Controller in the site you want managed. It is recommended to install the Site Agent on multiple Delivery Controller’s in your site for high availability.

Once the Site Agent is installed on a Delivery Controller, return to the Citrix Cloud portal and you should receive the Agent was successfully installed message. Click Next.

Enter credentials to a Citrix Full Administrator account in your site. This account will be used to run health checks and analyse the site for updates. Click Add Site.

After a few moments the site will appear under Smart Check. The site will also be added to Smart Scale. Click on Get Started.

Shortly after adding a site to Smart Check, health checks will be performed.

Note: Make sure your Delivery Controllers are allowed to run PowerShell scripts.

Once you navigate to a Site within Smart Check you’ll see if there are any outstanding warnings and when the next scheduled checks are due to commence. You can also View Reports, perform manual checks, configure the site and more. I’ll go through each section. For my site, 1 warning is outstanding. Click on the > arrow beside 3 Checks set performed for more information.   

You can see that 3 different checks have ran, two completed without issue but the Site Health Checks found an issue.

There will be a display of each component that checks have been run against, the Controllers, Machine Catalogs and Delivery Groups along with errors or warnings. As you can see my Controller has a warning. I can click on it to see what the warning is.

Upon exanding the Delivery Controller, the warning states that no recent backups have been taken of the Site database. Clicking on the right arrow beside the date and time the warning was found displays further information.

The alert displays more information including a recommended fix.

You will also be emailed when issues have been found from Health Checks.

If you want to turn email notifications off, click Resource and Settings -> My Profile -> change Enabled to Disabled beside Smart Check issues summary.

Update: Smart Check can now discover License Servers, PVS Servers and StoreFront servers and allows you to run custom created health checks against them.

Back over in Smart Check, clicking on a site and then clicking on Site Details displays your Delivery Controllers and gives you the option to synchronise site data, remove the site or change the Full Administrator credentials.

Those same options are available by clicking on the verticle ellipsis. The Sync Site Data option allows Smart Check to detects additional infrastructure that has recently been added to your site. Click on Edit Site Credentials.

You can change credentials to another Full Administrator then click Done.

If you want to perform a manual health check, click Perform Check. You can perform individual checks or all using the Perform all Checks option. I’ve purposely powered off my VDA so I’ll click on Apps and Desktops Health Checks.

Click Perfom Checks Now.

The appropriate checks begin to run.

One error has been found on my Delivery Group. Click the Delivery Group.

The error shows that there is 1 Unregistered VDA against the Delivery Group and that the Delivery Group is not able to serve connections. Click on the > arrow for more information.

Here the additional information displays recommendations to fix and the time the error was found. If you want to hide the alert, click Hide Alert.

Click Hide Alert. Notice that it will not appear again until we restore the alert.

To restore the alert, click on the vertical ellipsis and select Show Hidden Alerts.

The alert will appear back against the Delivery Group, click the > arrow beside the error date and time found and then select Restore Alert.

Smart Check Schedules:

If you want to change Health Check schedules or disable them, click on Configure.

You’ll be given a list of the four checks possible. You can configure the health checks to run on a schedule (or not). By default all schedules apart from LTSR Checks run every day between 12AM and 5AM based on the Time Zone of the first Delivery Controller Smart Check discovers. You can choose to run the checks Every Day or Every Week.

The LTSR Check is not scheduled to run. You can run the check manually. To the top-right, click Return to Health Report.

Click Perform Check -> LTSR Checks -> Perform Checks Now.

Once the LTSR check is complete, if your Site it not compliant, an issue will flag.

The issue found states that Components of target machine incompatible with Citrix LTSR.

More information displays information on what to do. My XenDesktop site was running 7.13, so the site was not compatible with XenDesktop 7.6 LTSR (7.15 LTSR was not released at the time).

You can view a report of the LTSR check by clicking on View Reports. Click Download Report next to the LTSR report.

A number of different files will download in a packages folder. Most of them CSV. I’ll open a couple as examples.

The licenseserver.csv report shows that my License Server version is newer than the required LTSR version.

The same goes for the citrixdirector.csv report.

The ReportHtmlFile.html shows an overall report indicating that the site is not compliant with XenApp/XenDesktop 7.6 LTSR.

The ComplianceReport.csv file lists all components found in the site, their version and the version they should be for LTSR compliance.

Upload Site diagnostics to CIS via Smart Check:

The Smart Check section of Smart Tools allows you to upload diagnostic files to Citrix Insight Services at the request of Citrix support. You can also copy and send Citrix support generated links to your support files. Click Diagnostics -> Upload Diagnostics.

Click Select File to upload a diagnostics file.

As the diagnostics file uploads you should not navigate away from this page.

Click Done.

After the file has been uploaded it is analysed by CIS.

When analysis completes you’ll see some basic information about the file. Click on the > arrow to display more information.

You’ll be presented with slightly more information including a report link to share with Citrix support. Whilst you can upload any type of diagnostics file, Smart Check currently only supports running health checks on XenApp and XenDesktop.

If you were to upload a XenApp or XenDesktop support file, the site if not already known to Smart Check will be added to Smart Check. You can then install the Smart Check site agent on Delivery Controllers in that site to allow health checks to be performed. If you remove a site from Smart Check, make sure the diagnostic data is also removed from Citrix Insight Services or else the site may be re-added to Smart Tools.

If you click View Report against any site added to Smart Check, you can get some site specific information such as the number of Delivery Groups, Controllers and Machine Catalogs in that site.

If you click further into the site components i.e. Delivery Groups, you are presented with the names of each group along with any known issues.

Here you can see both Delivery Group names.

Looking at the Delivery Controller of a particular site displays the product version, name of the DDC and any outstanding alerts.

Install Smart Tools Site Agent on multiple Delivery Controllers:

As mentioned before it is advisable to install the agent on multiple Delivery Controllers for high availability. After you have added your site to Smart Check, if you click on Site Details the Delivery Controller which already has an installed agent displays along with any other discovered Delivery Controllers. You have the option of installing the agent on additional Delivery Controllers from this portal.

Remove Site from Smart Check:

To remove a Site click View Report on the site of your choice, now either click the verticle elipsis -> Remove Site or click Site Details -> Remove Site.

Click Remove.

You can also remove the Site Agent which unregisters the site from Smart Tools. If the unregister operation is not possible due to communication issues with Citrix Cloud then use the above Remove Site method.

 Smart Check Log Files:

Smart Check checks output log files in the following locations:

• Site Health Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xdsitescout-<timestamp>. Log files are deleted after 5 days.
• Update Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xdscout-<timestamp>. Log files are deleted after 5 days.
• Apps and Desktops Health Check log files are stored on your Delivery Controller(s) in C:\Program Files (x86)\Citrix\LifecycleManagement\proc\xaxdscout-<timestamp>. Log files are deleted after 5 days.

Citrix Smart Migrate (to be discontinued in near future):

Citrix Smart Migrate can assist you in migrating XenApp 6/6.5 to XenApp/XenDesktop 7.x. You used to be able to migrate VDI-in-a-Box 5.4 to XenApp/XenDesktop 7.x but this ability was removed August 2017. For XenApp 6.x migrations Smart Migrate helps by exporting existing farm policies and settings and imports them to your new 7.x site.

You can migrate using an automated fashion by installing the Site Agent on one 6.x and 7.x controller, installing the XenApp 6.5 PowerShell SDK on all 7.x controllers or manually by runnnig migration scripts and uploading policies and settings to Citrix Tools for migration.

For more information see https://manage-docs.citrix.com/hc/en-us/articles/212714903-Prepare-to-migrate-your-XenApp-6-x-or-VDI-in-a-Box-5-4-deployment

To kick off a deployement, in Smart Tools click on Smart Migrate and then Add a Migration Project.

Using the drop-down select the migration you wish to perform.

Note: Ability to migrate VDI-in-a-Box 5.4 was removed in August 2017.

Upon selecting the migration type (in this case XenApp 6.5 to 7.x) you’ll be presented with some pre-requisite checks so make sure you have completed them before continuing. Click Add.

Select Fully Automated:

or Partially Automated:

If you select Fully Automated you’ll be asked to select your XenApp 6.5 environment and controller. The 6.5 farm should be added to Smart Tools. You can choose to connect an existing deployment at this stage.

If you chose Partially Automated you’ll be tasked with downloading the scripts, running them manually, collecting policies and settings related to your XenApp 6.5 farm and then uploading them back to Smart Tools.

XenApp 6.x Migration Tool:

The XenApp 6.x Migration Tool is a collection of PowerShell scripts designed to migrate policy and farm data from XenApp 6.0 or 6.5 farms to 7.x.

You firstly run the scripts on a 6.0 or 6.5 controller, and then run import cmdlets on a XenApp 7.x controller. This tool will continue to be available after Smart Migrate has been discontinued.

For more information see: https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/upgrade-migrate/xenapp-worker-upgrade.html

Citrix Smart Scale:

Smart Scale is designed particularly to scale up and down Citrix VDAs per schedule and power manage them to save on the costs of running workloads on public clouds such as Azure or AWS. The amount of VDAs running in a Delivery Group monitored by Smart Scale can be based on session demand of Load Index value. Alternatively you can specify how many VDAs minimum you want running at any given time of the day to ensure adequate availability of resources for your user base.

Smart Scale requirements:

• Smart Scale is supported on Amazon EC2, Azure Resource Manager and Classic, and Citrix XenServer 6.2, 6.5, 7.0.
• You must configure hosting in XenApp or XenDesktop for Smart Scale to work.
• Your Site Delivery Controller(s) must support atleast PowerShell 3.0.
• Smart Scale supports XenApp, XenDesktop, XenApp and XenDesktop Service, XenApp Essentials and XenDesktop Essentials. Up to 2,000 VDAs per Site can be power managed (1,000 per Delivery Group) and up to 120 Delivery Groups can be power managed per Site. Monitoring data collection is supported for up to 5,000 VDAs per Site.
• Smart Scale supports pooled and static persistent VDI desktops but this is currently in “preview” and best to be trialled in testing environments whilst Server OS is fully supported. You should disable any power management functionality within XenDesktop to avoid conflicts with Smart Scale. When using VDI desktops, Load and Load/Schedule based scaling is not supported. When using schedule based only scaling, it is supported but Citrix recommend you use Smart Scale only during times where users log on to machines that are already powered on such as during business hours. When outside of business ours where machies are likely to be powered off, do not use Smart Scale but instead use the XenDesktop built-in power management capabilities. Also with random desktops which power off each time a user logs on, Smart Scale may attempt to power off the machine as well and eventually display an error on the Events and Machine Activity pages.

As the front tile says, “Keep costs of your cloud based deployments under control with usage and schedule based scaling”.

To access Smart Scale, launch Smart Tools and click the Smart Scale tile.

Add Site to Smart Scale:

Any sites you have already added to Smart Tools via Smart Build (agent must be deployed as part of blueprint) or Smart Check will be displayed, including any site with a Site Agent installed on one or more of the Delivery Controllers. XenApp and XenDesktop Service sites do not need added as scaling is directly actioned through the XenApp and XenDesktop Service. If you need to add a site manually, you can always click Add Site. This will allow you to install the Smart Tools Site Agent to one of your Delivery Controllers. The process has been described under Smart Check.

Once your site is added it displays under Smart Scale. Click Get Started.                         

The main page displays each Delivery Group to the left and Delivery Group specific data along the middle pane. Here you can see estimated savings calculated based on the machine running cost per hour. Say for example you have an Azure subscription and run VDAs on machines that cost $1 per hour. If you tell Smart Scale the price, an estimated savings value is calculated based on the amount of time Smart Scale is able to keep a VM powered off. This is the benefit of Smart Scale as it power manages machines when they are not used rather than have all VDAs running at the same time incurring cost. This is quite like the on-premise Power Management capabilities of XenDesktop so nothing new.

In this screen you also have the total amount of VDAs in a Delivery Group, how many sessions are running, how many VDAs are powered on and so on. You also have four tabs below the site name. Smart Scale by default will be disabled on all Delivery Groups so it is up to you to enable on the Delivery Groups of your choice. To enable Smart Scale against a Delivery Group, select a Delivery Group to the left and click Configure.

There is a toggle switch to the right, beside Scaling Disabled. Click the toggle.

The text will change to Scaling Enabled. Scroll down.

Here you can configure capacity management for the Delivery Group.

Using Smart Scale you can control load as follows:

• Load-based and schedule-based scaling – Create schedules and define how many VDAs you want to be powered on at that time and scale VDAs up or down based on session demand.
• Schedule-based scaling only – Create schedules (blocks of time) and define how many VDAs you want to be powered on at that time.
• Load-based scaling only – Based on Session Count or Load Index of the VDAs, scale up or down VDAs to meet demand. Keep in mind that a Delivery Group monitored by Smart Scale must have enough VDAs to meet demand. Smart Scale does not automatically provision and add extra VDAs to Delivery Groups.

By default Load-based and schedule-based scaling is selected with 1 Max session per host. Click the Advanced button.

Here you can adjust the capacity buffer which is by default at 10%. What this means is that if for example you have 20 VDAs in total with 10 users connected on a 1 to 1 basis, an 11th VDA will be powered on (assuming it is not already powered on) to be able to host an 11th session. If you had set the Capacity Buffer to 50%, 15 VDAs should be powered on as 50% of 10 sessions = 5. It is up to you to make sure the Delivery Group has enough VDAs to host session demand. If 100 user sessions are connected, VDA capacity is scaled to support 110 sessions. Power Off Delay is a newer option and specifies if machines should be powered off only after the initial delay has lapsed. Click OK.

You can also set the Scale metric to Load Index, the default value is 10000 and cannot be changed. Load Index is only applicable to Server OS. If the Load Index value is reached, VDAs are power managed appropriately. To read up on Load Index see https://www.jgspiers.com/vda-load-index-xenapp-session-load-balancing/

Create Smart Scale schedules and load scaling:

You also have the option of creating new schedules, which dictates the amount of VDAs minimum that should run at any given time. The Default schedule is used at times where a custom schedule is not active, so one VDA will be powered on during this time. The time is based on local time of your Delivery Controller(s). You can also enter the machine cost for estimated savings. By default this value is 0.06. Beside Schedules, click Create New.

Enter a name, a value for how many machines you want to run and when you want to run them. My Delivery Group has 4 VDAs, so I am telling Smart Scale that I want 2 VDAs to be powered on every day between 8AM and 9PM. Outside of these times the Default Schedule will keep just one VDA online and scale based on demand which is optional. You can instead specify a % of machines that must be powered on during the schedule. For example, 10% of 10 machines is 1 VDA and 10% of 100 VMs is 10 VDAs. As Delivery Groups scale up or down, Smart Scale follows and keeps the correct percentage of machines powered on. Click Create.

The new schedule shows as below. You can create multiple schedules but they cannot conflict with one another.

As a test I will set my Capacity Buffer to 50%.

I will also keep the Session Count at a maximum of 1 session per host.

Click Return to Site Monitoring.

To recap, my Delivery Group has 4 VDAs in total. I have restricted each VDA to only launch a maximum of 1 session and told Smart Scale to keep a minimum of 2 VDAs powered on during 8AM-9PM every day. I have also set the Capacity Buffer to 50% so that when a second session is launched a third VDA is powered on. To show this working, click on Machine Activity. Here you see two VDAs have been powered on to meet my schedule demands. The Machine Activity tab shows which machines have been powered on/off and been placed into maintenance mode.

If you click on the Events tab you will see similar information.

You can change the time range up to a month. The Machine Activity tab allows you to do the same.

Two sessions have now been launched against VDA2 and VDA4.

Shortly after VDA1 is powered on, as the previous two sessions triggered the Capacity Buffer.

As a third session connects to VDA1 and then logs off, VDA1 is placed in Maintenance Mode to prevent anyone else connecting and it is then powered off. Smart Scale selects the VDA with fewest sessions and places in maintenance mode. Once the machine has drained of sessions it is powered off. At this stage if the VDA was hosted in the public cloud we would be saving money.

Note: To ensure machines are adequately drained, create idle and disconnected session policies.

The Site Details tab shows brief information about your site Delivery Groups and Delivery Controller(s) including status as indicated by the green tick. You can force a site data sync, remove the site from Smart Scale or edit the Site Credentials.

Note: Site Credentials must be of an account that is a member of atleast the Delivery Group Administrator role in Citrix Studio and part of the Domain Users group. This account is used to impersonate the Site administrator and execute monitoring and scaling actions.

Using the verticle elipsis you can perform the same actions including turning off Smart Scale for a site. Smart Tools can automatically turn off Smart Scale on your Site if none of your Delivery Groups are configured for power management through Smart Scale or no Smart Scale events such as powering on or off have been generated in the last 30 days.

Smart Scale monitoring data is collected every 5 minutes for a Delivery Group when you enable Smart Scale for that Delivery Group. There may be a slight intial delay in displaying monitoring data when you first add a Site to Smart Scale. If Smart Scale is later disabled, no new monitoring data is captured but you can still view previously collected monitoring data.

Enable or Disable Smart Scale error event notifications:

Browse to Resources & Settings -> Notifications and enable/disable Smart Scale error events.

Remove Site from Smart Scale:

To remove a Site from Smart Scale you can either uninstall the Smart Tools Site agent from your Delivery Controller(s) which unregisters the Site completely from Smart Tools, or you can remove the Site from Smart Scale which also removes the Site from Smart Check but keeps the agent installed on your Delivery Controller(s).

Note: XenApp and XenDesktop Service sites cannot currently be removed from Smart Scale. It is recommended to just disable Smart Scale if you do not want to use it.

To do this click on the Site you want to remove and click Site Details -> Remove Site.

Click Remove.

Troubleshoot Smart Scale events:

For a list of events and troubleshooting tips see https://manage-docs.citrix.com/hc/en-us/articles/115002373886-Troubleshoot-Smart-Scale-events

This post explains how to launch Desktops and Applications in Windowed Mode using specific resolutions or a percentage of the screen.

By default when we launch applications and desktops they launch seamlessly as if running on the local endpoint. If applications and/or desktops behave in a way were seamless does not suit, you may want to consider launching those problematic resources in Windowed Mode instead.

Launching in Windowed Mode is easy and can be set up per resource. You can either define a static resolution or define a percentage of the screen.

On your StoreFront server(s), navigate to C:\inetpub\wwwroot\Citrix\CitrixStore\App_Data.

Note: Your path will be different depending on your Store name.

Now launch default.ica in a text editor.

To set a specific resolution underneath Application= type in brackets [] the name of your application as displayed in Citrix Studio. Underneath type the [Application] name type:

TWIMode=Off

DesiredHRES=

DesiredVRES=

The resolution is up to you.

Save the default.ica file. The next time youu launch a resource it will display as below in Windowed Mode:

To set the Windowed Mode as a percent of the screen, replace DesiredHRES= and DesiredVRES=with ScreenPercent=. This works well especially for published desktops.

A list containing the majority of Citrix support articles collated to make this page a one stop place for you to search for and find information regarding any issues you have with the main Citrix products and their related dependencies.

The page is updated daily with new support articles and information. Articles will change from time and if information here is outdated or incorrect please let me know using the comments. Links may also expire or change so if you find broken links, please let me know. For each issue, known product versions affected are recorded however that does not mean products versions that aren’t listed are not affected.

Each product table has a search box that you can type in to if looking for a specific fault. For example if you have an error code or message, use that to perform a search. You can also use your browsers search feature which will perform a search against the whole page based on the words you enter.

App Layering
AppDNA
Azure, Citrix XenApp Essentials and XenDesktop Essentials
Citrix Cloud
Desktop Lock
Director
Federated Authentication Service
Internet Explorer/Firefox/Chrome
Licensing
Machine Creation Services
NetScaler
NetScaler Management and Analytics System
Profile Management
Provisioning Services
Receiver for Android
Receiver for HTML5
Receiver for iOS
Receiver for Linux
Receiver for Mac
Receiver for Windows
SCOM Management Pack
ShareFile
Skype for Business
StoreFront & Receiver for Web
System Center Configuration Manager
Thin Clients
Universal Print Driver & Server, General Printing
VMware ESX
Windows 10
Windows Server 2016
Workspace Environment Management
XenApp & XenDesktop (excluding Machine Creation Services)
XenMobile
XenServer

App Layering:

• Citrix Fixes – App Layering

AppDNA:

• Citrix Fixes – AppDNA
  

Azure, Citrix XenApp Essentials and XenDesktop Essentials:

• Citrix Fixes – Azure, Citrix XenApp Essentials and XenDesktop Essentials
  

Citrix Cloud:

• Citrix Fixes – Citrix Cloud
  

Desktop Lock:

• Citrix Fixes – Desktop Lock
  

Director:

• Citrix Fixes – Director
  

Federated Authentication Service:

• Citrix Fixes – Federated Authentication Service
  

Internet Explorer/Firefox/Chrome

• Citrix Fixes – Internet Explorer, Firefox, Chrome
  

Licensing:

• Citrix Fixes – Licensing
  

Machine Creation Services:

• Citrix Fixes – Machine Creation Services
  

NetScaler:

• Citrix Fixes – NetScaler
  

NetScaler Management and Analytics System:

• Citrix Fixes – NetScaler Management and Analytics System
  

Profile Management:

• Citrix Fixes – Profile Management
  

Provisioning Services:

• Citrix Fixes – Provisioning Services
  

Receiver for Android:

• Citrix Fixes – Receiver for Android
  

Receiver for HTML5:

• Citrix Fixes – Receiver for HTML5
  

Receiver for iOS:

• Citrix Fixes – Receiver for iOS
  

Receiver for Linux:

• Citrix Fixes – Receiver for Linux
  

Receiver for Mac:

• Citrix Fixes – Receiver for Mac
  

Receiver for Windows:

• Citrix Fixes – Receiver for Windows
  

SCOM Management Pack:

• Citrix Fixes – SCOM Management Pack
  

ShareFile:

• Citrix Fixes – ShareFile
  

Skype for Business:

• Citrix Fixes – Skype for Business
  

StoreFront & Receiver for Web:

• Citrix Fixes – StoreFront & Receiver for Web
  

System Center Configuration Manager:

• Citrix Fixes – System Center Configuration Manager
  

Thin Clients:

• Citrix Fixes – Thin Clients
  

Universal Print Driver & Server, General Printing:

• Citrix Fixes – Universal Print Driver & Server, General Printing
  

VMware ESX:

• Citrix Fixes – VMware ESX
  

Windows 10:

• Citrix Fixes – Windows 10
  

Windows Server 2016:

• Citrix Fixes – Windows Server 2016
  

Workspace Environment Management:

• Citrix Fixes – Workspace Environment Management
  

XenApp & XenDesktop (excluding Machine Creation Services):

• Citrix Fixes – XenApp & XenDesktop (excluding Machine Creation Services)

XenMobile:

• Citrix Fixes – XenMobile

XenServer:

• Citrix Fixes – XenServer