Creating a Load Balanced Multi-Node Citrix Receiver StoreFront Server Group for use with Citrix CloudGateway

Share Button

Hopefully, you are well aware that Citrix Web Interface is no longer being developed past the current version, 5.4. Stephane Thirion and Thomas Koetzing have covered product development and some background information well in their excellent blog posts you can find here:

Instead of rehashing all the background details, I wanted to go through an advanced multiple server Receiver Storefront deployment with NetScaler being used for load balancing.  Then, I’ll cover the critical components required to connect through Access Gateway Enterprise Edition (on the NetScaler Platform) and Access Gateway VPX (v5.0.4). Let’s start with an architectural overview to discuss the modular components involved:

You will notice that additional databases will be required for more than one store.  If these databases are remote, the same scripts will need to be executed for each new store database to be created properly.

Let’s get started with the basic installation.  The Receiver Storefront can be downloaded from mycitrix.com (valid login required) under the CloudGateway product family. Select CloudGateway Express:

Select Receiver StoreFront 1.0:

Once this is downloaded, the installation is straight forward.  From a fully patched server, launch CitrixReceiverStorefront-x64.exe (Run as Administrator if UAC is enabled):

Accept the license agreement and click Next:

Note, the required roles and components will be installed automatically. Click Next:

Click install:

Confirm that all components were installed properly and click Finish:

The installation steps above are the same for all servers in a given server group, so if you are installing on multiple servers, follow the process above.

Next, we need to do some work to stage the remote SQL Database. Mirrored databases can be used to provide high availability for the Store data using the steps provided under the section “To configure a store to use a mirrored database” (http://support.citrix.com/proddocs/topic/dws-storefront-10/dws-configure-conf-file.html). For this blog post, I am using a remote server with a single database for the server group and initial Store (http://support.citrix.com/proddocs/topic/dws-storefront-10/dws-deploy-multi-database.html).  I’ve found this documentation is not very clear, but these SQL scripts actually need to be run to create additional store databases as well.  If you create a new blank store database without using the provided scripts, users may receive the notification below:

First, a local security group (on the SQL servers) or domain security group must be created so we can group all of the Receiver StoreFront servers and assign SQL permissions. I prefer the domain security group option for accessibility. Simply create a new group and add all Receiver StoreFront servers to this security group:

To simplify the database creation process, you can use these scripts (created and adapted from the remote server database reference above):

ReceiverStoreFront_SQLScripts

Log into your SQL Server with a Database sysadmin account and open SQL Server Management Studio. Open the first script (ReceiverStoreFront _1-Create DB.sql). Perform a find and replace to change the database name from ‘CitrixReceiverStoreFront’ to a database name of your choosing. On the fourth line, change the path to the database (.mdf). On the fifth line, change the path to the database log file (.ldf). Once these three changes have been made, click execute and you should receive confirmation that “Command(s) completed successfully.”:

Open the second script (ReceiverStoreFront_2-Create Tables.sql). On the first line, change the database name from ‘CitrixReceiverStoreFront’ to the database name you entered in the first script. Click execute and you should receive confirmation that “(1 row(s) affected)”:

Open the third script (ReceiverStoreFront_3-CreateGroupLogin.sql). On the third and eight lines, change the login name ‘VMCloudGateway’ to the LocalComputerGroup or DomainGroup you created earlier. Change the final line from ‘CitrixReceiverStoreFront’ to the database name you entered in the first script. Click execute and you should receive confirmation that “Command(s) completed successfully.”:

Open the fourth script (ReceiverStoreFront_4-AssignGroupLogin.sql). On the first line, change the database name from ‘CitrixReceiverStoreFront’ to the database name you entered in the first script. On the second line, change the login name from ‘VMCloudGateway’ to the LocalComputerGroup or DomainGroup you created earlier. Click execute and you should receive confirmation that “Command(s) completed successfully.”:

Repeat this process to create additional store databases if necessary.  Next, let’s create some DNS records.  First, you will need a DNS record for the Load Balancer Virtual IP (VIP).  In my environment, I simply chose storefront.vm.2k8:

While setting up an Access Gateway Enterprise Edition (AGEE on NetScaler) or Access Gateway Standard/Express (VPX 5.0.4) is too involved for this blog post, I will make several references to these appliances and show you how to setup the StoreFront specific components. In my environment, I am using remote.vm.2k8 for the AGEE and cloudgateway.vm.2k8 for my VPX 5.0.4. We’ll come back to these later:

Similar to Access Gateways, the actual load balancer setup is rather involved, so I will just cover the pieces that are important.  1) Create an LB VIP that ties to the http(s) (80/443) services and IP addresses of your Receiver Storefront servers. I simply used tcp for the monitor:

