Today I learned that Citrix posts its XenApp build debug symbols to a publically accessible symbols server.  Cool!  This is mostly to make life easy for the Citrix support folks, but what ever the reason, this means that the symbols are in a place that you can see them!

If you are familiar with WinDBG or Debugging Tools for Windows, then you know that the Microsoft Symbol server is a welcomed item in understanding the state of any machine you are inspecting.  Microsoft posts all the symbols for every component of every released version of Windows to msdl.microsoft.com/download/symbols. Set up the _NT_SYMBOL_PATH environment variable and the debugger does the rest to fetch Windows symbols from the internet.  Yeah, old news. 

I recently learned that Citrix also posts the XenApp symbols!  And to this I say, down right neighborly of us! 

Here's the link that says how to set it up, CTX118622.

What are symbols?

When building a program, the compiler does its thing and then the linker does its thing to actually create the executable content.  When putting the program together, one of the things that the linker does is produce a table of program symbols and their location in memory (symbols).  Programmers use these to figure out what's going on where they can then see nice "strings" rather than hex numbers. I say programmers, but it is really the debugger that does the work. 

There are two choices in symbols, the "FULL" and the "STRIPPED".  Simply put, the "full" ones are better, much like source code access.  The stripped ones though are still very helpful and it is these that are on the Microsoft download server ... and the Citrix download page. 

Neat thing of today, I've been writing code at Citrix for a long time and never known that the symbols were available to the outside.  NEATO.  This sure beats debugging stack traces with only hex locations of functions.

If you're not debugging systems on a regular basis, you may still find this useful for analyzing crash dumps.  One of the first things you do after a failure is windbg -z memory.dmp and then !analyze -v.  Give the debugger symbols and you can get a more precise location of a failure.  Good stuff.

Joe Nord

Today, most of the "new workforce" has grown up with computers, TiVo(tm), social networking, instant messaging, blogging, texting, Twitter, and the Internet. In most cases, these people are tech-savvy and they have an understanding of newer technologies. They all carry a cell phone and use it as a main point-of-contact. They have, and will, leverage new technology just to see "what it does."

When new workers join the workforce, they expect a similar computing experience. If the "Echo-Boomers" have a company computer, they expect it to behave and be comparable to the laptop they use for personal computing needs. They expect a choice of computers based on merit, aesthetics,and function, but do not see the reason for standard issue laptops that are not as advanced as the personal computer they use at home. They want a small selection to choose from and want to customize it to make it "their own."

IT, on the other hand, looks at the standardization of equipment as a "must have" to support the hardware. What if IT did not have to support the hardware and just the digital assets? What if the user took care of the hardware?

There is a "middle-ground" in this battle between IT and "new generation." It is called Bring Your Own Computer (BYOC). Citrix has been in the news over the last year with this concept and I have received many emails asking me to explain this "new school of thought." In this series of blog posts I will demystify the BYOC paradigm and show you how users can have a choice of computers and devices whilst IT retains control over digital assets that are paramount to company success. Stay tuned...

HDX MediaStream does a fantastic job of reducing the network bandwidth requirements for streamed video compared with rending the video on the server. When using HDX MediaStream your bandwidth requirements roughly equal the bit rate of the source video file. For lower quality clips, like those found on YouTube, this is around 256Kbps. For full HD content the bandwidth requirements can be as high as 8Mbps.

While this works great over a high speed LAN, trying to push that amount of data over typical branch office T-1 is another story. This problem is magnified even more when you have multiple users in the branch office who are repeatedly pulling down the same video content. In this situation, the video quality suffers and other business applications can be impacted. This issue has nothing to do with XenApp or XenDesktop. It is purely a function of the size of video file and the limited amount of available network bandwidth.

What can you do about this? Well if the culprit is the latest viral video making its way around the Internet you could attempt to block access to sites like YouTube. However, what if the video is for legitimate business purposes? I talked to one customer at Synergy who is rolling out a corporate compliance training video to their entire company using XenApp but is worried about the impact to network bandwidth.

Enter Citrix Branch Repeater and HDX IntelliCache. With Branch Repeater 5 we now participate in the ICA session and accelerate the ICA virtual channel used by HDX MediaStream. The first time the video is streamed to the branch office, Branch Repeater caches the content locally. The next time the video is requested, Branch Repeater serves the content from its local cache rather than pulling it across the WAN. Using branch caching, you can reduce the bandwidth requirements for on-demand videos by up to 90%.

Don't just take my word for it. You can see a demo if this in action on the latest edition of Brian Madden TV. (If you don't want to watch the entire episode you can jump ahead to 5:49 into the clip).

The "layers of cake" presents great opportunities for Citrix Delivery Center storage optimization.  Rather than store separate images for each machine, you can have ONE image for maintaining the operating system, ONE location which holds the application images, and ONE location for the User Profile.  This is valuable for XenApp, but it is especially important in XenDesktop where the number of machine images multiplies to be a really big number. 

This post describes the "problems" of getting applications into this layered world and discusses multiple solutions; including several that are not ideal.  It concludes with short term and long term recommendations.

Here's a slide that I presented at the Citrix Synergy conference in Las Vegas last week.
 
Even has candles!  Provisioning Services provides the bottom layer.  Application Streaming provides the middle layer and Citrix Profile Manager provides the per-user settings as the top layer of this multi-layer cake.  Getting this to move from "vision" to "reality" though involves system design and piecing this into your larger data center configuration is a complex operation.  The benefit though is increased flexibility and improved management of your systems as you are managing only images and assigning these as workloads to machines. 

Why does Application Streaming provide the middle layer
In this discussion, the "Streaming" aspects of Application STREAMING are really overrated.  The important fact is that the base operating system image focuses on being the operating system and the application layer focuses on providing applications.  Application Streaming is well suited to this need primarily because of the just in time application delivery - delivery based on which USERS will actually visit the machine.  To implement the separation in the layers of cake, the lowest layer cannot have knowledge of the application set and this means that the applications have to be RUNTIME provided to the execution machine.  The Citrix XenApp publishing does exactly this, both for Stream to Server (XenApp) and for Stream to Desktop (XenDesktop).  In both cases, the machine is "vanila".  A user logs in, application icons are placed onto the machine via the Plugin for Hosted Apps (aka PNAgent) and eventually the user clicks on something to cause the application to run.  With "streamed" applications, the applications are presented to the user "just in time" for their use.

Where it gets complicated
WOW, this is awesome.  I can have my cake and eat it too!  The details though are subject suitable for significant debate of best solution.  In particular the delivery of applications to the middle (application) layer. 

Provisioning Sevices will provide the base operating system image to the bottom layer and this layer will be absent most applications.  Sure, some foundation applications that are used by all users may be in this layer, but the advantage in the layers of cake is separating the applications from the operating system and this motivates us to want the apps delivered via Application Streaming regardless of benefits of isolation. 

Provisioning Services implements ONE to MANY by having a single disk image that it distributes to MANY "machines".  These machines may be real machines, or they may be virtual machines.  Either way, they get a MAC address and this defines them as a "machine".  Since this is a disk image and used by many, PVS must implement "write-back" cache so that machines using the shared image can update that image at runtime.  Important changes to the single image will be performed in "single" mode of PVS, but runtime changes to the disk must be maintained so that PVS can runtime support the temporary changes that the host operating system and applications will make the the "disk".   For each machine that PVS is running, it maintains a write-back cache.

The PVS write-back cache is "temporary".  When the machine shuts off, it is discarded.  This is what we "want", but it also "must be" because PVS is a block based implementation of a disk and it really has no idea what is stored in what block on the disk.  It doesn't even know what the "files" are.  With numerous machines "writing" conflicting changes to the disk at the same time, the only way out is to write cache these and then discard the cache when the machine shuts off, or in the XenDesktop case, when the user logs off.

Why is this a problem

If the Application Streaming application content (RadeCache) is runtime populated, then users will experience a first time application launch penalty each time the machine is booted.  In the XenDesktop case, this will be experienced on each logon.  The RadeCache must be populated and while it holds only a portion of what the application "installed", it is still enough data that the population of this space is a sore-point for first time use of applications.  In server case, or stream to a physical desktop, the first time launch is a one time cost.  The second time launch is much more important.  BUT, in the layers of cake the first time launch penalties become a every logon penalty.  The first experience on each logon is that the user behavio will be "slow" and then this "slow" performance will be repeated each time the user logs off and logs back in.  NOT GOOD.

It gets worse.  The PVS system write-back cache is about to get hit with LOTS of stuff.   As an example, consider MS Office 2007 on the notebook from whcih I'm writing this post.  The populated stuff to support MS office is about 400MB of disk space.  This will populate into the PVS write back cache and that's alot of disk space if you multiply it by 1000 machines.  More to consider, the Application streaming System does a network read to get the data from the Application Hub, it then writes it to the "local" disk, which in this case, isn't local.  The PVS write-back system then has to send that data across the network, back to the PVS server, who has to maintain the data on a per-machine basis; and potentially later, send that data BACK across the network to the execution machine to support execution.  I'm not sure of the numbers, but if you load it heavily enough, this will start to be a burden on almost any network.

How to solve

First a bit of background on the streaming system storage of application content.  The disk storage is the key here.  Everything that represents the application gets added to the streaming execution cache, which defaults to disk location, \program files\citrix\RadeCache.  There is a GUID beneath here to hold the execution content for each "profile" or execution "target" which represents the installed application that the streaming system is keeping track of.  Technically, a versioned GUID, GUID_version where version is used to allow "hot" update of applications.

