Starting StoreFront 3.9, it is possible to use SAML authentication direct to StoreFront with ADFS and integrate that with the Citrix Federated Authentication Service.  Users authenticate at the Identity Provider, the assertion is sent to StoreFront, a certificate is issued for authenticating to the VDA.

You can also configure the same scenario but with NetScaler for external access. See http://www.jgspiers.com/adfs-authentication-storefront-netscaler-saml-citrix-federated-authentication-service/

Previous to StoreFront 3.9, you had to go through NetScaler to use SAML authentication against StoreFront. Now you can go direct with 3.9 without the need for NetScaler for internal connections. ADFS is currently the only supported SAML Identity Provider for use directly to StoreFront. Users authenticate with SAML at the Identity Provider, and then StoreFront issues a certificate to the user which is used for authenticating to the VDA.

SAML authentication direct to StoreFront can be used with Receiver for Windows 4.6+ (not possible when through NetScaler) and through Receiver for Web.

♣ Install and Configure Active Directory Federation Services
♣ Install and Configure the Citrix Federated Authentication Service
♣ Configure StoreFront
♣ Add StoreFront Relying Party Trust
♣ Log on to StoreFront using SAML
♣ Events Logs, viewing and revoking issued Certificates from FAS

Install and Configure Active Directory Federation Services

Before installing the ADFS role on Windows Server, draw up PowerShell and enter command Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)). This command immediately creates a Key Distribution Service Root Key, stored in Active Directory and allows us to create a group Managed Service Account password for the ADFS service account we create later. Run this command from a Domain Admin or Enterprise Admin account.

Now intall the ADFS role using Server Manager, then launch the Active Directory Federation Services Configuration Wizard -> Next.

Specify a Domain Admin account to perform the ADFS configuration. Click Next. 

Import a public issued cerificate that matches the ADFS URL users will be redirected to for authentication. In my case, this is adfs.jgspiers.com. Set the Federation Service Name as your ADFS URL. The Federation Service Display Name will show to all users at log on. Click Next.

Note: The ADFS URL must be different from the ADFS server hostname. In my case, the ADFS server has a hostname of idp.jgspiers.com and an ADFS URL reachable via adfs.jgspiers.com.

Under Create a Group Managed Service Account enter a unique name. Managed Service Accounts are supported in Windows Server 2012 onwards and come with strict, complex passwords which are changed automatically every 30 days. Click Next.

Check Specify the location of a SQL Server database and enter your SQL server details. Click Next.

Click Next after reviewing your options.

Click Configure.

Providing no errors occur, the ADFS server will be successfully configured. Click Close.

Create an internal A Record for your ADFS URL.

Next on the ADFS server, launch PowerShell and run command Set-ADFSProperties -AutoCertificateRollover $false. I am doing this because I do not want to use the ADFS generated Token-decrypting and Token-Signing certificates. Instead we will use our own generated through ADCS (Active Directory Certificate Services). In my case I have two certificates with subjects of:

• adfssigning.jgspiers.com
• adfsdecryption.jgspiers.com

Enrol the certificates, install them on the ADFS server and then launch the ADFS Management console. Browse to AD FS -> Service -> Certificates.

Use the Add Token-Signing Certificate and Add Token-Decrypting Certificate actions to add your own self-signed certificates as shown below.

Token-decrypting certificate:

Token-signing certificate:

Within the ADFS Management Console, click each new certificate and select the Set as Primary action. Delete the existing, autogenerated Token-decrypting and Token-signing certificates that came with the installation.

On the ADFS server, launch MMC and add the Computer Certificates Snap-in. Navigate to the Personal store, right-click on the Signing certficiate and click All Tasks -> Manage Private Keys.

Click Add.

Click Object Types and check Service Accounts -> OK. Enter the name of the Managed Service Account you used during ADFS configuration.

Specify Read permissions for the service account and click OK. Perform the same action on the Decrypting certificate. Afterwards, restart the Active Directory Federation Services service.

Install and Configure the Citrix Federated Authentication Service

To begin, as a Citrix recommended practice, deploy a dedicated server to host the Federated Authentication Service. The server must be running Windows 2008 R2 or later. This service automatically on behalf of users enrols for certificates against Active Directory Certificate Services, so it is important that this server is secured.

To insall FAS, launch the XenApp/XenDesktop 7.9+ media and click on Federated Authentication Service.

Accept the License Agreement and click Next.

Click Next.

Click Next. Port 80 TCP will be used.

Click Install.

Once FAS has installed, log on to your StoreFront server and launch PowerShell. You are going to enable FAS on the Store of your choice. Run the following commands and propagate to remaining servers if applicable:

• Get-Module “Citrix.StoreFront.*” -ListAvailable | Import-Module
• $StoreVirtualPath = “/Citrix/Citrix” (Note: Change /Citrix/Citrix to your own store path)
• $Store = Get-STFStoreService -VirtualPath $StoreVirtualPath
• $Auth = Get-STFAuthenticationService -StoreService $Store
• Set-STFClaimsFactoryNames -AuthenticationService $Auth -ClaimsFactoryName “FASClaimsFactory”
• Set-STFStoreLaunchOptions -StoreService $Store -VdaLogonDataProvider “FASLogonDataProvider”

On a Delivery Controller, run commands asnp citrix.* and Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true

Next we need to use Group Policy to specify which servers are used for FAS. On the FAS server, navigate and copy all files and folders from C:\Program Files\Citrix\Federated Authentication Service\PolicyDefinitions.

Copy them to the PolicyDefinitions folder within SYSVOL aka your Group Policy Central Store.

Now create a Group Policy Object which points to your FAS, StoreFront and VDA servers. You could link the policy to a high level OU or at the domain level if you don’t want to be more granular. Expand Computer Configuraton -> Policies -> Administrative Templates -> Citrix Components -> Authentication and double-click Federated Authentication Service.

Check the Enabled radio box. Click Show beside DNS Addresses and enter your FAS server hostname. Click OK.

You can also enable the ability for in-session certificates by configuring the In-session Certificates setting. By default, VDAs will not allow access to FAS issued certificates after a user logs on, however this setting does allow the use of certificates and places a certificate in the users personal certificate store after logon. This is useful when you have applications or web applications that require client certificate authentication or when you need to sign documents using a digital certificate.

You can specify that prompts for consent to use the certificate in-session can appear on-screen per-application, once for a session or not at all. You can also configure how long a consent lasts for before asking again.

Note: Make sure to also check Available after logon within the FAS administration console under User Rules or else users will be denied access to their certificates when they log on to a VDA.

Log on to your FAS server and launch the Citrix Federated Authentication Service console. You may have to run a gpupdate before the FAS address appears as below. Click Ok.

On the Initial Setup page, click Start next to Deploy certificate templates.

Click OK. As mentioned in the note, FAS will attempt to install three certificate templates on to your ADCS server. This may require that the account you are running the FAS tool with is a Domain or Enterprise Admin. These steps can also be performed manually if needed using PowerShell.

The first section will turn green once the templates have been installed. The second step may also turn green without any additional input. If it dooesn’t, click Start under step 2 and select your Certificate Authority. Do not proceed to step 3 just yet.

On your Certificate Services server, the three certificate templates show as below.

Open the Certificate Authority console and navigate to Certificate Templates, right-click and select  New -> Certificate Template to Issue.

Highlight the three Citrix FAS related templates and click OK.

Note: You can choose to optionally deploy either the Citrix_RegistrationAuthority or Citrix_RegistrationAuthority_ManualAuthorization  templates. The first template is for auto-enrolment and the second requires certificate requests using that template to be manually issued. If you are using the Citrix_RegistrationAuthority template, you should restrict the permissions so that only the FAS server can auto-enrol this certificate.

Now return to the FAS server. Click on Start beside step 3, Authorize this service. What this is going to do is submit a certificate request to ADCS based on the Citrix_RegistrationAuthority_ManualAuthorization or Citrix_RegistrationAuthority certificate templates. The first template requests manual approval, whilst the second is configured for auto-enrolment.

Click OK. The request will be sent to the selected Certificate Authority server, but you can specify another.

If you are manually approving using the Manual Authorization template, the FAS console will wait for approval. At this stage you need to manually issue the certificate request.

Open up the Certificate Authority console, navigate to Pending Requests. Right-click on the existing pending request and click Issue under All Tasks.

Once the certificate has been successfully issued, step 3 will turn green. The Initial Setup is complete. FAS now has the ability to issue certificates to users.

Click on the User Rules tab. A default rule has aleady been created. You can customise this rule, or create your own additional rules. Rules dictate which StoreFront servers can request certificates from FAS, which users certificates can be requested for and which VDAs can consume those certificates. Rules can be applied to different StoreFront servers using Group Policy. For now I will stick with the single default rule and make some modifications. Make sure Certificate Authority matches your CA (you can add multiple CA servers using PowerShell) and the Certificate Template is set to Citrix_SmartcardLogon. Click Edit beside List of Storefront servers that can use this rule.

Ensure only your StoreFront servers have the Assert Identity permission. No other server should be included in the list. Click OK. Click Edit beside List of VDA desktops and servers that can be logged into by this rule.

By default Domain Computers have Relying Party Allow rights. You can change this to specify that only certain VDA machines can be logged on to using FAS. Click OK. Click Edit beside List of users that StoreFront can log in using this rule.

By default, Domain Users can log on using FAS. Again, you can change this. Click OK.

Once you are satisfied with all rules, click Apply and then OK.

It is strongly recommended that you restrict the FAS server to only being allowed to issue certificates using the single Citrix_SmartCardLogon template and to certain users. Excluding administrators is a good example of users who should not be issued a certificate under FAS. You can configure restrictions within the Certificate Authority console.

Configure StoreFront

Launch StoreFront. By this stage you will already have configured FAS against the store of your choice. Select that same store and click Manage Authentication Methods.

If you upgraded StoreFront from a pervious version to 3.9, you will not see SAML in the list of authentication methods like below. If you installed StoreFront 3.9 fresh you will. If you don’t see it, click Advanced -> Install or uninstall authentication methods.

Check SAML Authentication -> OK.

Click OK. Propagate this chane to any remaining StoreFront servers.

Launch PowerShell on the same StoreFront server and run the following commands.

• Get-Module “Citrix.StoreFront.*” -ListAvailable | Import-Module
• $StoreVirtualPath = “/Citrix/Citrix” (Note: Change /Citrix/Citrix to your own store path)
• $Store = Get-STFStoreService -VirtualPath $StoreVirtualPath
• $Auth = Get-STFAuthenticationService -StoreService $Store
• Update-STFSamlIdPFromMetadata -AuthenticationService $auth -Url https://adfs.jgspiers.com/FederationMetadata/2007-06/FederationMetadata.xml (Note: Change adfs.jgspiers.com to your own ADFS URL)

At this stage the federation metadata is read from ADFS.

During the metadata importing process, StoreFront attempts to import the ADFS Signing-token certificate. If it is unable to read the subject name of the certificate for any reason, you’ll get an error as below and the StoreFront console will not load any settings.

Event Log reports that the value for property subject is not valid.

Open the web.config file located on StoreFront under C:\inetpub\wwwroot\Citrix\CitrixAuth\ and beside the subject line enter the certificates subject name. In my case, adfssigning.jgspiers.com.

At this stage StoreFront will load properly. Navigate to Manage Authentication Methods and under SAML Authentication select Identity Provider.

You’ll notice the information that was abstracted from ADFS including the ADFS signing certificate and URL. Propogate changes to any remaining StoreFront servers and log on to your ADFS server.

Add StoreFront Relying Party Trust

Launch the ADFS Management Console. Navigate to AD FS -> Trust Relationships -> Relying Party Trusts -> Add Relying Party Trust.

Click Start.

Check Import data about the relying party published online or on a local network and enter the Federation metadata address as below. Change xendesktop.jgspiers.com/Citrix/CitrixAuth to your own StoreFront URL and Citrix store name. For example, this could be yourstorefront.com/Citrix/YourStoreAuth. Click Next. If successful, ADFS should be able to read federation metadata from StoreFront.

Enter a display name and click Next.

Click Next.

