Configuring multiple URLs on a single-site StoreFront deployment

Configuring multiple URLs on a single-site StoreFront deployment allows an organization to have different URLs for different stores. It also allows you to redirect HTTP traffic to HTTPS and NETBIOS names to Fully Qualified Domain Names (FQDN).

Note: this article applies to internal connections to StoreFront as opposed to connections made via Citrix ADC ("NetScaler"). Citrix ADC offers different methods for URL redirects, such as creating multiple vServers. For pure HTTP to HTTPS redirection there are three methods available as described in detail by Citrix CTP Carl Stalhood in his article SSL Virtual Servers – NetScaler 12.0 / Citrix ADC 12.1.

Table of Contents

Introduction

A singe-site StoreFront deployment is a prerequisite to be able to use the StoreFront console. A singe-site StoreFront deployment means that only one IIS site is used:

Configuring multiple URLs on a single-site StoreFront deployment - Single IIS site

As opposed to a multi-site StoreFront deployment, which means that two or more IIS sites are created on your StoreFront server.

Configuring multiple URLs on a single-site StoreFront deployment - Multiple IIS sites

The moment you create more than one StoreFront deployment (= more than one IIS site) on a single StoreFront server, the StoreFront console can no longer be used. You will have to resort to PowerShell to manage your environment.

Citrix StoreFront unattended installation with PowerShell - StoreFront management console unavailable in multiple-IIS site deployment

I can imagine that for this reason, multi-site StoreFront deployments are undesirable in many organizations. But what if you still want to use multiple stores within your single-site deployment and you want to use different internal URLs to reach these stores? And what if you want to allow people to logon using HTTP and than to automatically redirected them to HTTPS? Let me present you with a very simple solution how to accomplish this, without having to install more than one (pair of) StoreFront server(s).

Note: the solution presented in this article is mainly intended for connections made using Receiver for Web (through your web browser) as opposed to Receiver. The simple reason is that one StoreFront deployment can only have one baseline URL, which is used by Receiver. In this article I assume that you would like to offer your users more URLs besides the baseline URL.

My proposed solution has the following requirements:

  • You need a list of the URLs you would like to use and which store(s) they should resolve. You can have multiple URLs pointing to the same store.
  • For each of the URLs you need to create DNS names in your LAN infrastructure.
  • You will need a wildcard or a Subject Alternative Names (SAN) certificate. In case you are using a SAN certificate, make sure that the certificate includes all URLs you want to use.
  • A redirection file. In this article I provide a template you can use.

Additionally, your StoreFront baseline URL needs to be the same for all connections through Receiver as opposed to Receiver for Web (browser).

The following sections explain each of the requirements in more detail.

List of URLs and store(s) and DNS names

In this article, I assume that your StoreFront infrastructure consists of two servers (for load balancing and high availability). This is not a requirement though. You can have more or less StoreFront servers within your StoreFront group.

I use the following URLs as an example:

  • storefront1.mydomain.com
    The DNS name of the first StoreFront server. For testing purposes, it is handy that an administrator can enter the server name of an individual StoreFront server without having to use the load balancing name. This URL is redirected to the store /Citrix/StoreWeb.
  • storefront2.mydomain.com
    The DNS name of the second StoreFront server. For testing purposes, it is handy that an administrator can enter the server name of an individual StoreFront server without having to use the load balancing name. This URL is redirected to the store /Citrix/StoreWeb.
  • portal.mydomain.com
    The load balancing name of your StoreFront infrastructure. Let us assume that this is the name of the baseline URL. This URL is redirected to the store /Citrix/StoreWeb.
  • salesapps.mydomain.com
    An additional URL that can be used using Receiver for Web. This is not the baseline URL.This URL is redirected to the store /Citrix/SalesWeb.
  • Optional: director.mydomain.com
    In case you have StoreFront installed on the same server as Citrix Director, you can also redirect administrative users to the home page of Director. By default, the director URL resolves the following path and file name: /Director/LogOn.aspx?cc=true.

Now that we decided which URLs to use and which stores to resolve, we have to create the DNS names and create (or request) the certificate. Creating the DNS names is outside the scope of this article.

Wildcard or SAN certificate

Since you are running a single-site StoreFront deployment on a single IIS site, you can only bind one certificate.

Configuring multiple URLs on a single-site StoreFront deployment - IIS site certificate binding

If you want to use multiple URLs, you will need either a wildcard certificate (e.g. *.mydomain.com) or a SAN certificate with multiple DNS names.

Configuring multiple URLs on a single-site StoreFront deployment - SAN certificate

Note: a wildcard certificate only works when all URL have the same domain suffix, e.g. *.mydomain.com. In case you would like to use different domain suffixes, e.g. *.mydomain.com and *.myotherdomain.com, a SAN certificate is required.

