This is a new step in application and desktop delivery access point process but Citrix again made it very messy to understand (at least for me…) This is very important to know and understand every component of this new products, but between, Receiver Storefront, CloudGateway Express, CloudGateway Enterprise, AppController and all the past names, some of us can be lost, and our customer are even more lost… (nFuse, Web Interface  2 3 4 5 etc… and Receiver Storefront)

If I remember well, at Synergy in Barcelona last October, CloudGateway had been introduce by Citrix CEO with this slide :

Now when I read documentation about CloudGateway Express and Enterprise release, I think we lost something :

The data “square” (ShareFile & RingCube (?)) is gone for now… Anyway, with the previous picture you can have a clear view about each component present in Citrix CloudGateway.

(more…)

22 107

  • Henrik Johansson

    “The upgrade from Express edition to Enterprise edition should be simple and painless, just need to try it out to check how simple it is”

    Yes and no since you don’t update the storefront, you add another source of information.
    In my opinion the naming of Storefront to Cloud Gateway Express is a marketing thing that confuses ppl.
    Storefront is your users entry point and Cloud Gateway Enterprise is information connector the same way XenApp/XenDesktop is.
    App access in CG Enterprise is still the same way as with Express.

    But…CG Enterprise is still a great product, just need to be clarified to ppl what it really is for and in what way access is suppose to flow (in current version).

    Pricing is the next thing to calculate on depending on what license you buy for CGEnt.

    And last…agree what you said…would be good to see more integration with ShareFile and still waiting to see the license integration for ShareFile to the existing licenses…it’s really starting to get to many add-on licenses…

    /Henrik “HenrikJay”

  • New post: Web Interface, moving forward to Receiver Strorefront ? – This is a new step in (http://t.co/VvydQ1pG)

  • Post Edited: Web Interface, moving forward to Receiver Strorefront ? http://t.co/VvydQ1pG

  • Post Edited: Web Interface, moving forward to Receiver Strorefront ? http://t.co/VvydQ1pG

  • Pierre Marmignon

    Along with the marketing mess, what scares me is that Web Interface will disapear and that its new replacement is not providing the same features !

    As a user frontend for a strategic solution, you should not have that many features missing.

    We may have to wait for StoreFront version 3.0 or 4.0 to have features Web Interface is already providing …

    So yes or no ? It also depends on the features you need!

    Thomas posted a good comparison on http://www.thomaskoetzing.de/

    Regards,

  • Pingback: Ingmar Verheij (@IngmarVerheij) (@IngmarVerheij)()

  • Pierre, I totally agree with you on the fact Citrix should give a production and full feature ready product as a final version.
    In an other hand, I understand Citrix, the pressure is very high now on the market and Citrix need to adapt very quickly as the range of their product is larger every year.

    Cheers, see you soon

    Stephane

  • Pierre Marmignon

    In my view, Production and existing customers are more important than marketing 🙂

    You can release a little bit less often but stronger products and avoid products like XenApp 6.0 you have to dismiss only after 2 years and a half …

    That’s really short when you are a strategic vendor for large corporations …

  • Pingback: Ingmar Verheij (@IngmarVerheij) (@IngmarVerheij)()

  • Pierre,
    About XenApp 6, one more time I agree with you and I’m afraid XenApp 6.5 will have the same treatment…
    I understand Citrix need to release fast and accelerate the development rhythm but what I don’t understand is the end of life of certain product (ie XenApp 6).
    But having a good delivery infrastructure will allow our customer to move forward from XenApp 6 to 6.5 or 7. This is where we needed to give good advices to our customer so they won’t be stuck to evolve along Citrix or other vendor releases.

    Cheers,

    Stephane

  • Pierre Marmignon

    There are some contradictions in what you wrote : let’s forget a little bit about the marketing and be pragmatic (lots of releases to maintain = money so the shorter the support cycles are the best it is when you release often):

    – Advise for the future as an expert, but assume in 2 years and a half the future won’t be supported (hum) ???!!! Could we assume, as experts, advising this?
    – What you’re saying could be true for SMB where it’s easier to do bing bang changes but not for large enterprises where a strategic XenApp deployment takes time.

    You can hardly deploy 100K+ users and all related applications in only a few monthes!

    – Moreover, if the good delivery infrastructure (PVS ?) has the same short support timeframe issues, then you are constantly migrating everything …

    I agree that we can help them to be more flexible but when the access layer is strategic it has to stick to OS support timeframes.

    This has the same impact as if Microsoft was doing the same with its Windows releases, would you trust them as a strategic layer ?

    Yes timeframes between releases are shorter and shorter, but IT is delivering a service and cannot afford this service to be in constant upgrade.

    I can’t imagine CSPs upgrading their all Xenapp Servers every 6 monthes …

    FTR Enterprise usually means 4 years of support (3+1).

    When you settle something in large companies or CSPs, this is for 3 to 5 years (generally 5), even with the most flexible infrastructure.

    All UAT processes / User experiences changes (…) are so important you cannot just sum it up as a XenApp 6.5 upgrade / PVS 6.0, even if from a pure technical point that’s what you see.

    You need to assess, test, automate, rollout … It takes time and costs money.

    For example, I have some customers with 200+ PVS streamed XenApp Servers and the PVS upgrade has to be studied carefully as well as the XenApp one.

    If the production is not working properly, it’s millions per hour lost.

    I won’t bet anything on migrating quickly to XenApp 6.5 / PVS 6.0 / XenServer 6.0 without a complete project management where I can guarantee the level of service to be at least the same and my customer does not have the money to do such projects every year and a half.

  • Pierre, there are no contradiction, I just try to comment and remain neutral.
    I’m more than aware about production priorities, project and financial issue regarding production disruption.
    My point is now we have more sophisticated tools, Citrix, vmware and Microsoft vendors are all playing the same game : They want to sell and earn money.
    We, your company, my company are using these products to leverage flexibility and cut cost within production environments, small or large. What I’m saying here is we need to think our delivery methods and architecture to be able to adapt those rapid product changes and evolution, we know how too well now what are the difficulties and the time it takes to move from a version to the next one (Citrix, Microsoft and vmware etc …)
    Of course there is automation, assessment etc and yes, it needs to be address as a project but the strategy now is to think and build a flexible solution to be able to bring on every new version or new component without having to change the whole project as well as in time frame as in resources and cost…

  • Pierre Marmignon

    No Offense but it’d be possible in an ideal marketing world where every new release is stable and production ready and does not cause any outage risk and regarding my experience, that’s not the case in my real world but I may be missing something 🙂

  • Pierre Marmignon

    To conclude this nice discussion, i think we can agree to disagree 🙂 BTW it was nice discussing with You and I’ve had this discussion with lots of people and they are two points of view on this one what our comments discussion is reflecting.

    See you soon !

  • It’s always nice to exchange opinion with you 🙂

    See you soon Pierre !

  • Sam

    Hi Stephane,

    I am quite disappointed by the fact that the Receiver Storefront is not customizable out of the box. I think the green bubbles doesn’t give the Receiver 3.1 enough justice in terms of look and feel. Is there a way to customize the Receiver without having to use an Access Gateway ?

    Thanks in advance

  • Hi Sam,
    I agree the lack of customization and feature available with WebInterface is a shame.
    To make things clear, you can customize CAG since 5.0.4 but it customizes only the CAG logon screen, then the Sotrefront receiver need some manual work to obtain a cool customization.
    I’m doing a side by side feature comparison blog between WebInterface and Storefront, it will be soon online

    Cheers,

    Stephane

  • vikram

    Hi,
    currently we are using Web Interface 3.4 with XenApp server 6.0 for Windows 2008 R2. We want our website to be acccessed via iPad and android tablets and we need to pass some configured values via Reciever to the published application. We are able to do this for iPad but its not working on Samsung Tab as the Receiver for Android does not support passing command line parameter via Receiver..
    Can we implement the above by using StoreFront?
    Please help!!

  • Hi Vikram,

    I’m not sure this is related to the Web Interface version number or the CloudGateway product. It looks more like a “missing” feature on the Citrix Receiver for Android…
    DId you try with the Receiver for Android beta ? https://market.android.com/details?id=com.citrix.labs.Receiver&feature=search_result#?t=W251bGwsMSwxLDEsImNvbS5jaXRyaXgubGFicy5SZWNlaXZlciJd ?
    Cheers,

    Stephane

  • vikram

    Hi Stephane ,
    Thanks for the help. We had confirmation from Citrix that Receiver for Android does not support this feature so we wanted to use the Storefront if we can store some user specific values on the client device i.e. iPad or Samsung Tab. If we can store the values locally by using StoreFront then it may work for our purpose as Web Interface does not provide any feature to store values at client device.

  • Pingback: @archynet()

  • Pingback: Receiver Storefront – adding a server to a server group | archy.net()