You COULD populate the RadeCache into your base PVS disk, but this rather defeats the separation between Operating System and Application images.  This solution is "out".

The better solution says that the RadeCache should not be stored on the same disk volume that is the bottom layer.  Instead, the RadeCache should be moved to another disk volume and this disk volume should be common and shared across all the using systems (XenApp servers or XenDesktop clients).  Now, the maintenance of the operating system image can be ONE; and done via Provisioning Services and the maintenance of the applications can be ONE; and done via the Application Streaming profiler + the shared RadeCache execution space.

Getting more complicated
Much of what follows are multiple approaches to solving this problem.  The "correct" answer will depend on your network configuration and the tools that you have available to assist with representing a shared network resource as a local system disk volume.

PHYSICAL MACHINES

The easy solution.  In XenApp for example, even if using PVS as boot source, you likely still have a physical disk volume on the execution machine.  If yes, configure that space as write-back cache for PVS and the complications are improved.  The extra network hops will go away.   I'm not positive, but it is likely that this write back cache still resets on each boot, so there will still be first-time launch penalties.  With that, we should instead focus on machines that have no physical disk as the solution here will work for both configurations. 

We need a central source that can be mounted into all execution machines and treated as streaming runtime execution storage.  We want the "RadeCache" to be "fully populated" so that the streaming system NEVER needs to do a runtime cache fill.  In this way, the "streaming" aspects of Application Streaming are handed off to other technologies that will make the RadeCache appear as present even when they are remoted.  A side benefit of this is that App Streaming file based cache fills then get replaced with a page based system.

Application Hub

In a way, we already have a central space that holds the application content, it is the Application Hub.   Generally, all the profiles are stored beneath some "top" location and each profile contains the execution content to support that application on what ever the execution system may be.  One complication is that the "execution stuff" is stored inside a .CAB file.  While this is handy for compression and handy for portability to offline execution, it is not handy for access at runtime, pretending that the cab contents are actually present on the referencing machine.  It WOULD SURE BE HELPFUL if the CAB file were replaced with a subdirectory that has the same name, but is an uncabbed representation of the execution content.   In this way, the streaming system could redirect the local machine RadeCache\GUID_v to the Application Hub, profilename\GUID_v directory.  Do this and the problem is SOLVED.  Only problem, it doesn't work. 

Redirecting the execution content to network source

The "LINKD" command in Vista command prompts provides the foundation.    You need to use the /D option to create a directory junction.  Cool part here is that you can redirect the directory space to another volume and that volume CAN BE ON A NETWORK!  My experiments say that this works on Windows Vista, but that it does not work on Windows XP.  Given most XenDesktop configurations are Windows XP, this is a complication.  Note that the foundation reparse points that make this magic possible having been present in NTFS since Windows 2000.  The ability to convince the OS that this is present appears to only work on Vista and above.  I wrote some programs to exercise this back in the early Tarpon days; none bore fruit, but then again, Windows 2000 was a required operating system at the time, so more options may be available.

But wait, I can mount a volume into an empty directory on Windows XP.  Yes, yes, you can, but you can only mount the ROOT of that volume.  On Vista, you can mount subdirectory to subdirectory -> Much more useful!

The foundation commands are: As an admin:

CD \Program files\Citrix\RadeCache

mkdir \\apphub\share\profiles\profilename\GUID_v  (and then uncab the cab contents into that dir).

MKLINK /D GUID_v \\apphub\share\profiles\profilename\GUID_v

DIR GUID_v  ( Local directory, then you see everything on the network server )

In theory, DONE!  The streaming system will redirect stuff into the RadeCache, the I/O manager and NTFS will convert those into reparse points where they will ultimatley go back down the stack, this time as a network file system operation and all will be happy.

But, runtime, the Application Streaming system gets unhappy.  I have tested this only with the non-released streaming client that I'm using on all my machines, including the machine I'm using to write this post.  There is some chance that this will actually work on the currently released stuff.  The stuff "you don't have yet" does registry MOUNTS rather than loading of registry information.  This is far more efficient at runtime, but it is also dependent on the operating system supporting the mount and when asked to mount a registry hive from a non-local disk location, the system responds, very simply, "NO".  DUDE!  Nothing is local!  You think C: is better than that redirected space, trust me, it's all bad!  Please push on and give it a shot!  Nope.  Doesn't happen.

Using a second disk volume
Provisioning Server focuses on providing the operating system image; read this as "one volume" per machine.  What if you had a second "local" disk volume?  Yes, that would work!  You could tell the Application Streaming system to move the RadeCache to the second disk volume and all would be happy!  The streaming system already comes with a utility to move the cache, it is ClientCache.exe and is included and installed with the streaming client.  Here's a link that describes how to use it.  So far so good.  The streaming system though will insist that this "new" location be on a "local" disk. 

The second disk volume would contain only a fully populated view of a conceptual RadeCache of a machine that has ALL applications fully streamed.  Requires the admin to create this second disk image and requires that this image be maintained when applications are updated, but all of these things are containable and might even make sense as we all get used to maintaining the layers of cake.

How do you MOUNT a second disk volume?

Nicely, this disk volume does NOT have to exist at machine boot.  It only needs to exist BEFORE the user has a chance to launch any "streamed" applications.  If we assume that they do that in their startup folder, then this means that we need the second disk in place as a function of logon.  It could be in a system logon script.

The mounted disk volume must be LOCAL.  The streaming system insists on it.  It isn't that the streaming system is against storing execution content on remote systems, it just insists on it - which is interestingly very similar to the registry mount rocks I threw earlier in this post. 

The streaming system file system filter driver observes all file system volume mounts.  If it's "local" and if its "NTFS", it gets involved in the I/O stack and can use this space as a place to store the execution content.  

The App Streaming system spends alot of time lying to applications about what is present.  Our trick is to LIE to the LYING system to fool it into believing a disk volume is "local" when everything is really remote.

How to lie?

Some customers have elegant disk systems that allow them to mount extra "drives".   If so, then the ideal such system would allow mount of space into N machines where there is ONE backing store.  In utopia, this space is read/write.  Only the Streaming Caching service will write to it and any writes done for any user on any given machine would then benefit all users on ALL machines.  ELEGANT!

I belive such systems exist, but I have not yet seen it successfully implemented.  One complication is that the streaming system insists that the disk volume be formatted NTFS.  If the file sytem isn't NTFS, we get out of the way.  In this case, we don't want to get out of the way and given numerous machines accessing a single shared source, the odds of this having NTFS as the file system are ... remote.  It will though have most everything we need.  If you have one of these, shoot me a line and we'll work with you to get the streaming filter willing to put the streaming cache into that space. 

VHD, ISO

XenServer, VMWare, Hyper-V

The machine virtualization technologies also provide tools to mount disk volumes.  If we can mount a single disk volume, local disk, into multiple machines, ideal.  If this supports WRITES, better.  At logoff, would need to merge this common RadeCache back to a master store to become the base image for additional users.  All of this would work - but it is all very involved.

Ideal world

In an easier world, the Application Streaming system itself would permit redirecting the RadeCache execution space to a central network location, on the Application Hub.  That does not exist.  The fact that I'm talking about it though should tell you that I want to solve this problem.  I've been avoiding talking about it because I am not yet satisified with the answer.  This post though attempts to discuss your NEAR term solutions.

What should I do?

Near term, populate the RadeCache into the base PVS image.  I know this isn't ideal, but it is a workable solution and solves the performance aspects.  Longer term, investigate mounting .ISO and VHD and look into abilities to leverage storage arrays to provide "local" disks that are really remote.   Longer term, understand that this is a common need and solving it, is broadly important. 

Joe Nord

Product Architect- Application Streaming and User Profile Manager

Citrix System, Fort Lauderdale, FL

I recommend: Never PreDeploy to XenApp Servers; never PreDeploy to XenDesktop clients.  Always PreDeploy to notebooks.

Background: Application Streaming supports server side execution, client side execution and client side execution that can go offline.  These are controlled with publishing; should the application be available for offline or not, and via client side utilities (RadeDeploy) to optionally predeploy the execution content to the execution machine.  Notice that PreDeploy is REQUIRED and automatic for offline, but that Deploy is optional for online. 

What does "online" mean?

Online execution means that the streaming client has everything it needs to run the application available via the network.  This means that it can "see" the Web Interface and can "see" the Application Hub.  By contrast, "offline" means that execution can still happen when the Web Interface and Application Hub are not available.

In programmer speak, this is a 2*2 matrix with 4 possible states; one of which is invalid, offline without Deploy.  I argue that Deploy + online, while valid, should not be used if the execution machine is inside the data center.  If the network is "solid", don't Deploy.  The corollary, if the machine is "sketchy", always publish for offline, with automatic deploy.  This would get the number of states down from 3 to 2, which makes programmers happy.

What is Deploy

The guts of the streaming client are unaware of whether execution is server side or client side, online or offline.  The execution engine brings execution content into the RadeCache (\Program files\Citrix\RadeCache) and fetches that execution content from a CAB file on a file server or web server (App Hub).  In the online case, the cab file location is REALLY on a server.  In the offline case, the streaming engine is pointed to the Deploy location on the local machine and does "local streaming".  I call this streaming from one side of the hard disk to another; it was my idea back at the beginning and I must say that 4 years later, I'm pretty happy with myself.  The caching activities in the streaming service and the kernel mode stuff in the file system driver are completely oblivious to "offline/online" and the streaming happens with the same code path in all cases; happy.