In case you are using a SAN certificate, the DNS names of each of the URLs you want to use should be included. I strongly recommend using Fully Qualified Domain Names (FQDN). As described in the following section, NETBIOS names can be redirected to FQDN URLs in the redirection file.

So, to follow our example, the SAN certificate should include the following DNS names:

  • storefront1.mydomain.com
  • storefront2.mydomain.com
  • portal.mydomain.com
  • salesapps.mydomain.com
  • director.mydomain.com

One more thing, since these URLs are only used internally, you can create them using your internal PKI infrastructure, for example Microsoft Certification Authority. Just make sure that your internal root certificates and intermediate certificates are present on your StoreFront server as well as on your local clients. The easiest way how to deploy these certificates is via Group Policy. We will deal with this in the section Install the root and intermediate certificates on the local StoreFront server (and on your clients) in this article.

Creating the redirection file

Let me start by explaining what exactly I mean with a redirection file. I am talking about a JavaScript function that redirects URLs stored in an *.HTM file (Default.htm). It looks like this:

Configuring multiple URLs on a single-site StoreFront deployment - Default.htm contents

The main purpose of this file is to redirect users that land in the root directory of IIS, which by default is C:\inetpub\wwwroot, to a different subdirectory or virtual directory. Often, a user does not know the full URL. The user only knows the host name portion of the URL. For example:

  • Full URL of a StoreFront store: https://portal.mydomain.com/Citrix/StoreWeb/
  • What the users know: http(s)://portal.mydomain.com

A redirection file accomplishes the following:

  • It ensures that the user lands on the correct page.
  • It allows the use of multiple URLs on a single IIS site.
  • It ensures that host names are called fully qualified to prevent certification errors.
  • It ensures that the HTTPS protocol is used instead of HTTP.
  • It reduces support calls, incidents and troubleshooting.

I have prepared a working example of such a file (as seen in the previous screenshot). Click the button below to download the ZIP file that contains the Default.htm file.

Default.htm

You can open this file in your favorite editor such as notepad.exe. Let me take you through the contents of this file.

The main portion of the file consists of the redirect function. Within this function I compare certain components of the URL to determine how to redirect the user. Let's take a closer look at these components.

  • Example URL: https://portal.mydomain.com:444/Citrix/StoreWeb
    • https: = the protocol of the URL
    • portal.mydomain.com = the hostname of the URL
    • 444 = the port of the URL (default ports such as 80 and 443 are not shown in most browsers)
    • Citrix/StoreWeb = the pathname of the URL
    • The complete URL is referred to as HREF.

So when a user enters http://salesapp in the address bar of the browser for example, the Default.htm file redirects the user to the URL https://salesapp.mydomain.com/Citrix/SalesWeb/. The redirect function in this case does three things:

  • Changes the protocol from HTTP to HTTPS
  • Adds the fully qualified domain name to the hostname portion of the URL to prevent certificate errors (remember, the certificate should contain the FQDN).
  • Adds the pathname Citrix/SalesWeb/.

The same principal applies when a user (administrator) enters the URL http://storefrontserver1.mydomain.com. The Default.htm file redirects the user to the URL https://storefront1.mydomain.com/Citrix/StoreWeb/. In this example the redirect function performs two actions:

  • Changes the protocol from HTTP to HTTPS
  • Adds the pathname Citrix/StoreWeb/.

Bringing it all together: configuring your StoreFront servers

Now it is time that we bring it all together and that we prepare our StoreFront servers. The following steps have to be repeated on each StoreFront server in your StoreFront group:

Install the wildcard or SAN certificate on the local StoreFront server

You wildcard or SAN certificate needs to be installed in the certificate store of your local StoreFront server.

There are several ways how to install a certificate. The manual way is to open the Microsoft Management Console (mmc.exe), add the Certificates (Local Computer) snap-in and import the certificate in the Personal store.

Configuring multiple URLs on a single-site StoreFront deployment - MMC certificates personal store

To automate the installation of the certificate I recommend using the function DS_InstallCertificate in my PowerShell Function Library. This function uses the PowerShell cmdlet Import-PfxCertificate.

You can also use tools to install the certificate, for example Microsoft's CertUtil.exe which is included in the operating system (C:\Windows\System32).

Install the root and intermediate certificates on the local StoreFront server (and on your clients)

Your wildcard or SAN certificate will be issued by either a root or an intermediate authority.

Assuming you issued your wildcard or SAN certificate using an internal PKI, the root and intermediate certificates need to be installed on the local StoreFront server as well as on any internal (Windows) client that will access the URLs. In case you used an external provider, the public third-party root and intermediate certificates should already be present in the corresponding certificate stores.

Root certificates are placed in the Trusted Root Certification Authorities store and intermediate certificates in the Intermediate Certification Authorities store.

