Category Archives: Xendesktop/Xenapp

  • 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. https://www.mycugc.org/p/fo/st/per=10&sort=0&thread=2096&p=1

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 (https://docs.citrix.com/en-us/storefront/3/sf-plan/sf-plan-ha.html) 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 – http://www.jgspiers.com/storefront-high-availability-optimal-routing/.  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.

Old:

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

New:

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 – https://support.citrix.com/article/CTX139343?_ga=2.209223634.1931658170.1508160390-868616312.1493145342
    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.

Before:

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.

After:

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 – http://www.carlstalhood.com/storefront-config-for-netscaler-gateway/#gslb

Subscription Synchronization

Tips from@CStalhood http://www.carlstalhood.com/storefront-subscriptions/:

  • 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 – http://docs.citrix.com/en-us/storefront/3-12/configure-manage-stores/configure-two-stores-share-datastore.html

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 – https://docs.citrix.com/en-us/licensing/11-14/technical-overview.html

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’  – https://docs.citrix.com/en-us/storefront/3/sf-plan/sf-plan-ha.html.   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 – https://support.citrix.com/article/CTX136165 . 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 – http://verticalagetechnologies.com/index.php/2017/04/11/a-citrix-activeactive-deployment-introduction

Part 2 – http://verticalagetechnologies.com/index.php/2017/06/06/a-citrix-activeactive-deployment-part-2


  • 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: http://www.carlstalhood.com/smartaccess-smartcontrol-netscaler-11/

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: https://docs.citrix.com/en-us/netscaler/11-1/about-the-netscaler-11-1-release/whats-new-in-previous-11-1-builds.html

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

Prerequisites:

Follow the rules for setting up Smart Access using – http://www.carlstalhood.com/smartaccess-smartcontrol-netscaler-11/

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 != 192.0.0.0 -netmask 255.0.0.0
      • 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. https://msdn.microsoft.com/en-us/library/mt614935.aspx. Although there are some limitations.  Ultimately I chose a SQL Mirror configuration in the end.

Citrix has a great article (http://support.citrix.com/article/CTX140319) 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.

FIRST:

## 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

##

##

$ServerName=”sql-servername\sqlexpress”

$DBName =”database-name

#

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

$cs

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

SECOND:

## 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”

THIRD:

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

## DO NOT PROCEED UNLESS THEY ARE ALL $NULL

Get-AcctServiceStatus

Get-AdminServiceStatus

Get-BrokerServiceStatus

Get-ConfigServiceStatus

Get-EnvTestServiceStatus

Get-HypServiceStatus

Get-LogServiceStatus

Get-MonitorServiceStatus

Get-ProvServiceStatus

Get-SfServiceStatus

Get-AppLibServiceStatus

FOURTH:

## 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

##

$ServerName=”PrimarySQLServerDNSName.domain.com

$DBName =”DatabaseName

$LogDBName = “DatabaseName

$MonitorDBName = “DatabaseName

$FailoverPartner = “SQLFailoverPartnerDNSname.domain.com

#

$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.”

Get-AcctServiceStatus

Get-AdminServiceStatus

Get-BrokerServiceStatus

Get-ConfigServiceStatus

Get-EnvTestServiceStatus

Get-HypServiceStatus

Get-LogServiceStatus

Get-MonitorServiceStatus

Get-ProvServiceStatus

Get-SfServiceStatus

Get-AppLibServiceStatus

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.


Twitter