Tag: storefront

Choosing ”HTML5 Receiver” vs ”Native Receiver” dynamically through Netscaler Rewrite Policies

After a user has authenticated on a NSGW vServer, the user will either be prompted to select which Receiver Type (HTML5 vs Native) he/she wants to use, or a choice will be made automatically depending on how well the user’s web browser manages to detect a local Citrix Receiver install. See below picture for an example of the prompt I’m referring to.

You can however get rid of below prompt, and at the same also have a mechanism that selects which Receiver Type that should be for a particular user or scenario. This is achieved through Netscaler Rewrite policies.

How does it work?

In a normal scenario, after the Receiver Type has been selected (either automatically or by user), then the cookie ‘CtxsClientDetectionDone=true’ will be created in the user’s web browser. If Native Receiver has been chosen, then the cookie ‘CtxsUserPreferredClient=Native’ will also be created. By using Rewrite Policies we can create these two cookies by ourselves for the user, and therefore suppress the prompt for the user and automatically choose which Receiver Type to use.

If HTML5 should be used, then we only want to apply the Rerwite policy ”RWP-RES-DISABLE-RECEIVER-CHECK” to suppress the prompt. When Netscaler sees that the cookie ‘CtxsUserPreferredClient’ Cookie is missing, it will default to HTML5 Receiver (this is dependent on your Storefront configuration – see further down). If we want to force the Native Receiver, we also apply the rewrite policy RWP-RES-SET-NATIVE-RECEIVER” to create the cookie ‘CtxsUserPreferredClient=Native’.

In below scenario, I have defined an Expression for my Rewrite Policy ‘RWP-RES-SET-NATIVE-RECEIVER’ to only apply if the user is connecting from IP subnet 10.240.5.0/24. You can also use ”HTTP.REQ.HEADER(\”User-Agent\”).CONTAINS(\”Chrome\”)” to only apply it to Chrome Users, or use most other type of Expressions. I tried to use HTTP.REQ.USER.ATTRIBUTE(1) and HTTP.REQ.USER.IS_MEMBEROF(\”GroupName\”) expressions, but it seems that these expressions will always evaluate to false for a Rewrite Policy bound to a VPN vServer, so they don’t work, which is a shame.

 

 

For the choice between Native Receiver and HTML5 Receiver to work, you will need to configure your Storefront so that both HTML5 and Native Receivers are possible, like below picture. If you configure ”Always use Receiver for HTML5” instead of ”Use Receiver for HTML5 if local Receiver is unavailable”, then it doesn’t matter that the cookie ‘CtxsUserPreferredClient=Native’ exists. Similarly, if you configure ”Install locally” instead of ”Use Receiver for HTML5 if local Receiver is unavailable”, then Native Receiver will always be used.

If you want want the dynamic choice between HTML5 and Native Receiver, then don’t use ”Use Receiver for HTML5 if local Receiver is unavailable” and only create the ‘CtxsClientDetectionDone’ cookie to suppress the unnecessary prompt for the user.

Feel free to email me at rasmus.kindberg@xenit.se if you have any suggestions or questions related to this blog post.



StoreFront for Web med Firefox 52

NPAPI är ett API som används för att identifiera plugin för webbläsare och tillåta dem att köras när man går in på sidor som kräver dem. API:et är väldigt gammalt och det finns många mer moderna och smidiga lösningar än att använda just NPAPI. För att få webutvecklare att gå över till nya teknologier och modernare lösningar har bland annat Google Chrome sedan en tid tillbaka slagit av stödet för API:et. The Mozilla Foundation har även dem meddelat sedan en tid tillbaka att det skulle slås av för Firefox – från version 53.

I Citrix fall har NPAPI använts för att identifiera, aktivera och använda Citrix Receiver när man startar sessioner från Citrix StoreFront for Web, det vill säga när man loggar in i en webbläsare för att starta skrivbord eller publicerade applikationer.

Det verkar som att Mozilla har ändrat sig och helt enkelt slagit av stödet en version tidigare än kommunicerat, vilket förmodligen kan ställa till det för en hel del mjukvaruutvecklare och systemleverantörer – där ibland Citrix. Som tur är så är Citrix väl förberedda och har redan släppt en lösning!

Som nämnt var Citrix sett till att vara förberedda på NPAPI förändringen, från version 3.8 av Citrix StoreFront var allt förberett och planerat för att använda den nya tekniken så fort version 53 skulle komma. I och med att förändringen kom en version tidigare behöver administratörer gå in och manuellt ändra konfigurationen – det är väldigt enkelt!

Det man behvöer göra är att modifiera sin *web.config* för de StoreFront Stores som används för StoreFront for Web (C:\inetpub\wwwroot\Citrix\StoreWeb, där StoreWeb är namnetpåstore+Web).

Leta där i upp följande rad:

Och ändra till:

Som den uppmärksamme läsaren möjligen noterar så uppdaterar man den regexp som definierar vilka versioner av Firefox den så kallade protocolHandlern skall användas istället för native NPAPI från version 5[3-9] till 5[2-9] – helt enkelt från 53-59 till 52-59.

Efter en replikering av inställningarna, vid högt tillgänglig StoreFront, och en iisreset så skall Firefox åter fungera perfekt med Citrix StoreFront for Web.

Lycka till!

Källa: https://www.citrix.com/blogs/2017/03/15/firefox-52-and-citrix-receiver-for-web/



