How To: Deploy StoreFront 2.0

If you have been doing Citrix for any length of time you are probably very familiar with the “Web Interface” servers of old. That has now changed, Web Interface is on its way out and its replacement is StoreFront. With the release of XenDesktop 7 we also finally got StoreFront 2.0 which addressed a lot of the complaints I had with StoreFront 1.2 (namely, the PITA SQL requirement). Having finally done some SF 2.0 deployments now I can say I am pleased with the progress that has been made..and for users running XenApp 6.5 we finally got pre-launch functionality back with SF2.0.

In this post I would like to walk you through a basic 2 server, highly available StoreFront deployment with remote access via Access Gateway. This will strictly be the server side, and you would want to read my How To series on NetScaler 10.1 config to cover the NS config side. So let’s get started…without requiring all the SQL databases this really lays down smooth now as you will see.

First off, check your prereq’s and make sure you’re inline. They can be found in the eDocs here: http://support.citrix.com/proddocs/topic/dws-storefront-20/dws-system-requirements.html

For the purposes of this How To, I am deploying on 2x 2008 R2 SP1 servers running on Hyper-V R2.

Step 1: Navigate to the properties of your Local Area Connection and disable IPv6. Once complete, click IPv4 and open its Properties.

SFHT-0000

Step 2: Navigate to the WINS tab and disable NETBIOS of TCP/IP.

SFHT-0001

Step 3: Navigate to your install media (SF2.0 comes on the XD7 media or as a separate download, whichever) and run the Storefront executable. If you are like me and you want to let the installer do all the requirements for you you will get the following popup. Just click “YES” and let it do its thing.

SFHT-0002

Step 4: Eventually the install of the prereq will complete and the StoreFront install can proceed.  Accept the license and click “Next”.

SFHT-0003

Step 5: Yep, I’m lazy..it’ll install IIS for me because I didn’t. Click “Next”.

SFHT-0004

Step 6: Click “Install”. Wow..that is SO much easier than StoreFront 1.2.

SFHT-0005

Step 7: After a few minutes the install will complete and you can click “Finish”.

SFHT-0006

Step 8: You are now presented with the StoreFront console. If you are using HTTP internally and will not be placing SSL certificates on the StoreFront servers then proceed to Step 12.

SFHT-0007

Step 9: Go open up IIS Manager and “Import” your certificate. This will be the same certificate you would have (or will be) loading on your NetScaler to handle the internal load balancing.

SFHT-0008

Step 10: Select the “Default Web Site” and click “Binding” on the right-hand side.

SFHT-0010

Step 11: Change the drop down to https, then select your SSL certificate from the drop down. Click “OK”. You can now close out of IIS Manager.

SFHT-0011

Step 12: Since IIS and .NET have both been laid down by the StoreFront installer its a good bet to go check Windows Updates and bring them current. Reboot if required.

SFHT-0009

Step 13: Open up (or go back to) the Citrix StoreFront mmc from the Start Menu. Click “Create a new deployment”

SFHT-0012

Step 14: Enter in the name of your internal load balanced DNS name (this is an internal DNS record that points to the load balancing VIP for SF on your NetScaler. i.e., sf.mydomain.local. Don’t really sweat the name..with SF and Receiver your users are getting away from typing URLs so its unlikely they would need to go to it anyhow.) Be aware, this internal URL should NOT be resolvable externally. Things will NOT work correctly with the beaconing if it is (beaconing is how Receiver figures out if it inside the LAN or outside) Info HERE and HERE.

SFHT-0013

Step 15: Enter in a name for your store

SFHT-0014

Step 16: Click “Add”

SFHT-0015

Step 17: Select your controller type, display name, change the transport type to HTTP (usually, unless you ride XML over HTTPS), and then your XenApp servers XML port. Click add and enter in your controllers FQDN one at a time. Repeat for every controller type in your org. To be clear, don’t mix XD and XA controllers in the same “group” here. You should end up in step 18 with a line for each type..XenApp..XenDesktop..etc. Note, if you have a netscaler load balancing your XML traffic (if you followed my articles you do), that IP should be the first in the list of controllers for each respective type.

SFHT-0016

SFHT-0017

Step 18: Click Next

SFHT-0018

Step 19: Remote Access. Select No VPN Tunnel for the majority of deployment unless you require VPN with Access Gateway Plugin or the like. (NOTE: If you are not allowing external access then leave “None” selected and proceed with clicking “Create” and go to Step 22, otherwise..) Click Add.

SFHT-0019

Step 20: Enter in the display name for your Access Gateway, your external URL, version, leave SNIP blank, and callback url is also your external URL. Click Next.

SFHT-0020

Step 21: Add STA’s one by one in format http://XAFQDN.internaldomain.local:XMLPORT. When complete, click “Create”.

SFHT-0021

Step 22: You should be presented with a summary screen and a success message!

SFHT-0022

Step 23: Now navigate to the “Authentication” section and click  Add/Remove Methods

SFHT-0023