Deploy is implemented by copying the execution content from the Application Hub and placing a copy of the Application Hub contents onto the execution machine; in \program files\citrix\deploy.  Looking back, I wish we had put the RadeCache and Deploy directories one level deeper, but this is where they exist. 

How to deploy

There are two ways to deploy.  In the automatic case, the admin publishes an application and, to some users (you), publishes that application as available for offline.  When you refresh applications in PNAgent (plugin for hosted apps), PNAgent gets a list of all of the applications that are available offline. 

The administrator has a choice when publishing.  In the Access Management Console, the admin can say that the Pre-Deploy should happen immediately, or they can state that the Deploy should happen on the FIRST use of the application.  I have not yet found a single admin who has gone with the Deploy on application refresh.  Network storms at 8:05am are not how they want to start their day.  This means that applications are not available for offline until the application has been run online, at least once.  

Eventually, the user (you) clicks on an icon to run the application.  The application is run as if "online" and in the background, the server side content is xcopied down to the Deploy location on the execution machine.  This automatic action does not occur if execution is on a XenApp server. 

The first use of the application continues in "online" configuration and it isn't until the next fresh launch of applications from that profile that the offline content is used.  Looking back, it would have been better to have completely copied the offline content to the execution machine before ever running the application.  The user feedback could then be ... "Copying your offline content, please go get a cup of coffee while I transfer 2GB to your machine".  Instead, the user is faced with online execution, competing  copying execution content from the file server into the RadeCache AND the streaming system copying the whole CAB file from the file server into the Deploy location and this presents a less than ideal first time experience, if the application is large.  Yes, the offline deploy is done on an "idle thread", but single user, 2GHz + dual-CPU machines spend lots of time idle, so it competes.  Eventually, you get the execution content local and further streaming from that profile is local to the execution machine AND available for offline. 

How to PreDeploy to XenApp server

First, don't!  Second, you could use RadeDeploy.exe to command the deploy to happen, and if you do, it will occur.  This would normally be done by software management system.  The streaming client running on that server will at runtime look for the deploy content and if it is there, it will use it. 

WHY NOT Deploy to servers!

It isn't about the first execution.  Yes, the first execution will be faster if you are PreDeployed.  The application update though will be SLOWER.  You first deploy.  This happens once.  Later, you will update the application numerous times.  The update in "online" scenario is more efficient than the update in "offline".  I should note that I really mean that the update is more efficient without PreDeploy.  Online/Offline is not the trigger, the trigger is Deploy/NotDeploy - then again, one shouldn't deploy without offline, so they really are the same state.

Consider a large application, say 1GB in size.  If you PreDeploy it, you will have everything available for cache fills based on copies across the local disk; efficient.  If instead, you don't PreDeploy it, some small percentage of the application will be runtime copied into the execution cache.  

When it comes time to update the applications MOST of the execution content will be unchanged.  The Streaming Client will "KNOW" what files are the same, and which are different and it will "KNOW" this without a deep look at the files inside the CAB.  In the online case, all of the "same" content can be immediatley promoted from version 1 to version 2 with no network involvement and this happens whether deployed or not.  In the "deployed" case,  the streaming system though needs to bring down EVERYTHING and this is very inefficient. 

In Streaming Client 1.1, this resulted in a full copy of the CAB file from the network server to the Deploy location on the client.  Notice that it is a single file (the cab); the client copied the whole thing and this is not friendly to the network and worse, it is very bad if the user is remotely connected over a VPN; where Deploy SHOULD be used.  

In Streaming Client 1.2 (XenApp 5.0), the streaming client was enhanced to bring down only the "deltas" from version "old" to version "new".  This is much more efficient network wise and brings Deploy case on-par with the online case, but it is still less efficient.  Ultimately, the whole cab file is needed for both "old" and "new".  The streaming system knows what has to exist, but the CAB file format does not allow update in place.  To save network usage, the streaming client trades client side CPU and Disk activity to save network.  This means that the Deploy update consists of a full un-cab of the CAB file, apply the updates, and full re-cab.  For a 1GB application, this can take minutes!  10s of minutes?   What is my machine doing!!  AArgh!

In a XenApp hosted environment, there is no need to pay the un-cab/re-cab penalty; the most efficient update is directly inside the execution cache and this has existed since the first release of Application Streaming.  All of the above rocks thrown, are we going to make the Deploy/Offline case more efficient?  Certainly!

What should I do to optimize first time launch on the XenApp server?

Turn on "-e" RadeRun switch.  Here is a KB article with more details.  Execute one application from each profile, ONCE.  Finally, be sure to then turn off -e.  Yes, I say turn it off because if you don't you will un-pack everything from the CAB on EVERY launch of any application for every user - which will be dog slow.   

You can achieve the same thing by running RadeRun.exe directly from the command line, specifying the -e switch.  This best done by automated systems, when the users aren't around.

With the single run with "-e", everything will be extracted from the Application Hub and placed into the streaming execution cache.  The streaming system will still do it's "just in time" programming, but it will pretty much never conclude that a cache fill is needed and the result is that execution will not suffer a first time launch penalty.

Enjoy, 

Joe Nord

Citrix Systems, Product Architect for Application Streaming and User Profile Manager.

I was on a webinar with Goldman Sachs last week and their most technically astute analysts were talking about the future of virtualization in relation to Public and Private Clouds as well as the ability to deliver next generation applications using Web 2.0 technology.  I posed the question to them, "What about the tens of thousands of applications that have been written in Windows that either can't or won't make the transition to 'webification'" (a cool term I dreamed up at the spur of the moment!).  The answer was predictable but unfortunately had been left out of the entire discussion until I brought it up.  The analyst responded, "Whoever figures out how to get those [Windows] apps into a SaaS model has a huge opportunity in the market today."

Well lucky for all of those ISVs who have written their code in Windows that Citrix has developed a way to bridge the gap between Cloud nirvana and Cloud reality. With this in mind any application that is currently available over Terminal Services can be deployed directly from the MSP or Enterprise in a SaaS model.  But what is promised by Cloud hype today for a seamless, simple and secure environment will take time to evolve. There will be three phases to the delivery of applications through the Cloud.  This journey will take anywhere from 5-10 years but there are elements that can be done today.  This evolution will be consistent with existing business practices in both the service provider (hosted applications space) and the Enterprise IT space.  In a phase I, the foundation by which ISVs, Service Providers and Enterprises look to deliver solutions is depicted in the illustration below.
First we need to understand that there will be two basic customers of the Cloud to deliver SaaS; the Managed Service Provider (MSP) and the Enterprise.  Small and Medium Business (SMB) customers look to MSPs to handle the complexities of application delivery, business continuity and IT management.  These MSPs are also often times ISVs in their own right, delivering their application over the Internet as a cost effective distribution mechanism.  What the Cloud means for the MSP in Phase I is a growth strategy for low cost CapEx.  MSPs will use the Cloud by extending their data center server farms and in some case the entire infrastructure depending on the complexity of the application.  The simpler the app, the easier it is to replicate in the Cloud.  Also,  it makes a great deal of sense for these service providers to use the Cloud for business continuity as the usage will be variable and cyclical in nature.. a great way to save costs.

Enterprises are skeptical of the Public Cloud as depicted in this illustration and will be looking for data center extensions but much more related to non mission critical applications that have little affect on the day-to-day running of the business.  Certain web sites, databases, and non business productivity apps are included in this set.  The core focus of this phase will be expansion and extension of the data center, not replacement.  Private Clouds will have to evolve first in the Enterprise in order for there to be any synergy in full extension of service into the Public Cloud.

The key element to either MSP or Enterprise use of the Public Cloud for Software delivery will be the ability to provide a seamless interface depicted in this illustration as the "Cloud Bridge".  In other words to fully accomplish data center extension, the administration of workloads and storage will indeed have to be extensions of the exsiting systems.  To do this, Cloud providers will have to enable administration consoles to integrate with the management of workloads in the Enterprise and MSP.  Without this capability, the cost of managing disparate systems will overshadow the cost savings of hard capital.  Use of the Public Cloud for computing will be limited without this functionality.

Further, in order for Cloud providers to be successful at extending data center functions, they will need to provide reference architectures for the MSP as well as the Enterprise for best practices and deliniate use cases based on these architectures.

Citrix technology allows workloads to be distributed over several data centers and in fact have been used this way for years.  This approach has mainly been used for remote delivery of applications and/or business continuity.  By extending the use of XenApp and XenDesktop into the Cloud, both MSPs and Enterprises can cut the cost of their data centers today and achieve higher reliability at a lower cost.

Third parties have developed solutions to provisioning of services such as this for the MSP.  Enterprises will need to work hand-in-hand with the Cloud provider to insure the seamless extension of their unique architectures and produce roadmaps for further use of the Public Cloud.  Citrix Provisioning Server and Workflow Studio will be essential in this seamless transformation as the Cloud evolves to be the "virtual" extension of these physical data centers to deliver Software as a Service.

It's here - The Citrix Service Provider program AND Receiver for iPhone 1.0. This is the most exciting announcement since I've been here at Citrix. 

Can you imagine the power of the most successful application delivery technology on the planet coupled with the highest growth mobile device on the planet?  We've been working on both at Citrix for a while and now they are both available together. 

Today Citrix announced the creation of a new licensing approach for service providers.  The Citrix Service Provider program that enables hosting services companies to access our technology in a subscription licensing arrangement to rapidly expand the delivery of applications for Windows based Software as a Service.  This program is a monthly "active" subscriber pricing and licensing model that gives flexibility with no upfront cost. 

