Category Archives: Citrix

  • 0

A Citrix Active/Active Deployment – Part 4

The last couple weeks have been a hoot.  Here’s the progress that’s been made.

  • XenServer hosts have all been setup (running 7.1)
  • Storage (FC) and NAS have been setup
  • All the VMs have been built, joined to the domain, patched, and prepped.
  • The FMA Site has been configured and settings have been replicated (see ‘delivery controller‘ section)
  • PVS Site has been setup
  • Storefront has been setup
  • Netscaler SDX/VPX have been setup

As you can see we pretty much now have the same components/VMs/Roles in each datacenter.  Interesting that a new Citrix blog post was released talking about Site design (Better than Ever, Xenapp/Xendesktop Site Design (v2017).  This post summarizes some pros and cons on 1 site designs and 2 site designs.  We are still moving forward with the 2 site design approach as it is geared up for the best flexibility, high availability, and stability.

the MyCUGC site has an interesting conversation that talks about some different active/active and active/passive scenarios.  This is worth a read.

In this post I’d like to focus on Storefront configuration.  For the initial deployment I created two Storefront VMs, installed Storefront, and joined them to my existing Storefront server group.  This way all the existing settings propagate to these new VMs.  I thought this was an easy option because the Stores need to have identical names and since all the rest of the settings are pretty much the same, it was just easier.  Here’s an article ( that describes the caveats.  After the propagation, I removed both new VMs from the ‘storefront group’.

We now have a couple things to address:

  1. Aggregation of resources
    1. Export, Edit, and Import of Subscription database file
  2. Multiple Netscaler Gateway per Store
  3. Subscription Synchronization
  4. STA

Aggregation of Resources

The aggregation of resources means Storefront will ‘sort’ through the published apps/desktops in each Site/Farm and present them as a single resource.  For instance in both Sites you have a published Desktop called ‘Administrator Desktop’.  Without aggregating the two Sites/Farms you will see two separate icons, one from each Site.  These icons are usually denoted by the name + (1) or (2) next to it (Ex: ‘Administator Desktop (1)).

What we want to do is aggregate these resources so the user is only presented with one icon, ‘Administrator Desktop’.  In an active/active scenario when User1 clicks on the published resource it launches in Site1.  When User2 clicks on the published resource it launches in Site2, and so on and so forth.

Citrix CTA, George Spiers (@JGSpiers), has a great article on this –  He explains what each checkbox does and how it affects the aggregation of resources.  One thing to note is that some default functionality has changed in the ‘Assign Controllers to the User Groups’ area.


This talks about the order of the Sites to be used in a ‘Failover’ fashion


this talks about the order of the Sites to be used in a ‘random order’.  This 2nd picture is how I have my Stores configured.

I’m using Storefront 7.15 LTSR and from what I can tell George was using Storefront 3.8.  Entering both Sites in this location gives a true balance of resources.

For the aggregation of resources I’m just using the ‘Load balanced’ configuration.  As i still want to be able to publish unique resources at each Datacenter.  I’m guessing this is the more common option and provides more flexibility on on being able to publish specific apps in a specific datacenter, as well as troubleshooting application launches at both datacenters.

XD7.6 is at Datacenter#1 and CTXONE is at Datacenter#2.  Since XA6.5 is being dcommed soon, we will not be configuring it in an HA/GSLB fashion.

           Export, Edit, and Import of Subscription database file

Basically what happens here is, if you enable Storefront aggregation on an existing Storefront server, the subscriptions get tagged with a ‘DefaultAggregationGroup.\’ instead of the ‘Site/Farm’ name.  So what you have to do is

  1. Before you enable aggregation, export the subscription database file –
    1.  Add-PSSnapin Citrix.DeliveryServices.SubscriptionsManagement.Commands
    2. Export-DSStoreSubscriptions –StoreName StoreName –FilePath DataFile
  2. Edit the file by doing find/replace
    1. Find/Replace entry for the sitename
      1. Find: SITE-NAME.       (this is your XA/XD 7.x Site Name)
      2. Replace: ‘DefaultAggregationGroup.\’
    2. Using Notepad++ do a Find/Replace on all lines for
      1. find: \$[A-Z][0-9]*(-[0-9]*|[0-9]*)
        1. What this does is remove any of the $**** entries that is used.  You mostly see this in 7.x Sites.
      2. replace:
  3. Enable aggregation
  4. Import the new file using the commands from the website above
    1. Import-DSStoreSubscriptions –StoreName StoreName –FilePath FilePath

You’re subscriptions should now be working as normal.


Notice i also have a 6.5 farm in my storefront group. Since this farm isn’t being aggreated the tags don’t change at all.  So you shouldn’t have to worry about any of those entries.


Multiple Netscaler Gateway per Store

You basically have two different sets of Netscalers trying to access the same store using the same URL.  So how does Storefront known which Netscaler you are coming from to perform the Authentication?  For this you need to configure the ‘VIP’ and Callback on the specific entry in Storefront.  Carl Stalhood has some good documentation on this here –

Subscription Synchronization

Tips from@CStalhood

  • The store names must be identical in each StoreFront server group.
  • When adding farms (Manage Delivery Controllers) to StoreFront, make sure the farm names are identical in each StoreFront cluster (server group).
  • Load balance TCP 808 for each StoreFront cluster. Use the same VIP you created for SSL Load Balancing of StoreFront. Each datacenter has its own VIP.
  • Run the PowerShell commands detailed at Configure subscription synchronization at Citrix Docs. When adding the remote cluster, enter the TCP 808 Load Balancing VIP in the other datacenter. Run these commands on both StoreFront clusters.
  • Don’t forget to add the StoreFront server computer accounts to the local group CitrixSubscriptionSyncUsers on each StoreFront server.
  1. I basically performed the powershell commands at each side.  I had a start time difference of 5 minutes and the same interval of 10 minutes.  So at Datacenter#1 the synchronization would kick off at 5:00AM, and then run again in 10 minutes.  At Datacenter#2 the synchronization would kick off at 5:05AM and then run again in 10 minutes.  Note: you can added multiple stores to synchronize.  Also, we don’t need to add ‘Store2’ to this list.  Instead of adding multiple stores here, we will be pointing ‘Store2’ to ‘Store1’ Datastore subscription file.
  2. To address having multiple subscription stores per store, we can have each store share a common ‘datastore location’.  This way users that accessing both Stores will share a common subscription location.  We are already addressing the synchronizing between Storefront Groups at each Datacenter.  Follow this article to share a common location –

STA Servers

Since Datacenter#1 Netscalers could be up and Datacenter#2  XA Site could be down, you need to make sure to add the STAs on all Gateway VIPs on the Netscaler and all Netscaler Gateway entries on the Storefront stores.  I’ve seen some diagrams where you can create a GSLB or LB VIP for the STA servers.  That is also an option.

For this setup, I simply added 4 STA entries (1 for each delivery controller) to the configuration locations.

  • 2

A Citrix Active/Active Deployment Part 3

I’m at the point now where the Datacenter#2 has Networking, Storage, and Hosts ready for me to use.  That means it’s VM building time.  You pretty much need the identical components you have for your existing site.  Remember the key focus here is Highly Available and reliability.  So if one datacenter goes down, the other one will be able to take over.  This means we need the same VMs with the same roles.

  • 2x – Storefront Servers
  • 2x – Delivery Controllers
  • 2x – Director Servers
  • 2x – SQL ‘Always On’ Servers
  • 2x – PVS Servers
  • 1x – Licensing Server

Licensing: Usually in Active/Active scenarios you would deploy a Licensing VM and allocate/purchase the same amount of Citrix licenses as the first site.  Since this wasn’t budgeted we will be using a manual failover type of approach when it comes to the licensing server. We’ll be sending both Datacenters to one licensing server.  If that site fails or the primary licensing VM fails, we will manually switch the Citrix Sites to use the backup licensing server.  So technically we will be building a VM, installing the Citrix license role, but not allocating any licenses to it.  This should pass any ‘audit’.  Note:  You technically have 30 days to get the license server up before functionality goes away.  That should be enough time to backup/restore, build new, or whatever.  This backup licensing server will most likely be used in an ‘Ohh SH!…’ moment.

Here is a blurb about ‘Grace Periods’ from Citrix docs –

Grace periods

If product servers lose communication with the License Server, the users and the products are protected by a grace period. The grace period allows the product servers to continue operations as if they were still in communication with the License Server. After the Citrix product checks out a startup license, the product and the License Server exchange “heartbeat” messages every five minutes. The heartbeat indicates to each that they are still up and running. If the product and the License Server don’t send or receive heartbeats, the product lapses into the licensing grace period and licenses itself through cached information.

Citrix sets the grace period. It is typically 30 days but can vary depending upon the product. The Windows Event Log, and other in-product messages, indicate if the product has entered the grace period, the number of hours remaining in the grace period. If the grace period runs out, the product stops accepting connections. After communication is re-established between the product and the License Server, the grace period is reset.

The grace period takes place only if the product has successfully communicated with the License Server at least once.

Grace period example – two sites, both using the same License Server

The connection between Site 1 and the License Server goes down causing Site 1 to go into the grace period, continuing operation and making connections. For concurrent licenses, they can connect up to the maximum concurrent licenses installed. For user/device licenses, they have unlimited connections. When Site 1 reestablishes communication with the License Server, connections are reconciled and no new connections are allowed until they are within normal license limits. Site2 is unaffected and operates as normal.

If the License Server goes down, both sites go into the grace period. Each site allows up to the maximum number of licenses installed. As above, the user/device licenses have no limit.

Storefront:  There are some key considerations when building out the storefront servers with multi-site design in mind.  Please read ‘StoreFront high availability and multi-site configuration’  –   Once we get everything setup, I’ll expand upon aggregating sites.  Stay tuned for a future blog post on those specifics.

When you decide whether to set up highly available multi-site configurations for your stores, consider the following requirements and restrictions.

  • Desktops and applications must have the same name and path on each server to be aggregated. In addition, the properties of aggregated resources, such as names and icons, must be the same. If this is not the case, users could see the properties of their resources change when Citrix Receiver enumerates the available resources.
  • Assigned desktops, both pre-assigned and assigned-on-first-use, should not be aggregated. Ensure that Delivery Groups providing such desktops do not have the same name and path in sites that you configure for aggregation.
  • App Controller applications cannot be aggregated.
  • Primary deployments in the same equivalent deployment set must be identical. StoreFront only enumerates and displays to users the resources from the first available primary deployment in a set, since it is assumed that each deployment provides exactly the same resources. Configure separate equivalent deployment sets for deployments that differ even slightly in the resources they provide.
  • If you configure synchronization of users’ application subscriptions between stores on separate StoreFront deployments, the stores must have the same name in each server group. In addition, both server groups must reside within the Active Directory domain containing your users’ accounts or within a domain that has a trust relationship with the user accounts domain.
  • StoreFront only provides access to backup deployments for disaster recovery when all the primary sites in the equivalent deployment set are unavailable. If a backup deployment is shared between multiple equivalent deployment sets, all the primary sites in each of the sets must be unavailable before users can access the disaster recovery resources.

What I did is built my new VMs, installed Storefront, and joined them to my existing ‘Storefront group’.  This way, everything would have the same names, setup, and configurations.  Afterwards, I disjoined the ‘group’ and added only the storefront servers at Datacenter#2 to a ‘storefront group’.

Director Servers:  For director you will need to follow the Multi-Site instructions – . The overall goal for this will be to have Director at each Datacenter be configured for ‘Multi-Site configuration’.  We will use GSLB to send users to a LB VIP at either Datacenter.

Provisioning Services: We will treat PVS as separate entities.  So build out PVS like you would normally from scratch.  Since we use Unidesk/App Layering we will setup a 2nd ‘app layering connector’ that points to Datacenter#2 PVS servers.  Now, I don’t literally have to publish the template at both locations.  ‘Publishing’ compiles all the different layers, which takes time.  So we could setup a powershell sync/transfer script to copy the VHD to the second PVS store.

SQL ‘Always On’:  Since we will be deploying a Site at each Datacenter, technically that site should have it’s own Servers.   Deploy how you would normally deploy in a standard 1 site configuration.

Delivery Controllers: At this point just build your Site as you normally would.  In another post I’ll go through our different options on how both sites will talk to Storefront, and which sets of icons will be available based on settings.  Initially, I’ll be using my homeboy’s, @ryan_c_butler, replication script to export my current Citrix sites information to Datacenter#2 Citrix site.  This is something that can also be used as a scheduled task to keep both environments in sync.

Over the next week or so i’ll be verifying normal functionality of the site, storefront, netscaler, etc…  After that, i’ll be getting into the Storeront and GSLB configurations.

Stay tuned….

Previous Posts:

Part1 – Introduction –

Part 2 –

  • 0

Citrix App Layering – With Extra Frosting

I’ve had the pleasure of using Citrix App Layering for the past few weeks.  I have to say it’s pretty addicting.  Immediately after using the product I could see it’s potential. What started out as a POC/Demo turned into a layering frenzy.  First the OS layer, the Platform layer, then an App Layer.  Now we have over 40 App Layers, 4 Platform layers and 2 OS layers, all mixed into 10 different images.  This product is so simple to spin up too.

A few of us on twitter were recently discussing how powerful the product is and some ideas we would like to see implemented in future versions.  I wanted to write this to help let Citrix know we love the product, but want to see more!

For those that want some more information on the basics here are a couple websites to get you going:

During this post I’d like talk about the ‘Frosting’.  These are the extra features and possible opportunities I’d like to see Citrix make to the product in the future.  Before anyone starts getting down on me, just know that I’m an optimist and a full believer in exploring new ideas to make something better.  Like all good managers will tell you, the day your employees stop coming to you with new ideas is the day you need new employees.  Also, you can’t get what you don’t ask for.  So here goes…

Extra Frosting Ideas:

  1. Folders – Currently there is no way to categorize any layers.  This is fine if you only have a handful of layers, but if your organization is like mine, you’ll soon have 100+ layers.  You do have the option to ‘search’, but us Citrix Admins like our folders (Appcenter > Studio).
  2. Elastic Layers for ALL – Right now the only way you can provide elastic layers is to deploy an ‘App Layering Image’.  For those that want to try your first elastic layer, you‘ll need to deploy 1 OS layer, 1 Platform layer, and 1 Elastic image.  Citrix should be able to make this simpler and let us deploy an ‘agent’ to a standalone VM/physical PC.  This is a pretty big one IMO.  When admins are demo’ing/POC’ing this product they are going to compare it to App-V, AppVolumes, etc…  Right away the product will fail to meet their needs with the ‘virtualizing apps’ way of thinking.  This product does Image Management firstly, and app virtualizing secondly.  Citrix will need to fix the flexibility of Elastic Layers to truly compete with other vendors in this space.
  3. Provisioning Time – This is probably the number 1 complaint I hear about.  The whole process takes too long.  The majority of the steam comes from ‘publishing the image’, whether it’s to PVS or a Hypervisor.  If your on XenServer/Hyper-V there aren’t as many conversions since the VM itself is VHD.  However, if you run VMware there are conversions that need to happen to go from VMDK to VHD.   If you want to test a new version, be prepared to wait 30 minutes.  Office isn’t activating?  New version and wait 30 minutes.  Forgot something?  New version and wait 30 minutes.  The more layers you have the larger the Image and the longer you’ll have to wait.  This goes for adding versions too, not just publishing.  When you add a new version it takes a copy of the locally stored OS layer and spins up a new disk on the hypervisor of choice.  This all takes time.  Any way of streamlining or making this faster would greatly benefit us admins.
  4. Testing Layers – I think of this one like PVS streaming to server.  We need the ability to test layered versions quickly, without having to wait 30 minutes to publish an image.  Now I don’t need this to be ‘production ready’, I just want something that I can test quickly to verify functionality.
  5. Where’s VHDX – the images that App Layering publishes are all VHD, unless you’re provisioning to VMware.  Over the last two years there have been so many enhancements to use VHDX that I feel Citrix needs to get this incorporated.
  6. DR/HA – Currently Citrix/Unidesk recommends that you backup your ELM (virtual appliance) and CIFS location like you normally would any other device.  Their viewpoint is that if ELM goes down, you aren’t really down.  Since elastic layers will still be available, you just won’t be able to make any changes, to elastic layers or to any layers.  To me this thinking won’t cut it in the enterprise world.  There are teams dedicated to virtualizing apps and managing images.  A missed day could mean a zero day patch doesn’t get deployed.  There is a ‘layer sync script’ for VMware appliances – However, I’m currently using XenServer.  I would love to see something built into the product to manage my high availability for me.
  7. Mix/Match OS layers –  This would give us the ability to use the same layer on multiple OS versions.  While I 100% get why they took away this option, I just would rather they let us choose.  If you want to put a checkbox with a disclaimer that it’s not supported on a per layer basis, fine.
  8. Automation/API – Us admins need the ability to script, automate, and control actions.  It would be nice to be able to script updating Chrome in a new layered version.  That’s just the tip of the iceberg, you could pretty much script all individual parts of the published image (windows updates, patches, new DLLs, etc…).  Think MDT on steroids.
  9. Notifications/Alerting – I like knowing whats going on and being able to fine tune the alerts.  Maybe i want to be alerted when the layer is done sealing, or maybe i want to be notified when the layer is done publishing.  Maybe it’s an email or a popup in the task bar.  I just want notification options 😉

I just want to reiterate, I’m loving this product so far.  The ease of use and power to manage images is amazing.  I have no doubt Ii’ll continue to use it in the future.  These are just a few things I’d love to see in future versions.

Let me know if you have you’re own ideas to better App Layering.

  • 3

A Citrix Active/Active Deployment Part 2

Since Part 1 has been published we have learned a little bit more about the overall design of the environment.  Let’s recap the initial requirements.

  • Management has instructed the team to build a Highly Available and Stable environment that spans multiple data centers.
  • Each technology component must be separate in each datacenter.  Which means, no sharing of Citrix resources for the infrastructure type roles (Broker, Storefront, etc…).
  • We need to be able to test changes in One Datacenter, while not affecting the other datacenter.

Netscalers:  We will have 2 SDX Netscalers at each datacenter.  On each SDX, there will be 1 VPX that’s in an HA pair with a VPX on the 2nd SDX (that houses the Netscaler Gateway, GSLB configuration, Load Balancers, etc…).  Similar to the screenshot below.

Storage and Hosts: There will be hosts and storage placed at each datacenter.  A combination of ESXi and XenServer will be used for the hypervisor.  ESXi will house the infrastructure roles (storefront, delivery controller, PVS servers, etc…).  XenServer will house the session VMs (“Friends don’t let friends get vTax’ed”).  We will have Fiber connection Dell Compellant at each datacenter.  This will provide the storage for our VMs, PVS Stores, etc… User files will reside in one datacenter and will be replicated to 2nd datacenter as ‘read only’.  Should the primary DC go down, the secondary would take over.  This means no matter what datacenter a user logs into, they will access their redirected folders, my documents, etc… in the 1st datacenter.  Note: this is a limit of our storage platform which follows the master/slave rules. This may change over time.

XA/XD Sites:  We chose to deploy two separate sites, one in each DC.  Based on Carl Stalhood’s article (screenshot below) and Chris Gilbert’s article, we could technically get away with deploying 1 site, however we chose to separate this into two due to failure domains.  This will allow us to completely test Site upgrades/updates, PVS image updates, etc… without affecting both datacenters.

Provisioning Services: Each datacenter will have 2 PVS servers for HA.  Each side will connect to their respective SMB share, local to that DC.  We will most likely use a powershell script to copy vdisks across.

Now that we have a better picture of the design, the hosts and storage are setup, and a basic picture of the configuration we’ll begin building out the VMs in the 2nd datacenter.  This will look pretty much identical to the first datacenter.

  • 2x Delivery Controllers
  • 2x SQL severs (Always On)
  • 2x PVS Servers
  • 2x Storefront Servers
  • 2x Director Servers
  • 1x Licensing Server

Once I have these VMs built and installed, along with the Netscaler SDX/VPX, I’ll dive a bit deeper on configuring the ‘multi-site’ components such as Delivery Controller, Storefront, and Netscaler configuration.

In the meantime we have some fine tuning/hardening around sync’ing: Site settings, Storefront subscriptions/stores, and PVS images.  We also need to come up with game plan for multi-site Ivanti/Appsense setup.

Stay tuned for Part 3.


Part 1 – Introduction

Part 2 (this blog)

Part 3

  • 2

A Citrix Active/Active Deployment Introduction


Ok, where does one begin when talking about an Active/Active Citrix Deployment?  I’m frazzled just thinking about it.  Do I start with the Profiles, Netscalers, PVS Images, XenApp Sites…?  Let’s first describe the requirements.  Management has instructed the team to build a Highly Available and Stable environment that spans multiple data centers. Ready…Go!

However vague that is, we will let best practice, use case, and experience dictate the rest.

Our Data Centers are located within 10 miles of each other with dark fiber connecting the two together.  From a response standpoint we should have 50-100Gbps of bandwidth with less than 2ms latency.  Hardware wise, each Data Center will have their own Networking, Storage, Hosts, Internet, Netscalers, etc…

Here are some of he major topics I’ll be covering in more detail in this series of blog posts.  I’m not sure if this will be a 4 series blog post or a 10 series blog post.  I’ll keep writing more and more if the community wants to see more.

Netscalers/Storefront:  High level SDX/VPX placements and configuration for Active/Active setup utilizing GSLB.  What load balancing rules will I follow? How will DNS be used for Internal and External users?

Storage and Hosts: Placement of NAS.  Do files get synced to both locations?  How should my documents files be handled?

XA/XD Sites:  Should I have one or two sites?  Should users have a primary data center?  What will Active Directory group structure look like?

Provisioning Services: Will I have separate PVS deployments, or should they be under the same site?  How should images be synced to the 2nd location?

Profiles: How will profiles be synced across data centers?  If someone logs into Site A in the morning and then logs into Site B in the afternoon, will they have the same settings?

While we may not have all the answers at the moment, here are some soft directions that we have been given as well.  We need to be able to implement changes (host patching, PVS version updates, etc…) at the site level, fail over the site that the changes are taking place in, test those changes, then put users back onto said site, and perform the changes to the other site.  I realize this could all be accomplished in a target format from within a site, however, this is the direction we have been given.

Now, there is not ‘right’ way to accomplish this, especially with the different variables of where the data center is located, the storage back end, and the customer requirements/directives.  As I’ve said before, there are 100 ways to skin a cat.

In the following blogs i’ll get more into the details surrounding the technical setup of the primary components to complete our Active/Active setup.


Part 1 (this blog)

Part 2 

  • 1

Citrix – Smart Access – Conditional Clipboard Access

SmartAccess and SmartControl let you change ICA connection behavior (e.g. disable client device mappings) based on how users connect. Decisions are based on NetScaler Gateway Virtual Server name, Session Policy name, and Endpoint Analysis scan success or failure.

Carl Stalhood has a great blog on how to configure/setup Smart Access.  You can find it here:

Smart Access uses Netscaler Universal Licenses.  Platinum Netscaler Licenses includes this feature, but Enterprise and Standard editions required you to pay for however many you want (usually based upon concurrent users).  This is still the case today.  However, Citrix has recently changed the quantity of Universal Licenses they provide you out of the box. As of Netscaler 11.1.49, New CCU packaging and pricing have changed in the following ways:

1. MaxAAA is automatically set to the maximum licensed number.

2. Licenses now use the following scheme:

a. Platinum: Unlimited (formerly 100)

b. Enterprise: 1000 (formerly 5)

c. Standard: 500 (formerly 5)

d. Any other license: 5

e. If additional CCU licenses are present on the system, you add those to the above values

(for example, standard is 500 + any additional CCU licenses).

f. Disregard additional CCUs for the platinum case, since platinum is already unlimited.

This is awesome news for the community as we’ll be able to provide this functionality at no additional cost, for most organizations.

Smart Access is such a powerful tool and there are many use cases that could be used:

  • Control Device Drive mappings for certain Netscaler Gateways
  • Control Visual Settings/Experience for External/Internal Users
  • Control Application/Desktop icon visibility
  • Etc…

As you can see you can pretty much control and configure any Citrix Policy depending on different access conditions.  This is handled by ‘tagging’ the session as it comes through the Netscaler Gateway via some sort of ‘Netscaler session policy’ condition.  Once the session is ‘tagged’, you’ll create a Citrix Policy with some setting defined filtered by ‘Access Control’.  You’ll define the Netscaler vServer name and the ‘Smart Access’ policy name in the ‘Access Control’ filter in Studio.  When you’re done, you will have a citrix policy is being applied/not applied based on your Netscaler session policy parameters.

In this blog, I’ll focus on controlling Clipboard Access for Internal/External connections.  Here are my requirements.  (Note: Instead of Clipboard, you can substitute that for any configurable Citrix Policy)

  1. Disable Clipboard Access for anyone connecting to Citrix from an External/Untrusted location
  2. Enable Clipboard Access for anyone connecting to Citrix Internally (By default clipboard redirection is allowed)

I’ve Outlined 4 different stages to get this completed:

  1. Prerequisites
  2. Netscaler Configuration
  3. Citrix Policy Configuration
  4. Testing


Follow the rules for setting up Smart Access using –

Note: If you are using a Content Switch to direct users to Netscaler Gateway (with a non addressable IP), you might have to adjust the Content Switch Policy or create a dummy ‘Call back’ vServer to address the Storefront Callback setup.

Netscaler Configuration:

  • Create a Netscaler Gateway Session Profile (Don’t configure any settings, just a blank Profile)
  • Create a Netscaler Gateway Session Policy.  Use the blank profile configured above.
    • Expression: REQ.IP.SOURCEIP != -netmask
      • Feel free to addon with ‘&&’ and/or ‘||’ operators

As you can see I’m looking to see if the user’s endpoint IP Address in NOT in the 192.x.x.x range.

Note: The Session Policy is configurable based upon any Expression you’d like.

  • Bind the newly created Netscaler Session Policy to your Netscaler Gateway vServer
    • Note:  This needs to have a lower priority over all other session policies, so it get’s evaluated every time.

Citrix Policy Configuration:

  • Setup the Smart Access Control Filter in a Citrix Policy (Studio)
    • Create a new policy with ‘Clipboard Redirection’ disabled.
    • Configure ‘Access Control’ as the filter, click Assign and enter in the relevant Netscaler Settings
      • Farm name: is the ‘FarmName:’ value from director (in the director screenshot below)
      • Access Condition: is the name of the Netscaler Session Policy (highlighted in the screenshot above)

Testing Smart Access

  • Confirm the expression is working from Director
    • As you can see, under the SmartAccess Filters tab, you can see the session policy is added.
      • This is because I connected externally, so my IP address IS NOT 192.x.x.x.
      • Note: The Source IP is the Endpoint IP, unless you are routed via NAT.  When you come through a NAT.  Your Source IP becomes your Public IP.
        • This is why the Netscaler Session Policy is true, because i came over an external connection, via NAT.  Thus NOT having an IP address in the 192.x.x.x range, thus making the policy True, thus getting added (or ‘Tagged’, as i like to say) to the SmartAccess Filter.

Well, that should just about do it.  You’re end result is that you won’t be able to copy/paste (clipboard redirection) for users connecting externally.

I’d love to see this process made a little bit more seamless.  Switching the vServer to ICA Mode and being dependent on Universal Licenses should go away IMO and be available Out of the box. Citrix’s Universal License change in Netscaler 11.1.49 is a step in the right direction though.

Thanks to Carl Stalhood and Beau Smithback for resource documentation and help with Setup/Configuration.

  • 2

Citrix Xenapp/Xendesktop 7.9 Database Migration – SQL Express to Mirror

For brand new Xenapp/Xendesktop implementations you are given the option to build out the Site quickly using SQL Express.  While SQL Express may be supported, it’s certainly not recommended.  Any Citrix XA/XD production site/farm should be installed into a full version of SQL.  Many Citrix projects start out as ‘Proof of Concept’ or Trial phase, get vetted out, then move to production.  Since many of these POCs are built with SQL Express (an option when building out a new farm/site), many production environments still utilize this technology.

SQL-MirrorThis blog will focus on migrating an existing Citrix Xendesktop/Xenapp 7.9 Site from a SQL Express 2008R2 database to a SQL 2012 R2 Standard database in a mirrored configuration.  SQL server high availability is a key component in a stable environment.  SQL Mirroring or ‘Always On’ are the two preferred methods.  Mirroring seems to be more prevalent due to the SQL Enterprise license required for Always On.  This changes in SQL Server 2016 Standard. Although there are some limitations.  Ultimately I chose a SQL Mirror configuration in the end.

Citrix has a great article ( detailing this process, so most of the steps and powershell commands I used was from there.  The article also explains some prerequisites that are needed. For instance, the database recovery model must be set to ‘Full’.

I’ll assume you can setup your own 3 SQL Servers (2 SQL Standard, 1 Express Witness).  Confirm the recovery model and other points of interest from Citrix’s article above.  When you have the mirror configuration in place, you can then proceed to run the powershell commands.   I separate this out into 4 batches of code:

First batch – This batch of code disables logging, sets the database server/name variables, and tests out the connections to confirm there are no errors before proceeding

Second batch – This batch of code Sets the Database connection strings to $NULL

Third batch – This batch of code confirms all the Connection Strings are set to $NULL.

Fourth batch – This batch of code sets the currently NULL’ed out Database Connection Strings to the new datbase server location and adds the ‘failoverpartner’ server to complete the Mirrored setup.

Here was a couple gotchas:

  1. When testing with one delivery controller
    1. Citrix policy – ‘prohibit’ enable auto update of controllers
    2. Insert GPO to send VDA to one controller
    3. Remember to remove the policy and put back the 2nd controller when done testing/moved.
  2. Once disabling site logging and monitoring
    1. Do this on both controllers
    2. Then backup database
  3. Issues with  Set-AppLibDBConnection –DBConnection $null
    1. Restart Delivery Controller server
    2. Had to stop the citrix delegated administration service
    3. Then command worked.
  4. Setting Citrix Database Connections to $Null
    1. Make sure all services show up as DBUnconfigured
    2. Do not proceed unless they all are
  5. When you get to the enable site logging and monitoring
    1. Do this on both controllers before proceeding
  6. If changing the database name, avoid using spaces

Below is the Powershell code I used.  I categorized them in batches from ‘First’ to ‘Fourth’.  However, when I actually ran the code, I EXECUTED THIS LINE BY LINE.  This is so I could granularly confirm each output from the command was processed successfully and with desired results.


## This batch of code disables logging, sets the database server/name variables, and tests out the connections to confirm there are no errors before proceeding

#Disable Configuration Logging

Set-LogSite -State “Disabled”

write-host “Close and Reopen Studio”

Set-MonitorConfiguration -DataCollectionEnabled $False

Write-host “Backup database”


## Replace <dbserver> with the New SQL server, and instance if present

## Replace <dbname> with the name of your restored Database




$DBName =”database-name


$cs=”Server=$ServerName; Initial Catalog=$DBName; Integrated Security=True”


Test-AdminDBConnection -DBConnection $cs

Test-ConfigDBConnection -DBConnection $cs

Test-AcctDBConnection -DBConnection $cs

Test-AnalyticsDBConnection -DBConnection $cs

Test-HypDBConnection -DBConnection $cs

Test-ProvDBConnection -DBConnection $cs

Test-BrokerDBConnection -DBConnection $cs

Test-EnvTestDBConnection -DBConnection $cs

Test-LogDBConnection -DBConnection $cs

Test-MonitorDBConnection -DBConnection $cs

Test-SfDBConnection -DBConnection $cs

Test-AppLibDBConnection -DBConnection $cs


## This batch of code Sets the Database connection strings to $NULL

## First unregister the Delivery Controllers from the current database:


Set-ConfigDBConnection -DBConnection $null

Set-AcctDBConnection -DBConnection $null

Set-AnalyticsDBConnection -DBConnection $null

Set-HypDBConnection -DBConnection $null

Set-ProvDBConnection -DBConnection $null

Set-BrokerDBConnection -DBConnection $null

Set-EnvTestDBConnection -DBConnection $null

Set-SfDBConnection -DBConnection $null

Set-MonitorDBConnection -DataStore Monitor -DBConnection $null

Set-MonitorDBConnection -DBConnection $null

Set-LogDBConnection -DataStore Logging -DBConnection $null

Set-LogDBConnection -DBConnection $null

Set-AdminDBConnection -DBConnection $null

Set-AppLibDBConnection –DBConnection $null

Get-Service Citrix* | Stop-Service -Force

Get-Service Citrix* | Start-Service

Write-host “Restart Controller”


## This batch of code confirms all the Connection Strings are set to $NULL.














## This batch of code sets the currently NULL’ed out Database Connection Strings to the new datbase server location and adds the ‘failoverpartner’ server to complete the Mirrored setup.

asnp Citrix*


## Replace <dbserver> with the New SQL server, and instance if present

## Replace <dbname> with the name of your restored Database



$DBName =”DatabaseName

$LogDBName = “DatabaseName

$MonitorDBName = “DatabaseName

$FailoverPartner = “


$cs=”Server=$ServerName;Initial Catalog=$DBName;Integrated Security=True;Failover Partner=$FailoverPartner”

$csLogging= “Server=$ServerName;Initial Catalog=$LogDBName;Integrated Security=True;Failover Partner=$FailoverPartner”

$csMonitoring = “Server=$ServerName;Initial Catalog=$MonitorDBName;Integrated Security=True;Failover Partner=$FailoverPartner”

Set-AdminDBConnection -DBConnection $cs

Set-ConfigDBConnection -DBConnection $cs

Set-AcctDBConnection -DBConnection $cs

Set-AnalyticsDBConnection -DBConnection $cs

Set-HypDBConnection -DBConnection $cs

Set-ProvDBConnection -DBConnection $cs

#Set-PvsVmDBConnection -DBConnection $cs

Set-BrokerDBConnection -DBConnection $cs

Set-EnvTestDBConnection -DBConnection $cs

Set-LogDBConnection -DBConnection $cs

Set-LogDBConnection -DataStore Logging -DBConnection $null

Set-LogDBConnection -DBConnection $null

Set-LogDBConnection -DBConnection $cs

Set-LogDBConnection -DataStore Logging -DBConnection $csLogging

Set-MonitorDBConnection -DBConnection $cs

Set-MonitorDBConnection -DataStore Monitor -DBConnection $null

Set-MonitorDBConnection -DBConnection $null

Set-MonitorDBConnection -DBConnection $cs

Set-MonitorDBConnection -DataStore Monitor -DBConnection $csMonitoring

Set-AppLibDBConnection –DBConnection $cs    # 7.8 and newer

Set-SfDBConnection -DBConnection $cs

##Enable Monitoring

Set-MonitorConfiguration -DataCollectionEnabled $true

##Enable Configuration Logging

Set-LogSite -State “Enabled”

write-host “Restart Citrix Studio.”












Perform this same process on each Delivery Controller in your Site.

I hope this helps everyone.  There really wasn’t anything out there recent as far as blogs on this type of move with XenDesktop/XenApp 7.X.  So there you have it, fully functional database migration with XenApp/XenDesktop 7.9 from SQL Express to Mirrored Configuration.

  • 7



Many companies wish to customize portions or add their little quirks/branding to sections of the Netscaler Gateway/Unified Gateway logon page.  With the introduction of 11.x, customizing the logon page has became increasingly easy.


Netscaler-Disclaimer-EULAThis blog post will cover adding a disclaimer/footer to the logon page.  This can be done via the ‘EULA’ section of the NG.  This approach adds a ‘checkbox’ that you must check before you can continue.  However, you don’t actually need to read any part of the EULA/Disclaimer.   You can simply just check the box and continue on your way.  This might not be suitable for some companies as the user doesn’t need to actually read the text to continue.

You can use ‘Rewrite’ Policies to add a disclaimer/EULA/Footer to the logon page that is 100% shown all the time.  This Rewrite policy can be bound to any Netscaler Gateway vServer.  I’ll give you the commands to create the Rewrite policies.  This method is probably the easiest as the GUI is not intuitive enough to perform this without in-depth knowledge.  Not to mention the information/code seems to change for each version (10/10.1/10.5/11).  It would be great if Citrix documented this more thoroughly, or provided us a simple web gui that denotes each section of the logon page that corresponds to the Rewrite policy pattern.  As a bonus I added a URL to the bottom as well. (You’ll notice that I insert “+” every so often.  This is to get around the 255 character limit.)

Here are the 2 commands that you run:

add rewrite action rw_act_insert_loginfooter insert_before_all “HTTP.RES.BODY(120000).SET_TEXT_MODE(IGNORECASE)” q{ “var login_footer=$(\”<div style=’text-align:center;font-size:15px;color:white;’><br>US Government Notice and Consent. AUTHORIZED USE ONLY. <br><br>You are accessing a COMPANY system which provides access to a U.S. Government information system, which “+” includes: (1) this computer, (2) this computer network, (3) all computers connected to this network, and (4) all devices and storage media attached to this network or to a computer on this network. This information system is provided for U.S. “+” Government-authorized use only. Unauthorized or improper use of this system may result in disciplinary action, as well as civil and criminal penalties.<br><br>”+”By using this information system, you understand and consent to the following: You have no reasonable expectation of privacy regarding any communication or data transiting or stored on this information system. At any time, and for any lawful “+” Government purpose, the Government may monitor, intercept, and search and seize any communication or data transiting or stored on this information system. “+” Any communication or data transiting or stored on this information system may be disclosed or used for any lawful Government “+” purpose.<br><br><a style=’color:yellow;font-size:15px’ href=’’>Forgot Password</a></div>\”).appendTo(logonbox_container);”} -pattern “box_view.prepare_view();”

add rewrite policy rw_pol_insert_loginfooter “HTTP.REQ.URL.CONTAINS(\”gateway_login_view.js\”)” rw_act_insert_loginfooter

Next, you’ll go to the NG vServer in the GUI and add a binding for the Rewrite policy. Netscaler-Rewrite-Bind

Tip:  When testing to confirm everything worked, you’ll need to clear your browsers’ internet cache to see the changes right away.



That’s it.  You now have a working disclaimer.

For those doing two factor authentication, I haven’t found a way to change the 2nd password field using a Rewrite policy on 11.x.  For now you are better off creating a custom theme.


  • 0

Citrix, what if Session Pre-launch could…


*Citrix Session Pre-Launch*

Let’s face it.  EUC is all about the user experience and Users don’t like waiting around for things.  Nor should they, especially when we have tools available to dramatically help.  I’m talking about Citrix’s Pre-Launch feature.  For those not familiar, Pre-Launch gives you the ability to Launch a users’s session before they actually launch it themselves.  When you click on the application, you don’t have to wait for the session to load, GPOs to apply, or mapped drives to connect.  It just opens up like a local application.  Users want and love a ‘local-like’ experience.


This past couple weeks I’ve spent the majority of my time at a hospital in the NICU.  Like many others hospitals, they use XA65, WI, with their application (Epic).  Also like many others, they click on their published applications and wait 20-70 seconds for their application to load.  In life threatening emergencies, that could be the difference b/t life and death.  After taking an informal pole with all the nurses, I’ve concurred the number one complaint is waiting for things to load.  While Citrix Session Pre-Launch won’t solve all their problems, it can make a big difference in their productivity.  I don’t know about you, but hearing a 34 week old baby scream, while the nurse waits for her application to load isn’t the most soothing experience.

So what can we do?

The way this process currently works:

  1. User signs into Xenapp services/Store via Receiver
  2. During the authentication and app enumeration process WI/Storefront checks what app/desktops get published.
  3. If that app/desktop has Pre-Launch configured, a session is started, without user interaction.
  4. This does does consume a license, but can be configured to disconnect after a certain period of time.

This is such an untapped feature that I really never see in the field.  But why?  Why wouldn’t admins/users want to take advantage of this?  There are several reasons IMO.

Pre-Launch Doesn’t get used because:

  1. It consumes a Citrix license right off the bat
  2. It only works when connecting through  Xenapp services/Store
  3. Resource constraints on hardware in the data center

How do we get around these hurdles?  Should we switch all of our customer’s licenses to ‘Concurrent’?  Should we force users to use XA Service/Storefront Store 100% of the time? Typical businesses size their environment based upon max concurrent resources being used, plus growth.  So i’m not too concerned about the Resources, but i’m sure we can improve upon this.

Here is what I propose:

  1. Citrix – upon initiating the pre-launch session should change the ‘state’ of the connection from ‘connected’ to a new state.  Possibly call it ‘pre-launch’ and don’t count this toward a license count.
  2. Enable Session Pre-Launch for web connections.  There’s always a use case for this.
  3. Implement a Scheduled based Pre-Launch at a set time.  At 4:30AM, I’d like to startup a bunch of pre-launch sessions for a group of users that login at 6AM.  When they arrive at work, their sessions are already geared up.  This process needs to be ‘throttle-able’.  Maybe this could be done with a TTL token from their last successful connection as long as it was within 3 days…I’ll let the brilliant coders at Citrix determine the best way.
  4. Create a metric for the “Probability that a User will login”.  We know “Carl” from accounting never gets sick.  For the past 4 months, Carl hasn’t missed a day of work.  This puts Carl’s “Probability to Login” at 100%.  I’d like to start a Pre-Launched session for 90% and above.  Wishful thinking? Maybe, but if you don’t ask for it, you probably won’t get it.



  • 2

System Center Endpoint Protection & Config Manger in Citrix Xenapp/PVS


One ocitrix-logo-250x250f my clients is undergoing a complete Datacenter transformation.  With this comes a lengthy list of multiple decisions on what to bring over from the old to the new.  This post will focus on transitioning their current virtual machine anti-virus protection to a new solution.  The new solution is System Center Configuration Manager/Endpoint Protection in a Citrix XenApp/PVS environment.  This consists of Citrix Xenapp 6.5, PVS 7.1, and System Center 2012 R2.  Although, I don’t really see any reason these same steps wouldn’t work in  later versions of Xenapp and PVS.

Currently they are using Trend Micro Deep Security 9.5 and OfficeScan 11.x to protect their Endpoints as well as their virtual machines.  I have to say, I do really like Deep Security to protect the virtual machines.  Very little maintenance is required and it just seems to do its job well.  Unfortunately, somebody has to pay the bills to keep it licensed.  The client decided to utilize their current Microsoft ‘Enterprise Agreement’ licensing and protect themselves with System Center Endpoint Protection, with Config Manager managing the agents.

While I do realize there are other blog posts out there that contain similar information on this topic, I was not able to use just one site to complete this project.  At the bottom of the post I document where I got most of the resources used to complete this project.SystemCenterEndpointProtection

First, we need to install SCCM into the image.  SCCM is used to manage and control the agents centrally.  It is used to control all the special exclusions, real-time scan settings, etc…  Without it, you would have to manage each agent manually.

SCCM Steps:

  1. Create a new PVS Version
  2. Install the ConfigMgr client
    a. Launch the SCCM setup client from the SCCM server – \\SCCMserver\Client\CCMSetup.exe
    b. Add ‘domain\username’ domain account as local admin on the xenapp 6.5 server.

SCEP Steps:

  1. Run bat file:
    1. MKDIR e:\SCEP
      1. this is the ‘cache drive’ used to store RAM overflow, event viewer, pagefile, and SCEP anti-virus definitions.
    2. cmd.exe /c Mklink /d /j “C:\ProgramData\Microsoft\Microsoft Antimalware” E:\SCEP
    3. Install SCEP executable
  2. In SCCM After SCEP/SCCM is deployed:
    1. Create Device Collection
      1. Add your servers to the collection that you are installing SCEP on.
    2. Create Endpoint Protection Policy
      1. Apply to Device Collection (Device/Antimalware policies tab)
        1. SCEP-antimalware-policy
    3. Create Deployment Endpoint Protection Policy
      1. Apply to Device Collection (Device/Client settings tab)
        1. SCEP-protection-policy

Final Steps:

  1. Seal Image using the following bat file:
    1. Net stop “SMS Agent Host”
    2. del %WINDIR%\smscfg.ini
    3. Powershell -command “Remove-Item -Path HKLM:\Software\Microsoft\SystemCertificates\SMS\Certificates\* -Force”
    4. wmic /namespace:\\root\ccm\invagt path inventoryActionStatus where InventoryActionID=”{00000000-0000-0000-0000-000000000001}” DELETE /NOINTERACTIVE
    5. Del “c:\programdata\citrix\pvsagent\LocallyPersistedData\CCMData\CCMCFG.bak”
  2. Use Xenapp Role Manager to do the final seal and shutdown the image.

Confirm Steps:

  1. Confirm SCCM Policy Deployment to the SCEP agent (on the SCEP agent, drop down arrow, about)
    1. SCCM-confirm3
  2. Confirm the devices are manageable in SCCM
    1. SCCM-confirm1
    2. SCCM-confirm2
  3. Test Protection
    1. I was able to test protection using a ‘dummy’ anti-virus test file
      1. create the .txt file with the string in it.
      2. Safe the file
    3. SCEP should recognize it as a threat and clean the file appropriately

That’s it, your Citrix PVS machines should now be protected by System Center Configuration Manager and System Center Endpoint Protection.  Now I realize there are 100 ways to skin a cat.  Please let me know if have/find any efficiency’s in the steps and i’ll be happy to change the contents of the site.

A big THANK YOU to everyone involved in creating and helping answer questions on the following sites: