Home » storefront

Tag: storefront

Modify Default Storefront website for Citrix NetScaler Access

In newer versions of Citrix XenApp and XenDesktop (7.6+) if you selected to install Storefront, then the website will be preconfigured by the XA/XD Setup wizard. In order for this to function for Citrix NetScaler access there are some settings we need to set up in order for NetScaler to be able to connect to the StoreFront server and launch sessions.

Prerequisites

Item Description
 * You will need to know the FQDN of your NetScaler Gateway
* The internal or private IP Address of the VIP assigned to the NetScaler Gateway*
 * Know the details of your Citrix Server STA (your Citrix DDC(s))

* The StoreFront server must be able directly communicate with the VIP of the NetScaler Gateway, otherwise when the StoreFront server resolves the FQDN it will resolve the internet IP address and potentially will not work.

Modify the Default Store

Step Description Screenshot
1 Log into Citrix Studio

Expand Citrix StoreFront

Select the Existing Store ‘Store Service’

Click Manage NetScaler Gateways

2 Click Add

Enter the Display name and the FQDN of the external Gateway URL

(In this example my gateway FQDN is called ‘gateway.jsconsulting.services’

Click Next

 3 Click Add

Enter the Name of your DDC

In our example we only have one server – which is the http://citrixserver.home.local/scripts/ctxsta.dll

Click Next

4 Enter the callback URL of the NetScaler Gateway ensuring your StoreFront server is able to resolve the FQDN to an internal/private ip address.

Click Create

 5 Close the Manage NetScaler gateways screen
6 Ensure the StoreFront / Citrix server can resolve the FQDN to the inside IP Address of the NetScaler Gateway

Use locally managed DNS if you have the Zone configured on your local DNS server(s)

Or use the Windows host file to add a private entry.

Remember if you have multiple storefront servers and multiple sites, host file management can quickly become time consuming and error prone. Ideally use internal DNS.

Note: Windows host file is located in c:\windows\system32\drivers\etc\hosts and has no extension. You may need to copy it to the users desktop first, manipulate the file, and copy it back due to Windows User Account Control (UAC)

7 Ensure the StoreFront server resolves the FQDN to the NetScaler inside VIP address

Note: In production environments ping may not be allowed between the NetScaler network and the StoreFront network(s) – you need to ensure that 443 TCP is opened and allowed through the Firewall from the StoreFront servers to the NetScaler VIP

8 Back in the Studio expand Manage Authentication Methods
9 Ensure Pass-through from NetScaler Gateway is ticked
10 Back in Studio Select your store and click Configure Remote Access Settings

Ensure you Enable remote access

Select No VPN Tunnel

Tick the NetScaler Gateway appliance listed

Click OK

If you want to learn more about Citrix NetScaler check out our online NetScaler course at www.mastersof.cloud

Signup below to receive a free 200 page Citrix NetScaler Introduction guide!

Deploy a Citrix StoreFront Server for Citrix NetScaler Access

In the following steps we will detail how to configure a stand alone installation of Citrix Storefront and give examples of how to connect this to your Citrix NetScaler

Step Description Screenshot
1 Open the Citrix StoreFront Console

Expand Citrix StoreFront

Click Stores

Click Create Store

2 Click Next
3 Give the store a name

Select Set this receiver for Web site as IIS Default

Click Next

4 Click Add

On the Add Delivery Controller screen click Add

Add Delivery Controllers FQDN

Untick Servers are load balanced

Select Transport type as HTTP

(you should use HTTPS if the SF server is in a DMZ or for extra security)

Click OK

 5 Click Next
 6 Enable Remote Access

Ensure Allow Users to access resources only delivered through StoreFront (No VPN Tunnel) is selected

Click Add

7 Enter details for the new gateway

Example: my gateway is called gateway.jsconsulting.services and the URL is https://gateway.jsconsulting.services

Click Next

 8 On the STA Screen

Click Add

Enter the FQDN of the Citrix XA/XD server

 9 Enter the FQDN of the STA server

Click OK

10 Untick Load balance multiple sta servers

Tick Enable session reliability

Untick request tickets from two stas, where available

Click Next

 11 Enter the NetScaler details – Leave logon type as domain

Enter Callback URL as the same entered in step 6 https://gateway.jsconsulting.services

Click Create

12 Click Finish
 13 Ensure default appliance is the NetScaler appliance created / added in steps 1 through 12

Click Next

 14 Ensure that both methods of Authentication are selected – Username and password and Pass through from NetScaler Gateway

Click Next

15 Leave both options ticked

Click Create

16 Click Finish
 17 Back in the StoreFront console click Receiver for Web Sites tab and copy your StoreFront URL

Open your internet browser and test this URL

&

https://gateway.jsconsulting.services

 

If you want to learn more about Citrix NetScaler check out our online NetScaler course at www.mastersof.cloud

Signup below to receive a free 200 page Citrix NetScaler Introduction guide!

Citrix Storefront 3.9 passthrough authentication issues

Situation:

After a customer recently upgraded to Storefront 3.9 some users complained of having to authenticate twice when using various browsers. Once in Storefront and once again in a Windows Login prompt when they launch their selected application.

This seems to be related to the way Storefront runs the receiver detection, if a compatible receiver is detected the users are prompted and asked if they want to ‘Log On’ with their local computer credentials. (see screenshot from Workaround 1 below).

Previously we have only ever used ‘username and password’ authentication, but this process seems to negate / bypass the authentication configured in Storefront.

Workaround #1:

The users should be prompted each time to ‘passthrough’ their windows local windows credentials by clicking ‘Log On’.

The users can skip the passthrough and simply click ‘switch to user name and password’

To use the account you used to sign on the computer, click Log On.

Workaround #2

If you have more than one Store in Storefront separate the authentication methods in Storefront so they are not shared between the stores (as pass through detection continued to happen regardless of the authentication method selected when shared between stores)

(note the storename has been obscured for customer anonymity)

Resolution:

In relation to the references section for setting up a good receiver configuration this customer had broken the majority of the rules for good reason. So there was no adhering to the Citrix best practises, so workaround 2 became their resolution based on other requirements (like not all users are domain joined, not all devices that connect are manager by the customer, rather 3rd parties to which they have no control, the users have no / little access locally to upgrade or install or modify receiver configurations – the list goes on)

Post the upgrade the Authentication method between two different stores were merged, and shared authentication was enabled. Regardless of the settings we were selecting / applying in the Browser, the pass through continued to haunt users and attempt to log them in with their local credentials.

Once we split the authentication, so it could be controlled separately between the two stores, the issues went away and we had more granular control.

There were are number of things the customer was not doing like configuring the receiver clients locally, and configuring the local receivers to support http:// as they have a large number of non domain joined users and this prevented a ‘one size fits all’ approach to deploying receiver and Storefront internally. Our final suggestion was to look to replace this entirely with NetScaler and HTML5 instead.

References

https://docs.citrix.com/en-us/receiver/windows/4-7/secure-connections/receiver-windows-configure-passthrough.html

Citrix Storefront Upgrade Failure 2.x to 3.9

Situation:

When trying to Upgrade our Citrix storefront servers from a 2.x version to 3.9 of storefront we encountered the following error: This meant the installation failed with the previous storefront version removed completely, and all configuration lost, and we were then unable to install any further version of Citrix Storefront.

Application Log Error, Source: Citrix Extensible Meta-Installer EVENTID: 0
Timestamp: 05/07/2017 19:04:43
Category:Error, WinError
Message:Unexpected exception. Message: Exception has been thrown by the target of an invocation.. Stack Trace =    at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
  at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Citrix.Cxmi.CustomSandbox.ManagedDllLoader.CallStaticMethod(String typeName, String methodName, Dictionary`2 methodParams)
   at Citrix.Cxmi.Workflow.ExecuteTask.Execute()
   at Citrix.Cxmi.Workflow.WorkflowSequence.Execute()
   at Citrix.Cxmi.Workflow.WorkflowSequence.Execute()
   at Citrix.Cxmi.Workflow.WorkflowExtension.Run()
   at Citrix.Cxmi.Core.Engine.Run()
   at Citrix.Cxmi.Core.Program.Main(String[] args).

Things Tried:

Deletion of all local temp files – Failed

Complete uninstall and reinstall of Storefront versions – Failed

Reinstall of old version 2.x – Failed

Install of new 3.x  version as different user – failed

We had no choice but to revert the VM snapshot to recover the production Web server.

Solution:

Upgrade to Storefront 3.0 First, then attempt to upgrade to a higher version.

Storefront 2.5 'Cannot Complete your Request'

Ive seen this error a number of times:

  1. Misconfiguration of storefront server itself
  2. The server has just rebooted and IIS is still starting up
  3. A firewall preventing the storefront server(s) getting back to the SNIP of the Netscaler(s)
  4. and now today…

Today I added a new Delivery controller in Storefront 2.5 so I could publish ‘XD’ resources.

In the XD7.6 studio console I created a new machine catalogue and delivery group called ‘J&J Testing’

When accessing the delivery group in the Studio it looked fine

When testing the login process via storefront we received ‘Cannot complete your request’.

Removing the ‘XD’ from the list of delivery controllers in storefront – worked instantly, storefront logins working again
This was not a solution however.

Deleting the delivery group ‘J&J Testing’ and re-adding the ‘XD DDC’ back to storefront as a delivery controller worked straight away.

Solution: Can only assume here that the ‘&’ ampersand in the name of the delivery group killed the publication there of, or the delivery group publication process failed and a recreate was required.

Eitherway dont use ‘&’

Combine Storefront and Web Interface on same server

Scenario:

Two storefront 2.5 servers running and delivering apps for our users via an external netscaler gateway services.

Internally however all users still have the PNAgent / Citrix Online Plug In verion 12.1 – connecting to a citrix Web interface 5.4 site.

The Storefront legacy support works – but each and every application the end user has access to is displayed regardless of the published app settings. 

Other Services settings like the server shortcut management, session options, workspace control etc are all gone and non confgurable when usint the Storefront ‘Legacy’ support.

Web Interface (honouring Citrix Published Settings)

 PNAgent_PublishedAppSettings_HonouredPNAgent_PublishedAppSettings_Honoured_Client

 

Storefront Legacy (Ignoring published settings and displaying ALL Apps the user has access too)

(some app names obviously edited out for privacy)

 

STOREFRONT_Legacy_IgnoringPublishedSettings

So we are unable to simply change the end users ICA Client to point to the https://storefront/Store/PNAgent/Config.xml as all their shortcuts in the start menu would appear and any icons published to the users desktop would disappear (this support just doesnt exist for storefront legacy support)

2 steps forward, 10 backward

Most tech geeks couldnt care less about shortcuts and end users will get used to it, but its these nice to have features and granularity of control that make the difference between a working solution and a great solution.

The end solution:

We decided to simply combine Storefront and Web Interface on the same server(s)

We wanted to use the new storefront servers as they were already load balanced behind an inside HA pair of netscalers

We wanted to retire the existing Web interface servers as they were running 2003 server, werent patched, running on ageing harwdare etc

The installations dont get in the way of each other, in fact you can run the storefront AND the webinterface services sites on the same server side by side! The only thing that doesn’t seem to work (once they are installed together) is setting the default store for the Storefront legacy site configuration (so if you have more than one store forget it)

Tested Versions: Storefront 2.5; Web Interface 5.4

Storefront 2.5 gets mandatory shortcut creation!

With the release of storefront 2.5 we can make published applications mandatory within the Receiver and the storeweb, which is SWEET.

Publish the application and change its description to keyword: mandatory(subsequent keywords can be separate by a space i.e.

“keywords: mandatory featured”

Storefront2.5 with the mandatory keyword

 

|
|

 

If the mandatory keyword from the published application is removed, the shortcut stays, but a ‘remove’ option appears.

storefront mandatory shortcut removal

 

This also works in conjunction with the older style XenApp / web interface filtering I blogged about here. So I can have our internal PNAgent selectively filtering apps that have a description starting with #, and I can finally force company specific apps under the receiver, receiverweb and in the windows start menu and stop the ‘where have all my applications gone..?’ 🙂

Cheers

Citrix Storefront 2.1 Upgrade to 2.5 – Issues Experienced

 STOREFRONT 2.5 UPGRADE from 2.1 – Notesstorefront-storeweb

We were running Storefront 2.1. It was installed and working fine for all normal storefront web and support for SSON legacy clients with a 2 node storefront farm via a load balanced netscaler setup.

We decided to install the Storefront 2.5 over the top – just to see how it would behave. We downloaded the new version, took a server snapshot, and then ran the install as administrator.

First and foremost its identical to the 2.1 installation and actually looks like brand new install. During the install it mentions nothing upgrading, just simply installs and takes a good 20 minutes, with little in the way of feedback along the way.

The following problems were experienced after the upgrade of our Storefront servers.

  1.        Clients can no longer SSON through the PNAgent
  2.        Storefront webpage only displaying 1 of the 2 delivery controllers configured. (legacy xenapp 4.5, nothing from xenapp 6.5)

Solution

We ended up wiping the store configuration entirely and starting again.

No amount of changing or disabling and reenabling the existing store would work, and its not like its that difficult to recreate the same site with the same name. This would be frustrating if we had many multiple stores.

All testing was carried out without the netscalers or the LB services. This was to be sure it wasn’t adding its own complexities or problems to the setup.

During testing the local hosts file was updated so I could be sure I was targeting the individual storefront servers I was upgrading at the time.

Further details / Troubleshooting steps.

PROBLEM 1

Tried Reboot – didnt fix

Tried the PS Script to enable SSON for legacy – didnt fix

Checked the settings for the legacy clients – it was enabled and store correctly listed

Disabled legacy support

Re-enabled Legacy support (without SSON)

Online Legacy client prompts for user and password, could authenticate successfully only displaying the legacy 4.5 apps from one of two delivery controllers listed.

Run  powershell command as administrator on the Storefront server

& “C:Program FilesCitrixReceiver StoreFrontScriptsEnablePnaForStore.ps1” -SiteID 1 -ResourcesVirtualPath /Citrix/Store -LogonMethod sson – to re enable the legacy SSON

Legacy clients get error messages popup saying its authenticating,

Citrix Onling Legacy client attempting to authenticate
Citrix Onling Legacy client attempting to authenticate

Then the server could not be contacted.

 

Online legacy client unable to authenticate to upgraded storefront server
Online legacy client unable to authenticate to upgraded storefront server

Then magically refreshes a 3rd time and just logs in anyway!?

 

PROBLEM 2

Removed XENAPP65 Delivery controller and readded settings for 2 ZDC’s – Didnt work

Added just one of the ZDC’s as an IP address – still not working, website now slower and authentication takes twice as long.

Removing store entirely.

Readded the store entirely, connected XA65 first and tested – both website and PNAGENT Legacy worked (once again running the Powershell PNAgent command

& “C:Program FilesCitrixReceiver StoreFrontScriptsEnablePnaForStore.ps1” -SiteID 1 -ResourcesVirtualPath /Citrix/Store -LogonMethod sson

Powershell output from the command that enabled SSON for storefront legacy support
Powershell output from the command that enabled SSON for storefront legacy support

If the client had connected while the authentication method was reset you will see

Legacy online plugin will change the authentication method automatically
Legacy online plugin will change the authentication method automatically

It logged in! Success!

Propogate changes to the other server (also just upgraded) – DONE.

Piece of cake… *ahem*

Storefront Logon Failure Event ID

Security Log > Audit Failure Event ID 4625

An account failed to log on.

Subject:
Security ID: NETWORK SERVICE
Account Name: SERVER$
Account Domain: DOMAIN
Logon ID: 0x3e4

Logon Type: 8

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: jamesscanlon
Account Domain: DOMAIN

Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc000006a

Process Information:
Caller Process ID: 0xa20
Caller Process Name: C:Program FilesCitrixReceiver StoreFrontServicesDefaultDomainServicesCitrix.DeliveryServices.ServiceHosting.WindowsServiceHost.exe

Delete Storefront store from Citrix receiver.

Follow this one at your own risk, it hasn’t been thoroughly tested other than testing the fact the storefront site has actually been ‘removed’ so the end user is prompted to install / log in again.

Scenario: Client upgrading from 1.2 storefront, wanted to change names or url, store and cert. Wanted 2.1 storefront. Didnt want to upgrade or migrate.

Solution: We installed a separate 2.1 storefront server, configured it accordingly. Published the site, tested the site, then change the _citrixreceiver SRV record so the end users could enter their EMAIL address in the receiver login page. The existing store would still exist and duplicate icons would show and various other pain occurred unless the end users removed the original storefront store.

This could be manually done from the receiver or alternatively we ran a GPO on a per user basis (run once) to delete the following keys (we only had one site – so it didnt matter if we wiped the whole key/store)

  • HKCUSoftwarecitrixdazzle*
  • HKCUSoftwarecitrixreceiverSR*
  • HKCUSoftwarecitrixreceiverctxaccount*

This cleared the remembered store entries on the local W7 host and the users were prompted to type in their email details to connect to the storefront again – only this time because the _srv record was updated they connected to the new site.

Clunky, but so far it has worked, everytime.

Im sure there are plenty of other better ways of doing this, please do let me know if you have any advice / ideas ! We also tried the receiver clean up utility, which completely removes the receiver but somehow managed to leave some of the start menu shortcuts behind and didnt run for every user correctly..