We've spoken to several hosting service providers and ISVs who have been looking for a solution like this for years.  The results of the poll in one of my past blogs revealed that over 32% of those responding thought Citrix should have a subscription based licensing program and others wrote in that the program should include at a minimum both XenApp and XenDesktop.  Well we heard you and have included these products as well as XenServer.  You can find out more about this program and the details for it in the partners section of citrix.com. 

Now imagine the power of a service provider license agreement with the combined power of a universal client that allows access to any Windows application on any device.  Have you got that picture in your mind?  Now imagine turning those applications loose on the hottest mobile device on the planet... you guessed it, the iPhone!  If you want to experience it, just go get it at the Citrix web site!   

With the power of what end users have been asking us for in the iPhone and the ability to drive software as a service through subscription licensing, Citrix provides the only complete solution for service providers to give access to any application on any device.  Oh and obviously the same HDX experience is consistent on Desktops, Laptops, Smart Phones and Thin Clients... and all of this is now in the Citrix Service Provider program! 

You asked for it... and we delivered!

Twitter

When we talk about the Citrix Delivery Center, we are talking about an end-to-end application delivery infrastructure solution. A solution which represents a family of Citrix product lines: Citrix XenServer, Citrix XenApp, Citrix NetScaler and Citrix XenDesktop. It also represents products that add integrated security, management and networking functions, products such as: Citrix Access Gateway, Citrix Branch Repeater and Citrix Desktop Receiver. Overall, the Citrix Delivery Center gives customers the power to adopt virtualization that meets their specific requirements. Customers can choose to optimize delivery of their Web Applications, Windows Applications, Desktop Delivery, Data Center Optimization - individually or in combination. How about all of them?

Now according to a recent Forrester study "49% of enterprises surveyed that are implementing or interested in virtualization solutions indicate that improving disaster recovery/business continuity continues to be a very important motivation for adoption". So what better way to pique their virtualization/business continuity interest than by demonstrating an end-to-end Citrix and Marathon combined solution onsite at the world's largest business software company SAP.
Recently the Citrix Worldwide Consulting Solutions and Business Development teams did just that. We built and demonstrated a Proof of Concept environment that delivered a highly available and virtualized SAP infrastructure using a complete Citrix Delivery Center solution. Within a two week period, the Citrix, Marathon, and SAP teams built and demonstrated a complete Proof of Concept environment. For a quick project overview please refer the data sheet here.

So how did we do it....First we virtualized every Citrix Delivery Center component and the backend SAP NetWeaver application servers using Citrix XenServer. Then we showcased what a remote SAP NetWeaver user would experience accessing the SAP NetWeaver Portal via Citrix Delivery Center while focusing on the high availability/fault tolerant solutions Citrix and Marathon provide. Finally, we simulated a complete failure in the primary site and used the combined NetScaler Global Server Load Balancing feature in conjunction with Marathon's everRun DR product to failover SAP to a secondary data center.

Let's go through the steps that describe the demonstrated user experience:

• Remote SAP NetWeaver Portal user securely connects to the SSL VPN provided by Citrix Access Gateway Enterprise Edition.
• All connections from the remote user client are accelerated using Citrix Branch Repeater Plug-in.
• Remote user is seamlessly presented with the Citrix Web Interface website with on-demand access to virtual desktops, applications, bookmarks and other corporate resources.
• From the Citrix Web Interface page, the remote user launches a virtual Windows XP desktop hosted by Citrix XenDesktop. This desktop is a private virtual image of Windows XP running within a secure data center and maintained from a centralized Windows XP image provisioned dynamically with Citrix Provisioning Server.
• From the secure virtual Windows XP desktop, the remote user launches a published SAP NetWeaver Portal delivered by Citrix XenApp. The published NetWeaver Portal application is separated from the virtual Windows XP Operating System allowing optimal user performance.
• As the remote user navigates the application, all SAP NetWeaver Portal connections pass through a Citrix NetScaler configured to optimize SAP NetWeaver Portal application delivery.

We also demonstrated the following high availability and recoverability solutions provided by Citrix XenServer and Marathon everRun software:

• Level 1: XenServer delivers out-of-the-box high availability, including cost-effective core failover, recovery and restart capabilities for SAP applications running in the virtual environment.
• Level 2: Marathon everRun VM delivers high availability of component-level fault tolerance, eliminating downtime caused by I/O component failures and guaranteeing recovery from system failures.
• Level 3: Marathon everRun VM's Lockstep Technology delivers continuous availability from system-level fault tolerance, eliminating data loss, downtime and transaction loss.
• Disaster Recovery: Marathon everRun DR provides a robust and flexible remote disaster recovery solution providing automated and reliable long-distance protection for critical data and applications, in this case, SAP.

Each piece of the demonstration was broken down into small video segments for this blog. The first video features the Citrix Delivery Center environment for SAP from top to bottom including the remote user login, virtual desktop access, and SAP NetWeaver Portal launch. Then a complete site failure is simulated and the secondary site recovery is shown using Marathon's everRun DR solution with Citrix NetScaler's Global Server Load Balancing feature.

Stay tuned for a detailed reference architecture and video blogs on different High Availability scenarios including everRun VM also demonstrated at SAP Co-Innovation Lab.

Here's the video:

My guess is most people reading this are of the technocrat ilk.  Not that there's anything wrong with that, it just gives us a slanted view of the world.  We see things from a technology standpoint and not from a people orientation.  That's why the science of User Experience exists.  If programmers and technologists at large produced technology that was well suited for the average human, there would be no need to re-engineer it after it was "finished".  And that is the dilemma of Cloud Computing.  The reason it has such a huge following with great expectations and at the same time resembles the well known fable Stone Soup, is that the most important ingredient is missing.... the human being.

Who will be the winner in Cloud Computing?  Will it be  Amazon, Microsoft, or Google?  Could it be Rackspace, Savvis, Verio or some other tier two player.  Or maybe it's the proverbial start up that has yet to come on to the radar screen.  It could be all or none of these.  But what determines who wins isn't who has the largest data center with throw-away server blades or even who has the cheapest storage array.  The winner will be the company or companies that figure out that in order to be successful, you have to flip your business upside down and start in the place where any of  this makes a difference.

Ah! you say, not the dreaded "U" word.  Yes, it's the User.  Many of us subscribe to the technocratic oath, "If it weren't for all those stupid users, my job we be a lot easier!"  Indeed it would, because without end users there would be no reason to write code, test code, focus group code, market.. sell or support code.  There would be no need for hypervisors, virtualization, or  network optimization.  We could all just talk to each other in binary or Linux script and never even see the light of day.  But alas, we develop technology for people who think "single instance management" is what a Geek calls his landlord. 

There are  three basic tenants that are quintessential for the company who wants to win the Cloud race;  Simplicity, Seamlessness and Security.  And remember these tenants are not from the viewpoint of the technologist, but from the viewpoint of the dreaded USER!

Simplicity - Imagine a place where the user is the center of the universe.  Where any call to any algorithm or any routine or any data path was controlled by the user.  Where domains could be set up dynamically based on the user's persona  (action, place, language, etc).  Imagine a user not only having access to any application, anywhere on any device but having it available based on usage patterns and individuality.  This is the ultimate goal of persistence.  Having the ability to not only store off a linear progression of data which is mounted to a virtual drive...  but to memorize the usage patterns of individuals and allow them to access their information from anywhere as though they had just put it down on the kitchen table to grab a snack and then come back to it mid sentence, or mid cell/column or mid presentation.  The Citrix Any (application), Any (device), Any (where) philosophy maps to this goal.

Seamlessness - If you asked the typical User how much bandwidth they had they would have no idea what you were talking about.  The more savvy User might respond, "I have DSL at home but I work on the LAN at work."  They couldn't tell you the difference between upstream, downstream, packet loss, throughput or MBPS.  And guess what? They don't care!  All they want is  for their 'service' to be dependable and consistent.  And that is the perspective the winner of the Cloud race will have...The ability to 'understand' the User in such as way that he has service (access to any application or information) regardless of the network he is on or the machine which he happens to have at his disposal.  That means that applications must be reliable and consistent whether they are running on a high end desktop or a low end PDA.  "Well!", some of you will say, "that is unreasonable and is not technically possible!"  Welcome to the world of Cloud Computing and the dreaded USER!  Whoever owns  the User Experience is the one who will win the Cloud Computing race.  Are you surprised?  You shouldn't be.  Why do you think Apple spends so much time and effort advertising applications and not their cool new phone.  The tag line is "There's an app for that."  Not , "there's a cool new phone for graphics and user interface".  That's how a technocrat thinks, not a typical User.  And Apple embeds its User Experience in its devices... whether the high end desktop or the low end PDA.  They make their money off of the music and software to load and run it... and off of any and all of the applications in the Apple Store.  How much money do you think AT&T makes off of the applications run on an iPhone... nada, nothing ,zippo... that's how much.  That is why Apple is in a better place to win the Cloud race than AT&T... even though AT&T owns the pipe, the data centers and the monthly access bill.  The Citrix Receiver and HDX technology fit this goal.

Security - Users don't care about 64 bit encryption or VPNs or tunnels or storage array administration.  They only care about whether or not other people (companies or individuals) have access to their information when they want them to and don't have access when they don't want them to.  Imagine a universe where the same persona for domain control (simplicity) was used to control information access.  Where an individual would be treated as an object with attributes defining his security parameters.  And imagine a security system that allowed individuals to create their own profiles which were deterministic in nature regarding their separate and distinct pieces of information, by media type (voice, video, text) and by distribution (Friends, Home, Work - proprietary, Work - Public, etc).  "Too difficult!  That would take AI!  What are you crazy!" Does that about sum it up?  The Citrix (sorry can't talk about this yet) technology fits this goal.