Step 24: If you did in fact configure for  external access, User name and Password and Pass-through for NS Gateway are already checked. Lets add Domain pass-through to make it easier on our users to not have to login to Receiver if on a domain joined laptop. Remember to install Receiver with /IncludeSSON switch for that to work. See CTX133855 for details or my more detailed “How To” article HERE.

Click “OK”

SFHT-0024

Step 25: Missed a screenshot here but navigate back to “Server Group” and select “Add Server”. You will see the following box appear.

SFHT-0026

Step 26: Now go to your second StoreFront server, on which you have done you IPv6, NETBIOS, Updates, installed StoreFront and its just sitting there waiting….and click “Join existing server group”.

SFHT-0025

Step 27. You will be prompted for the “Authorizing Server” and “Authorization Code” that you received on the first box..enter it and give it a few minutes. Once done, both servers will be in sync. Don’t forget that any changes you do moving forward you need to propagate by going to the server on which you made the changes and clicking “Propogate Changes”  on the Server Group page

SFHT-0027

Step 28. Lets enable the Receiver for HTML5. With SF 2 its included (Hallelujah!) but we still have to enable it. Navigate to Receiver for Web and click “Deploy Citrix Receiver”

SFHT-0028

Step 29: Select “User Receiver for HTML5 if local install fails” and click OK.

SFHT-0029

Step 30. Ok, lets propagate our changes by going to Server Group and clicking “Propogate Changes”.

SFHT-0030

SFHT-0031

Congratulations you now have a StoreFront 2.0 server group deployed and in-sync, with Receiver for HTML5 enabled. If you follow my series on the NetScaler you will load balance the SF traffic with a VIP and your Access Gateway is providing for external access when your users are on the go. In addition your XML traffic is all load balanced via the NetScaler and those VIPs are #1 in your list of Controllers on StoreFront!

As always, hope this can help someone out there!

6 thoughts on “How To: Deploy StoreFront 2.0

  1. Great post. Thanks so much for taking time to do this.
    Can I ask, do I need 2 pair of storefront servers? One pair for internal and one pair for external? A bit confused if I can only bind a single certificate to the storefront server (matching load balanced name in internal net scaler) how will that work with an external VIP address if it must be different to determine beacons. Does the external Netscaler use the same internal LB SF address. Sorry if I’m being stupid. WI was easy at handling this part. Thanks again.

    • Thanks for the kind comments and you’re not being stupid! SF is a new way of “thinking” and it definitely takes time to get, but it will click eventually I promise you.

      You do not need 2 pairs of StoreFront servers, a single (highly available) pair will service your internal and external users. You will bind a certificate, lets call it sf.mydomain.local, to your StoreFront store..to successfully load balance that we will also install that certificate on our NetScaler and apply it to our LB vServer. That handles our internal connection needs at that point..if Receiver, via its configuration that it received from Storefront when the user initially connected and entered their email address and stuff, determines now via beacons that its inside the LAN it will hit the sf.mydomain.local URL to connect you to your resources.

      Now to handle external connections, you would have an external DNS entry of citrix.mydomain.com that leads to your NetScaler Gateway..this would have a certificate loaded on the NS that lists that name and it would be bound to the AG vServer. On the backside of the NetScaler, AG would hit SF on its load balanced URL via HTTPS. So if a user’s Receiver determined it was outside the LAN via Beacons now, it would hit the citrix.mydomain.com address..which all still leads to the same StoreFront store. Seamlessly.

      If you check out my NetScaler series, parts 3 and 4 you can see the config on the NS/AG side and it may make more sense?
      Hope this helps!

      • Thanks for the reply. That’s makes sense. With my platform Netscaler license I can do load balancing to an extent right? Or do we need to really purchase a Netscaler standard license for the internal HA pair? I will read the remains series.

        Not many people have a way of explaining things in a clear way.

        In your case sir I applaud you. Many many thanks for your time. I’m sure the community appreciates this as well.

        Kindest regards
        George

      • First off, thanks again for the kind comments. I am glad to share, I am lucky to be surrounded by colleagues that have explained things to me when I needed. Humbled to be able to help, and hope this helps you. 🙂

        Any NetScaler, including the VPX Express (free!!) can do load balancing, the limiting factor will be the throughput. For instance a VPX Express has a 5Mb throughput cap on it. This opens up an entire new discussion though on required bandwidth, because obviously an internal client is not routing all their ICA session traffic through the internal LBVIP..they hit it, it load balances to SF..SF hits the XML brokers..enumerates the apps..finds a match..throws Receiver an ICA file..client connects to XA server..so the general load isn’t very large…but thats an entirely new blog post 😉 I will say I have many SMB clients that just run VPX Express and it meets their needs just fine, and did I say it’s free!?!

        You just need to make sure for external users that you have your Access Gateway platform license loaded and your AG vServer is in standard mode..which if you follow my deployment series it will be. Read these articles HERE and HERE to shed some light on all this, they explain the licensing part far better than I ever could. Let me know if this helps!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s