Cloud Gateway a Wrap-Up so far Part 2

Cloud Gateway a Wrap-Up so far Part 2

Table of Contents :

1 : Introduction
2 : Cloud Gateway architecture and components
3 : Cloud Gateway Mobile Experience (MDX) Technology
4 : Access Gateway : ICA Proxy, Clientless VPN and Secure Browse
5 : Native Receiver VS Receiver for Web
6 : ShareFile
7 : Conclusion

1 : Introduction

A few months ago I wrote a wrap-up about Citrix Cloud gateway and the upcoming 2.0 release, it’s one of the posts on my blog that gets the most hits so I thought I should write a follow-up. If you are new to Cloud Gateway you should read my previous wrap-up first to get a better understanding of the architecture. In this post I’m going through the new features of Cloud Gateway 2.0 and things I came across when setting up a demo environment.

2: Cloud Gateway architecture and components

Cloud Gateway consists of the following key components :

Appcontroller for User provisioning and SSO to Web (internal & external), SaaS and Native mobile apps
Citrix Receivers for connecting to Cloud Gateway

Optional components are :

Storefront Services for connecting to XenApp & XenDesktop back-end and providing access through Receiver for Web \ HTML5
Access Gateway Enterprise (Netscaler VPX/MPX) for external access to Cloud Gateway
Merchandising Services for controlled plugin distribution
– Integration with ShareFile infrastructure (Follow-Me-Data)

All optional components are included in the current Cloud Gateway Enterprise edition, except for the ShareFile subscription fee and the Access Gateway Platform license (universal licenses are included).

Citrix made a clever move by making Storefront services an optional component of Cloud Gateway, in this way they can sell Cloud Gateway as a separate stand-alone product, but on the other hand offer tight integration through Storefront for existing Citrix customers. I think the majority will use Cloud Gateway to extend their current Citrix back-end so Storefront will play a key role in most environments. In the use case that Storefront is not used, Citrix Receivers connects straight to Appcontroller or indirect through Access Gateway to Appcontroller.
Because I think a picture speaks 1000 words, I made a basic diagram of the Cloud Gateway components including ShareFile :

3 : Cloud Gateway Mobile Experience (MDX) Technology

Cloud Gateway MDX is the new marketing term for the features of Cloud Gateway, you can compare it with the marketing term HDX which stands for all the user experience optimizations around the ICA protocol. Let’s translate the MDX features into some more technical descriptions :

Feature Description
MDX App vault Sandboxed container controlled by Citrix Receiver which can be   remotely wiped
MDX Web Connect Embedded (mobile) web browser for secure browse connections
MDX Micro VPN Client side rewrite technology through Netscaler (Secure Browse)
MDX Policy Orchestration Management of (native) mobile apps through Appcontroller and   provides smart access like features

This MDX features gives IT control and security over their apps and data, but at the same time gives the users the freedom to control their own mobile device. I think this is best for both worlds and it prevents that users are going to work around the system.

MDX Ready Program
Citrix will initiate a MDX Ready partner program to validate apps for use with MDX, Citrix self will release an MDX native e-mail app which runs inside the App vault container and doesn’t expose itself to other apps on the mobile device improving security.

4: Access Gateway : ICA Proxy ,Clientless VPN and Secure Browse

Ok now things are getting very interesting, lets start with Access Gateway…

Access Gateway support
Cloud Gateway MDX features are only available in conjunction with Access Gateway Enterprise (Netscaler), there is no support for Access Gateway VPX (STD\ADV), in fact Citrix will shortly announce that Access Gateway VPX will go end-of-life. I wrote a blog about the future of Access Gateway a while ago, I wrote down my thoughts about why Citrix would support 2 products with almost identical features and why I think Access Gateway Enterprise (Netscaler) is the better product. At first I thought they should keep Access Gateway VPX as a replacement for Secure Gateway to provide basic connections and provide it for free, but then they would still need to support 2 products. If we look at the VPX appliances, we have a Netscaler VPX and the Access Gateway VPX, if we look at the MPX appliances we have the Netscaler MPX and Access Gateway Enterprise MPX, did you spot the outsider? Yep the big difference is that Access Gateway VPX is a very different product and the rest is Netscaler only licensed differently, if we look closer there is one edition missing :

Access Gateway Enterprise VPX
To replace Access Gateway VPX, there will be a Access Gateway Enterprise VPX edition (Finally!), this is a stripped down Netscaler which only gives you access to Access Gateway features. Citrix will also provide trade-ups and will adjust the pricing accordingly. So at the end we will have the following Access Gateway appliances left :

CAGEE Physical Appliance (MPX) CAGEE Virtual Appliance (VPX)
MPX 5500 Access Gateway Enterprise VPX
MPX 7500/9500
MPX 9700/10500/12500/15500