Many of us who see the world through technocratic glasses will object to this logic and simply state that it can't be done.  Others, like Google who retain on average over 2,500 data points per user (those who use  Google search engines routinely) and sell billions of dollars in advertising based on profiles and personas will say... that's right it can't be done... by you!  Sprint is running a TV commercial today which identifies just how much information they know about the millions of subscribers on their network.. right down to the volume of people who light up their cell phones when landing at an airport to the number of people using Twitter (or even know what Twitter is).  All of this information is available today, it's just that the technocrats are thinking more about how many terabytes of data storage is available and how much per hour a Windows session will cost based on grid computing algorithms.

Do you think the dreaded User gives a rip about that kind of stuff?  Simple, Seamless and Secure... the company who understands that and takes advantage of it with their technology is the company who will win the Cloud Computing race!

...and the companies who understand how to create an environment where these three tenants are achievable will also win ....big time!  So take your technocrat hat off and start thinking like the dreaded User.

Twitter

FUD!  An acronym used in industry to invoke Fear, Uncertainty and Doubt!  It's a marketing term that is based on emotion and is very affective when placed in the right context.  FUD is used in Press Releases, Marketing collateral and even in Keynote addresses.  Its main purpose is to throw off the status quo and create a mind shift for what is perceived to be right and true.  According to Wikipedia, "FUD is generally a strategic attempt to influence public perception by disseminating negative information designed to undermine the credibility of their beliefs."

So what is the FUD about Cloud Computing and Hosting Providers using SaaS as a delivery mechanism for applications?  Well first we have to look at the negative press of late regarding the cost of deployment.  From a recent NY Times article, a quote regarding a McKinsey & Co report states "Its study uses Amazon.com's Web service offering as the price of outsourced cloud computing, since its service is the best-known and it publishes its costs. On that basis, according to McKinsey, the total cost of the data center functions would be $366 a month per unit of computing output, compared with $150 a month for the conventional data center."  According to this data, Cloud Computing is not cost affective and therefore "a faulty assumption".  This article goes on to state, "We should focus on things we know work now, and virtualization works". Since I work for Citrix it would seem only natural that I would also take this stance in support of everything virtual.  But what the article and (McKinsey) data don't explain is that Amazon EC2 is virtualization.  Isn't it?

It sure seems like we spend an inordinate amount of time in the IT world polarizing one system against another.  The truth is Cloud Computing is an evolution of what has been going in the virtualization world for years.  If you believe the Forrester statistics, about half of the server/computing world are virtualized today.  While that number is staggering it also leaves a huge opportunity for companies to deliver applications via a virtualized approach.  The Forrester data also shows "Firms surveyed showed growing interest in pay-per-use-hosting of virtual servers, one of many types of cloud service offerings in the market."  This statement would seem to be contrary to the McKinsey report.  So who is telling the truth?  The reality is it's too early to tell because the eco system has not yet been fully defined.  But one thing is for sure, companies both big and small are looking for ways in which to do business differently in regards to their IT costs. 

The "nirvana" of Cloud Computing would be any single device would be able to access any single application securely and seamlessly with the only cost being usage on an hourly basis.  No IT infrastructure cost.  No IT labor cost.  Just one utility bill and instant access to any application.  Well we're not there yet and we need a roadmap to make that happen.  It starts with what we have and builds from there.   Large enterprise companies are already deploying private clouds. The future is bright but there are several steps to go before nirvana is achieved.  This brings us to the core of this blog.

Wouldn't it make sense to engage the hosting service providers who are in business today when it comes to Public Clouds?  With over 5,000 worldwide these providers are the core to a cloud based offering.  In the purest sense, each uses the cloud on a daily basis to deliver their applications to the thousands of businesses and end points in their subscription network.  The hosting providers making real money have already virtualized their applications and in some cases their data centers as well.  In order for these hosting providers to grow rapidly they will need a utility based offering to expand their data center and minimize upfront costs.  They are looking at companies like Amazon and Microsoft to do just that.  And why not, if they already have a sustainable business model, using Cloud Computing Utilization as a means for growth makes a lot of sense. 

For sanity sake, we should use a company like Rackspace as a baseline for this type of business.  These guys were one of the few successful IPOs in 2008 for IT (or for any segment for that matter).  In December of '08 they posted revenues of $540 Million with Operating Income of $40 Million.  That doesn't sound like a business with a flawed operating model.  Rackspace does three types of business; Managed Hosting, Cloud Hosting and Email Hosting.  This is a killer combination and one of the reasons that they continue to grow despite the FUD about Cloud Computing.

System Builders (who usually service the SMB with IT services) are also great candidates for Cloud Computing.  Tens of thousands of these small IT shops could access the huge server farms and storage arrays available from Cloud Computing companies to produce an offering to their end customer for critical functions such as business continuity.  This helps the System builder to expand their model without having to spend capital to do it.

I've spoken to several Hosting Providers and System Builders recently about this model and they are cautiously optimistic about it.  Notice I didn't say they are fearful of it.  Why?  Because they know the value of what they produce for their end customers is in their value added services and not in utility based pricing.  The SMB especially wants 'one throat to choke' when something goes haywire with their data or applications.  These Hosting Providers and System Builders have built a rapport with their customers and have become their trusted advisor.  So will the SMB go directly to the big cloud in the sky for help with their IT solutions... not likely in the near term... but will Hosting Providers and System Builders use Cloud Computing to expand their existing offering and prolong capital outlay... you better believe it!

Has it all shaken out yet?  No way.  Will there be modifications to the existing pricing structure, usage characteristics and even end customers? Most definitely.  FUD will not answer the critical questions that need to be answered to make Cloud Computing a reality.  But neither will statements about nirvana happening in the next few months.

The next time you hear "Cloud Computing is here now and it will change forever the way we do IT" just ask yourself what the eco system looks like today, how it will evolve and who stands to benefit most by adopting the uber data center?  Sure there is a model for success, but it will not be a radical departure from the business models used today.  Just ask the ASPs of 2000.  Or better yet, talk to the folks who are actually using Rackspace or Amazon EC2/S3. You'll get a better understanding of why they continue to succeed... despite all of the FUD.

The approach for applications delivered from a third party off-premise data center is a growing rapidly.  According to one estimate it was an $8.8 Billion market in 2008, growing to $17.6 Billion by 2011.  The bulk of this growth will happen in the Small to Medium Business (SMB) segment.  According to Gartner, Small Business is defined as 1-99 employees while Medium Business is 100-499 employees.  This emerging market for applications delivery and data management is not fulfilled by shrink wrap applications purchased at the local Office Depot.

Recent research points to the fact that the SMB is fed up with trying to maintain these applications and also fed up with having to employ a staff of IT managers just to keep the wheels from falling off their business. These companies have been forced to look very closely at their expenses during this protracted economic recession and high on their list of budget cuts is IT as it represents hard cost and intangible value.  A few of the continuing issues that IT has been unable to solve on-premise (in the SMB) is the simplified management/storage of data, office productivity application upgrades, database management and web site enhancements.  As a result, these traditional on-site IT functions are rapidly moving off premise.

Some of the small businesses I've spoken to recently are trying to set up simple CRM systems, Voice over IP and Business Class email.  They are looking to 3^rd parties for the implementation of these systems in order to offload the IT function as they are really only interested in the services themselves.  They want support of the services but not the burden of employee overhead and the ongoing headache of data center facilities issues.  They told me it is becoming more and more difficult to find IT managers who are competent and who understand the complexities of their business.  These companies tend to be in the 20-199 employee range which cuts across both Small and Medium business.

So these companies have a real dilemma in that they want to take advantage of all the innovation in information technology but don't want to pay for a full time staff to implement it.  As the notion of off premise applications delivery or Software as a Service has gained more awareness, this becomes at least one option for consideration.  But what of the custom applications that a Law firm has developed to search through client files?  Or what about the data files that are used to run multi-million dollar CNC machines in a manufacturing shop?  How about a 30 employee insurance retailer with home grown software for CRM?  Most of these companies are already dealing with the mess created by an IT employee who wrote custom code for their core business and then bailed to take a higher paying job somewhere else.

For the past 5-10 years small outsourcing IT companies called System Builders have been growing their businesses at break neck speeds because of the demand previously mentioned.  These nimble firms provide IT expertise jobbed out to the SMB at rates that undercut a full time on-site staff.  They have become a viable alternative to high priced IT employees who used to work directly for the SMB. 

In some cases, the SMB has his own data center on premise but it is configured and maintained by these System Builders.  When we consider the 500 Million end points (SMBs worldwide) who are in need of this type of service it's not surprising that alternatives approaches are being used.  One such alternative is SaaS and service providers who support this segment are also growing at double digit rates.  Configuring and maintaining a data center is one thing, but who provides the delivery mechanism and support for software delivered as a service? 

At the uber-SaaS level companies like Salesforce.com come to mind.  But when it comes to niche applications, business continuity and business customization a support tier must be involved in order for the SMB to get what they need. There are three distinct priorities for the SMB in this regard; Integration and support, working with a few trusted vendors, and tiered service offerings.  System Builders and Managed Service Providers (MSP) fill these requirements and are absolutely necessary in order for the eco-system to be balanced.  Without these partners, the SMB is left to solve his own problems which is contrary to the current trends.