Configuring multiple URLs on a single-site StoreFront deployment - MMC certificates root and intermediate store

There are several ways how to install a certificate. The manual way is to open the Microsoft Management Console (mmc.exe), add the Certificates (Local Computer) snap-in and import the certificate in either the Trusted Root Certification Authorities or Intermediate Certification Authorities store.

You can also use the function DS_InstallCertificate in my PowerShell Function Library to automate the installation.

What I recommend though is to use a Microsoft Group Policy.

Configuring multiple URLs on a single-site StoreFront deployment - Group policy install certificate

Add your certificate to the appropriate store in Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Public Key Policies.

As said, please make sure that you install the root and intermediate certificates both on the local StoreFront server as well as on any internal (Windows) client that will access the URLs.

Bind the wildcard or SAN certificate to your IIS site

After installing the wildcard or SAN certificate on the local StoreFront server you need to bind the certificate to the IIS Default Web Site.

The manual way is to open the IIS Manager, right-click Default Web Site, select Edit Bindings, select or add https port 443 and select the certificate.

Configuring multiple URLs on a single-site StoreFront deployment - IIS site certificate binding

You can use the function DS_BindCertificateToIISPort in my PowerShell Function Library to automate the installation.

Copy the redirection file to the IIS root directory

Copy the redirection file to the IIS root directory, which by default is C:\inetpub\wwwroot.

Configuring multiple URLs on a single-site StoreFront deployment - Default.htm

You can use the function DS_CopyFile in my PowerShell Function Library to automate this step.

Set "Default.htm" first in the list of Default Documents

Make sure that Default.htm appears first in the list in the Default Document setting.

The manual way is to open the IIS Manager, select Default Web Site. In the right window pane, select Default Document. Configuring multiple URLs on a single-site StoreFront deployment - IIS Manager Default document

Move Default.htm to the top of the list. In case the document name does not exist, create it by clicking the Add... button.

Configuring multiple URLs on a single-site StoreFront deployment - Default Document

In case you want to automate this you can use the following code snippet:

Please also see the section Set Director Default Webpage in my article Citrix Director unattended installation with PowerShell. This section describes a similar situation.

Disable HTTP Redirect

In case you configured a specific store as the default website in the StoreFront console, this has to be removed. If you are not sure what I mean, please check out the section Set Default Website in my article Translating the Citrix StoreFront console to PowerShell. The point is that HTTP Redirect should not be configured. Otherwise it overrules the Default.htm redirection file.

Configuring multiple URLs on a single-site StoreFront deployment - HTTP redirect

In case you want to automate this you can use the following code snippet to disable HTTP Redirect:

Conclusion

It is possible to have multiple URLs for a single-site StoreFront deployment using a JavaScript based redirection file.

I tested this method in the following browsers:

  • Internet Explorer 11
  • Google Chrome 72
  • Mozilla Firefox 65

Please be aware that when using an internal PKI infrastructure, Firefox, by default, does not use the local Windows certificate store. To enable this, the setting security.enterprise_roots.enabled must be set to true. See the Bugzilla Bug 1314010 for more information. To enable this feature on a single computer:

  • In Firefox, type 'about:config' in the address bar
  • If prompted, accept any warnings
  • Right-click to create a new boolean value, and enter 'security.enterprise_roots.enabled' as the Name
  • Set the value to 'true'

Reference: Configuring Firefox to use the Windows Certificate Store

I hope that this article was of some help to you.

Share this post:
Dennis Span on EmailDennis Span on LinkedinDennis Span on Twitter
Dennis Span
Dennis Span
Dennis Span works as a Senior Citrix Architect for a large insurance company in Vienna, Austria. He holds multiple certifications such as CCE-V, CCIA and CCEA. In 2017, Dennis became a Citrix Technology Advocate (CTA). In 2019, he became a Citrix Technology Professional (CTP). Besides his interest in virtualization technologies and blogging, he loves spending time with his family as well as snowboarding, playing basketball and rowing. He is fluent in Dutch, English, German and Slovak and speaks some Spanish.

2 thoughts on “Configuring multiple URLs on a single-site StoreFront deployment

    • Hi Nishith,

      It is true that the base URL is “inherited” by each store. However, the base URL is used by Receiver, not Receiver for Web (browser). So when accessing your (StoreFront) applications via a browser, you can use any URL you want. If you want to use HTTPS, you of course need to install a certificate on the StoreFront server. If you want to be able to use the StoreFront console you can only have one IIS site (= single-site StoreFront deployment). Since you can only bind one certificate to an IIS site and if you want to use multiple URLs, either a wildcard certificate (e.g. *.mydomain.com) or a SAN certificate containing multiple DNS names (URLs) is required. I hope this clarifies your question.

Leave a Reply

Your email address will not be published.

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.