2) On the method and persistence tab, I used Method: Least Connection, Persistence: Cookieinsert with a backup persistence of SourceIP. Note, my storefront.vm.2k8 DNS record points to the load balancer VIP.

Now that we’ve covered all the initial staging of the environment, let’s get started with configuring the Receiver Storefront. Since we didn’t install SQL on any of the StoreFront servers, you’ll note the only two options available are Deploy a multiple server group and Join existing server group. Select Deploy a multiple server group on the first server:

Enter the hostname (DNS record) you used to point at the load balancer VIP (http://storefront.vm.2k8). Enter the FQDN of the SQL server where you created the database. Enter the database name:

Click Test Connection to validate communication to the database:

If the connection test passes, click Create:

Once the database is connected, click Create Service next to the Authentication section:

If you won’t be using an Access Gateway, you can deselect the final option. Otherwise, select all three and click Create:

Click Create Store next to the Stores section to create the initial store:

Name the store (if you have a preference), otherwise leave the default name and click next:

Enter the first XML broker (XenApp or XenDesktop) to connect to. Change the transport type and port number appropriately. Additional XML brokers must be added once the store is initially configured. (Best practice: Always use FQDN when specifying XML brokers). Click Create:

Click Create Site next to the Receiver for Web section to create the initial browser portal.

You are not given an option to customize the URL when creating the Receiver for Web sites during the initial configuration. This can be customized by creating additional sites in the advanced configuration.  Take note of the full path provided for the initial site (http://storefront.vm.2k8/Citrix/StoreWeb) and click Finish:

Next, let’s add all of the additional servers to the server group.  Select Server Group from the left navigation and click Add Server:

Write down or copy the Authorization Code:

Login to the next server in your server group and launch the Citrix Receiver StoreFront console. Select Join existing server group:

Enter the DNS name of the first server (Authorizing server) and the Authorization Code you noted above. Select Join:

This process may take just a moment. When it’s complete you will receive a notification that the server is now part of a multiple server deployment. Click OK:

Repeat this process to add any additional servers to the server group. From this point forward, all management of the server group should be done from the principal server and ALWAYS propagated to the member servers. Log back into to the first server and click OK to the notification regarding the new server that was added:

On the right, select Propagate Changes:

Click OK to confirm that this process will forcefully overwrite changes made to the server group:

This process may take some time depending on the number of servers added to the server group. Click OK once complete:

Before we move on to the Access Gateway configuration, let me point out a couple advanced configurations I would typically implement. Under Authentication, select Configure Trusted Domains:

If you environment only has a single/flat domain, I would recommend entering the NetBios name here to prevent users from needing to type DomainUsername on the login page:

Select Manage Password Options if you want to enable users to change expired passwords:

Under Stores, select the store we initially created and choose Manager Server Farms:

Edit the default farm that was created (Farm 1) and give it a more appropriate name. Enter additional XML brokers at this point. Remember, best practice always use the FQDN:

Additional farms can also be added at this time for instance if you want to aggregate XenApp and XenDesktop resources:

Once you have made all the necessary XML broker changes, review and close the Manage Server Farms dialog:

If you are using the managed Citrix Receiver to deliver PNAgent-like functionality (Start menu, desktop placement, etc), you can optionally select Enable Legacy Support in this same section:

Check the option to Enable legacy support, select a default store and note the path to config.xml. This path will be used in place of the older Services Sites configuration:

Optional: If you want to setup IIS redirection, this must be done on each server in the server group and can be setup to ensure that when users type the short name (http://storefront), they are properly redirected to the default site (http://storefront.vm.2k8/Citrix/StoreWeb/). Open Internet Information Services (IIS) Manager. Expand the server -> Sites. Highlight the Default Web Site and select Http Redirect:

Select Redirect requests to this destination. Enter the full path to the StoreWeb portal (i.e. http://storefront.vm.2k8/Citrix/StoreWeb). Select Redirect all requests to exact destination (instead of relative to destination). Select Only redirect requests to this directory (not subdirectories). Click Apply:

At this point we have finished the advanced configurations and are able to connect to the Receiver StoreFront internally. Next, let’s configure the various components necessary for Access Gateway Enterprise Edition and Standard/Express. The next several steps cover required CAGEE configuration, remember previously, I stated my CAGEE was tied to remote.vm.2k8.  Scroll down to see steps related to CAG Standard/Express 5.0.4.

Select the Gateways section and click Add Gateway Server:

Enter a display name, gateway URL (this must match the SSL certificate on the CAGEE VIP), select Appliance, select Set server as Access Gateway Enterprise Edition, enter the Subnet IP (Or MIP depending on your configuration), and choose the logon type (Domain only or dual factor). Click Next once all settings have been entered:

Enter the gateway URL. Again, this must match the SSL certificate on the CAGEE VIP and must be resolvable internally. Click Next:

Enter the addresses of your Secure Ticket Authorities. Again, similar to XML brokers, it’s a best practice to use either FQDN or static IP addresses. Select Request tickets from two STAs, where available. Click Create once all addresses have been entered:

Click Finish.

The next several steps cover required CAG Standard/Express (v5.0.4) configurations, remember previously, I stated my CAG was tied to cloudgateway.vm.2k8.

Select the Gateways section and click Add Gateway Server:

A couple notes for CAG Express/Advanced/Standard v5.0.4…The Gateway URL is very specific.  For Receiver StoreFront, this must match both the SSL certificate AND the hostname on the Networking section. If the hostname on the CAG does not match the SSL certificate/entry point, change that first before troubleshooting any further.

Enter a display name, gateway URL (this must match the SSL certificate, include the full path to the logonpoint), select Appliance (or Access Controller where applicable) and click Next:

Enter the gateway URL. Again, this must match the SSL certificate on the CAG and must be resolvable internally. Click Next:

Enter the addresses of your Secure Ticket Authorities. Again, similar to XML brokers, it’s a best practice to use either FQDN or static IP addresses. Select Request tickets from two STAs, where available. Click Create once all addresses have been entered:

Click Finish.

Select the Beacons section and click Manage Beacons:

Enter a minimum of two external URLs to be used as beacons (for example, google.com and citrix.com). Click OK:

Go to the Stores section and select Enable Remote Access:

Select your access gateway from the list (entered above). Select a default gateway and click OK:

For the Access Gateway Enterprise Edition session policy, set the Web Interface Address and Citrix Receiver Homepage to the /Citrix/StoreWeb path of the load balancer address (i.e. http://storefront.vm.2k8/Citrix/StoreWeb):

For the Access Gateway Standard/Express logon point, set the Web Address and Homepage to the /Citrix/StoreWeb path of the load balancer addres (i.e. http://storefront.vm.2k8/Citrix/StoreWeb):

 

As I mentioned toward the middle of the blog, anytime you make changes to the StoreFront server group, be sure to go to the Server Group section and click Propagate Changes:

Deep breath…That’s it!  At this point, I now have a fully functional Citrix Receiver StoreFront server group with a network load balancer, Access Gateway Enterprise Edition and Access Gateway VPX Express for remote connectivity! Now, wasn’t that easy?  If you have any questions, comments, or just want to leave feedback, please do so below.  Thanks for reading!

–youngtech

Share Button
  1. make certainmake certain10-16-2015

    Fantastic written content , regards for
    the help and advice.

  2. DeepDeep02-07-2013

    The link for ReceiverStoreFront_SQLScripts is dead. Can you please upload this?

  3. Bill GouldBill Gould06-07-2012

    Excellent post. I’m confused about why the CAG Std/Exp is involved at all except as an alternative to the Netscaler/AGEE. Is there a reason?
    Typically I’d have a GSLB device on the edge, might even be a pair of Netscalers, and then some AGEEs inside doing all the server LB, authentication, policies, etc. I’d anticipate that my Storefront servers would live back with the AGEEs. I could be way off, no doubt there. Just curious.

    • Dane YoungDane Young09-03-2012

      Bill,
      Thanks for your response. The CAG STD/Exp configuration was simply provided as an example as there are some caveats to using CAG instead of CAGEE.
      Thanks,
      –youngtech

  4. Neil SpellingsNeil Spellings01-18-2012

    Great post!

    One further enhancement you could make is to create an additional VIP on your Netscaler and load balance the XML gateways. You can then utilise the advanced XML Gateway monitors that ship with the Netscaler to monitor the health of each of your XML servers, and remove any that don’t respond correctly to avoid the “blackhole” effect. The Netscaler handles this better than Storefront. This may require an additional Netscaler (VPX is perfect for this) on your internal network if that’s where your XML servers reside.

Leave a Reply