Just as the SMB has a specific focus for their collective businesses, System Builders and MSPs are also focused on the delivery of applications, data storage and services to support each of these.  Therefore, a second tier must be introduced to handle the aggregation of these tens of thousands of System Builders and MSPs for training, license reporting, product fulfillment and marketing.  Software and Hardware Distributors fulfill this role.  Distributors usually have multiple products at their disposal, work across regional boundaries, move vast amounts of product and can provide better volume discounts as a result. Independent Software Vendors (ISVs) use these distributors as the first tier of the channel in order for them to concentrate on the development of the applications themselves.

ISVs sell to their authorized Distributors who in turn train and support the System Builders and MSPs.  Each player in the chain provides a unique value proposition and in the end work together for the benefit of the end user to complete the requirements for software and services.  This model is also proving to be the most cost effective way to provide Information Technology/Systems to the SMB space.

So if you are a System Builder, MSP or even an SMB looking to solve your business problems related to IT, Citrix has some pretty interesting solutions that all come through our (you guessed it) Distribution channel.  Check out how to get in contact with one through our web site.

Securing Web Applications with an Application Firewall

I have been working with Application Firewalls for quite a few years - many times to protect web applications published in languages and character sets that I didn't understand. Frequently, I have seen these Application Firewall deployment projects get bogged down in pursuit of the perfect policy set.

I have also seen many situations in which this process and application changes actually break these applications.

The NetScaler Application Firewall deployment can also be subject to these issues since the appliance provides extensive application firewall features. Even with the learning capabilities, creating the ideal set of security policies for any application can be a trial and error process that can take significant time.

In this blog, I would like to share an implementation methodology that shortens the deployment, and helps avoid breaking the applications to be protected. Experience has shown that approaching the configuration of the Application Firewall in stages is the key to timely success. This methodology is effective for all types of applications and their needs.

To alleviate the time and risk of varying degrees of policy complexity, break the task into stages. That is, separate the policy configuration into groups of ascending risk.  While some may raise the point that a simplified protection policy set is not complete, it must be remembered that protection stages will build upon each other, and will be better than allowing unfiltered access while all policies are in learning or logging/warning mode.

The benefit of staging is that a basic set of policies are made operational.  Then, the following stages will consist of conducting a repeatable process of "policy tightening" procedures as required by the application.

Stage I

When configuring the NetScaler Application firewall policies, start with some of the basic protections.  Activating the simple, generic policies almost never produce false positives.  These typically include:

• Protect against Cross Site Scripting (XSS) attacks
• Protect against SQL Injection attacks
• Protect against Buffer Overflow attacks
• Prevent Credit Card Leakage
• Prevent access to system files
• Alter the contents of the server headers

Activating these policies will typically not break applications.  As such, a small user community - with etc/hosts overrides - can be used to validate the configuration over a fairly brief validation period.

More importantly, this is a great start. These policies create security effectiveness that can typically be rated as a level seven on scale of zero though nine (you can never get to a perfect "10" in security).

Stage II

The next stage will include applying policies that require more application validation to determine the application specific relaxation adjustments ("policy overrides").

But first, don't forget to ask yourself if this application actually requires tightened policies.

If so, Stage II protections should be sequenced - Cookie Tampering prevention should be blocked first. Then, move on to blocking tampering with the values of parameter and/or hidden form fields.

Start with cookie poisoning prevention ("Cookie Consistency"). It will be likely require the least number of relaxations. This will build on the Stage I successes most rapidly.

To do this, use the learning process to identify the cookies that are legitimately altered between the response and request process. Minimally, relaxations will be required for cookies that are set and modified by third party monitoring services. Again, because of the staging, this learning can happen while the basic policies are in place and actively applying their protection mechanisms.

If further tightening is required, focus on creating policies that prevent users from tampering with the values of parameter and hidden form fields. This is achieved by activating "Field Consistency" learning in the NetScaler application firewall. Depending on the architecture of the application or a frequent use of client side scripting, these policies carry a higher risk of blocking legitimate requests. These policies thus require a more extensive learning period and associated relaxation overrides.

It should also be noted that these Stage II policies and their relaxations do have a tendency to be susceptible to producing false positives as applications change, and should be re-evaluated in conjunction with major application changes.

Stage III and Beyond

If the application is contains super sensitive information, and undergoes frequent changes, further security configuration may be required.

Stage III typically involves enforcing field formats and enforcing user navigation paths. Adding restrictions to field input types, such as date formats, and more, will require further time for learning these application attributes. Be aware that these policies will also be more likely to be sensitive to application changes.

Enabling the "Start URL" facility allows users to access only the specifically stated URL types. Due to the flexibility inherent in application architectures, however, these restrictions may require modification to include additional request types present in a particular application.

Lastly, carefully consider activating "URL Closure" to control the flow of access by users. Enforcement of this policy set disallows users from navigating to locations not previously offered by an application response. These policies may require significant application validation if client side scripts modify URLs, or if FLASH objects contain links.

The above policies tend to bend the needle towards the nine level and will be more likely to cause false positives during policy refinement or when the application changes. Leaving these to Stage III, however, allows continued protection afforded by the policies of Level I and Level II during the refinement, however.

Summary

Personally, when I plan my application firewall deployments, I always attack the assignment in the phases outlined above. I focus on the quick return policies first. Then I take time to consider if the sensitivities of the specific application even warrant the extra effort of going all the way to Stage III. This last question can produce some interesting answers that pit my application security ideals against the practicalities driven by the depth of my current to-do list.

And then, of course, this staged approach may be completely ignored in situations in which a specific application just suffered from an attack through a specific Level III vulnerability. Such situations may warrant overriding the staged approach and focusing on addressing the impacted vulnerability immediately.

Also, don't forget to sign on to MyCitrix and download the Application Hacking Kit and actually try some of the most common application attacks on the BadStore application!

How many of you have worked with or started designing a XenDesktop solution?  Chances are you have tons of questions about the best way to design the environment for growth, scalability and stability.  I know this because I, like so many others, are asked the same questions.  For example

• Should I install or stream applications into the virtual desktop?
• Where should the Provisioning Services write cache go?
• How should I design my Web Interface implementation to provide seamless integration without causing confusion for my users?
• How do I provide better availability to the TFTP server used to deliver the Provisioning Services bootstrap file?

Thomas Berger and I started gathering these questions to build the XenDesktop Design Handbook.  The current release of the Handbook is focused on Operating System, Application and Virtual Desktop delivery design decisions, but this is only a start. Over the coming months, we will continue expanding into different design decision areas commonly discussed in a XenDesktop solution including: virtualization infrastructure and implementation practices. We will discuss the Citrix Consulting Best Practices about these topics and encourage you to submit your related questions .  Thanks and we look forward to hearing from you 

Daniel - Sr. Architect

Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

 
We're going to have another exciting round of Geek Speak Live! at this year's Synergy! As many of you know, Geek Speak is a series of informal discussions led by technically minded folks about topics that interest us all; for example, "TS vs. VDI" and "IT in the Cloud." This year we have four different session formats planned: a Geek Speak day session track, Geek Speakeasy sessions during Expo Hall, Geek Speak Tonight!, and a Geek Speak Happy Hour.

For details about the different session formats, check out http://www.citrixsynergy.com/geekspeaklive

We've got several Citrix Technology Professionals (CTPs) and other industry experts lined up on the agenda to do what they do best...lead interesting discussions! Speakers include:

- Alex Danilychev  
- Bernhard Tritsch  
- Brandon Shell
- Brian Madden  
- Charles Aunger
- Gabe Knuth 
- Gus Pinto
- Jason Conger  
- Jeroen van de Kamp  
- Joe Shonk
- Michael Keen
- Rich Crusco
- Rick Dehlinger  
- Ruben Spruijt  
- Shawn Bass  
- Steve Greenberg
...and more!

And this time, we're going to have the Citrix CTOs mixing it up even more with the CTPs. The following CTOs are planning their GSL sessions as we speak:

- Abolfazl Sirjani
- Brad Pedersen
- Chris Fleck
- Ian Pratt
- Jason Lieblich  
- Kurt Roemer  
- Martin Duursma
- Michael Harries
- Simon Crosby  

You can vote on your favorite session topics and suggest new ones through our Geek Speak Live Topic Voting Tool. Just log onto the site to cast your votes!

We will also have sponsor sessions taking place at the Geek Speakeasy. These sessions will be led by:

- Microsoft
- HP
- Dell
- Intel
- NetApp
- Wyse
- Stratus
- AppSense
- IGEL
- Symantec
...and more!

We'll be posting more details about the Geek Speak session speakers, topics, and schedule soon, so please stay tuned to the Citrix Community and Synergy sites to find out the latest. Note that speaker and session details may be subject to change prior to the event.

Be there -and- be square! Hope to see you at this year's event.

Laura Whalen

Citrix Systems, Inc.

The game in Application Streaming is "profile once", "run many".  The Streaming Profiler captures stuff at profiling time and stores it someplace that it can be referenced at execution time.  This post describes the format of the "stuff".  "Describes it" is a loose statement of documenting the format because it isn't exactly "hidden" from the get go.  Having a written description though can be useful when looking at the content stored on your Application Hub. 

The stuff stored on the file server (Application Hub) is two portions:

1) A profile contains a list of applications, by name along with a list of icons, by image. Combine that together with the location of the Application Hub and the name of the profile and you have EVERYTHING you need to publish an application.  The "profile layer" contains only the publishing data.  Notice that the Citrix Access Management Console which publishes applications in XenApp needs to look only at the "profile layer", this is on-purpose.  You can publish a single icon and later implement multiple execution methods to execute that application, for example, 32 and 64 bit versions of the application.  Publish once!  Less icons, less publishing.