Click Next. This will permit all users. You can create specific Issuance Authorization Rules to allow users from certain Security Groups to be allowed or denied authentication to ADFS for example if you have a requirement.

Review all imported settings and click Next. Signature and Encryption certificates will have been generated from StoreFront and imported to ADFS.

Keep the Open the Edit Claim Rules dialog box checked and click Close.

Click Add Rule.

Using the Claim rule template dropdown, select Send LDAP Attributes as Claims. Click Next.

Enter a Claim rule name. Under Attribute store select Active Directory. Under LDAP Attribute enter User-Principal-Name and Name ID under Outgoing Claim Type. Click Finish.

Click OK.

To test everything is working, enter your StoreFront URL as below. You’ll be asked for your username/password. When entered and accepted, you should be presented with the claims and assertion.

Using the StoreFront console, uncheck User name and password to use SAML only. Propagate changes to any remaining StoreFront servers.

Log on to StoreFront using SAML

Now enter your StoreFront Receiver for Web address or use the Receiver for Windows client. You should be redirected to ADFS. Enter your credentials.

If successful you’ll be directed back to StoreFront and shown your applications and desktops.

Events Logs, viewing and revoking issued Certificates from FAS

Once the user authenticates with ADFS, StoreFront issues an identity assertion to FAS for user george.spiers@jgspiers.com.

FAS then begins the issuing of a certificate to user george.spiers@jgspiers.com.

A certificate request is made to the Certificate Authority.

If the request is granted, FAS issues a certificate to george.spiers@jgspiers.com.

The request details are logged.

FAS keeps hold of the certificate and private key. The private key is not shared with StoreFront.

As a user connects to a VDA, the VDA reports that an Identity Assertion Logon is occuring along with details of the user logging on.

The certificate request can be seen from the Certificate Authority console.

If you double-click on the request, you can see the certificate which expires in 7 days.

You can also view issued certificates that are cached on the FAS server. Launch PowerShell and issue command Add-PSSnapin Citrix.Authentication.FederationAuthenticationService.V1 and Get-FASUserCertificate -Address IDP.jgspiers.com with address being your FAS server name. These certficates will be cached by default for 7 days.

If in-session certificates are enabled, StoreFront again issues an assertion to FAS.

A record is then generated to say that VDA1 is accessing the issued certificate for user george.spiers@jgspiers.com.

You can remove FAS issued certificates for specific users using a command such as Remove-FASUserCertificate -Address IDP.jgspiers.com -UserPrincipalName george.spiers@jgspiers.com from PowerShell on your FAS server. If you run the same command without the -UserPricipalName switch, all issued certificates will be removed from the specified FAS server.

You can also pre-generate certificates using New-FASUserCertificate. This could help in situations where you want to pre-generate certificates during non-peak hours to reduce load on FAS and ADCS servers.

A number of performance counters come installed on the FAS server after you have installed the FAS role. These are helpful in determining how many certificates FAS has currently enrolled, how quick certificates are generated, signed and so on. Certificate generation normally takes around 1 second, the certificate is then cached for 7 days to make logons faster however assertions will still be made to FAS from StoreFront and the VDA when users are re-authenticating within the 7 days.

Auditing Group Policy changes is a good practice to apply to ensure no settings are removed or added that could affect end-user experience.

This should apply to every environment, as such it is equally important to track all changes made to Group Policy in a Citrix environment. Many large enterprise companies come with large IT teams, many of whom have the ability to work within Group Policy and do so frequently. With this in mind, it’s easy to lose track of the configurations that are made. A Group Policy system could start with ten settings, and end up with hundreds. How many of the settings implemented can be justified? How many settings are applied to all users when in theory not everyone needs it applied to them? How many settings are configured but never removed when no longer needed?

Microsoft and other third-party solutions exist such as AGMP (Advanced Group Policy Management) and Netwrix exist that all have ways to audit Group Policy. It is recommended to use these if you have the opportunity, but there is also a method for those of you who don’t have such tools at your disposal. The capabilities to monitor Group Policy changes come built-in to Windows Server. Whilst this method doesn’t tell you exactly what setting has changed, it does tell you when Group Policies are edited, deleted, linked, unlinked, created and by who – so it may well suit your needs.

♣ Enable Directory Service Changes
♣ Configure Group Policy Object Permissions using ADSIEdit
♣ Viewing Group Policy Audit Event Logs
♣ Configure Event Log Forwarding (Subscriptions)

Enable Directory Service Changes

Log on to a Domain Controller and launch the Group Policy Management Console. Edit the Default Domain Controllers Policy found under the Domain Controllers built-in Organizational Unit.

Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> DS Access -> Audit Directory Service Changes.

Check Configure the following audit events -> Success -> OK.

Configure Group Policy Object Permissions using ADSIEdit

Now on a Domain Controller, launch ADSI Edit as an administrator.

Connect to the Default naming context and browse to CN=System -> CN=Policies under your domain name. Right-click Policies and click Properties.

Click the Security tab followed by the Advanced button.

Click on the Auditing tab and then on Add.

Click Select a principal.

Enter Everyone and click OK.

Under Applied to select This object only.

Check the Create groupPolicyContainer objects permission and click OK.

Create a second permission entry for Everyone which applies to Descendant groupPolicyContainer objects.

Check Delete and Modify permissions. Do not click OK yet.

Also check Write versionNumber. Click OK.

Click OK.

Click OK.

Viewing Group Policy Audit Event Logs

The following Event Log ID’s are of interest:

• 5136 – Group Policy changes, value changes, links, unlinks.
• 5137 – Group Policy creations.
• 5141 – Group Policy deletions.

Now when a Group Policy object is created. Event ID 5137 is logged containing details of who created the Group Policy object and the fact an object was created.

The Event Log description also displays the Group Policy Object’s Unique ID – 73744FDF-xx.

Another Event ID 5136 is logged with the Sysvol Path where the Group Policy obect will be stored. The Unique ID is used in the path name.

SYSVOL shows the path directory.

The Unique ID explained earlier also shows against the GPO when using Group Policy Management Console. Also take note of the Computer version which is currently at value 0 since it has not been edited before.

Another Event ID 5136 is logged showing the version number with a value of 0.

The New Group Policy Object value is deleted to make way for the name that was actually given to the GPO.

And as expected the display name is updated with a value of NewGPO.

When a change is made to the NewGPO Group Policy object an Event ID 5136 is logged. The account that made the change is recorded along with the Unique ID that helps you identity which GPO was changed.

The version number is also increased to a value of 2.

That same value reflects within the Group Policy Management Console.

When a Group Policy Object is linked to an Organizational Unit, an Event ID 5136 is logged with information of the user who made the link.

The OU that the GPO was linked to is recorded including a gPLink display name.

There isn’t much difference when a GPO is unlinked. An Event ID 5136 is again logged, only the Type shows as Value Deleted, indicating that the GPO was unlinked from the UserOU OU.

When a GPO is deleted, an Event ID 5141 is logged with the Unique ID of the GPO that was deleted and the user who performed the deletion. With the events now being logged, it’s a good start to tracking and monitoring all Group Policy activity. Another thing I like to do is separate the useful information from the rest of the pack. You are probably aware that the Security log on any server contains thousands of entries, nevermind the Security log of a Domain Controller. One option we have and I recommend this is forwarding the Group Policy related Event Logs to a collector server.

Configure Event Log Forwarding (Subscriptions)

In this scenario, my source Event Log server, the domain controller is named dc.jgspiers.com and the collector, who is collecting the GPO related events is named collector.jgspiers.com. On your Domain Controller(s), run winrm qc. On Windows Server 2012 R2 and above this is already configured however you can run the command just to be sure.

On your collector server, run command wecutil qc.

Since the collector will be reading events from your Domain Controller, edit the Event Log Readers built-in group adding the collector server as a member of that group. The group can be found in Active Directory under the Builtin OU.

On the collector server, open up Event Viewer. Click on Subscriptions and then click Yes on the message to configure the Windows Event Collector Service.

Now right-click Subscriptions and click Create Subscription.

Enter a name and click Select Computers next to Collector initiated.

Click Add Domain Computers.

Add the source (Domain Controllers) and click Test. Once the test has passed click on OK.

Click Select Events.

Check Information. Under Event logs select Security and in the <All Event IDs> box enter 5136-5137, 5141. This ensures the collector only collects Event Logs that we care about. Click OK.

Click Advanced and take note of the firewall port that must be open between the endpoints. HTTPS can be configured if desired. Click OK and then OK again to complete the Subscription creation.

The Subscription will show as below on the collector server..

Before Security events will be collected, you must allow the NETWORK SERVICE account access to the Security log via permissions. Launch RegEdit on each Domain Controller and navigate to HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security. Double-click the CustomSD REG_SZ.

Append (A;;0x1;;;S-1-5-20) to the end of the value. S-1-5-20 is the SID of the NETWORK SERVICE account. Click OK.

After a short moment in time you should start to get forwarded events in relation to Group Policy changes in the Forwarded Events location of Event Viewer on the collector server.

You could create a PowerShell script to send an email and use this script in a Scheduled Task which executes upon event log creation. That way you’ll receive an email upon these alerts rather than having to go looking for them.

Load Balancing sessions is an important part of the Citrix architecure. It ensures your session is placed on the best available Virtual Desktop Agent. Afterall, you don’t want to end up on a VDA alongside 23 other people when there is another VDA with only 15 users logged on to it. Not only does such a mishap affect you, it affects everyone else who is sharing that server and resources with you.

On the other hand though, it might be a good thing that load balancing happened in this way. You might have VDAs part of a Delivery Group that are better performing than others. More RAM, extra CPU and so on. Regardless of the use case, Load Index and some Citrix Studio policy settings can help achieve the right balance.

By default, load balancing works of a metric called Load Index. Out of the box, the Load Index value which can range from 0 to 10,000 is calculated based on how many sessions run on a machine. That is it. A VDA running 3 sessions will have a higher Load Index than a VDA running 2 sessions for example. Each session adds 0.4% to the Load Index.

Based on the fact that a session equals to 0.4% Load Index percentage or a Load Index value of 40, 250 sessions are allowed on a host. This is changeable via policy which I explain later on.

Here is an example of the Load Index of a VDA, as viewed from Citrix Directory. The Session Count value is 0.4% so we can assume since no default settings have been changed that there is one active session on this host.

Note: Load Index does not apply to Desktop OS machines, only Server OS.

Now when two sessions are placed on the host, the Load Index increases to 0.8%. Simple stuff.

You can also view the Load Index value from Citrix Studio by using the Select Columns action and selecting Load Index. The value here is not in percentage but rather a numerical value. Remember load is calculated from 0-10,000. Since the value here is 80, each session will increase the load by 40. 250 sessionon the host would max the value out at 10, 000.

The Load Index is also viewable using the Get-BrokerMachine PowerShell command. The value provided here is the same one shown in Studio.

To change how Load Index is calculated we can turn to Citrix Studio policies. Under Load Management whilst the setting Concurrent logons tolerance does not affect Load Index calculation, it does allow you to specify how many session logons a VDA can concurrently process.

By default 2 concurrent logons can process at one time. Logons are generally the most resource intensive so based on the performance of your VDAs you can lower or increase this value.

The CPU usage policy allows you to define a percentage upon which full load is reported. If the percentage is set at 70%, full load will be reported when a VDA CPU runs at 70%.

In this example with a 70% CPU limit set, here is an example of the Load Index being calculated at 71%. The actual VDA CPU is running at 50% in this example hosting two concurrent sessions.

When the CPU is increased above 70%, the Load Index reports Maximum Load at 100%. In Director 7.12+ you can click on failure types to get some more information. http://www.jgspiers.com/citrix-director/#Failure-Reasons

The Troubleshooting dailog shows that the Load Index has reached maximum capacity.

Once CPU consumption increases on a VDA, the Load Index increases gradually too around every 30 seconds. This ensures that a sudden spike in CPU even for 30-60 seconds will not cause a VDA to report full load.

As CPU consumption drops then Load Index drops around 1300-1500 (13-15%) roughly every 30 seconds. When Load Index is at 10000 or 100%, it takes around 2 – 2 1/2 minutes to decrease.