If you have a Netscaler MPX\VPX appliance you can enable the Access Gateway component and use it besides all other Netscaler functionality.

Access Gateway Policies and Profiles
The power of Access Gateway Enterprise IMHO is its flexible architecture, Access Gateway Enterprise fits like a glove in a lot of different environments and different access scenarios, because of its modular design. Since the Cloud Gateway release there are a lot of Access Gateway policies and profiles needed for different access scenarios and Receiver types, it will take some time to create and configuring them manually. To address this Citrix added a wizard (since version which will create a baseline of policies and profiles for you. After the baseline is set you can still configure and adjust everything  according your needs, so the wizard helps you with the baseline but there will be no compromise on the flexibility afterwards.

ICA Proxy
ICA Proxy will enable you to do SSO pass-through to Webinterface, it doesn’t use Clientless VPN so you can use it on a VIP in basic mode. ICA Proxy provides the same functionality as Secure Gateway, which means basic ICA connections only. It is not documented anywhere but I can confirm that ICA proxy still works with Receiver for Web so if you want to provide basic access to Xenapp or XenDesktop you can use it just like with Webinterface. If you want more Cloud Gateway functionality you need Smart Access functionality like CVPN :

Clientless VPN
Clientless VPN (CVPN) has been around in Access Gateway for a while now, this Server side rewriting technology is great for providing access to OWA and other webapps behind Access Gateway. But the downside of CVPN is that not every webapp supports it, I can remember spending a lot of time in troubleshooting rewrite policies to intranet applications, but if it works it works pretty well and you don’t have to leverage a full VPN tunnel to allow access to webapps securely. CVPN in a Cloud Gateway setup is only used for traffic to Receiver for Web and traffic to Appcontroller, besides that CVPN is turned off so external Web\SaaS apps are not rewritten by Access Gateway but instead opened directly by Receiver (after SSO is done by Appcontroller), for internal webapps there is a new feature in Cloud Gateway :

Secure Browse
Secure Browse is one of the features I’m most excited about, instead of leveraging CVPN or a Full VPN tunnel, the Receiver for IPAD uses a secure channel between Receiver and Access Gateway called Secure Browse (or MDX Micro VPN). Secure Browse provides secure session based access to internal webapps behind Access Gateway. Another cool thing about Secure Browse is that it’s using an embedded webbrowser (MDX Web Connect) to render both internal and external webapps controlled by Appcontroller. Web Connect is totally controlled by Citrix Receiver and doesn’t expose critical data on the mobile device, Secure Browse will support any webapp because there is nothing rewritten by Access Gateway so no more troubleshooting of rewrite policies and broken links.
Secure Browse is currently only available on the Receiver for IPAD, other Receivers will still leverage a full VPN tunnel to provide access to internal webapps, but it’s expected that Citrix will extend Secure Browse to other Receivers as well.
I tested Secure Browse with OWA and SharePoint and it works really well, I can’t wait to see this functionality on other Receivers to.

5: Receiver for Web VS Native Receiver

In my previous wrap-up I talked about the difference between Receiver for Web and Webinterface, it’s clear that there are still features missing in Receiver for Web in comparison to Webinterface, but Citrix is closing this gap in upcoming releases of Storefront, in version 1.2 for example they already made some enhancements by separating Desktops from Apps and allowing user initiated desktop restarts. In this wrap-up I made a list of different functionality I noticed when using the Receiver for Web and the Native Receiver, please note that this list can quickly become out dated when updates of the Receivers are released.

Receiver for Web Native Receiver
User initiated Desktop restarts Yes No
Desktop viewer used Only for XenDesktop Also for XenApp published desktops
ShareFile integration Through web SSO Embedded in Receiver
Location aware with Web Beacons No* Yes
SSO through Appcontroller Yes Yes
Initiate full VPN by clicking app No Yes
Separated views for Apps and Desktops Yes No
Auto Subscribed applications Yes Yes
Auto launch applications Yes** No
Sticky (mandatory) applications Yes*** No

* When connecting with Receiver for Web through Access Gateway, the connection is always established through Access Gateway. In Webinterface it was possible to configure the connection method based on the IP range, Web beacons makes the decision based on internal and external URLs but this only works for the Native Receiver.

** Auto launch is default enabled in Receiver for Web when there is only 1 published desktop, if you have more desktops published you can manually edit the Default.htm.script.min.js file to define which one should be auto launched, expected is that auto launch will be enabled through a keyword  just like with auto subscribed applications

*** Sticky applications removes the delete cross when you hover over the app icon, to enable this you need to manually edit the Default.htm.script.min.js file, expected is that sticky apps will also be enabled through a keyword in the app description

So it’s clear that there are some functional differences between this Receivers, which one you should use depends on the functionality you want and the access scenario you need to provide.
For example : If you want ShareFile integration besides published apps go for the Native Receiver, if you want to provide a (kiosk) access model for published desktops go for Receiver for Web.

6: ShareFile

ShareFile is another element of Cloud Gateway i’m very excited about, if you integrate ShareFile into your Cloud Gateway setup, you can give your users a true follow-me-data experience on every device without compromising on security. IT can remotely wipe data from lost or stolen devices and data is stored in an encrypted format to further improve security. Data is also available offline with ShareFile sync. Besides follow-me-data ShareFile enables users to share (large) files with colleagues, but also with external contacts, you can trace who downloads files or control the amount of downloads. Besides that file versioning, drive mappings and Outlook integration are all features that are available with ShareFile. Some elements are comparable with other follow-me-data solutions like RES Hyper-Drive, which is also a nice on-premise follow-me-data concept from RES Software, because ShareFile is now part of Citrix there is a tight integration with Cloud Gateway and the Receivers.

ShareFile and Appcontroller
You can establish a SAML trust between Appcontroller and ShareFile to provide account provisioning, in this way your AD users are automatically created inside ShareFile, I noticed in my demo environment that  this process sometimes take a while, so before you start troubleshooting wait a bit. Also be sure to create a role for ShareFile users inside Appcontroller, because if you select All Users, every AD account will be created in ShareFile consuming all your licenses (learned this the hard way). What’s very cool is that you can configure ShareFile to only allow authentication through Appcontroller and SSO, in this way users cannot connect to ShareFile directly further improving security. If SSO to ShareFile isn’t working please check the time settings on Appcontroller, if it’s a few minutes of SSO doesn’t work correctly, it took me some time to figure that out.

ShareFile Storage Zones
With ShareFile storage zones you can control where data is stored, a Storage Zone can also be On-Premise, more awesomeness will come in feature releases of Storage Zones when we can connect ShareFile to existing CIFS shares and SharePoint environments, imagine the possibilities!

7: Conclusion

Congratulations! you made it to the conclusion section 😉 sorry it was a bit of lengthy post but that’s because Cloud Gateway and surrounding technologies are a big deal and there is so much to cover. Cloud Gateway lets you aggregate and secure Cloud services and On-premise services into one logical logon point with the same look and feel on every device. Integration plays the key role in Cloud Gateway. I’m very excited about Cloud Gateway 2.0 and the upcoming features, on one hand its giving IT the flexibility and control over data, apps and security they need and on the other hand gives the user freedom to choose whichever device they like to use, I really think this concept is the future and I think it will change the traditional desktop as we know it today.

If you want to be notified when Part 3 or another blogpost comes out, subscribe to my blog site or follow me on Twitter : @bramwolfs

Please note that the information in this blog is provided as is without warranty of any kind, it is a mix of own research and information provided by Citrix. Some information is based on speculations and predictions.

Citrix HDX SoC finally the Thinclient becomes Thin again!

Table of contents :

1: HDX System on a Chip architecture
2: SoC and Citrix Receiver
3: SoC and RemoteFX
4: SoC and Windows Embedded
5: Conclusion

1 : HDX System on a Chip (SoC) architecture

In this blog we are going to take a closer look at the SoC architecture, and I will tell you why I think this is going to change the Thinclient industry.

What is a SoC?

A system on a chip (SoC) is an integrated circuit that integrates all components of a computer or other electronic system into a single chip.

This Single Chip contains both hardware and software components. The last one is for controlling hardware components inside the SoC. Please note that the Citrix Receiver software isn’t part of this software, this software contains codecs and other controlling software bound to the SoC itself.

The following components are part of the HDX SoC :

– ARM based CPU
– DSP (Digital Signal Processor)
– DMA (Direct Memory Access)
– NIC, Audio, Video and USB Controller
– Multimedia encoders/decoders

As you can see there is a lot of stuff in the Chip, you can almost say that basically everything you need is on this Chip, only memory and storage are external from the chip. This single chip approach is also taken by many other devices such as phones and tablets.

To make the chip more visual I made a drawing of the SoC architecture, please note that this is not a diagram of how the components interact with each other, but just a basic overview of the components inside the SoC :

The DSP is an interesting one, this component is used for image decoding which would otherwise be done by the CPU. Now that the DSP is taking care of the heavy lifting, CPU cycles are saved for other processing tasks increasing performance. Because the SoC is built from industry standard building blocks, the costs are kept to a minimal, so while the performance is increasing, the costs are being lowered, that’s what I call a win-win situation 😉

2: SoC and Citrix Receiver

Citrix Receiver itself isn’t part of the SoC architecture, this has the huge advantage that the Receiver software can be modified by Citrix without the need to update the SoC, so Citrix can add more features to Citrix Receiver without being slowed down by the SoC vendors to update the SoCs. To leverage the components on the SoC, Citrix provides a modified version of the Citrix Receiver for Linux, the process that takes place is fairly simple :

1: The SoC architecture exposes API’s to the underlying OS, this is done by the SoC vendor
2: The Citrix Receiver checks if this API’s exist when booting up
3: If the API’s are in place, Citrix Receiver will use the components inside the SoC and start offloading image processing to the DSP for example.

To illustrate this, I added the Citrix Receiver into the picture :

3: SoC and RemoteFX

While Citrix started the SoC initiative with a few chip manufacturers, the SoC isn’t reserved for use with Citrix HDX only, Thinclient vendors also support other remoting protocols on Thinclients with the SoC on board, for example RemoteFX can leverage the DSP as well. Now this combination is interesting, because you might think that RemoteFX features only works on windows clients with an supported version of RDP. Since this SoC consists of an ARM CPU and is Linux based you would not expect RemoteFX features there. Well this is done through the open source RDP client named FreeRDP. FreeRDP can leverage the DSP to offload image processing as well. Please note that FreeRDP currently only supports RDP 7 in combination with Win7\2008R2, there is no support for the new Remote FX features in RDP 8 (Win8\2012) yet. There is also no official statement that Microsoft is going to support FreeRDP with the new features in RemoteFX.

4: SoC and Windows Embedded Thin Clients

The first HDX SoC is coming with an ARM based CPU, this means no support for Windows Embedded, also Citrix Receiver for Linux is the only client from Citrix that supports the SoC initially. The x86 based HDX SoC will follow later, as you might know Microsoft will release an ARM based version of Windows 8 (Windows RT). The interesting part is that there will also be a Windows Embedded 8 ARM version, this OS will be more suitable for Thinclient hardware because it’s cheaper and less power consuming. WES nowadays isn’t really made for running on cheap Thinclient hardware, it’s like a big beast in a tiny cage, it’s slow and clunky to say the least. If you are looking for a way to tame the beast you should take a look at Thinkiosk from Andrew Morgan which provides a uniform interface across all your Windows Fat and Thinclients. There is also a interesting comparison between Fat and Thinclient hardware by Kees Baggerman and Barry Schiffer which shows some interesting results and discussions.

While the Linux based SoC Thinclients has much advantages regarding performance, small footprint and costs, there are some special use cases when you need Windows on your Thinclient end-point, for example when you need local printer or scanner redirection based on Windows drivers. I don’t think you need to make the decision based solely on HDX features anymore, because the most important features are covered in both versions (Windows and Linux), but there are certainly use cases that needs Windows Thinclients, my point is don’t buy them only because there is Windows on it which sounds save, but examine the use cases and mix and match!

A little bit off topic but I summarized a few highlights of Windows Embedded 8 that looks very interesting :

Hibernate-Once-Resume-Many restarts devices the same way every time
– Drive efficiencies by creating a custom image with only necessary functionality included
Keyboard Filter blocks special key-combinations on both physical and virtual keyboards
– Suppress Windows system dialogs with the Dialog Filter
– Manage and configure lockdown technologies with Unified Configuration Tool
Embedded Device Manager, together with SCCM, for operating system and application deployment

5: Conclusion

A lot of Thinclients (especially the more powerful WES variants) are almost in the same price range as a normal Fat client PC. When you are designing a VDI\SBC environment, this can be really a show stopper, because the goal on those projects is often to save money.
Now with the arrival of SoC the Thinclient is finally getting “Thin” again, Thin in form factor and price but not in performance!

5 Reasons why I think SoC Thinclients are going to take over the current Thinclient market :

1: Much cheaper to manufacture, because the SoC consist of industry standard building blocks it’s cheaper to manufacture then individual chips and components
2: The SoC uses far less energy to operate, there are even Thinclients coming that runs on PoE
3: It fits in more and smaller form factors, because it’s one chip it’s easier to integrate into other devices, such as monitors (or even TV’s)
4: The SoC is future proof, it contains standardized codecs and Citrix Receiver can be upgraded apart from the SoC
5: Performance wins, this is one of the biggest enhancements IMHO, because of the offloading and intelligent use of the SoC components performance is dramatically improved

I think with the coming of SoC we are also a step closer to nirvana phones, which I really think is the future together with BYOD.  Just dock in your phone and login, maybe Citrix should work together with some Phone manufacturers to get some HDX ready phones on the market 😉

Please note that the information in this blog is provided as is without warranty of any kind, it is a mix of own research and information from the following sources :

– Citrix unveils SoC initiative
– HDX SoC on Synergy 2012
– SoC WIKI reference
– SoC spurs innovation
– New Citrix Blog post from Vipin Borkar : Evolution of HDX SoC