2) One or more execution targets.  The targets contain only the stuff needed to RUN the application and a profile may contain multiple execution targets, though fewer is preferred. For convenience, everything associated with the target is contained inside a CAB container file, but the execution stuff is extracted to non-compressed space where it is accessed for execution.  This run time extraction occurs only once for the life of a target and the extracted content is shared across all users on a XenApp server side execution.  This means that only one user pays the "first launch penalty" and even that can be pre-performed.  The targets are named with GUID_version.cab and that naming exercise is outlined in excruciating detail, here.

Directory structure

Each profile is stored in its own directory; generally beneath a common "profiles" or "packages" directory on the Application Hub.  Each profile gets its own directory to simplify copying and maintenance of the profile content.  This also makes it easier to restrict access rights so that only the users who are published, can see the application profile.  Active Directory groups are very useful for this common publishing/access management.  Keeping them all in a same general location also makes it possible to have relative references between the profiles and this is exploited in Inter-Isolation Communication, so that links can be established without having to code non-portable paths to other profiles, handy.

Files that exist at the PROFILE layer

profilename.profile

XML formatted text file which is the "TOP" file of everything about the profile and all of its execution targets.  The "properties" of a profile that you can edit in the streaming profiler are all stored inside this XML file.  You COULD edit them via manual XML edit, but I would not recommend that as a practice.  The profile includes information about the applications that can be published and pointers to the icon data described later in this post. For entertainment, copy the profilename.profile to profilename.XML and then load into Internet Explorer or Firefox for syntax assisted viewing.  You can see "secret stuff" beyond what the profiler GUI shows you, such as the version data of the streaming profiler that was used to create the profile or to most recently modify a target.

icons.bin

Binary file holding bits which represent all of the icons of every application installed into every target of the profile.  The Applications at the profile layer are a "set union" of all of the applications of all of the Targets.  Likewise, the icons at the profile layer are the "set union" of all of the icons of all of the applications of all of the targets.  Notice that Targets do not store icons as icons are not needed for execution.  The format of the icon data is binary.  There is no API in Windows to "convert this HICON to binary", or to extract all the icons from this file and store them where I can get to them later in a screen resolution that is right on the machine that I will be running on then rather than the machine that I am running on now.  The streaming profiler/client pull this off and doing that along with upgrading color depth to 32-bit means that icons file format is an area ripe for change.  We have changed the format of the icon data 3 times that I can recall.  To get to the bits, use Profiler SDK (bottom of post).

hashes.txt

SHA1 cryptographic hash of every file at the profile layer. sha1 = rich man's CRC.   More details on these in target section.  At concept, this file is the "key" to Digital Signature.  The profile XML data can be digitally signed and inside that file is a hash of the hashes.  The hashes has a hash of all of the files of the profile/target and all of this flows downhill to assure the streaming client that the content it is pulling off of the Application Hub is the SAME content that the signing administrator put there.  Neat stuff! 

GUID_version.CAB

One or more CAB files which hold the execution content, the Target.  On the development team, we all rather wanted a container file.  A single file makes pre-deployment an atomic test. Do I have it?  The answer is yes, or no, but never "maybe".  This simplifies pre-deployment, but looking back it wasn't critical to have a container.  An important point: the CAB file is NOT compressed using the default Windows utilities. Those would cause the whole CAB file to change on a single file update and would make the action of pulling a single file out of the cab file slow.

Scripts (sub directory)

Subdirectory holding all "scripts" defined at the profile level.  Scripts are not text, they are binary.  Anything can be a script including textual bat files, executable content such as .EXEs and even "data". Though that last one should be marked as "disabled" so that the streaming client doesn't attempt to "execute it".

TARGET FILES (Stuff inside the CAB)

When browsing profile content using Windows Explorer, after opening the CAB file, sort by PATH.  All of the important stuff will be at the top (root of the CAB).

fontdata.dat

Font's captured during profiling that are accessed during execution

InstallRoot.tab

This file appears to be textual as it has a .TAB extension, but it is binary.   The .TAB file contains the "registry" content of the installed/profiled application captured during profiling.  In early development of Application Streaming, we actually used .REG files for this intermediate storage.  The content of the .TAB file is the same as a .REG file, except the hard coded paths common to .REG files are replaced with "relative" path storage and the registry content is converted to binary for efficient access.  I have previously described how to extract the registry content.

hashes.txt

The calculated hashes were originally to be used only to support digital signature of the entire profile (which is optional).  They work out to be really handy for other purposes.  Having these from version 1 to version 2 of a target upgrade lets the streaming client know which files, among potentially thousands, are the same from version to version, without even looking at the server side version of the files. This is so time efficient that the hashes are calculated and used even if the profile will not be digitally signed.  I say efficient because the streaming client can "know" that a server side version of a file is the "same as it was" based on a 4 byte in memory compare!  Good stuff for the bit heads in the crowd.

The TARGET level hashes file also stores the file date, time, size, attributes and everything else associated with directory enumeration.   The contents of this file are what is used to respond to directory enumeration at execution, for the files that "aren't there".

Yes, sha1 hashes can be a beast to calculate during profiling.  A high percentage of the time that passes during "finalizing your package" is spent calculating these hashes.  The other large portion is spent creating the CAB file.   The theory is that time spent in profiling is less important than time spent by the users, so the hashes are calculated, always. 

preextract.txt

The streaming client consults this file and will extract the given files before launching the to be run application.  IMHO, this file is bogus and should not exist, but back in the day I lost that battle.  I am pleased though that a current inspection of a "fresh" profile has this file created, but empty.  This means it will still be compatible with "older" streaming clients, but gets back to having no purpose.

SNF.txt

In the early days, this file held the short filenames that go with files that also have long filenames.  This is to support applications that use only short filenames at runtime and absolutely insist that the profiling time (install time) and runtime short filename be the same name.  The most demanding offender here is the MSI installer service itself, which is interesting to ponder as you would think that the MSI installer could handle long filenames. 

In the modern days, the contents of SFN.txt have been moved into the end of the per-file entry on hashes.txt.  This means that SFN.txt is a legacy that exists today only to support "older" streaming clients (backward compatibility).

SandboxData.XML

Another XML formatted file.  This one holds the "rules" which govern isolation. All of the "isolate", "ignore", "redirect" and "strictly isoalte" rules are defined in this file.   You can see the "default" rules by looking at the installation directory for the streaming client on your system.   The Streaming Profiler reads the installed version of this file to define the default rules for all created profiles.  Then, any runtime defined rules get added along with any rules that the administrator defines using the GUI of the streaming profiler.  The Targets rules are stored "with the Target" so that it's rules are "steady" even if a new version of the profiler is installed.

Device/drive letter

Represents the installation file system content for the captured installation.   It is a grand mystery why the AIE/Rade FSFD stores "Device" in the name of the captured file content.  In a perfect world, this would be replaced with just "drive letter" or even better, "boot drive". 

Summary

More details than you probably ever wanted to know.  But, there it is.  Please don't become too dependent on the specific format; we do not promise that it won't change.  If you want to change things in the profile or even look at it programatically, the RIGHT method is to use the streaming profiler SDK to get to the bits.  Really!  Use the SDK!  It insulates you from the format.  Knowing what the native bits are though, can be useful.

Joe Nord

Citrix Systems

In 1993 Bell Atlantic was frantically trying to figure out how to deploy television services over their network to compete with the then emerging Cable companies.  They failed.  In 1998 Verizon embarked on a campaign to provide television through their network starting with high rise apartments and condominium complexes in order to quicken the pace of deployment through what was then called MDU (Multi Dwelling Unit) delivery.  Deals were struck with huge developers and a 50 city roll out started in 2000.  They failed.  In 2001 BellSouth began deploying FTTC (Fiber to the Curb) in an effort to deliver entertainment services to their subscribers through high bandwidth fiber optic cable.  They failed.  In 2005 Southwestern Bell Communications (SBC) announced U-verse, a Very high speed Asynchronous Digital Subscriber Line (VHDSL) based Internet Protocol (IP) television service in Texas.  On December 16, 2008 SBC (now AT&T) announced it had signed its 1 million^th U-Verse customer.  This is a far cry from the tens of millions of customers that the cable companies have secured, but finally shows some traction. 

Why is AT&T succeeding when there has been such a long history of failure in this space?  Because over the past 10 years while Telcos have been failing at providing Cable entertainment services, cable companies like Comcast have been devouring phone subscribers.  In fact, Comcast just announced they are the fourth largest phone operator in the U.S. with 6.47 million subscribers.  It's a matter of business.  The Telco now has to succeed at providing alternate services because they have fierce competition over their core business... namely telephony.

The moral of the story is not to sell your Telco stocks or even be dismayed by the lethargic progress of these monoliths.  The moral is that whenever large corporations attempt large game changing moves, time is the only way to measure success.  Secondly, the measure of technology push and consequently adoption sometimes has to do with market pressure from competition and not just increasing revenues but protecting them as well.