Citrix StoreFront 3.X – Varning för .NET 4.6.2!

n4emv4ar-dotnet-logo1-300x229-s-1
För inte så länge sedan kom en ny version av .NET som ersätter nuvarande versioner av .NET 4.6 och .NET 4.5 (närmare bestämt 4.6.1 och 4.5.2). Jag skulle vilja varna alla som driftar Citrix-miljöer från att installera denna nya version av .NET på era StoreFront-servrar som kör Windows Server 2008R2. De versioner av StoreFront som är drabbade är 3.0 eller högre, det vill säga 3.0, 3.5, 3.6 eller 3.7. Märk väl att denna varning ej gäller för Windows Server 2012(R2) eller Windows Server 2016.

Citrix har gått ut med en så kallad Fast Publish-notis som säger att om man installerar den senaste versionen av .NET (4.6.2) på sina StoreFront-servrar så slutar autentiseringen att fungera i både webbgränssnitt och legacy services-sidor (som t.ex. används av Legacy PNA) helt att fungera. Dessvärre finns det i dagsläget ingen lösning utan rekommendationen från Citrix sida är att man installerar de ”senaste” äldre versionerna av .NET – 4.6.1 och/eller 4.5.2.

Min rekommendation till er är att hålla ett extra öga på WSUS och Windows Update för att se till att några uppdateringar inte trycks ut den vägen. Jag har inte sett denna uppdatering tryckas ut den vägen ännu, utan det är manuell nedladdning som gäller, men det bör inte vara långt kvar då versionen som sådan ser ut att fungera bra generellt sett.

tl;dr Installera inte .NET 4.6.2 på en StoreFront-server som kör Windows Server 2008R2!

Det här inlägget blev inte så tekniskt utan snarare ett Public Service Announcement, AKA PSA! Hoppas att det hjälper er att undvika onödiga driftstopp!

Källor:
https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
http://support.citrix.com/article/CTX216204



Publicera RDP Proxy-länk via StoreFront

Sedan ett tag tillbaka har NetScaler Gateway inte bara möjlighet att agera ICA Proxy för XenApp och XenDesktop, utan kan även agera RDP Proxy åt Remote Desktop Session Hosts.

För att dra nytta av detta har man antingen behövt publicera länken via Clientless-portalen som finns i NetScaler Gateway alternativt länka till den på något annat sätt. Jag hittade ett enkelt sätt att få in denna länk tillgänglig via StoreFront, så användarna kan starta sitt Remote Desktop via RDP Proxy på samma ställe de har sina publicerade skrivbord och applikationer från XenApp/XenDesktop. Värt att notera är att jag bara fått det att fungera via webläsaren och inte via Citrix Receiver, samt att detta inte är något som är supporterat från Citrix så finns möjlighet att det ställer till problem (men enkelt att inaktivera). Jag har testat det med StoreFront 3.0 och 3.5, men mycket möjligt att det kan behöva göras om för äldre/nyare versioner.

Utan att gå in något djupare på hur allt fungerar så skickar StoreFront en lista till webläsaren med alla tillgängliga applikationer. Det vi gör är att vi skriver om denna lista med hjälp av NetScalerns rewrite-funktion och infogar en ytterligare applikation på ungefär samma sätt som ”content” kunde bli publicerat i XenApp 6.5.

Först behöver vi inaktivera encoding så vi kan skriva om innehållet, jag gjorde det på följande sätt och applicerade det till den virtuella servern jag har för lastdelning av StoreFront:

Beskrivning av ovan:

  1. Skapa en rewrite action för att ta bort headern ”Accept-Encoding” från requesten som kommer från webläsaren till StoreFront-servern
  2. Skapa en rewrite policy som applicerar vår action när headern X-Citrix-Via är ”nsgw.xenit.se” (alltså endast när trafiken kommer via NetScaler Gateway, byt ut nsgw.xenit.se till ditt FQDN), när path är ”Citrix/StoreWeb/Resources/List” (byt ut StoreWeb till din StoreFront stores namn) samt när trafiken inte kommer från Citrix Receiver
  3. Bind policyn mot den virtuella servern för StoreFront

Nästa steg, utför själva omskrivningen av svaret från StoreFront till webläsaren:

Beskrivning av ovan:

  1. Skapa en rewrite action som infogar det nya innehållet (i JSON-format) efter ”resources”:[. Se till att byta ut FQDN för NetScaler Gateway samt RDPProxy-länken (i mitt fall 10.20.30.40) samt peka om URL till ikonen, samt välj ett namn och ID som passar.
  2. På samma sätt som innan, skapa en rewrite policy
  3. På samma sätt som innan, bind policyn mot den virtuella servern för StoreFront

Detta går att använda för fler typer av länkar, säg siter som är skyddade av AAA eller länk till någon hjälpsida. När jag testade mig fram till detta med hjälp av XenApp 6.5 och publicering av content fanns det en del andra parametrar som publicerades förutom dem jag infogar, men vad jag sett har det fungerat utan – men kan vara så att de behövs vid något speciellt scenario.

Hoppas detta kan vara till hjälp för någon som bygger en Unified Gateway med vill använda StoreFront som den enda portal att komma åt alla resurser. Förhoppningsvis kommer något liknande detta vara inbyggt i framtiden, så vi inte behöver göra det manuellt.