The CPU usage excluded process priority policy excludes processes from load calculation that have a priority of below normal or low. You can change the setting to Low or disable it completely.

Other policy settings include Disk usage and Memory usage. These values contribute to calculated Load Index along with CPU usage if enabled. By default these settings are disabled. When CPU, memory and disk usage settings are enabled the value of Load Index seems to be calculated by taking the highest value from one of these counters, and then adding 5% of the average value from the remaining counters.

A Maximum number of sessions setting also exists, this is the setting that allows you to change the maximum number of sessions that can be placed on a VDA. By default the value is 250 as discussed previously.

Find Unused Citrix VDAs Script.

Description: This script finds and reports to text file Citrix XenApp or XenDesktop VDAs which have not been logged on to for a defined period of time. This is helpful when determining VDAs that are now unused and can be reassigned or decommisioned.

Instructions: To avoid failure, run PowerShell as an administrator with atleast Read Only Citrix administrator permissions. Run this script from a Delivery Controller.

Download (click below):

Find Unused VDAs Script (6 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.

This script is not signed so when downloading you may receive a “Publisher could not be verified” message, this is generally only appearing on Internet Explorer and not the likes of Google Chrome. You can still download the file regardless.

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.

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.

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.

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.

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.

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

The following post describes how to configure SAML authentication with NetScaler as the IdP (Identity Provider) and Microsoft Office 365 as the SP (Service Provider). Going above just using SAML, a mixture of Azure Multi-Factor Authentication, User Certificates, LDAP and Negotiate authentication policies are used for authentication from external and internal locations.

To follow this guide, you should have atleast a single NetScaler ADC running Enterprise licensing or above. You should also have an Active Directory domain and a subscription to Office 365 with a verified external domain in place. The domain you use with Office 365 should be added as a UPN to Active Directory if it is not already your domain name suffix. The domain you also use with Office 365 cannot be set as primary. Microsoft do not allow primary domains to be federated. It is normal to set your default onmicrosoft.com domain as the primary domain.

♣ The Authentication Scenarios
♣ Additional Reading
♣ What is SAML
♣ Create Office 365 Domain Federation
♣ Create required Authentication Policies, Policy Labels and Login Schemas
♣ Create external AAA vServer and bind policies
♣ Authentication Results – External Users
♣ Create internal AAA vServer and bind policies
♣ Authentication Results – Internal Users
♣ Traffic Trace for external Certificate + LDAP Authentication

The Authentication Scenarios

The authentication methods and scenarios described in this post are as follows:

• Internal users that can make contact with a Domain Controller use Integrated Windows Authentication for access to Office 365 services. Any non-Windows device that cannot perform IWA is not discussed, however it would be easy enough to support such device types.
• External users with a user based certificate authenticate to Office 365 services with certificate based authentication followed by LDAP.
• External users without a user based certificate authenticate to Office 365 services with LDAP followed by Azure Multi-Factor Authentication.

Note: Whilst following the guide, you could keep things simple and only use LDAP authentication for external users. I just like to go a bit further to show the capabilities.

Additional Reading

This post talks about the use of Azure Multi-Factor Authentication but does not go into detail on how to setup or configure the required components and integrate the solution with NetScaler. To read how to setup and configure this technology see http://www.jgspiers.com/azure-multi-factor-authentication-netscaler-unified-gateway/

This post also talks about the use of nFactor Authentication for NetScaler. To read more on this feature see http://www.jgspiers.com/nfactor-authentication-with-netscaler-gateway/

What is SAML

SAML (Security Assertion Markup Language) provides a way for one federation (Identity Provider) to authenticate with another separate federation (Service Provider) typically to consume available services. As a SaaS provider, Office 365 (the Service Provider) directs users who want to authenticate to the service across to NetScaler (the Identity Provider). NetScaler is normally connected to Active Directory, however supports a number of different authentication protocols and as such can challenge the user for a range of authentication methods. If a user can successfully authenticate, the NetScaler sends a SAML assertion (token) to Office 365. Since Office 365 is configured to trust the NetScaler IdP, the token is accepted and users are granted access to the service.

Create Office 365 Domain Federation

To get started, you should have AD Connnect configured between your on-premise Active Directory and Office 365. This allows synchronisation of user accounts and attributes. I’ll not go into detail on how you set this up but within the Office 365 Admin Center go to Settings -> Services & add-ins -> Azure multi-factor authentication.

You can run the readiness check tool from here, then download and install AD Connect on your internal AD servers.

When you have AD Connect running, users from your Active Directory will be synchronised to Azure AD as part of your Office 365 package.

The next steps requires you to configure your instance of Azure AD for federation. You should have an external certificate ready matching the FQDN that Office 365 uses when redirecting users to NetScaler to complete authentication. The destination (redirect URL) will point to a NetScaler AAA vServer. In my case, the Redirect URL is https://aaa.jspiers.org. When providing this certificate to Office 365, you do not include the private key.

On your Domain Controller, run the Azure Active Directory PowerShell Module.

Enter command Connect-MsolService.

Enter credentials of an Office 365 Global Administrator. Click Sign in.

Run and following commands:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“yourcertlocation.crt“)

$certData = [system.convert]::tobase64string($cert.rawdata)

Run and following commands:

$domain = "yourdomain.com"

$fedBrandName = "yourfedname"

$IdPloginurl = "https://AAAURL/saml/login"

$IdPlogouturl = "https://AAAURL/cgi/tmlogout"

Run the following command which sets your domain name up with federated authentication:

Set-MsolDomainAuthentication -DomainName $domain -FederationBrandName $fedBrandName -Authentication Federated -PassiveLogOnUri $Idploginurl -SigningCertificate $certdata -IssuerUri $IdPloginurl -ActiveLogOnUri $IdPloginurl -LogOffUri $IdPlogouturl -PreferredAuthenticationProtocol SAMLP

To check the settings you entered, run Get-MsolDomainFederationSettings -Domain domainname. 

To checked that the domain is now using federated authentication run command Get-MsolDomain. If you need to change the domain back to managed authentication run Set-MsolDomainAuthentication -DomainName domainname  -Authentication Federated

Create required Authentication Policies, Policy Labels and Login Schemas

A number of authentication policies are required to support the different scenarios when users are external or on the internal network. A mixture of LDAP, Certificate, Negotiate and Azure authentication policies will be created and used depending on where the user is located.

For more information on Azure Multi-Factor Authentication including setup and configuration see http://www.jgspiers.com/azure-multi-factor-authentication-netscaler-unified-gateway/

First, to create the Azure MFA policy navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Actions -> Servers -> Add.

Specify a name, insert the IP of the Azure MFA server. Specify a higher timeout than the default of 3 seconds. This gives users time to respond to the OTP, Phone Call or Authenticator application prompt. Enter bind credentials and then scroll down.

Under Server Logon Name Attribute enter UserPrincipalName. We use UPN because we want users to enter their email address to log on. Users are typically used to entering an email when accessing Office 365, Exchange OWA and any public email providers. Whilst there is no requirement for me, if you want to extract user groups during authentication then enter memberOf underneath Group Attribute. Expand More.

Enter mail under Attribute 1 and objectGUID under Attribute 2. These are additional attributes that Office 365 expects to receive within the SAML assertion. The objectGUID is an important attribute as this value is what Office 365 uses to direct users to the correct mailbox. Office 365 uses this value as your ImmutableID. This value is unique for every user. Finish creating the LDAP profile.

Navigate to Security – >AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policies -> Add.

Enter a name for your Azure MFA policy, under Action Type select LDAP and under Action choose the new MFA policy you just created. Use true for the expression and click Create.

Next we create a SAML policy. Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> SAML IDP -> Profiles -> Add.

Enter a name. Under Assertion Consumer Service Url enter https://login.microsoftonline.com/login.srf. Under IDP Certificate Name choose the public certificate which matches your AAA vServer external URL users will be redirected to for authentication. Remember you also specified this same certificate when creating the Office 365 domain federation. Under Sign Assertion choose ASSERTION. Under Issuer Name specify your external AAA vServer URL in the format https://fqdn/saml/login. Scroll down.

Untick Reject Unsigned Requests. For Signature Algorithm choose RSA-SHA265. For Digest Method choose SHA256. For SAML Binding choose POST. Click More and scroll down.

Under Audience enter urn:federation:MicrosoftOnline. Under Skew Time the default value is 5 but can be lowered. This value specifies the amount of time difference that is allowed between the SP and IdP. Under Name ID Format choose Persistent and enter an expression of HTTP.REQ.USER.ATTRIBUTE(2).B64ENCODE. This specifies that the objectGUID attribute will be sent in the Assertion as Name ID. Under Attribute 1 enter Email and then enter expression HTTP.REQ.USER.ATTRIBUTE(1). Finish creating the SAML profile.

Click on the Policies tab -> Add.

Enter a name, choose the SAML profile you just created under Action and enter an expression of HTTP.REQ.HEADER(“Referer”).CONTAINS(“microsoftonline”).

Next a certificate policy will be created. Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Actions -> CERT Actions -> Add.

Enter a name and under User Name Field select SubjectAltName:PrincipalName. Click Create.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policies -> Add.

Enter a name, choose CERT under Action Type and then select your certificate action. Enter true for expression and click Create.

The next policy created will be another LDAP policy. This policy is for users who have a certificate to be challenged for LDAP as next-factor. Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Actions -> LDAP Actions -> Add.

Enter a name and specify the IP address of your preferably Load Balanced LDAP server. Enter bind credentials and scroll down.

Under Server Logon Name Attribute enter UserPrincipalName. Click More.

Under Attribute 1 enter mail and under Attribute 2 enter objectGUID. Finish creating the LDAP action.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policies -> Add.

Enter a name, under Action Type choose LDAP. Under Action select the LDAP action you just created and enter an expression of true. Click Create.

The next policy is another LDAP one. This policy will not perform explicit LDAP authentication but will be used simply to obtain the required attributes that Office 365 expects to see in a SAML Assertion. This policy will be used for internal users only. Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Actions -> LDAP Actions -> Add.

Enter a name, specify an IP address and enter bind credentials. Uncheck Authentication. Scroll down.

Under Server Logon Name Attribute enter userPrincipalName. Click More.

Under Attribute 1 enter mail and under Attribute 2 enter objectGUID. Finish creating the LDAP profile.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policies -> Add.

Enter a name, choose LDAP under Action Type and then select the LDAP profile you just created under Action. Enter an expression of true and click Create.

The next policy is of type NEGOTIATE. The Negotiate policy allows internal users to authenticate using Integrated Windows Authentication. Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Actions -> NEGOTIATE Actions -> Add.

Enter a name, under Domain Name specify your domain name. The username and password fields are required however you can enter a dummy account that does not even exist. It is not used. Under NTLM Path enter the FQDN to a Load Balanced web server that will be contacted for NTLM authentication. The web server should support NTLM. IIS is a perfect candidate. Click Create.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policies -> Add.

Enter a name, specify NEGOTIATE under Action Type and choose the Negotiate action you just created. Enter an expression of true and click Create.

The next step involves creating a Login Schema. This schema is for external users who authenticate with a user certficate and are then asked for LDAP credentials. The schema extracts the username from the certificate so you don’t have to manually enter it. If you need more information on Login Schemas and Policy Labels see http://www.jgspiers.com/nfactor-authentication-with-netscaler-gateway/

Create a Login Schema that resides in /flash/nsconfig/loginschema. The Login Schema extracts your username from the user certificate and then asks for your LDAP password.

The XML file should contain the following:

<?xml version="1.0" encoding="UTF-8"?><AuthenticateResponse xmlns="http://citrix.com/authentication/response/1"><Status>success</Status><Result>more-info</Result><StateContext /><AuthenticationRequirements>
<PostBack>/nf/auth/doAuthentication.do</PostBack><CancelPostBack>/Citrix/Authentication/ExplicitForms/CancelAuthenticate</CancelPostBack><CancelButtonText>Cancel</CancelButtonText>
<Requirements><Requirement><Credential><ID>login</ID><SaveID>ExplicitForms-Username</SaveID><Type>username</Type></Credential><Label><Text>Username</Text><Type>plain</Type></Label><Input><AssistiveText>Please supply either domain\username or user@fully.qualified.domain</AssistiveText><Text><Secret>false</Secret><ReadOnly>true</ReadOnly><InitialValue>${HTTP.REQ.USER.NAME}</InitialValue><Constraint>.+</Constraint></Text></Input></Requirement><Requirement><Credential><ID>passwd</ID><SaveID>ExplicitForms-Password</SaveID><Type>password</Type></Credential><Label><Text>Password:</Text><Type>plain</Type></Label><Input><Text><Secret>true</Secret><ReadOnly>false</ReadOnly><InitialValue/><Constraint>.+</Constraint></Text></Input></Requirement>
<Requirement><Credential><Type>none</Type></Credential><Label><Text>Please enter your password</Text><Type>confirmation</Type></Label><Input /></Requirement>
<Requirement><Credential><ID>saveCredentials</ID><Type>savecredentials</Type></Credential><Label><Text>Remember my password</Text><Type>plain</Type></Label><Input><CheckBox>
<InitialValue>false</InitialValue></CheckBox></Input></Requirement><Requirement><Credential><ID>loginBtn</ID><Type>none</Type></Credential><Label><Type>none</Type></Label><Input><Button>Log On</Button></Input></Requirement></Requirements></AuthenticationRequirements>
</AuthenticateResponse>

Navigate to Security -> AAA – Application Traffic -> Login Schema -> Profiles -> Add.

Enter a name and then click the pencil icon.

Select the Login Schema XML file you just created and click Select.

Click Create.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policy Labels -> Add.

Enter a name, under Login Schema choose the schema policy you just created. Click Continue.

Click Click to select.

Choose the standard LDAP policy which will be asked when users complete certificate authentication. Click Select.

Choose END next to Goto Expression. Click Bind.

Click Done.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policy Labels -> Add.

Enter a name and select noschema as the Login Schema. Click Continue.

Click Click to select.

Select the internal no authentication LDAP policy. Click Select.

Choose END under Goto Expression and click Bind.

Click Done.

Create external AAA vServer and bind policies

Next we create an AAA Virtual Server. This Virtual Server is public facing only and will serve external users. This is a typical scenario where the NetScaler resides in the DMZ. Navigate to Security -> AAA – Application Traffic -> Virtual Servers -> Add.

Specify a name, an IP Address and click More.

Enter your domain name under Authentication Domain. Click OK.

Click No Server Certificate.

Click Click to select.

Choose your public AAA certificate. Click Select.

Click Bind.

Since we are also doing an element of certificate authentication we have to bind the root or intermediate issuing CA certificate to the AAA vServer. Click No CA Certificate.

Select your root or intermediate certificate and click Select. Click Bind -> Close.

You’ll end up as below with one server and one CA certificate. Click on No SAML IDP Policy.

Click Add Binding.

Click Click to select.

Select the SAML policy and click Select.

Click Bind.

Click Close.

Click No Authentication Policy.

Click Click to select.

Choose the certificate authentication policy. Click Select.

Click Click to select under Select Next Factor.

Choose your Policy Label which extracts the username from certificate and presents LDAP fields. Click Select.

Click Bind.

Click Add Binding.

Make sure the priority is higher than the certificate authentication policy. Click Click to select.

Select the Azure MFA policy. Click Select.

For Goto Expression select END. Click Bind.

Click Close.

Under SSL Parameters check Client Authentication and set it to Optional.

Click Done.

Save your configuration via GUI or via CLI using command save ns conf.

Authentication Results – External Users

Now it is time to test the authentication to Office 365 externally, using SAML Assertions from NetScaler.

The first test is a user with an issued user certificate. When you browse to https://login.microsoftonline.com and enter your email address, you are prompted to select a certificate (if you have one). You can configure Internet Explorer/Chrome to skip any prompts and automatically select the certificate. In this case, I click manually select the cetificate and click OK.

I am then directed to NetScaler triple A. The username from my certificate is extracted so now I only need to enter my LDAP password. After doing so, click Log On.

If authentication is successful, an assertion is sent to Office 365 and I am granted access to my account.

The second test is with no user certificate. Upon entering my email address to https://login.microsoftonline.com I am directed to the NetScaler AAA vServer. This time since I do not have a user certificate I am explicitly prompted for a username and password. After clicking Log On you will receive an Azure MFA challenge. This could be a one-time password text message, phone call or Authenticator app prompt.

The Authenticator app prompt when used appears as below. Click Approve. 

I am then successfully directed to my Office 365 account.

Create internal AAA vServer and bind policies

Now that we have external users taken care off, we want to be able to authenticate internal users with a different set of policies. In theory, when users enter their email address to Office 365 they should be able to use Integrated Windows Authentication to log on so they do not even have to enter a password. The password they used to log on to their PC is simply sent to NetScaler automatically.

Create a new AAA vServer with an internal facing IP. Click More.

Enter your domain name and click OK.

Click No Server Certificate.

Click Click to select.

Select the same public certificate you attached to the external vServer. Click Select.

Click Bind.

Click No SAML IDP Policy.

Click Add Binding.

Click Click to select.

Select the SAML policy and click Select.

Click Bind.

Click Close.

Click No Authentication Policy.

Click Click to select.

Select the Negotiate policy and click Select.

Click Click to select under Select Next Factor.

Select the NoSchema Policy Label. Click Select.

Click Bind.

Click Close.

To support passthrough, we also need to create and bind a Session Policy to this vServer. Under Policies click +.

Choose Session and click Continue.

Click Click to select.

Click Add.

Enter a name and then click the plus symbol next to Request Profile.

Enter a name. For Default Authorization Action specify ALLOW. For Single Sign-on to Web Applications specify ON. Click Create.

Enter an expression of true and click Create.

Now choose the newly created Session Policy and click Select.

Click Bind.

Click Done.

Save the running configuration. The NetScaler configuration is now complete.

On your internal DNS servers, create an A record for your Redirect URL which points at the internally addressable AAA vServer. This will prevent internal users from trying to route to the external AAA vServer.

For passthrough to work, you also need to make sure the AAA FQDN is added to your Local Intranet zone in Internet Explorer. Sites in Local Intranet have the required setting enabled by default “Automatic logon only in Intranet zone”.

Authentication Results – Internal Users

Now when internal users log on to https://login.microsoftonline.com watch how their logon happens automatically.

Note: If you have non-Windows devices they obviously cannot do Integrated Windows Authentication on the internal network. For such devices you will have to create additional authentication policies and use expressions to appropriately target those policies to the right devices.

Traffic Trace for external Certificate + LDAP Authentication

Below is an example of some of the steps that occur when certificate and LDAP authentication takes place against the NetScaler AAA vServer and a SAML assertion is posted to Office 365.

The initial SAML request is sent from Office 365 to NetScaler AAA.

The end-client connecting does an intial GET request for AAA page tmindex.html.

Notice the referer for the content is https://login.microsoftonline.com.

NetScaler returns an HTTP 200 OK. A series of GET requests then occur for content that make up the page.

The end-client does a POST to get available authentication methods.

Another POST is sent to get the nFactor authentication methods.

End-client intially performs certificate authentication as requested by NetScaler.

NetScaler starts an nFactor session for the user authenticating and the flow for authentication is determined.

End-client sends the second factor LDAP credentials to AAA.

NetScaler makes a bind request to LDAP and authentication is attempted.

If LDAP authentication is successful, AAA creates a session cookie and the user is successfully logged on. At this stage authentication is complete.

The end-client sends a POST requesting the SAML assertion.

NetScaler sends the assertion to the user, which is then forwarded to Office 365 to complete the process.

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.

In this guide I discuss the steps involved for a successful deployment of Sophos Endpoint Protection in a Citrix App Layer.

There are two layers you need to work on to successfully layer Sophos. An Application Layer of course and also the OS Layer.

As you may or may not know, the SAM Database is only writeable in the OS Layer and any user or group created in Application Layers are not captured. To layer Sophos we need to create a local user and couple of local groups and for this reason the OS Layer is used for user/group creations and the Application Layer is used to store the Endpoint Protection software, all configurations and definition updates.

To begin, open a new version of your OS Layer and create the following local Groups:

• SophosAdministrator
  • Add Domain Admins or other groups who should be Sophos administrators to this local group.
• SophosOnAccess
• SophosPowerUser
  • Add groups that should be designated as Sophos Power Users to this local group.
• SophosUser
  • Add your Domain Users group here.

Next create a user account. Keep a secure note of the password and make sure the password is long. Check Password never expires and click Create.

Add this local account to the SophosUser group. Click OK. At this stage you should finalise the OS layer.

Create a new Application Layer for Sophos and install Endpoint Protection using your normal methods. Configure Sophos settings and any exclusions as desired. Next browse to %ProgramData%\Sophos\AutoUpdate\Config and open iconn.cfg in notepad.

Next to AllowLocalConfig = change the value from 0 to 1. Save and close the configuration file.

Open Sophos and browse to the Secondary location tab. Enter any value next to fields Address and User name. Click Change next to Password.

Enter the password value you used when creating the local Sophos user account in the OS Layer. Click OK.

Click OK.

A new file is created in the %ProgramData%\Sophos\AutoUpdate\Config directory named iconnlocal.cfg. Open this file in a text editor.

Copy the value beside UserPassword=

Open Sophos again, navigate to the Secondary location tab and remove any values in Address/User name/Password fields and click OK.

Open iconn.cfg again, this time changing the value of AllowLocalConfig back to 0. Save and close the file.

You should make sure to delete the iconnlocal.cfg file as it is no longer needed.

Open RegEdit and navigate to HKLM\SOFTWARE\WOW6432Node\Sophos\AutoUpdate\Service. Now double click REG_SZ Download Password.

Replace the existing value with the value you copied from iconnlocal.cfg. Next click Download User and replace the existing value with the name of the local Sophos account you created in the OS Layer.

Open services.msc and manually stop the Sophos Agent, Sophos AutoUpdate Service and Sophos Message Router.

Navigate to %ProgramData\Sophos\AutoUpdate\data and delete machine_ID.txt.

Within RegEdit, navigate to HKLM\SOFTWARE\WOW6432Node\Sophos\Messaging System\Router\Private and delete both pkc and pkp REG_BINARY objects.

Navigate to HKLM\SOFTWARE\WOW6432Node\Sophos\Remote Management\ManagementAgent\Private and again delete both pkc and pkp REG_BINARY objects.

Finish off the layer by running preparation jobs such as NGEN.