So what does all of this have to do with Software as a Service?  Well, take for instance the fact that Microsoft (as well as others) started to deliver their software over the Internet in 2000, created ASP.net in 2002 and has been hard at it ever since.  With hundreds of thousands of hosted Exchange licenses in this space it's safe to say that Microsoft is entrenched and growing.  With all of the business customers that Telcos like AT&T have, why aren't they also growing this (SaaS) business?  The answer is simple.  It has not yet begun to encroach on the core telephony business.  Or has it?  The enterprise space is usually the place that large telephony companies start new services.  One only has to look at Voice over IP (VoIP) implementations to see this.  Adoption of VoIP in the Telco subscription base has grown dramatically over the past few years.  And even though the growth has slowed in this economy, there is an extending strategy emerging for mobile use of VoIP.  This is the first entry of IP delivery services to business from the Telco showing traction.

Will the big Telcos or Service Providers be competition or partners for applications hosting providers?

All of this creates opportunity for existing Tier 2 Hosting/Managed Service Providers.  Why?  Large service providers do not set the pace for early adoption.  The iPhone is one exception but even then it was actually Apple who set the pace and not AT&T.  As more businesses adopt SaaS and the market share grows, Tier 1 service providers will be forced to reckon with the delivery of applications over their networks.

Since brand is the number one asset among these service providers they will be looking to purchase "white label" offerings which have a proven track record in services, especially those that scale.  These will be the Tier 2 applications hosting companies who show promise in their subscription growth, but more importantly have adopted a strategy for growth of their data centers which adds scale and flexibility.  Since Xen is used prolifically today in large service implementations XenServer would be a likely choice for HA (High Availability) and management.  And since XenApp is the most prolific application delivery platform on the planet and has the highest utilization capacity on XenServer of any hypervisor/SBC combination, it would make sense to use it in a hosting environment for scale.

If you want to grow your current hosting business beyond Microsoft Exchange, you need to look at what a long term strategy is for servicing millions of subscribers, not just a few thousand.  Sure, in this economy you will need to pay the light bills with your core business and not throw money (CapEx and OpEx) to the wind.  But you better have a plan for sustained growth or you will be eaten alive by those companies who see the storm on the horizon for mass market application delivery.  If you don't believe me all you have to do is look to what happened last year at GE.  Even Google Apps won't compete in this market when there is an alternative that scales better like Zoho.

This is not to say you should dump all of your Windows apps... quite the opposite, for the Tier 1 service provider to pick up your service in mass, the applications will have to be in the main stream.  Launch what SMBs want and need, do it cost effectively and form a strategy for growth... that's the road to the big leagues.

If you want to learn more about a holistic approach that scales, check out the podcast that Doug Brown did a few weeks ago entitled, "Citrix Cloud Computing".

"What this power is, I cannot say. All I know is that it exists...and it becomes available only when you are in that state of mind in which you know exactly what you want...and are fully determined not to quit until you get it." - Alexander Graham Bell  (Kind of ironic don't you think?)

Twitter

We are moving down the best practices road and now we come up to Active Directory.  This, of course, is just a recommendation as I know everyone's AD structure will be different.  But let's start out with a long-standing best practice... XenApp servers have warranted their own organizational unit within Active Directory for organizational and policy enforcement purposes. The recommendation has also included breaking out specific XenApp roles or locations into their own OU.  Each identical group of servers would have the same policies applied. Typically, this creates an Active Directory structure like the following:

 
With the inclusion of Provisioning Services into the XenApp architecture, this recommendation does not change. In fact, this best practice becomes even more important because there will probably be special policy settings specifically for provisioned servers. Depending on how Provisioning Services is integrated with XenApp will help to determine if new OUs are required.

• If the OU contains a set of XenApp servers all provisioned with the same vDisk, then any Provisioning Services related policies can be applied to the entire OU.
• If the OU contains provisioned and non-provisioned XenApp servers, all hosting the same applications, then a new OU should be created that contains only the provisioned XenApp servers.
• If the OU contains provisioned and non-provisioned XenApp servers hosting different applications, then multiple OUs should be created containing only identical servers.

With Provisioning Services, the XenApp OU structure might resemble something like the following:

Each OU contains:

• Similar servers: Applications, infrastructure components, XenApp components
• Similar delivery processes: Provisioned or not provisioned
  

Please comment with your thoughts or if there is another best practices you are wondering about. The list has already grown based on feedback from previous blogs. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus

Daniel - Sr. Architect

Follow me on Twitter: http://www.twitter.com/djfeller

Many of you tuned into the TechTalk webinar over a month ago when I spoke about how to integrate applications into a virtual desktop. If you didn't attend the live event, you can still listen in to the recorded version of it.  It sounds like an easy topic, right? "Just install them stupid!"  Of course that approach does work, but is it the best approach?  Many of us are long-time XenApp people.  We see the value with virtualizing applications in XenApp.  We've already spent lots of time, money and sanity to get our XenApp environments tricked out so it is running smooth.  So I'm here to tell you, leverage it.  Just because you are going to do a virtual desktop solution does NOT mean you have to throw away your XenApp environment. That is just crazy.

Before you start on the XenDesktop build out, take a look at the just released Reference Architecture.  You can share and streamline your XenDesktop environment by using and sharing your XenApp environment. Some of the XenDesktop components can be shared with XenApp components.  Which ones? How about the license server, data store or Web Interface? 

Also, the integration must be streamlined.  You don't want to make your users jump through 20 hoops before they get to their applications. They will be tired and hate the solution, resulting in your project failing.  Make it look like the following diagram... Simplified user perspective

The user authenticates once, and they get a standard desktop image that is personalized with their unique set of applications, automatically.
Next, which apps go where?  This is a big question.  Do I let my XenDesktop users simply connect to hosted XenApp applications? If that is your objective, then why are you using XenDesktop?  Truth be told, some applications work better on a desktop OS. But these applications can still be delivered via XenApp.  Focus on application categories of Base, Anomalous, Resource Intensive and Technically Challenging.  These categories will guide you to the best solution. 
 
Click for larger image
Interested in building the XenDesktop/XenApp solution? Then grab the Implementation Guide.  Step-by-step instructions (with pictures) that shows you how to leverage your XenApp environment for XenDesktop.   If you are really good and just need a high-level guide, then grab the Getting Started Guide

The important thing to remember is don't throw away your past successes to build something new.  Leverage your past success to make your future success easier.

Daniel - Sr. Architect

Follow me on Twitter: http://www.twitter.com/djfeller

Have you been hearing about the new Citrix HDX Technologies? Have you heard that HDX enables branch office users to get that "high definition" XenApp experience? Are you still trying to figure out what this all really means?

Recently there has been a lot of new terminology, concepts, news, and capabilities for Citrix Branch Repeater to take in. One of the most exciting topics has been around multi-user XenApp optimization for branch office users with Citrix HDX Broadcast and HDX IntelliCache. Spend some time getting caught up to speed on all these great happenings by reading a new whitepaper titled "Understanding Citrix HDX Technology for Optimizing the Branch Office".

This whitepaper will enable you to speak like a HDX branch office guru as you learn about:

• What is driving branch offices to virtualize their applications
• What are branch offices doing about the WAN
• What Citrix Branch Repeater does for XenApp
• How HDX Broadcast and HDX IntelliCache deliver a high-def branch experience

The whitepaper (CTX120455) is available for download on the Branch Repeater section of the Citrix Knowledge Center.

This is the 3rd post in a series on Inter-Isolation Communication.  I previously shown the layers of glass with IIC and how the streaming profiler can mount sub-profiles as a part of running an installer for a new profile.  This post describes how ANY profile can be "sub" to another profile and how "profile trees" result that are potentially far deeper than one level.

Consider that before inter-isolation communication, administrators wanted to allow communication between sandboxes.  They want to have two profiles that they know are good; but want the applications in those sandboxes to be able to talk at runtime.  With inter-isolation communication, any profile can be part of an IIC profile.  The existing profile can even be made with a profiler that had no idea what IIC was.  The IIC supporting profiler and client first shipped with XenApp 5.0 (Streaming Client 1.2), but the profiler/client at this level can define IIC links to profiles created at earlier levels.

It is easy to consider that an IIC profile links 2 or more sub-profiles.  What is not so obvious is that IIC profiles may themselves be the item that is linked.  That is, the IIC profile may be the "linkee" rather than the "linker".

Consider this graphic
 
It is much to consider, but "TOP" is a dependent profile that links to 3 other profiles.  As TOP has its own isolation target, the profiler will mount everything underneath as a part of running the profiling activity to support creation of the Target at top.  The profiler supports setting the relative height of isoaltion spaces within a profile, so the order of A, B and C can be adjusted.  The layers of B1 and B2 though are defined as part of profile B and must be adjusted at that level.

Configuration of the profiles

A.profile may have come from an ealier version of the streaming system, where it did not know about IIC. 

B.profile is "links only" and this means that it was created with the IIC supporting streaming profiler and since it is an associative profile, it is merely "pointers" to the dependent profiles, which are B1 and B2.

C.profile is very much like TOP.  It mounts the C1 profile and then C has a produced execution target of its own which is the result of running installation activities while editing C. 

Eventually, TOP exists and all of this stuff is stored on an Application Hub, somewhere on your network.

NOTE: All profile links are by name only and are required to be on the same application hub/file server.  This is on-purpose so that all links are "relative" and the profile content can be moved from one server to another without having to edit any of the profile information.

PUBLISHING

When publishing applications, the Access Management Console will open TOP.profile and will present a set of applications for publishing which is the SET UNION of all of the sub-profiles.  It is possible that you want to publish all of the applications, but possibly more likely that you want to publish a subset.  Either way, as the administrator, you have the full set available for selection and it doesn't matter which target provides the initial executable.  

That pretty much puts it all together.  This stuff has been out for a while, its complex - but powerful.  

Joe Nord

Citrix Systems