Ruben Spruijt have updated the Application Virtualization Smackdown document to version 3. get it here

Ruben Spruijt have greated an AWESOME article about understanding how storage design, has a big impact on your VDI.

Citrix Consulting have used these informations and put them in their whitepapers and use the numbers for “Best Practise” its very important that you read this article if you are planning about implementing VDI on your Storage, because it can go very wrong if you dont understand the impact that VDI can have with your Storage.

The whitepaper can be downloaded from the  http://virtuall.eu/download-document/vdi-storage-deep-impact

Access Gateway 5.0 adds appliance failover as a new feature, which allows two appliances to run as an active/passive pair. In this post we’ll look at how failover works in Access Gateway 5.0, how to set it up and what end users can expect to experience in the event of a failover.

How it works 

When two appliances are joined as a failover pair, users connect to a shared virtual IP address instead of the real eth0 or eth1 IP address. You define one virtual IP address that users will connect to, and another virtual IP address which Access Gateway will use when communicating with back-end resources. 

These two virtual IP addresses can use the same IP address if you like. At the outset, any traffic sent to the virtual IP address will be handled by the primary appliance. If the primary appliance fails, then the secondary appliance will send out a network broadcast (gratuitous ARP) letting the nearby routers and switches know that it is taking over for the shared IP addresses. 

How does the secondary appliance know when to take over? Every second, the secondary appliance sends a health check request to the primary appliance on TCP port 694, expecting a normal response in return. If 10 of these requests in a row are unreturned, the failover event is triggered and the secondary appliance takes over. 

Sessions stay in sync 

During normal operation, user session information and policy configuration changes are automatically sent to the secondary appliance as changes occur. Therefore, when a failover occurs, users shouldn’t have to log on again. If they are connected to a hosted application or desktop using ICA, the Citrix Online Plug-in will leverage its Session Reliability feature to re-establish the network-layer connection with no data loss and minimal disruption to the end user. Ditto for the Access Gateway Plug-in; the end user gets silently reconnected without having to re-authenticate. While re-authentication should not be required, note that any TCP sessions that were active within a user’s VPN tunnel will have to be re-established after the connection is restored. So if the user was downloading a file when the failover event occurred, they would have to re-start the download. 

How to set up failover 

Start at the appliance you want to be the primary. Before you can enable failover, you need to assign an interface to the Appliance Failover adapter role. This is done on the Networking page of the appliance management console. If you’re using a Model 2010 appliance, choose eth1 for this role. If you have a virtual appliance, you can use eth1 or add a dedicated virtual interface (eth2) just for this role. After assigning the failover role to an interface, you can configure the settings on the Appliance Failover page. 

On the Appliance Failover page, you’ll need to provide four pieces of information: 

• Shared key – this is a common password known to both the primary and secondary appliances.
• Peer address – the IP address of the failover interface on the secondary appliance
• Internal virtual address – this is a new IP address that will be shared by both the primary and secondary appliances. The gateway will use this address when communicating with authentication servers and other internal resources.
• External virtual address – this is another shared address. End users connect to this IP, so it should be an externally routable address or the DMZ address that your external address maps to. The internal and external virtual IP addresses can be the same if you so choose.

After entering the above information, click Save and then click Start. You’ll be asked to reboot. After rebooting, users should be able to log on by pointing to the external virtual address. 

Next, move to the management console on the secondary appliance. On the Appliance Failover page, change this appliance’s role to Secondary, and enter the following information: 

• Shared key – type the same shared key that you defined on the primary appliance
• Peer address – enter the IP address of the primary appliance’s failover interface

Click Save and then Join Primary. After rebooting the secondary, appliance failover is now configured. On the secondary appliance, most of the configuration pages in the management console will become inaccessible since it inherits configuration settings from the primary, including host name, certificates, licensing configuration, authentication profiles, logon points, SmartGroups, secure ticket authorities & access control lists. Adapter roles, IP addresses and static routes are not shared between primary and secondary appliances. 

Notes 

• In earlier versions of Access Gateway Standard Edition, there was a failover feature that only worked for full VPN connections. In version 5.0, failover works across all connection types and does not require the Access Gateway plug-in.
• If you have trouble getting failover to work, use the console networking utilities to ensure that each gateway can ping the other’s failover interface IP address. When you have multiple interfaces, each interface should be on its own subnet. When the failover interfaces can’t reach one another, both appliances will think they are the primary.
• If you want to enable single sign-on to a Web Interface site, configure the Web Interface to resolve the Access Gateway FQDN to the internal virtual IP address. That way when the Web Interface server makes a call to the authentication service URL, the callback will reach whichever appliance is currently serving as primary.
• Physical and virtual appliances can be mixed within a pair. If you currently have a single Model 2010 appliance deployed, consider adding Access Gateway VPX as a failover appliance. This is a great way to get started with VPX and add redundancy to your deployment.

For more information about appliance failover in Access Gateway 5.0, refer to the Access Gateway 5.0 Documentation topic or watch this video of the failover configuration process.

Technology Concept Release

Citrix Labs is pleased to announce the availability of Project Alcatraz Technology Concept Release.

Project Alcatraz provides the ability to lock the screen of any application delivered by XenApp to mobile devices after a period of inactivity by using a simple PIN keypad.
 
As this is a new capability for Citrix, we have chosen to assess market interest and opportunity via a Technology Concept Release.  As yet, no decisions have been made around commercialization of this technology.

Try Project Alcatraz here

Citrix Receiver for Android 2.0 includes the following new features:

• Connections to XenApp and XenDesktop through the upcoming release of Citrix Web Interface version 5.4.  This allows you to access your enterprise applications using Android’s built-in web browser working with Citrix Receiver.  Web Interface also supports 2 factor authentication secured using SSL.
• A task switcher feature that allows users to switch between multiple host side applications. This is useful with Citrix DocFinder where you may have multiple applications open when viewing and editing your documents.  Switching between those applications is now a lot simpler thanks to our new task switcher
• High quality, low bandwidth audio.  This enables users to view and listen to corporate presentations, videos and other content that is delivered to Receiver.  The low bandwidth requirement for high quality HDX audio means that this audio works well over WIFI as well as 3G connections.
• Storing user passwords for accounts created on Citrix Receiver (Administrator configurable).  This means no more typing your domain password every time you start an application.  For administrators this feature can be controlled in the same way that password saving is controlled on other versions of Citrix Receiver -through the Citrix Web Interface Management console.
• Support for time zone redirection allowing the time zone of the device to be used in the session.This is particularly useful for time based applications such as desktop sessions and calendar applications where the XenApp or XenDesktop data center is either running on UTC or in a different timezone to the end user.
• Reliability and stability fixes.

Download here