Finally run Shutdown For Finalize. You are now ready to publish Sophos as a layer.

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 (47 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

As of NetScaler 12.0 build 51.24 authentication to NetScaler Gateway virtual servers can be performed by StoreFront rather than LDAP.

To send authentication requests to StoreFront, we must use an AAA virtual server which required NetScaler Enterprise licensing.

Impersonation is used by StoreFront to log on the user connecting through NetScaler Gateway. NetScaler sends credentials to StoreFront in JSON format.

To get started navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Actions -> StoreFrontAuth -> Add.

Enter a name and the URL to your StoreFront server. Click Retrieve Auth Enabled Stores and use the drop-down to select the specific Store you wish to use. For domain, enter your domain NETBIOS name. Click Create.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policies -> Add.

Enter a name, choose Action Type StoreFrontAuth and use the drop-down to select your recently created StoreFront authentication action. Enter an appropriate expression and click Create.

Next create an AAA Virtual Server. The server does not need an IP so use Non Addressable as the IP type and click OK. 

The virtual server does not need a certificate so click Continue.

Click on No Authentication Policy.

Select your StoreFront authentication policy and click Bind. Finish creating the AAA vServer.

Next navigate to Security -> AAA – Application Traffic -> Authentication Profile -> Add.

Enter a name and choose your AAA vServer under Authentication Virtual Server. Under Authentication Host enter anything. Click Create.

Bind the Authentication Profile to your NetScaler Gateway virtual server. Click OK -> Done.

Now test logons by browing to the NetScaler Gateway URL. The logon screen is rendered by NetScaler using RfWebUI or whichever theme you use.

Once you click log on, the security logs of StoreFront show the new logon as below.

At an HTTP level, NetScaler sends a POST to StoreFront.

The credentials are sent via JSON with masked credentials.

Afterwards NetScaler sends the normal GET request for Receiver for Web UI. 

StoreFront should reply with a 200 OK.

Native one time password using Citrix NetScaler is a new feature released in version 12.0 build 51.24. Using the native OTP capabilities of NetScaler reduces the need to purchase third party authentication systems when you want to protect your resources with multiple factors of authentication.

Native OTP is built on the nFactor authentication system which requires an AAA Virtual Server and advanced authentication policies. I have described nFactor in detail including it’s capability across the following posts:

http://www.jgspiers.com/single-sign-on-office-365-netscaler-saml-azure-mfa-authentication/

http://www.jgspiers.com/netscaler-nfactor-authentication-google-recaptcha-first-ldap-second-factor/

http://www.jgspiers.com/nfactor-authentication-with-netscaler-gateway/

Because we need to use nFactor, you’ll require a NetScaler Enterprise license at a minimum.

The following guide describes setting up a one-time password portal where users enrol their mobile devices and manage their enrolled devices going forward. NetScaler Gateway will also be used to protect XenDesktop resources by challenging users for their LDAP credentials and a one-time password. The mobile app used to provide the one-time password is Google Authenticator.

Create an Authentication virtual server. An IP is not needed so set the IP Address Type to Non Addressable. Click OK.

Bind any server certificate to the virtual server. It does not matter which one.

Make sure the Portal Theme is set to RfWebUI. Click OK -> Done.

Next create an Authentication Profile and under Authentication Host enter any URL, it does not matter. Under Authentication Virtual Server select the AAA vServer you just created. Click Create.

Edit your NetScaler Gateway virtual server and under Authentication Profile choose the profile you just created. No basic authentication policies should be attached to the NetScaler Gateway vServer. Click OK.

Next we will create a required advanced Authentication Actions/Profiles, Policies, Login Schemas and Policy Labels. Firstly navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Actions -> LDAP -> Add.

The first LDAP server action will be for standard LDAP authentication. Enter a name, the LDAP IP and bind account information.

Under Server Logon Name Attribute enter sAMAccountName. Under Group Attribute enter memberOf if you want to perform LDAP group extraction and under SSO Name Attribute enter cn. Click Create.

Create a second LDAP action, this time for OTP authentication. Uncheck Authentication and enter other details as below.

Under OTP Secret enter userParameters and click Create.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policies -> Add.

Enter a name for the OTP LDAP policy. Under Action select the LDAP OTP action. Enter an expression of true and click Create.

Create a second authentication policy for OTP management using LDAP. Under Action select the standard LDAP authentication action that has authentication switched on. Under Expression enter HTTP.REQ.COOKIE.VALUE(“NSC_TASS”).EQ(“manageotp”). Using this expression, only users who browse to the OTP management portal will be challenged for this LDAP policy. Click Create.

Create a third and final authentication policy for OTP using LDAP. Select the same LDAP standard authentication policy that have authentication turned on. Enter an expression of true and click Create.

Next we need to create two Login Schemas. Navigate to Security -> AAA – Application Traffic -> Login Schema -> Profiles -> Add.

Enter a name for the OTP management portal and under Authentication Schema click the pencil button.

Select the OTP management schema. Click Select. You should create your own schema and place on the NetScaler under directory /nsconfig/loginschema/. I have pasted the Login Schema for OTP management below which you can copy and paste in to your own XML file.

ManageOTPSchema.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AuthenticateResponse xmlns="http://citrix.com/authentication/response/1">
<Status>success</Status>
<Result>more-info</Result>
<StateContext></StateContext>
<AuthenticationRequirements>
<PostBack>/nf/auth/doAuthentication.do</PostBack>
<CancelPostBack>/nf/auth/doLogoff.do</CancelPostBack>
<CancelButtonText>Cancel</CancelButtonText>
<Requirements>
<Requirement>
<Credential><Type>none</Type></Credential>
<Label><Text>Please log on</Text><Type>heading</Type></Label>
<Input/>
</Requirement>
<Requirement>
<Credential><ID>login</ID><SaveID>login</SaveID><Type>username</Type></Credential>
<Label><Text>User name:</Text><Type>plain</Type></Label>
<Input><Text><ReadOnly>false</ReadOnly><InitialValue></InitialValue><Constraint>.+</Constraint></Text></Input>
</Requirement>
<Requirement>
<Credential><ID>passwd</ID><SaveID>passwd</SaveID><Type>password</Type></Credential>
<Label><Text>Password:</Text><Type>plain</Type></Label>
<Input><Text><Secret>true</Secret><Constraint>.+</Constraint></Text></Input>
</Requirement>
<Requirement><Credential><ID>otpmanage</ID><Type>none</Type></Credential><Input><Text><Secret>false</Secret><Hidden>true</Hidden><InitialValue>1</InitialValue><Constraint>.+</Constraint></Text></Input></Requirement>
<Requirement>
<Credential><ID>Logon</ID><Type>none</Type></Credential>
<Label><Type>none</Type></Label>
<Input><Button>Submit</Button></Input>
</Requirement>
</Requirements>
</AuthenticationRequirements>
</AuthenticateResponse>

Click Create.

Now create a second Login Schema, this time for OTP challenges. Enter a name and click the pencil button.

Select your challenge OTP schema under directory /nsconfig/loginschema/. This schema is made up of Username, Password and Passcode boxes for LDAP and OTP factors. Click Select. I have pasted the Login Schema for OTP challenges below which you can copy and paste in to your own XML file.

LDAPOTPSchema.xml

<?xml version="1.0" encoding="UTF-8"?>
<AuthenticateResponse xmlns="http://citrix.com/authentication/response/1">
<Status>success</Status>
<Result>more-info</Result>
<StateContext></StateContext>
<AuthenticationRequirements>
<PostBack>/nf/auth/doAuthentication.do</PostBack>
<CancelPostBack>/nf/auth/doLogoff.do</CancelPostBack>
<CancelButtonText>Cancel</CancelButtonText>
<Requirements>
<Requirement><Credential><ID>login</ID><SaveID>ExplicitForms-Username</SaveID><Type>username</Type></Credential><Label><Text>User name</Text><Type>plain</Type></Label><Input><AssistiveText></AssistiveText><Text><Secret>false</Secret><ReadOnly>false</ReadOnly><InitialValue></InitialValue><Constraint>.+</Constraint></Text></Input></Requirement>
<Requirement><Credential><ID>passwd</ID><SaveID>ExplicitForms-Password</SaveID><Type>password</Type></Credential><Label><Text>Password:</Text><Type>plain</Type></Label><Input><Text><Secret>true</Secret><ReadOnly>false</ReadOnly><InitialValue></InitialValue><Constraint>.+</Constraint></Text></Input></Requirement>
<Requirement>
<Credential><ID>passwd1</ID><SaveID>passwd1</SaveID><Type>password</Type></Credential>
<Label><Text>Passcode:</Text><Type>plain</Type></Label>
<Input><Text><Secret>true</Secret><Constraint>.+</Constraint></Text></Input>
</Requirement>
<Requirement><Credential><ID>saveCredentials</ID><Type>savecredentials</Type></Credential><Label><Text>Remember my password</Text><Type>plain</Type></Label><Input><CheckBox><InitialValue>false</InitialValue></CheckBox></Input></Requirement>
<Requirement><Credential><ID>loginBtn</ID><Type>none</Type></Credential><Label><Type>none</Type></Label><Input><Button>Log On</Button></Input></Requirement>
</Requirements>
</AuthenticationRequirements>
</AuthenticateResponse>

Click More.

Enter 1 in the Password Crential Index box. We want to capture the credentials entered in the first factor for authentication to StoreFront. Click Create.

Navigate to the policies tab and click Add.

Enter a name for the OTP management schema and select the same under Profile. Enter an expression of HTTP.REQ.COOKIE.VALUE(“NSC_TASS).EQ(“manageotp”) which makes sure only users browsing to the OTP management portal receive this Login Schema. Click Create.

Create another Login Schema for the OTP challenge for users authenticating to NetScaler Gateway. Enter an expression of true. Click Create.

To create Policy Labels which contains next factors of authentication, navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Policy Labels -> Add.

Enter a name for the OTP Policy Label. Under Login Schema select noschema. Click Continue.

Under Select Policy click Click to select.

Select the OTP LDAP policy where authentication is turned off.

Under Goto Expression select END. Click Bind.

Click Done.

Next a Traffic Policy is needed to make sure StoreFront is presented with credentials (username/password) from the correct factor of authentication and not the OTP passcode factor which would obviously result in an error. Navigate to NetScaler Gateway -> Policies -> Traffic Policies -> Traffic Profiles -> Add.

Enter a name and scroll down.

Under SSO Password Expression enter http.REQ.USER.ATTRIBUTE(1) and click Create.

Click the Traffic Policies tab -> Add.

Enter a name and select the Request Profile you just created. Under Expression enter true. Click Create.

Browse to your NetScaler Gateway virtual server and next to Policies click +.

Use the drop-downs to select Traffic and Request. Click Continue.

Click Click to select.

Select the Traffic Policy you just created.

Click Bind.

Now we have to bing the Authentication Policies and Login Schemas to the AAA vServer, as well as linking the Authentication Policies the single Policy Label. Edit your AAA vServer and click No Login Schema.

Click Click to select.

Choose the OTP management Login Schema which only evaluates if the users NSC_TASS cookie matches manageotp.

Click Bind.

Bind the second Login Schema for LDAP and OTP challenges. That Login Schema should have a higher priority. Anyone not browsing the OTP management URL are presented with an LDAP and OTP schema to authenticate to NetScaler Gateway. Click Close.

Click No Authentication Policy.

Click Click to select.

Select the management OTP LDAP policy which evaluates when users have a NSC_TASS cookie matching manageotp.

Click Click to select under Select Next Factor.

Select the noschema OTP Policy Label.

Click Bind.

Click Add Binding to begin binding the Authentication Policy for NetScaler Gateway authentication.

Click Click to select.

Choose the OTP challenge LDAP policy. This policy have an expression of true for all users accessing the NetScaler Gateway URL.

Under Select Next Factor click Click to select.

Select the noschema OTP Policy Label.

Click Bind.

Click Close.

Save the running configuration. The setup is complete.

Users must firstly enrol their phones to be able to use OTP. The URL they need to use is https://netscalergatewayurl/manageotp. In my case, https://unifiedgateway.jgspiers.com/manageotp. When browsing to this URL, NetScaler sets a cookie against your session which allows the management OTP Login Schema and LDAP authentication policy to evaluate. Enter an LDAP username and password and click Submit.

Since this is the first time logging in, no devices will be registered. To register a device click Add Device.

Enter a name to identity the device your enrolling such as your personal Android or corporate mobile. Click Go.

A QR code displays. You’ll need to download Google Authenticator to your phone.

Once downloaded open Google Authenticator and click Scan a barcode. Scan the QR code and then click Done in the OTP management portal.

You’ll get the Added successfully! message. To test authentication is working with one-time passwords click Test.

Using your phone, look at the current one-time password.

Type this code into the management portal and click Go. You should receive a verification successful message. You can return to the OTP management portal at any time to test authentication, delete devices or add more devices.

Within Active Directory for users who have enrolled, the userParameters value is updated including the name users specified during enrollment. 

Now when you want to authenticate with NetScaler Gateway, omit manageotp from your URL, instead entereing https://netscalergatewayurl. Since you aren’t browsing the management OTP URL, no cookie is set and as a result you are presented with the OTP challenge Login Schema. Enter your LDAP credentials and one-time password. Click Log On.

You should successfully authenticate and reach StoreFront.

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.

This script can be used to prepare layers right before they are finalised.

To install and configure App Layering 4.x see: http://www.jgspiers.com/installing-configuring-unidesk-4/

To create and update an OS Layer see: http://www.jgspiers.com/create-update-os-layer-unidesk-4/

To create and update an Application Layer and create Elastic Layers see: http://www.jgspiers.com/application-layers-elastic-layering-unidesk-4/

Script author: George Spiers – @JGSpiers

With thanks to Trentent Tye for allowing me to include his Ghost Device removal script.

Tested working on OS version: Windows Server 2016, Windows Server 2012 R2, Windows Server 2008 R2, Windows 10, Windows 7.

Description: This scripts runs a number of tasks to clean out temporary folders, clear out Event Log entries, remove ghost devices from Device Manager, and run NGEN native image regenerations before shutting down the image in preparation for layer finalisation. If running this script on Windows 8.1+ or Windows Server 2012 R2+ there is an extra firewall check that looks to see if any of the firewall profiles are disabled and if so, asks if you want to enable them. When patching within an OS Layer version my patching software requires a number of ports to be open and it is easier just to temporarily disable the firewall until patching is done. The problem was remembering to enable the firewall again!

Note: You should run this script each time you create an OS Layer version, Application Layer/version and Platform Layer/version.

Instructions: You must run this script as an administrator. You must also set the PowerShell Execution Policy to atleast “RemoteSigned” or “Unrestricted”.

Download (click below):

App Layering Preparation Script (96 downloads)

Whilst not in-depth by any means, this post should hopefully help you understand how Load Balancing works on NetScaler and how some of the different options affect where your requests end up at the back-end.

Load balancing of a service can be performed in a number of ways as decided by the NetScaler administrator. We refer to the ways NetScaler load balances traffic as methods. A number of methods exist and some of the popular ones are:

• Round Robin – One of the most simple to configure and understand. Round Robin sends each request sequentially to back-end servers.
• Least Connection – The default method on NetScaler and suits most requirements. Directs traffic to the service that has least connections.
• Least Response Time – Directs traffic to the service that has least connections and lowest response time. Metrics are calculated every 7 seconds. This can be chosen for HTTP and SSL services only.
• Least Packets – Directs traffic to the service that has received the least packets in the last 14 seconds.

What I find is people often get confused as to how exactly requests are load balanced. In many cases, you may think that when browsing to a web page load balanced by NetScaler, the entire request is sent to a single specific service based on the load balancing method. The truth is that it is each HTTP GET request that is load balanced individually across the back-end servers. A request to load a web page generally results in several different HTTP GET and 200 OK responses.

To help you understand this better, in this example, I am load balancing the IIS default web page across two back-end servers. There is no persistency set and the load balancing method is Round Robin. It takes 3 HTTP GET requests from the client to load the IIS default web page. In return, it takes web servers 3 HTTP responses to send that requested data to the client. Here is a WireShark trace. You can see the three HTTP GET requests a client makes to NetScaler:

To confirm, I test web page hits against a single load balanced Virtual Server on NetScaler.

The load balancing method used is Round Robin.

Two back-end web services are bound to the virtual server. Both configured on port 80 and using the same weight.

At the beginning, the services have received no hits. Now we will see what happens when you browse to the VIP.

Using Internet Explorer, I enter the URL pointing to the load balanced VIP and successfully receive the default IIS splash page.

Looking back at the Virtual Server statistics, you can see that my 3 HTTP GET requests were load balanced across both back-end servers. Not just one as many people would think. What happens if we browse to the VIP again?

Since Round Robin is being used, we would indeed expect that the requests even out. Since WEB01 received the 1st and 3rd requests last time, this time WEB02 received the 1st and 3rd requests with WEB01 receiving the second.

There are different features on NetScaler that affects how traffic is load balanced. One of these configurable settings is Weights. You can assign weights to each of your services for example if a web server can handle more requests than the other. In this example, I’ve assigned a weight of 5 to WEB02. What this will mean is that for every 1 request that reaches WEB01, 5 requests should be directed to WEB02. Let us test the theory.

Browsing to the load balanced VIP for the first time.

The results show that WEB02 took two requests and WEB01 took one.

Upon browsing to the VIP again, WEB02 takes all 3 requests. Now the next time we browse WEB01 should take atleast one request.

And it does. WEB01 takes another single request and WEB02 takes the other two. If I was to browse again, WEB02 would consume all three requests reaching a total of 10 requests.

As a summary, you may look at these statistics in production and think something is wrong, so it is important to understand how different settings affect load balancing even if it doesn’t look normal at first glance.

Persistence is another factor that controls which server receives a request, of course because with persistence clients are sent to the same back-end server until the persistent connection expires or is flushed. To show you how it does affect, I’ve configured SOURCEIP persistence on the load balanced Virtual Server with a timeout of 2 minutes.

After browsing to the load balanced VIP address, all three requests as expected are sent to a single back-end server.

Browsing again within the 2 minute period sends all requests again to WEB01.

The next test sees persistence changed to COOKIEINSERT. As clients browse to the load balanced VIP, NetScaler sends a cookie to the client’s web browser which will later be used for persistency. The COOKIEINSERT method is also time based and once the time limit lapses, the existing cookie expires.

It is recommended that you use Version1 cookies to ensure compatibility with all clients. To configure Version1 cookies, navigate to System -> Settings -> Change HTTP Parameters -> Cookie.

All three requests successfully directed to WEB02.

As mentioned, you can configure a timeout value. The default is 2 minutes. A timeout value of 0 would result in the persistent session never timing out. If you right-click the persistent cookie and view properties within Temporary Internet Files, you’ll see the expiry time of two minutes by default:

You can also specify a name for the cookie. If not specified, a cookie name is generated for you.

Cookie Insert persistence does not appear in the persistence table on NetScaler, because it is a cookie. To view the persistence table for other methods, navigate to Traffic Management -> Virtual Server persistence sessions.

You should also configure a Backup Persistence method when using COOKIEINSERT. This can be SOURCEIP. The reason being, in most cases you cannot control if browsers are configured to accept cookies. Also some browsers will empty cookies when closed.

If you look at the services after enabling COOKIEINSERT persistence, you’ll see a generated Persistence Cookie Value.

Finally, there are some other factors to be aware off that can affect how NetScaler balances requests. Without going in to too much detail, some of these are:

• Services that are DOWN will of course not receive any requests.
• Slow Start – If a Virtual Server state changes to online, or a new service is bound to a Virtual Server, the Virtual Server can initially use Round Robin to distribute requests to back-end servers. Eventually, the actual load balancing method specified on the Virtual Server will be used. NetScaler does this to prevent a single server becoming overloaded with requests. For example, you have Least Connection configured with two services both handling many requests. A new third service is bound to the Virtual Server and now a whole load of new requests flood to the new server which clearly will have the least connections. This could be overpowering for the back-end server and result in overload, which affects user experience as their request takes longer to complete. To configure Slow Start (also known as Startup Round Robin), you can do so either Globally or at a Virtual Server level. For example, setting Slow Start to a value of 10 will make NetScaler use Round Robin for the initial 10 requests before switching to the specified load balancing method.
  • Gobally – Configure setting Startup RR Factor under Traffic Management -> Load Balancing -> Change Load Balancing Parameters.
  • Virtual Server – Within the Virtual Server properties under Method, configure settings New Service Startup Request Rate and optionally Increment Interval.
    • If specific values are not set globally or at Virtual Server level, by default a newly configured Virtual Server operates in Slow Start for the first 100 requests received. If one or more services are newly bound or newly enabled, or if the load balancing method is changed, NetScaler dynamically computes the number of requests to serve in Round Robin mode.
    • Hash based load balancing methods are not supported with Startup Round Robin.

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:

The NetScaler Management and Analytics Service was released in the 2nd quarter of 2017 as a cloud offering from Citrix Cloud. Using MAS allows you to automate the deployment, management and monitoring of NetScaler appliances hosted across single or multiple resource locations.

There also is an on-premises variant of MAS. For a detailed guide see http://www.jgspiers.com/citrix-netscaler-management-analytics-system/

For a list of what’s new, fixed and known issues with NetScaler MAS Service, see https://docs.citrix.com/en-us/netscaler-mas/netscaler-management-and-analytics-service/release-notes.html

The MAS Service supports NetScaler MPX, VPX, SDX, CPX, NetScaler Gateway and NetScaler SD-WAN appliances. To manage such appliances, you install a NetScaler MAS Agent in your Resource Location. The agent collects all required data from your NetScaler appliances and sends to the MAS Service within Citrix Cloud.

♣ Features not supported (September 2017)
♣ Supported web browsers
♣ MAS Service Agent System Requirements
♣ MAS Service Firewall Port Requirements
♣ Minimum NetScaler versions required
♣ Minimum XenApp/XenDesktop versions required
♣ Minimum Citrix Receiver versions required
♣ Thin Clients supported for HDX Insight
♣ HDX Insight data retention periods based on NetScaler licenses
♣ Install MAS Service Agent
♣ Add first Instance to MAS
♣ Automate a Load Balancing Deployment using StyleBooks
♣ MAS Dashboard
♣ Create Site
♣ Manage Instances
♣ Viewing Events generated from Instances
♣ Instance Groups
♣ Delete or view details of MAS Agents
♣ Viewing Reports from all Instances
♣ Viewing Event Messages for all Instances
♣ Configure Syslog
♣ Create Rules
♣ Configure Event Severity
♣ Viewing the SSL Dashboard and installing Certificates
♣ Configure Enterprise Policy Settings
♣ View SSL Audit Trail
♣ Create Configuration Job
♣ Maintenance Tasks
♣ Viewing Configuration Audit
♣ Create Audit Template
♣ Sites and IP Blocks
♣ Network Functions
♣ View and Manage Load Balanced Virtual Servers and Services
♣ Generate Reports
♣ Thresholds
♣ Analytics
♣ Deploy extra MAS Agents and Prune Events/Syslog messages
♣ Configure Role Based Access Control
♣ Change Data Record settings
♣ Configure how long data persists
♣ Create Threshold
♣ Manage Subscriptions and Auto-selection of managed Virtual Servers
♣ View Audit Log Messages
♣ Enable Insight
♣ Extract saved configuration from NetScaler and use in an Audit Template

Features not supported (September 2017):

Whilst NetScaler MAS from Citrix Cloud provides many of the features available in the on-premises version, the following features are currently not supported as of September 2017:

• Deployment
  • Migrating Insight Center to NetScaler MAS Service.
  • Integrating NetScaler MAS Service with Citrix Director.
• Application Analytics and Management
  • Managing and monitoring HAProxy instances.
  • Advanced analytics.
• Networks
  • Support for NetScaler SD-WAN Enterprise Edition.
  • Backup and restore of NetScaler instances.
  • Physical downloads of backups from NetScaler instances.
  • Physical download of SSL Certificates and Keys from NetScaler instances.
  • Single sign-on to NetScaler appliance GUI.
  • Record and Play functionality in Configuration Jobs.
  • NetScaler VPX check-in/check-out licensing.
  • NetScaler pooled capacity.
• Web Insight, SSL Insight, TCP Insight, Video Insight and WAN Insight.
• Limited system settings.
• Orchestration
  • Integration with OpenStack and VMware NSX Manager.
  • NetScaler automation in Cisco ACI’s Hybrid Mode.
  • Container Orchestration: Integration with Mesos/Marathon and Kubernetes.

Supported web browsers:

• Internet Explorer 11+.
• Chrome 19+.
• Safari 5.1.1+.
• Firefox 3.6.25+.

MAS Service Agent System Requirements:

An Agent is required within your Resource Locations that have a NetScaler presence. The Agent acts as the communication broker between your managed NetScaler instances and Citrix Cloud. The Agent can be installed on Azure, AWS, XenServer, ESX, Hyper-V or Linux KVM. The requirements for the MAS Agent are:

• 8GB RAM with 32GB RAM being recommended by Citrix for better performance.
• 4 vCPU with 8 vCPU being recommended by Citrix for better performance.
• 120GB HDD with 500GB recommended by Citrix for better performance.
• 1Gbps NIC.

MAS Service Firewall Port Requirements:

Minimum NetScaler versions required:

• For StyleBooks – 10.5 and later.
• For Monitoring/Reporting and using Configuration Jobs – 10.5 and later.
  • Note: Standalone Access Gateway Standard appliances are not supported by MAS.
• For HDX Insight  – 10.1 and later.
• For Gateway Insight – 11.0.65.31 and later.
• For Security Insight – 11.0.65.31 and later.

Minimum XenApp/XenDesktop versions required:

• For HDX Insight – XenApp 6.5 and XenDesktop 7.0, build 3018.

Minimum Citrix Receiver versions required:

• Citrix Receiver for Windows 4.0.
• Citrix Receiver for Linux 13.0.
• Citrix Receiver for Mac 11.8.2.
• Citrix Receiver for iOS and Android are not currently supported.

Thin Clients supported for HDX Insight:

• WYSE Windows, Linux and ThinOS based Thin Clients.
• 10Zig Ubuntu based Thin Clients.

HDX Insight data retention periods based on NetScaler licenses:

• NetScaler Enterprise – 5 minutes to 1 hour of HDX Insight data retention.
• NetScaler Platinum – 5 minutes to over a month of HDX Insight data retention.

Install MAS Service Agent:

Citrix recommend you install a MAS Agent in each datacentre that hosts NetScaler instances to be managed by MAS in Citrix Cloud. There is no high availability option atleast for the moment so all agents are active. To deploy multiple Agents, you deploy the first Agent as I am about to show you and then from the MAS Service in Citrix Cloud use the web application console to deploy any additional number of Agents.

To get started, log on to https://citrix.cloud.com and click Manage under NetScaler Management and Analytics Service.

Click Get Started. You have to deploy an agent to your Resource Location first before doing anything else.

Select your hypervisor from the drop-down and then click Download Image. You can download an Agent image for Hyper-V, Linux KVM, XenServer, ESX or deploy on to Azure and AWS (no image download required). Deploying to Cloud does not require an Agent download, as the image already exists in the Azure/AWS marketplace.

In this guide, I use Hyper-V. Keep this page open as you’ll need to copy/paste the Activation Code and Service URL during Agent configuration. The Activation Codes are unique to each Agent. In the case of installing multiple Agents, you generate new Activation Codes from the MAS console.

Once the image has downloaded extract it and then take a copy of the Dynamic VHD, uploading it to your Clustered Shared Volumes or datastores. Create a Virtual Machine, attaching the Dynamic VHD to the Virtual Machine to act as the system disk. In the case of ESX, import the downloaded OVF template.

Power on the virtual machine. You’ll reach the MAS initial network configuration section. Using the menu items, configure the network as below making sure the appliance can access the internet to contact Citrix Cloud. Save and quit.

Note: The default credentials for the MAS Agent is nsrecover/nsroot.

Note: If you need to later reconfigure network settings, run CLI command networkconfig.

Enter the Service URL and Activation Code that shows on the Citrix Cloud portal.

Add first Instance to MAS:

Return back to Citrix Cloud and your new agent should show under Discovered Agents. At this stage you can import a NetScaler instance to be managed by the MAS Agent. You can add MPX, VPX, SDX, CPX, Gateway, SD-WAN (WO) and HAProxy instances. Click Add Instances.

Enter the IP address (NSIP) of your NetScaler appliance to be added to MAS. If you have a NetScaler cluster, specify the Cluster IP address. If you are adding a High Availability pair, add the primary node and the secondary will follow. The ns_nsroot_profile contains default NetScaler credentials. Considering you will likely have a different set of credentials for nsroot, you can click the plus icon to add a new profile. Once ready, click OK.

Note: You can also add instances from a text file containing each instance IP address, using option Import from File.

After a few moments, MAS should add the appliance and now Instances shows a value of 1. If you are done adding instances, click Done. If not, click Add Instances and repeat the process.

Click OK.

The Dashboard pane under Applications show different Load Balanced Virtual Servers discovered on your managed instances. You can click on each one to view the health status, application score, throughput and so on. The App Score defines how well an application load balanced through NetScaler is performing.

Automate a Load Balancing deployment using StyleBooks:

Under Configuration, a number of pre-built StyleBooks are available (with the option to import your own StyleBooks) that can be used on your managed instances for automation of configuration/deployments. For example, you can use the HTTP/SSL LoadBalancing StyleBook to automate deployment of a Load Balanced Virtual Server. Click on a StyleBook to start a deployment.

Note: To create your own StyleBook, see http://docs.citrix.com/en-us/netscaler-mas/12/stylebooks/how-to-create-your-own-stylebooks.html

Enter the required details you would normally specify when creating a Load Balanced Virtual Server, including all the back-end server IPs, port and protocol.

Specify if specific monitors or SSL certificates are required. Select which managed instance(s) you want to deploy the Virtual Server to under Target Instances. You can select multiple instances. You can also perform a Dry Run which won’t apply the configuration to your instances but will perform a test run for evaluation before you run it properly. Otherwise, click Create.

The deployment kicks off and runs through the multiple steps to create a Load Balanced Virtual Server including Server, Service Group and Virtual Server creation and all the bindings.

Once done, you’ll receive the successfully created alert.

Over on NetScaler, the new Virtual Server shows successfully and appears to be configured as desired.

MAS Dashboard:

The Dashboard pane under Networks shows a wealth of information for all your managed services. As shown below, you can see a summary of the number of Certificates, Applications, NetScalers and so on that are discovered by MAS. There is also a map which has the ability to show you where each Virtual Server/Application resides.

You also see s aummary of events by severity and up time which can be filtered from 5 minutes to 1 month.

Further down you can see certificates close to expiry and any instance that has unsaved configuration or configuration drift. If you click on the red Config Not Saved error circle you’ll be presented with the offending appliance that currently has some unsaved configuration.

From here, you can save the configuration direct from MAS. Click Save configuration -> Yes.

The Diff Exists alert will then clear from MAS.

Create Site:

Navigate back to Dashboard and click on Sites.

Sites will normally represent a datacentre or possibly a region within your organisation that has NetScaler presence. A default site will be created for you. To create a new site click Add.

Enter a name to represent the site. Select a Cloud Provider (Private, AWS, Azure or Google Cloud). Enter a location and click Get Longitude and Latitude. If Longitude and Latitude does not return any value, you may have to enter them manually. Finally, create and add an IP Block and click Create. As you will see later, the map populates with resources.

Manage Instances:

Navigate to Instances -> NetScaler VPX. You can also navigate to the MPX, SDX, CPX etc. sections. Here you see a list of appliances being managed by MAS and you can perform numerous actions, add new appliances, delete appliances, associate different profiles with each appliance and so on. If you are adding a new appliance to be managed by MAS, you must assign a MAS Agent to the instance.

Note: If you change NetScaler instance credentials after the instance is discovered, create and attach an updated profile to the instance and then rediscover the instance by clicking Action -> Rediscover.

If you click on the Action button, a number of tasks can be performed such as enabling/disabling Insight, rebooting the appliance, configuring Syslog and looking at events

As mentioned, if you click the Profiles button, you can associate a new profile with the managed appliance. This comes in handy if you were to change credentials on the appliance at a later stage.

If you select an appliance and click Dashboard, you’ll see a screen filled with information specific to that appliance. You can see CPU, Memory, Disk usage, Load Balanced Virtual Server health, HTTP throughput, any outstanding Events and so on.

Scrolling down you see the software and network information of the appliance and the state of any attached network interfaces.

Scrolling down further you can see the Licensed Features, Modes and saved/running configuration. You can also run a comparison between running and saved configuration.

Viewing Events generated from Instances:

Navigating to Networks -> Instances -> NetScaler VPX -> Events shows events specific to the appliance of your choice. By selecting an event, you can get further details, delete the event, clear the event or view a history of events of the same type that have been generated before on the NetScaler instance.

Instance Groups:

Instance Groups allow you to group together two or more NetScaler appliances. This allows you for example to run a Configuration Job against multiple appliances at the same time to further automate deployments and configuration, or update multiple hosts at once rather than running through upgrades individually.

Delete or view details of MAS Agents:

Under Agents, you get a view of existing MAS Agents running within your Resource Location and their State. You can delete agents or view the details of an agent. Agents are automatically updated by Citrix Cloud when a new release is made available.

Viewing Reports from all Instances:

Under Events -> Reports show a summary of events by severity across all your managed instances. The top 10 managed instances that have received the most events are displayed under Top 10 Instances. If an instance goes offline for example an event is generated and displayed here. You can sort the historical data from 5 minutes to 1 month.

If you click in to one of the event graphs, for example the minor graph, a filtered display listing all the minor events is shown. Again you can change the duration from 5 minutes to 1 month. You can also click into a specific event to see more details.

Here you can see more details of an event after clicking in to it.

Viewing Event Messages for all Instances:

Event Messages under Events shows a list of events for all managed NetScaler, NetScaler SDX and NetScaler SD-WAN WO appliances.

Clicking on an event and then selecting History brings you to the Event History pane. Helpful for identifying reoccuring faults on NetScaler.

Configure Syslog:

By default, MAS is not configured to collect Syslog messages from any managed appliance. You can however automate the configuration of Syslog so MAS does receive Syslog messages.

To do so navigate back up to Networks -> Instances and select your instance using the check box. Click Action -> Configure Syslog.

Check Enable. Select your log level and click OK.

After a few moments, syslog will be configured. If you look on the NetScaler instance itself, under System -> Auditing -> Syslog Auditing -> Servers you can see that the MAS server is now configured as a collector for all syslog events.

A syslog policy is also created and bound globally to the instance.

Navigating back to Syslog Messages on MAS you will see syslog messages beginning to populate and show up in the console. You can export syslog messages to PDF, JPEG, PNG or CSV files.

Create Rules:

Rules allow you to create actions based on events that are received by MAS. Click Add.

Check Enabled. You can specify an Event Age for example which would flag an alert if the NetScaler CPU levels exceed a defined threshold for more than 30 seconds, or an instance was offline for more than 15 seconds. Select which severity you want the rule to evaluate against. If you do not select any, all are by default selected. Set the Instance Family to NetScaler.

Select the instance(s) this rule will apply against. If you do not select any, all are considered. Click Add Action.

You can send emails, run a command, execute a job etc. To send an email when the rule is triggered, select Send e-mail Action. You can configure MAS to keep sending the alert until the event is cleared. To create a new email distribution list click the + symbol.

Enter email addresses that should receive the alert and from what email address alerts should be sent from. Click Create.

Finally click OK. You do have the option of altering the email subject and message, or uploading an attachment.

Click Create. You could add additional actions that execute when the Rule is triggered.

The newly created rule shows as below. You can add additional, delete or edit existing rules. You can also specify that the rule is run only during certain times. Click a Rule using the checkbox and click View Schedule and then create a new schedule. You may want to do this if you run resource intensive operations during certain times of the week or month and do not want to be alerted during those times.

Configure Event Severity:

You can configure Event severity by navigating to Networks -> Events -> Event Settings. For example, if you want to change a Major event to Minor/Warning or vice-versa depending on your needs. Check an Event and click Configure Severity.

Using the drop-down, select the new desired severity for the selected event and click OK.

Viewing the SSL Dashboard and installing Certificates:

The SSL Dashboard shows a wealth of information related to SSL certificates, ciphers in use, TLS versions in use and so on. You can see how many certificates that are installed on managed instances are close to expiring, which are self-signed vs CA signed, how many Virtual Servers use SSLv3 and more. A quck glance at this page could help you identity security risks due to vulnerable SSL configurations. You can also install certificates on your managed instances straight from MAS. Click Install.

Browse for and upload a certificate of your choice. Check Save Configuration if you wish which saves the running configuration on an instance after the certificate install is complete. Check the instance(s) you wish to install this certificate on to and click OK.

The new certificate will install and show underneath the SSL Dashbboard in my case as self-signed. Click on the Self signed counter to see a list of which certificates are installed on NetScaler that are self-signed.

Here you see the list as expected. You can delete certificates or view more specific certificate information.

You can also link/unlink certificates straight from the MAS console.

Configure Enterprise Policy Settings:

Navigate to SSL Dashboard -> Settings. This is where you can configure your Enterprise Policy Settings and configure notifications for certificates that are about to expire.

Whilst NetScaler MAS may recommend TLS 1.0 as a protocol, your company may not. The problem here is that Virtual Servers with TLS 1.0 enabled will not be flagged as a risk by MAS until you remove it from the Enterprise Policy Settings section. This is what the section is here for, so you can configure the requirements to that of your organisations to ensure SSL protocols, signatures, key strengths etc. not approved by your organisation are not in use across any of your MAS managed NetScaler instances.

View SSL Audit Trail:

Under SSL Dashboard is Audit Trails which show SSL related events that occurred from each managed NetScaler instance. As you can see, the certificate installation job I executed not long ago shows in the log including the time that action occured. If you install more certificates, remove certificates and so on those actions will be audited and shown under Audit Trails.

Create Configuration Job:

Configuration Jobs allow you to run any type of configuration on NetScaler using CLI commands that have been built in to the job. This can be helpful for automating tasks that you would normally perform manually on NetScaler. The jobs can be scheduled, repeated, run once, run across multiple instances and so on. To create a job click Create Job. In this example I will create a job that adds a VIP address to my single NetScaler managed instance.

Specify a name and instance type (NetScaler, NetScaler SDX, NetScaler SD-WAN WO). Beside SSH, type commands of your choice which you would like the Configuration Job to execute. You could also extract running and saved configuration from managed instances by setting Configuration Source to Instance and then clicking on Extract for Running Configuration or Saved Configuration. You then drag and drop the commands extracted to the commands field. This could be useful to quickly replicate configuration to multiple instances or for Audit Template purposes.

In my example, I’m adding a VIP of 192.168.0.30 so will just manually type the command as below. You can use variables in commands using a dollar sign if for example you want to add different configurations to different instances within the same Configuration Job. For example, adding two VIPs to instance one but adding only one of the VIPs to instance two.

Optionally, you can save this job as a Configuration Template which allows you to re-use this configuration when creating any additional Configuration Jobs in the future. If you have checked Save as Configuration Template then click Save.

Click Next.

You have to select which Instances or Instance Groups that this Configuration Job will be executed against. Select each Instance or Instance Group of your choice using the Add Instances button and click Next.

Click Next if you have no need to use variables. Files can be uploaded to reference variables.

Click Next.

Specify what you want to happen when a command fails. Also set the execution mode (Now or later).

You can specify jobs to execute on instances sequentially or in parallel. If a job fails on one instance it does not continue processing on the remaining instances. You can also tell MAS to send an email report once the job has run, or prompt the administrator running this Configuration Job for instance credentials. Click Finish.

Since I set the job to run now, it executes right away and has completed as shown below. Jobs can be edited and re-run in the future. To view a report of the last executed job result, click on Report.

An Execution Summary PDF report opens with details of the job, when it started, ended and the status etc.

Over on my NetScaler the newly created VIP shows.

Maintenance Tasks:

Maintenance Tasks contain a number of pre-built tasks that can be executed such as the Upgrade NetScaler task. You can not specifically create any of your own tasks. To perform a NetScaler VPX upgrade directly from MAS, see http://www.jgspiers.com/citrix-netscaler-management-analytics-system/#Upgrade-NetScaler

Viewing Configuration Audit:

The Configuration Audit pane shows an overview of all instances that either do not have their running configuration saved or a configuration that drifts from any Audit Templates you create. Audit Templates define what an instance configuration should be and if the true configuration doesn not match the Audit Template, MAS flags the instance under NS Auti Template Violations. Audit Templates are run against chosen instances every 12 hours.

If you click on Settings you can enable email notifications for audit alerts. You need to create a Mail Profile first.

Create Audit Template:

Audit Templates contain configuration you define that should exist in ns.conf on the instances you choose. To create an Audit Template, click Add.

Specify a name and either choose a saved Configuration Template or enter your own commands. The Configuration Template I created earlier called Add VIP will be used.

Click Next.

Choose which instances you want to apply this template too and click Finish. If the instance doesn’t contain a VIP of 192.168.0.30 an alert will flag in MAS under Configuration Audit.

Sites and IP Blocks:

Sites and IP blocks can be created to help localise your managed instances which populates the map under Dashboard with Load Balanced Virtual Servers based on where they reside in the world.

Network Functions:

Navigate to Networks -> Network Functions. Here you see an overview of metrics from all your managed instances. Dashboards exist for Virtual Servers with the highest client connections, lowest throughput and highest throughput etc.

View and Manage Load Balanced Virtual Servers and Services:

Navigate to Networks -> Network Functions -> Load Balancing. Here you get a quick overview of the amount of Servers, Service Groups, Services, and Load Balancing Virtual Servers discovered by MAS on all your managed instances. You can generate a report with the details of each Virtual Server. Click Generate Report.

Click OK under Export Now.

Note: You can schedule reports to be generated daily, weekly (across multiple days) or monthly (across multiple days) that are emailed to you.

The report will download and open as an Excel document. I only have one Load Balanced Virtual Server but when you have multiple, all the details below display for each entity. If you want to generate a report for all services, navigate to Load Balancing -> Services and click the export button.

Under Load Balancing -> Virtual Servers are all discovered Load Balanced Virtual Servers from each managed instance. Virtual Servers will appear here if you have set MAS to auto-select Virtual Servers to manage. If you have disabled the auto-selection of Virtual Servers, you must then manually select those that you want to manage before they show here. You can get a quick and easy view of the state, the instance each Virtual Servers resides on, protocol used and so on from this screen. You can also edit Virtual Servers straight from MAS by clicking on a Virtual Server using the check-box and selecting Action -> Configure.

Here, direct from the MAS console, you can bind/unbind Services/Service Groups, change Basic Settings, Persistence methods and all other settings that you would normally configure using the NetScaler GUI.

Under Load Balancing -> Services you can disable services, view service statistics and view which Virtual Server services are bound to. If you want to generate a report for all services, click the export button.

Generate Reports:

Under Network Reporting -> NetScaler you can generate a number of reports from your NetScaler appliances. Using the drop-down boxes, select a report, instances to gather statistics from and the duration from when to gather statistics from (hour, day, week, month).

Click Run and the report will display below. You can export reports to PDF, JPEG, PNG or CSV.

Thresholds:

Thresholds allow you to specify when MAS should generate an Event and optionally send you an email based on things such as high instance CPU usage, SSL request bytes, current client connections and much more.

Analytics:

Under Analytics, you have HDX Insight, Gateway Insight and Security Insight that also exist on on-premises deployments of MAS. For more information on Insight, see http://www.jgspiers.com/citrix-netscaler-management-analytics-system/#HDX-Insight

Deploy extra MAS Agents and Prune Events/Syslog messages:

Settings allow you to perform new MAS Agent installs, download the latest Agent build media and configure Event and Syslog prune settings.

In this example, you can configure how long you want MAS to keep Event messages for until they are pruned. By default MAS keeps Event messages for 40 days.

Syslog prune settings have a few more options to configure.

Configure Role Based Access Control:

There are some current limitations with RBAC as of September 2017. These are:

• RBAC is not fully supported for StyleBooks or in the Analytics Modules.

Under Settings -> User Administration -> Users you can view the super admin account. The super admin role is assigned to the account that logs on to MAS Service first with Citrix Cloud credentials but can be manually assigned to additional administrators. Any additional Citrix Cloud user who logs on to MAS will be shown here and assigned all permissions except for being able to access the User Administration section.

To create a custom role in MAS and assign to specific users, click on Access Policies -> Add.

In this example I’m creating a policy which allows editing of Subscriptions and read-only permission for all other areas. You can use the Toggle all “View” selection button which quickly sets view permission for all objects and then you can choose edit for specific objects. Click Create.

Next click on Roles -> Add.

Specify a name and move the newly created Access Policy to Configured. Click Create.

Click on Groups -> Add.

Enter a name and move the newly created role to the right. Click Next.

Click Create Group unless you want to limit access to specific instances, applications etc.

Move the users you want to add to this group to the right and click Finish.

Change Data Record settings:

Under Settings -> Analytics Settings -> Configure Data Record Settings allows you to enable/disable Security and HDX Insight logs. By default these logs are enabled so MAS will collect them from Instances that have been configured with Insight.

Using the check boxes, you can turn off HDX/Security Insight logs.

Configure how long data persists:

Under Analytics Settings -> Database Summarization you can change how long minutely, hourly and daily Gateway, HDX and Security Insight data persists on MAS. Click on one of the options.

Here you can change how often the data persists.

Create Threshold:

Thresholds are a handy way to configure MAS to alert you when certain thresholds on the collected analytics from your managed instances are met. To create a Threshold, click Add.

Enter a name, the Traffic Type can be HDX or Security. If selecting HDX you can choose an Entity of Desktops, Applications, Gateways etc. which NetScaler HDX Insight collects data for. Select a duration and specify how you would like to be notified of an alert. Finally click Add Rule to create any number of rules. In the example below, I could configure an alert to be sent via Email or SMS, or have the alert be simply displayed in the GUI when the rule metric ICA RTT for sessions is greater than a value of 100(ms). Once you have your rules defined, click Create.

Manage Subscriptions and Auto-selection of managed Virtual Servers:

Subscriptions are were you can turn Auto-select Virtual Servers either on or off. If on (which is the default), MAS selects Virtual Servers randomly to manage. If off, you have to manually choose your own Virtual Servers before they appear in MAS. If you have more Virtual Servers than licenses then either purchase additional licenses or manually tell MAS which ones to manage. The dashboard also allows you to see how many Virtual Servers are managed and how many Virtual Servers of each type (Authentication, Load Balancing etc.) are being managed. If I was to click on 1 underneath Load Balancing for example I’d be able to see which Load Balancing Virtual Servers MAS is managing. Users on a trial period of MAS Service receive a license for 10 Virtual Servers and 5GB storage as shown in the Subscriptions Summary.

To turn off Auto-select Virtual Servers set the toggle to OFF and then click Select Virtual Servers.

MAS already has a list of discovered Virtual Servers from your managed instances. To choose which Virtual Servers to manage, use the tabs and then click Add Virtual Servers. Use the check box to select a Virtual Server and click Select. Virtual Servers will then appear as below. If you want to unmanage a Virtual Server, check the box next to the Virtual Server and click Mark Unlicensed.

View Audit Log Messages:

Auditing -> Audit Log Messages show a list of Audit Logs related to the NetScaler MAS Service. You can view logins, actions MAS administrators make such as adding a NetScaler instance to be managed, adding/deleting IP blocks, generating reports under Network Reporting and so on.

Enable Insight:

To enable Insight on a VPX appliance for example, navigate to Networks -> Instances -> NetScaler VPX -> select the VPX you want to enable Insight for and click Action -> Enable/Disable Insight.

Using the drop-down, select a View (for example VPN), highlight the Virtual Server of your choice and click Enable AppFlow. You cannot enable Insight on Virtual Servers that are down.

AppFlow can be delivered via traditional IPFIX protocol or the newer LogStream method. Keep in mind that whilst LogStream is a new and efficient way of transporting analytics data from NetScaler instances to NetScaler MAS, it is current in beta. Specify an expression of true, tick Logstream and ICA. Click OK.

After a few moments you’ll see a green tick under AppFlow Logging and the Transport Mode of Logstream.  

Extract saved configuration from NetScaler and use in an Audit Template:

In this example, the requirement is to ensure that a key part of configuration on NetScaler does not change and if it does, MAS alerts us. For this scenario, I am creating a Configuration Job using part of the extracted NetScaler saved configuration, saving the job as a Configuration Template and then using that Configuration Template to build an Audit Template.

Navigte to Networks -> Configuration Jobs -> Create Job.

You don’t have to enter a name. Under Configuration Source select Instance.

Choose an instance and click OK.

Select Saved Configuration and click Extract. Once extraction is complete drag the commands from obhect to the commands field. What I normally do is select the few commands that I need copy them to notepad, click Clear above the commands field and then paste the specific commands in to the commands field. Check Save as Configuration Template, enter a name and click Save. At this stage exit the Configuration Job creation wizard.

Next we need to create an Audit Template. Navigate to Networks -> Configuration Audit -> Audit Templates -> Add. Enter a name and under Configuration Source select Configuration Template. Drag the newly created Configuration Template to the commands field.

Click Next.

Using Add Instances, select any amount of instances or Instance Groups and click Finish. The Audit Template will then be run against each instance(s) every 12 hours.