In case you haven't heard or seen , I'll be hosting a live TechTalk on Wednesday, July 23rd at 1PM Eastern covering the virtualization of XenApp on XenServer. For those of you who have read my blog, I know there are 5 of you, will know that I've been working on this aspect of server virtualization for some time.  I plan on covering what you should virtualize, how you should do it and how to make dev/test environment better with this solution. So if you want to hear me talk on a great topic, don't forget to register here.

July 23, 2008

1:00 PM Easter

1 hour duration

Daniel

Shipoopi!!

(Homer Simpson Quote of the Blog: "Kids, you tried your best and you failed miserably. The lesson is, never try.")

In my previous blog entry, I described the Green benefits of telecommuting and my plan to "road test" telecommuting technologies and experience. For my first test, I have chosen voice communications.

My reasons for choosing this over something more obvious such as remote application access, is that most telecommuting scenarios that I have seen or experienced were based on the telecommuter being able to use a mobile phone for making and receiving calls business calls. This is not always the case, and not in my current temporary scenario where I am overseas from my Silicon Valley office. And if my mobile phone did work here, it would be extremely expensive to use for the number and length of calls I normally make. Generally, I also find this reliance on mobile phone a hassle due to the cost when compared to business or even home landlines, and the knowledge that people who want to call me need to know a. that I am not currently in the office and, b. what my cell phone number is.

Here's something else, I strongly believe that talking is still the most efficient and effective form of communication between two people and sometimes more. I have seen way too much misunderstanding, delays, unnecessary stress or conflict through even best written email, as the written word often lacks the nuances you get in verbal communications. While talking on the phone is still less effective than true face to face talking, it still is a big advancement on email or even IM. I'm sorry, but emoticons just don't match body language ?.

So, as I start this particular evaluation, I have three criteria that I want to test:

1. As many of us work in a highly mobile manner, with the "office" now including when working from home, business travel and other mobile scenarios, how do we maintain a consistent way to be contacted by voice as well as email?

2. We all have a single work email address that is constant wherever we are, but what about our phone number? Why is it that we have to guess whether the best phone number to use is the desk or cell phone?

3. How often do you have to be the manual link between two electronic systems when you have to enter a phone number from an email or customer record into a phone keypad? How often do you type the wrong number because of this? I know I have.

4. How expensive is it to use mobile, home or hotel phones to maintain a consistent amount of voice communication? I believe that the frequency of calls to staff, management, colleagues and customers should not diminish just because you are not in the office.

Now the last 2 of these criteria I can test by using one of Citrix's own products, EasyCall. By installing EasyCall, I can make calls from my PC either by entering the number, or using the click to call feature to dial directly from, say, an email footer. Rather than being a VoIP solution, EasyCall connects a call by first calling my own phone (could be my home line or mobile) before establishing the connection to the number I have dialed. It also has a pretty cool corporate directory function, allowing me to search for colleagues by their name in a similar manner to the deskphone I have in the office.

Now before you think I am just using this blog just to promote EasyCall, there are still the other 2 telecommuting phone criteria that it seems I cannot use EasyCall to evaluate. This means that I still have not re-routed inbound calls so that people calling me, especially from outside Citrix, need not to know that I am in the office or out. In previous telecommuting scenarios I have had to set up, I achieved this by using softphone products such as Avaya IP Agent. In my personal life, I am a heavy user of Skype, so will also be looking at it and other VoIP solutions for inbound calls as well as possibly outbound. The only issue I can foresee with this is that my current connection to the internet has nowhere near the performance I have become used to in California, which may mean the call quality is not to flash. I'll keep you posted on what I try for inbound calls and how it works (or not).

Now back to EasyCall. To use it, I need to install an agent as well as have a EasyCall Gateway installed between the LAN and PBX. Fortunately, the good folks at Citrix IT Services have installed the gateway, allowing me to worry only about the agent. Installing the EasyCall agent is pretty straight forward, the only things I really need to know is where to find the installation files and the host name of my EasyCall Gateway. To see what the installation process was like, check it out at http://www.utipu.com/app/tip/id/2955.

As with all my blogs on Telecommuting, I am eager to hear from you your own views on this topic, or any criteria or scenarios you think I have missed for my evaluations. Just post a comment to this entry.

Most of what is written on Green IT concentrates on how the IT Department can reduce the carbon footprint of its operations, primarily through reducing Data Center power consumption. While this is important as IT operations makes up 2-3% of global power consumption, our efforts to reduce our environmental impact should not end with the data-center. As well as including the end-point into Green IT planning (something I covered in a previous entry), IT can have a role in enabling Green business practices such as the paper-less office, Remote Collaboration (thus reducing the need for business travel) and Telecommuting.

Its this last practice, Telecommuting, which I want to discuss in more detail. For one thing, its something that we can do as individuals (work and management permitting, of course) as well as on a cross-company, cross-industry and even national basis. It fits in with the "think globally, act locally" mantra, with the emphasis on "local".

The Telecommuting trend has for some time been more tied to employee satisfaction, work-life balance and increasingly recruitment strategies (such as "homesourcing"). However, the rapid increase in the price of oil has made the cost of commuting to work a much larger percentage of household budgets, and therefore more noticeable to the average Joe or Jane. While many of us may wish that people would find other motivations to reduce their carbon footprint other than the hip-pocket nerve, rising costs will probably have the most realistic chance of effecting widespread change.

Increasing the number of employees that telecommute rather than drive to the office can cause a significant reduction in the fuel consumption, and therefore carbon emissions, of those individual employees. While this may seem obvious, you can read a detailed study conducted by the University of California....back in 1988! As well, more recent EPA studies have shown that even a 10% reduction of cars during peak hours can reduce the fuel consumption of those vehicles still traveling to the office, as the improved traffic flow results in less time burning fuel in gridlock. To get an idea of how this works, think about how much better your own commute is during school vacation periods.

While this shows there there would be significant benefits to the environment if a greater proportion of the workforce spent at least some time of the working week telecommuting, how practical is this generally, and in specific job roles? If your job does not involve "face time" with customers, telecommuting is probably a more practical option for you than those involved in regular customer interaction. That being said,  there are a number of organizations allowing call-center agents to work from home, such as Cox Communications.

While I have regularly telecommuted over the last decade or so, as well as introduced telecommuting programs for employees doing Tech Support and Customer Care, I have decided to use a period where I need to work remotely to try to measure (at least to qualify if not to quantify) the effectiveness of the technologies used to enable telecommuting. Over the next few weeks, I will blog on my experience based on the following criteria:

• Voice: How can I remain in verbal contact with staff, colleagues and customers? How do they get in contact with me without having to know whether I am in the office or not?
• Applications: How does my app performance vary when not in the office? What impact does occasional offline access make to this?
• Security: What would happen if my laptop or home PC was stolen or otherwise compromised? How do I set up my physical facilities to minimize security risks?
• Collaboration: How important are those "water-cooler" discussions and other face-to-face formal and informal interactions? If they are important, how do you replicate this when remote?

I have experienced challenges with each of these criterion in my own experiences as well as those relayed to me be customers.
While most of the technologies I will be using come from Citrix (partly because we like to eat our own dog food but mainly because we have been a long-time enabler remote work practices such as telecommuting), I will be also looking at other products and technologies to fill any gaps or compare.

I mentioned earlier that I want to use this as an opportunity to discuss telecommuting. As such, I would really appreciate your comments and suggestions on what I should be testing (technologies, criteria and scenarios), what your own experiences have been, and whether you think an increased proportion of your work time as telecommuting would have a benefit to you, your employer, customers/partners and the environment. Please contribute to this discussion by posting comments to this entry. In a later entry I will add a forum address if there is sufficient interest in this topic.

It has been a few weeks since I first wrote about drinking the Citrix Kool-Aid and trying for ourselves to turn our lab into a dynamic deliver center.  The first part of this project is to identify what is the purpose of our lab.  After looking at things deeper, we are responsible for mainly 4 things:

Technical Readiness Infrastructure: 

The Tech Readiness group is responsible for creating and delivering technical training to our customer facing people. This includes Support, Consulting, SEs, etc.  This group develops hands-on training that walks the student through setting up, configuring and troubleshooting the product.

As you can imagine, during a new product release, we have classes stacked up one after another all around the world. These classes use prebuilt environments in a remote lab in Ft. Lauderdale.  So if a class is occurring in Singapore, London, Sydney, Paris or anywhere else , the students will connect to Ft. Lauderdale to work on the pre-configured lab environment. Because the focus of the classes is to train on the new features, we don't expect our students to run through installations.  This means the environment must be prebuilt ready for configuration.

As you can expect, this is a challenge, which brings us to our first few requirements:

• Requirement 1: Tech Readiness: Must be able to work with the latest products, whether they be hardware or software, remotely.
• Requirement 2: Tech Readiness: Must be able to refresh environment quickly to a base state with items installed, but not configured
• Requirement 3: Tech Readiness: All previous classes configurations must be removed and devices and servers must be put back to base state (including passwords, accounts, optimizations, etc)
• Requirement 4: Tech Readiness: Environment must be able to allow students to work with all features and products including WANScaler optimizations, NetScaler load balancing, XenApp Progressive Display, Smart Auditor, etc.
  

Worldwide Consulting Solutions

The Solution Center and Integrated Solutions team is responsible for developing best practices and recommendations for integrating Citrix products with other Citrix products and 3rd party products.  For example, these two teams have developed items discussing XenServer and XenApp integration and on how to integrate WANScaler and NetScaler with Microsoft SharePoint.  From project to project, the architecture could look quite different, but there is one common aspect to all projects... There is at least one Citrix solution involved. 

The types of projects can vary wildly from validating an application runs on XenApp, defining deployment best practices for a particular web application with NetScaler to performing scalability testing on the latest version of XenDesktop. All of these items come together to bring us a few more requirements:

• Requirement 5: Worldwide Consulting Solutions - Need to be able to bring up a set of Citrix solutions without requiring installation
• Requirement 6: Worldwide Consulting Solutions - Need to have the different project pods separated from other pods as one test might influence the results of another test
  

Field Teams

Working with our customer, many of our field Citrites find themselves in need of a reference system to be able to look up a setting, perform a quick test based on a customer question, or be able to demo a new feature that is easier to show than to explain.  These types of requests are short lived, but require a fast response. Because of the huge number of potential questions a customer could ask, it is impossible to anticipate every conceivable environment needed or when the requests could occur.  This type of situation brings about the following requirements:

• Requirement 7: Field Teams: Need to get access to a base system (regardless of product) in a short amount of time that can be modified. 
• Requirement 8: Field Teams: Each reference system must be isolated as customers will be seeing the systems in a lab that also contains systems of new, unreleased products
• Requirement 9: Field Teams: Need to be able to extend check-out time if work extends beyond original request date
  

Administration

I haven't hit all of the groups that use the lab because this blog would be longer than the movie script to the Simpsons Movie (which I highly recommend by the way), but most of their requirements are contained within the first three groups.  Before I close out, there are still a final set of requirements focused on the administration of the lab. We must make it easy and automated:

• Requirement 10: Administration: Systems should be in a low-power state unless they are being used.
• Requirement 11: Administration: The systems, when allocated, should be powered on automatically.
• Requirement 12: Administration: Systems should be automatically built, cleaned, decommissioned and assigned.
• Requirement 13: Administration: Hardware assignment notifications should occur through email with all pertinent connection information once the systems are online.
  

I know this was quite a long blog, but this is a big project and I didn't want to gloss over anything. 

Up next, a Proof of Concept.

Daniel

(Homer Simpson Quote of the Blog: "Oh, so they have internet on computers now!")

I make a living convincing applications to run, that were never "installed".  For this, I have many people to thank. 

I now take this opportunity to personally thank:

• The inventor of the windows Registry
• The inventors of COM and OLE and specifically the COM use of the registry for object registration!  Awesome!
• The person who thought it would be a good idea to share C Runtime DLLs under the \Windows space to save RAM
• Application vendors that don't "get it" that user settings go in the "user" space and that you can't update \Program files at runtime.

The fundamental item that keeps me happily working is that the majority of this stuff entails INSTALLATION TIME configuration activity that arguably shouldn't exist.   Looking back to DOS 3.3, life used to be much simpler.  Here's how I used to do it

• The operating system goes onto drive C:
• Applications and data go on drive D:

Assume you need to reload the OS frequently - or that you move from machine to machine to machine all the time.  Nicely, this hasn't changed.   After installing the operating system, you update PATH in the autoexec.bat and POOF!  You're DONE!

Today (I mean, really today - right now), I'm reloading my primary dev box. I've been reloading it for about a week, an hour here and an hour there.  Writing this blog gives me something to do while the various programs re-install.  Thankfullly, all the "streamed" apps are instantly available.

Why reloading?  Well, something got confused in the registry and it was no longer willing to work right.  I'm a certified expert at this stuff and the best I can come up with to describe the problem is that is it "no longer willing to work right".  Yes, I could probably diagnose why that application install I ran blew the machine away, but it isn't worth it.  I'll just reload the machine and be done.  Machines seem to behave faster after a reload anyway. 

HEY - This is one of the driving factors for application isolation.  Prevent things from getting out of whack. 

Its all my fault though - I messed with it.   I installed something and the machine then requires a reload.  .  Why is this my fault?   I'm struggling with the advancements in computer science that now require even a single application installation to be database driven, update system DLLs and executables, the application space itself and include numerous "registrations" such as COM.  All of this stuff seems superfluous.  In 20 years, I've gone from a 4.88 MHz machine where I could reload the entire machine in 30 minutes to a 2,000 MHz machine * 4 processors machine that now takes about a week to get back into working shape. 

"My Applications"

Consider also that I have to be an "administrator" to install applications.  Why is this?  Most applications are just executables and data files.   If I have a "My Documents" folder, why don't I also have an "My Applications" folder.   My applications should be mine, located some place other than where the OS is and they should be "installable" on another computer with nothing more than XCOPY /S /E.

A Xen World

What I really want is a pristine Operating System image, with a bunch of applications streamed on top of that image and my user data.  I don't really care how  the applications get there.  My administrator should just take care of this.  All of this should be maintained by my administrator because even as a techie, I don't want to deal with updating the applications, or the operating system.   If I were a "real user" I would really have little patience for all this configuration stuff.  Give me an icon and let me do my work.  It should be that simple, but interestingly, the complexity of getting to this centrally managed world is a difficult one do do with low cost and simplified mainteance. Its such a hard problem that Citrix, VMWare, Microsoft and all the vendors in this space are working on exactly this problem as the next big thing in the computer world.

For computer evolution, I dream back to the easy days 20 years ago.  Maybe in 10 more years, life will be as simple as the olden days.

Joe Nord

ClearType (aka Font Smoothing) is a software technology developed by Microsoft that improves the readability of text on existing LCDs, such as laptop screens, Pocket PC screens and flat panel monitors. With ClearType font technology, the words on your computer screen look almost as sharp and clear as those printed on a piece of paper.

For the longest time Microsoft ClearType has been working properly inside an ICA session with Citrix Presentation Server running on Windows 2000 Server, but it did not work with XenApp 4.5 running on Windows Server 2003.

As previously mentioned Citrix was working on an update to XenApp 4.5 for Windows Server 2003 to utilize this new Microsoft Update for Terminal Services to provide ICA users with ClearType support.

Well, on July 7th (yesterday) Citrix released a hotfix for XenApp 4.5 on Windows Server 2003 that enables ClearType on its XenApp 4.5 Servers.

Note: This patch also rectifies several other issues in XenApp 4.5. You can find the list of fixes by clicking here.

If you want to learn more about ClearType, I can suggest two great articles on this subject:

• Jeff Muir on ClearType and Terminal Services.
• Helge Klein has written an excellent article on ClearType Bandwidth requirements on Terminal Services.

Cheers,
Gus

For quite a few years, I've developed a set of Visio stencils that I've used, along with many of my coworkers, to create detailed design architectures for a Citrix solution. The stencils have morphed over the years and I have now consolidated them into a single package.  This one stencil has just about everything you will need to create detailed Citrix solution diagrams.  Included are items for the following products:

• XenApp
• XenDesktop
• XenServer
• NetScaler (includes rack-mountable stencils and NetScaler MPX)
• WANScaler (including the new Branch Repeater)
• Access Gateway
• Application Firewall
• Provisioning Server
• EdgeSight
• Password Manager
• Workflow Studio

I'm always looking for ideas on what's missing so there can be one comprehensive stencil set for Citrix solutions. Drop a comment and let me know what else is needed.

Download Visio Stencils here

I just came back from BriForum in Chicago and besides the awesome event that was, one more thing came to attention, half of the Notebooks being carried around by attendees and speakers were Macs.

Carried away by the energy of the event I decided build something for our Citrix Community. A dashboard app that makes easier for our visitors to read the latest posts and collaborate with their comments.

 Meet the Citrix Blogs Widget

 With version 1.0 you get:

• The latest 30 Citrix Blog posts
• Adjust view from Full to Summary
• Collaborate with your comments
• Open posts on Safari or Firefox
• Spotlight Search (Instant search)
• Push updates (no refresh required)
• Watch blogged videos
• Check for updates
• Send feedback

Requirements:

• Mac OS X 10.4 or greater

Download via CDN:

Citrix Blogs Widget

—

Special thanks to Chris Anthony's group for designing our dashboard logo! Thank you guys so much!!!

The last time I wrote about XenServer and XenApp, I focused on a whole set of items like manageability, availability, flexibility and utilization.  This time, I want to focus directly on utilization as based on the feedback I've received it seems it's the one many people are interested in.

Even before the scalability numbers of XenApp and XenServer came out, I had numerous conversations about virtualizing XenApp.  And now that Citrix is showing the XenServer overhead for virtualizing XenApp, those conversations have increased, but I think some critical points are being lost.  A couple of months ago, Citrix did scalability tests to identify that XenServer has roughly a 7-8% overhead when virtualizing 64-bit XenApp, and roughly 20% when virtualizing 32bit XenApp servers.  I was like WOW, 64bit is great, barely any overhead.  But how many people are actually running a truly 64bit environment?

Most people have the hardware, as it has been sold for years. Most people also have access to the 64bit version of Windows and XenApp. So why aren't we all jumping on the 64bit bandwagon? Because it's the applications. Unfortunately, many applications that XenApp environments run are 32bit, and some are still 16bit!  This conversion to 64bit applications will take time (Does anyone else remember the 16bit versus 32bit migration that happened years ago? It wasn't an overnight thing. It took time. And yet there are still 16bit apps out there.)  So this fact makes it highly unlikely that organizations will be able to convert their XenApp environments into complete 64bit setup. This means many will stay with 32bit only or else have mixed 32/64 bit environments.  So let's focus on the 32bit environments, are they virtualization candidates?

Maybe And most likely Yes.

Take a look at many XenApp deployments and what resource do you typically exhaust first?  RAM.  It is because in Windows 2003, we are limited to 4GB of addressable RAM.  So, when we hit that limit, everything else in the system is wasted (processor, IO and networking).  And I've seen some applications take enormous amounts of RAM. Just the other day I was working on some detailed Visio drawings and Visio took 1GB of RAM.  Yes, I said gigabyte.  (Of course the drawing was about the Simpsons and how Homer stays at the forefront of technology - He even had a blog called "Mr X. - All the Muck That's Fit To Rake").  So, a 20% overhead on 32bit systems? I probably wouldn't notice as my entire server is barely utilized except the RAM.  

RAM is easy to install and one of the cheapest things to add to a server.  Use the same hardware and increase the RAM to at least 8GB.  Now, try to run 2 virtual XenApp servers.  You might not double your user concurrency, but you will get pretty close, which will equate to hardware and power savings.

So take a look at your physical XenApp servers. Is the RAM fully utilized? What about the processor utilization levels?  I bet more likely than not the RAM is fully committed and the processors are running at 10-40% utilization. 

Daniel

(Homer Simpson Quote: "I want to share something with you: The three little sentences that will get you through life. Number 1: Cover for me. Number 2: Oh, good idea, Boss! Number 3: It was like that when I got here.")

Citrix Usability Design and Evaluation Team manager Doug Bloch recently wrote "Some of the challenges facing the User Experience team are ensuring that our new acquisitions match the user's mental models of our mainstream Citrix Products". Citrix Systems is not alone in addressing this - it is an issue that is faced across the industry.

I had the opportunity to speak with other designers facing this challenge at the recent annual conference of the Usability Professionals' Association in Baltimore, Maryland. When posing the question "What strategy would you use to integrate look and feel throughout a product line that has been impacted by acquisitions?" the feedback flew fast and furious! (One industry expert suggested that our products need to look like they came from "One idea, one mind", hence the title of this blog post. )

The usability and customer experience design professionals I spoke with feel strongly about the question based on the nature of our profession. But some of their input, and conversations with my teammates leads me to ponder the question at a more critical and fundamental level - what do Citrix customers think?

-                Is it realistic to expect that a "suite" of products that have been created by a few or several different companies can come together under one look and feel?

-                Could the answer be "It Depends"?  For example, is it only important to the teams deploying the product? How much or how often are end users impacted?

-                Have you seen how other companies have handled this challenge?

-                What kind of roadblocks do you think that Citrix might have in addressing this issue - and what have you seen as best practices for overcoming those roadblocks?

Looking forward to hearing what you all have to say.

The Application Streaming system "streams" stuff from the central network server to an execution platform.  The streaming aspects of this are very neat, but it turns out for many customers that the centralized publishing and the isolation provided from Application Streaming are the important parts. Well, different people have their own definition of the important parts, but stick with me on the concept.

The trick though is that a "first time launch" for a large application can be a massive data transfer and this isn't desirable if all you really wanted was centralized publishing and isolation.  How can you move that data transfer to "network idle time"?  RadeDeploy.exe is the utility included with the streaming client for this purpose.  Its is a command line utility that will advance copy the streaming content onto the execution machine.  It is assumed that the admin has facilities in their software management system to control when this utility gets executed so that the streaming content gets copied down to the execution machine before users arrive in the morning and start running applications.

Server side or client side?

Application Streaming client runs in two spaces: Stream to Client or Stream to Server.  For the most part, pre-deployment applies primarily to the stream to client configuration as its assumed that the Presentation Servers have a fast network between them and the file server that holds the streaming content.  

The ultimate mission is to move execution content from the central file server into the RadeCache execution spaces.  These are the "installation layer" of the 3 layers of isolation.  These directories are always a subset fill of the entire installation contents.  No matter what percent populated, the isolation system will lie to the application and tell it everything is present.

Here is the RadeCache space on my machine.

 
Copying from the network server to runtime fill the RadeCache execution space is the streaming aspect of Application Streaming.  In an online case, or more exactly, a non-pre-deployed case, the isolation system does cache fills by extracting content from the CAB file stored on a network server, pulling down the item needed for execution of the application, just in time for use.  This is the part of running the application, particularily first time launch, that generates network traffic.

 
To enable "offline use", the Streaming System also supports a concept called "PreDeploy".  Instead of streaming from a network server to the RadeCache, the streaming system will instead use a local Deploy folder as its source - and never contact the network server for the cache fill operations.  This is good stuff and since the Deploy location holds 100% of the content from the network server needed to run that application, it is possible to disconnect from the network while running a "streamed" application. 
 
Here's a snapshot of the Deploy location

 

Now - is it streaming?
 
The cool part of this implementation of "offline" is that the majority of the streaming system is completely unaware of the concept of offline.  When a cache fill is needed, the caching system asks the streaming service (radesvc.exe) to do the cache fill.  The services' logic is simple: Do I have this in the Deploy location?  Great, use that one. Else - consult the network server.   In the case of pre-deployed, the answer to the first question is always yes, so the traffic to the network server is completely avoided.  The file system driver that initiates the cache fill operation remains completely in the dark that the streaming was from one side of the hard disk to the other rather than across the network.  Keeping it simple, keeps it from breaking.
 
RadeDeploy.exe
Is the utility that populates the Deploy location identified above in graphic.  RadeDeploy copies the CAB file and other contents from the central file server and places it into the Deploy location.
 
Notice that RadeDeploy DOES NOT populate the RadeCache!   It perhaps SHOULD, but it doesn't.  This means that even if you do RadeDeploy to pre-copy execution content onto the client machine, you still have a first time launch penalty to apply to the first user on that machine that runs an application from that profile.  How can this be avoided?  In an ideal world, RadeDeploy.exe would also or optionally also populate the RadeCache.  It doesn't (Streaming Client 1.2).

 
You can do it manually.  How?
1) Do not delete the RadeCache directory.  DACLs are applied there that let the streaming service user account perform cache fills.
2) Create a subdirectory there to match the GUID and Version of the Target to execute.  Easiest way, run it once, see what gets created.
3) Extract Device\C and all dubdirectories from the CAB and place them into the RadeCache manually.
 
"Magic" is an acceptable means of populating the streaming cache.  Software management systems are assumed to be good people for populating the cache.  Ideally, you should do this when the streaming service is not running as it likes to keep track of what is in the cache so it can decide what to delete and otherwise avoid conflicts in cache fills/deletes.   At a minimum, do it when there are no active applications using the same cache content that is being filled.

 
When more stuff is where it will ultimatley need to be, runtime performance is optmized.

 
Final thought - Stream to Server and RadeDeploy

I'm not a big fan of Deploy for server side execution.  The servers are in the data center and they have fast and reliable networks.  Many application only EVER access 25% of what they "install", so avoiding the full CAB file can cut down the overall data transfer required in the data center. There's more...

 
Through HRP1 (Streaming Client 1.1), the non-Deploy update of cache space for Target update is much more efficient for that the Deploy case; only the changes are transferred on upgrade of a Target from V1 to V2.   In the upcoming Delaware release, this preference to not using pre deploy largely goes away as the same differencing is algorithm is given to the Deploy case as for the "online" update case.
 
Enjoy, 
 
Joe Nord

Is your organization aware of accessibility/508 requirements?

In 1998, Congress amended the Rehabilitation Act to require Federal agencies to make their electronic and information technology accessible to people with disabilities. Inaccessible technology interferes with an individual's ability to obtain and use information quickly and easily. Section 508 was enacted to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. The law applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. Under Section 508 (29 U.S.C. ' 794d), agencies must give disabled employees and members of the public access to information that is comparable to the access available to others. It is recommended that you review the laws and regulations listed below to further your understanding about Section 508 and how you can support implementation.

So, for employees who have some degree of special needs, certain accommodations need to be designed into the product. A few examples are sticky keys, screen readers and providing feedback not solely based on color perception. As the baby boom population continues to age, the percentage of users with some level of special needs is increasing.

Disability does not just mean those who are blind or deaf. Among other things it also covers folks that may be hard of hearing, those that are color blind, are unable to use their mouse, or speak clearly, or need things to be magnified, etc.

1. How crucial is it for your company to buy products that meet accessibility/508 requirements?
2. How important is it that the Citrix suite of products you use meet accessibility/508 requirements?
3. Which products do you believe must meet accessibility/508 requirements?
4. Do you have administrators or end users who are keyboard centric, that is they prefer to use keyboard (shortcuts, access keys) to interact with the software vs. mouse?
5. Do you have users who have difficulty using the mouse due to some physical limitations?
6. Do you have users who are color blind?
7. Do you have users who are visually impaired and often use some sort of a magnifier application to see the things on the screen?
8. Do you have users who are legally blind and use a screen reader such as JAWS?

I look forward to your comments and a very engaging discussion.

Regards,
Bhagirath Thaker
Usability Design and Evaluation

It looks like usability is important to a lot of people these days.  We recently ran a survey with Citrix's private Customer Advisory Community (CAC) called "Prioritizing Usability", and we got 106 responses, which is above average.  And the respondents definitely felt strongly.

The survey was meant to gauge what kind of usability was important for Citrix to address and whether people felt usability for administrators affects end-users and vice versa.   As the baby boomer population continues to make way for the new generation of echo boomers, "Old School" system administrators will be faced with the challenge of administering to an end user population that is used to customization and flexibility. That has not been a part of the "only give them what they need so they can't muck it up" policy that most administrators have lived by in the past.

Interestingly enough, most people in the CAC think our user experiences (UX) are already quite good, as you can see below:

 

79% felt the administrator user experience was "good" or "excellent".  84% felt the experience for end-users was "good" or "excellent".

Notably, almost all of those who had issues with the administrator UX pointed out the lack of one console, and others mentioned printing.  The end-user UX comments were not particularly consistent.

Where to focus

Still, if we had to focus our User Experience efforts somewhere, it was reasonably split with a leaning towards end-users (54%) as compared to administrators (38%).  And it is partially based on whether or not the current interfaces are considered "good enough."

For those who said we should focus on the end-users, a summary of the reasons is below:

• The End-user Experience  (EUX) can still benefit from improvement
• If end users reject the XenApp solution, it means there is no need for XenApp admins, or for XenApp
• Admins are trainable and can handle usability quirks.  End users cannot handle as well or simply will not handle usability quirks.
• Making users happy or more productive makes IT look good and can give IT more control or ability to standardize
• Fewer support calls

For those who said we should focus on the administrators, a summary of the reasons is below:

• The EUX is already good
• More EUX improvements won't boost productivity much, if at all
• If you make an admin's work easier, the EUX will naturally improve as well since admins can respond more quickly to problems or do it right for the user the first time.

Mutual Benefits

The other interesting questions we asked were about whether or not people felt that improving the administrator UX will benefit end-users, and vice versa.  Plenty of respondents would like improvements to both admin and end-user UX, as they see the benefits to each and how they feed off each other.  It's a win-win.

Others, on the other hand, felt pretty strongly that it was just one-way.  But the skewing indicates that more people strongly felt that IT benefits from EUX improvements than end-users benefiting from IT UX improvements.  The breakdown is below: 

How about you? 

Do you feel strongly?  Is there something here we missed?  If you're not a member of the Citrix CAC, feel free to jump in (I'd hate to count you twice, otherwise!).  And if you'd like to be part of this private community, we are accepting applications right now.  Here is a link to the page on Citrix.com where you can learn more about the community and apply for membership: Customer Advisory Community.

Thanks for your time.

Scott Novack

Usability Design and Evaluation Team

Once customers realize the benefits they can get from application virtualization, one of their most common questions is about packaging. If you've got 500+ applications that need to be profiled, you want to find a fast, reliable way to do it without tying up too many resources. That's why Citrix has teamed up with Acresso (formerly Macrovision) to tightly integrate their AdminStudio product with Application Streaming.

AdminStudio simplifies the profiling process by eliminating several steps. It has a Citrix Assistant that batch-converts existing MSIs to streaming profiles. The MSI-to-Citrix conversion tool guides you through the entire process, smoothing out the learning curve and helping to avoid common mistakes. AdminStudio also makes it easy to repackage legacy EXEs into virtual profiles without wasting time on snapshots.

With a few mouse clicks you can customize Citrix virtual profiles using AdminStudio's comprehensive Editor tool, which is based on industry-standard InstallShield technology. The Editor's Citrix Assistant gives you complete control over every aspect of virtual profiles — from modifying registry settings to specifying Citrix isolation options — so profiles meet your specific needs and corporate standards. AdminStudio also automates the profile testing and validation process, ensuring virtual profiles behave reliably.

No one knows applications like Acresso. Their InstallShield technology is the undisputed industry standard and AdminStudio is the most widely used software packaging solution on the market. Leveraging this experience with their world-class solutions gives customers a great shortcut for making the move to application virtualization. It can reduce packaging time by over 90% and cut overall implementation costs by 50%.

You can learn more about it at their website: http://www.acresso.com/products/licensing/adminstudio.htm.

For those of you that have taken advantage of this combined solution already, I'd love to hear about your experiences.

Within Citrix,  I'm on the team called Worldwide Consulting Solutions whose overall goal is to provide our customers with the tools and resources to successfully implement Citrix solutions.  Talk about an easy task .  The interesting thing about this goal is our customers. Our customers are potentially any Citrite, Citrix partner or Citrix customer.  Within this team, we have something called the Solution Center.  It is essentially a lab, but with some serious requirements.  The Solution Center lab must do the following:

1. Be capable of supporting integration tests and scalability analysis with Citrix products and 3rd party solutions
2. Be capable of supporting our readiness activities where many of Citrix's field personnel are trained and tested on our latest products and solutions
3. Be capable of providing temporarily systems for solution testing for our consultants and SEs, where they can test a feature, or look into a potential solution for our customers.

This is quite a task.  The challenge with the lab is provisioning these systems out on an as needed basis. From week-to-week the environment changes based on the needs of projects, training and testing initiatives.  Let me explain how this process works now:

1. A user would make a request for hardware based on a SharePoint web page. This page contains numerous fields so the Solution Center team can figure out what hardware to provide for the project. Items include dates, server type, OS, quantity, applications, HW requirements and an overall description.  Once a user submits this request, it is up to the Solution Center team to work out the logistics.
2. The Solution Center team takes the requests and tries to identify available hardware based on a master scheduling SharePoint page. Once hardware is identified, the new systems are built based on the user's specifications with SysPrep and Ghosting techniques. Currently, the group is building a library of XenServer virtual images to simplify this process.  
3. Once the system is built, the user is notified with IP Addresses and connection procedures.  The entire time from request to delivery can be up to 2 business days.   

This group as they have a very difficult job and they do it great, but one would think there would be a better way.  We have started to build XenServer virtual images libraries to more quickly build the requested environment, but there still is a manual process involved that slows the entire system provisioning down. Is it possible to create a self-service system that would not require manual work from the Solution Center staff?  What if we could cut down the time to build these environments from days to minutes while providing 24x7 service?  A self-service system like this would allow the team to weasel out of this time consuming work.  "Weaseling out of things is important to learn. It's what separates us from the animals! Except the weasel." (Homer Simpson).  

During Synergy we heard all about Citrix's vision for a Dynamic Delivery Center on the big screen (It looked like a really big TV).  And again, Homer provides us with a good recommendation, "When will I learn? The answer to life's problems aren't at the bottom of a bottle, they're on TV!"  So, we started drinking the Kool-Aid and we are going to see if the Kool-Aid tastes good.  Can we turn the Solution Center Lab into a Dynamic Delivery Center?  We will all find out together as we have just started to work on this project.

I will continue to blog about our challenges and successes throughout the project, which will contain analysis, PoC, design and implementation.  You will see

• Our requirements are (and they are challenging)
• Our overall architecture design
• How we implemented it
• The final outcome
  

This is going to be a fun project allowing us to get into the details of all of the Citrix solution stack.  So, stay tuned for Part 2: Analysis

Daniel

(Homer Simpson Quote: I want to share something with you: The three little sentences that will get you through life. Number 1: Cover for me. Number 2: Oh, good idea, Boss! Number 3: It was like that when I got here.)

The Streaming Profiler is the application that "captures" installation program content.   A simple view, the profiler's mission is to observe the activities of an installation program (disk/registry), prevent them from really happening and finally, to write down everything that the installation program thought should be done to the machine.   The whole time, the installation program BELIEVES that it has truly installed things just like at runtime under the Streaming Client, the executed application will believe that everything it needs for execution is present, even when only a subset is there.

From an isolation view, this activity of "profiling" is very-very similar to the activity of running isolated applications.   The Streaming Profiler though has many extra jobs such as extracting the icons of the application that was "installed" and making them available for the publishing system.  It also examines the isolated "Start Menu" to see what additions the installation program "thinks" it made to the system.  These additions become the list of detected applications that are part of the profile.  There is lots of other stuff going on such as simulating reboots and otherwise figuring out what the installation program was trying to accomplish.  All of these are neat things, but they are not the focus on this blog.

Where does the profiler put the temporary stuff? 

This is a question I get a lot.  People are well familiar with the "3 layers of isolation" chart that I have shown before in other posts.  During profiling, there are only 2 layers and the layer that is missing is the "user space".   In a way, the layer missing is the middle layer, but it fundamentally doesn't matter, there are only 2 layers during profiling.  The installation image during profiling is "writable".  At runtime, the installation image is read only and there is an extra "pane of glass" laid down to handle the per-user space.

During normal Streaming Client runtime, the installation image is "cached" below the \Program files\Citrix\RadeCache directory.  During profiling, these same directories are not used!  They are not used on-purpose to avoid any messing up by profiling and running applications at the same time. 

Right - where's the stuff?

The Streaming Profiler ALSO deletes everything when it closes profiles, or when the Streaming Profiler application is terminated.  WHY?  Why not?  It was temporary stuff.  This does make the content harder to find if you go looking for it AFTER you close the profiler.  In more realistic scenarios, this deleting of the temporary content is what allows the Streaming Profiler to profile hundreds of installers without rebooting the machine.  This is very handy for conferences where the show floor can "show and tell" profiling all day long without rebooting.

Right, where's the temp space?

Two things are needed to reflect the layers of glass of isolation.  The disk redirection and the registry redirection. 

DISK:    %TMP%\Citrix\Packager
REG:     HKLM\Software\Citrix\AIE 

Here's a snapshot of the disk and registry profiling locations on my notebook.
Registry temporary space during profiling 

Can I mess with it?
Answer: Sure!
Should you mess with it? No!

Long answer: Not unless you have a good reason!   In theory, there is no reason to mess with the content of these directories/registry while profiling.  BUT - People have asked about it, so they must have a good reason - or maybe just be curious.

When running the Streaming Profiler, the profiler GUI will open .profile files off of network servers.  Or, maybe it will create new profiles.  Either way, the GUI sends instructions to the profiler "back end" (radepkg.dll), which does the heavy work of operating on profiles.

When a profile is opened, nothing related to the execution targets is in the temp editing space.  Only when a Target is placed into edit state does the CAB file contents get unzipped into the temp space and the registry contents get extracted.  All the activities of profiling then work to "modify" this temporary space and when the profile is saved, the execution target is then "zipped up" (cabbed up?), into the image that is stored on the network server.  While the Profile/Target is being edited, the contents of the disk and registry are "fair game" for being messed.  Again: Should you?  No!  But, if you do mess with the extracted contents of the profile in the temporary space, while the profile is being edited, the changes you make WILL be captured and saved with the profile.  Like all back doors, don't expect the internal operation of the Streaming Profiler to be the same from release to release, but in concept, this process has worked so far.

Saving your changes... 
Just because you modify things behind the back of the streaming profiler does not mean that the Streaming Profiler will save your modifications.  If the profiler back end believes that "nothing changed", it will optimize the cab up and save portion of the editing to "do nothing" and this will abandon your changes.  The easiest way to convince the profiler that "stuff changed" is to launch an installer that does nothing.  My favorite is CMD (command prompt) - and then "exit".  Having launched an installer, the profiler back end will be convinced that the execution Target has been modified and will include that Target during the save.

A better way 

The better answer is to use the Streaming Profiler SDK.  You're trying to do programmatic stuff anyway, so why not do it from a program?  Even better, using the SDK will insulate you from changes in implementation of the streaming profiler.  More information on the profiler SDK can be found here.  What it comes down to is a COM interface into the profiler back end (the plumbing, not the GUI).   This is an area ripe for more discussion, so I'll put that on the list of things to write about.

What about all those subdirectories?

Right, those are my fault.  Though MSI and other installation tools normally have a limit of one active instance at a time, the Streaming Profiler does not.  That is, multiple instances of the Streaming Profiler *CAN* be opened at once and from the view of the profiler, all don't know about the others.  Eventually, MSI prevents multiple concurrent profiling, but that's a limitation of the installation system, not of the Streaming Profiler.  

Why bother with this?  Don't know, it seemed like a good idea at the time.  The good news is that you can open one profile for reading and open another for really profiling stuff and the streaming profiler back end will deal with keeping all the items separate.  Well, that's the theory at least, this multiplicity of profiling has not seen significant exercise in the field, but the profiler back end supports it. 

Consider that when a profile is created, the back end has to store the data for that profile, but that the profile does not yet have a name.  The name is only assigned during SAVE and this lack of a name is a big headache for the back end.  The PROFILE is edited and the Targets of that profile can be edited.  

When the profile is edited (happens immediately when you open the profile in the Streaming Profiler), the profile contents are placed into edit space (build location) in a PKG_n directory/key below the top locations noted earlier in this post.  (Example: PKG_1).  If PKG_1 already exists, the back end moves on by bumping the number until it finds a whole that isn't being used by some other profiler.  Eventually, it gets a hit and that's the number space for the profile that is being edited.

When the Target of a profile is created, or edited, the back end needs to extract its contents to temporary space so that the "layers of glass" can be constructed and so that the Target can otherwise be edited.  Targets are identified by their GUIDs, so it would make sense that the GUID is the key for storing the Target's contents.  It WOULD make sense, except....   The Target's GUID is assigned when it is created - and then CHANGED when the Profile is SavedAs.  The Profile also has a GUID that receives must less attention, but it is still there.  

On a SAVE, the GUIDs are retained and the version number of the Targets is incremented.
On a SaveAS, the GUIDs are changed.  

The first save of a new profile (a created profile) is always a SaveAs, so the GUIDs are useless for storage of temporary content.

Since the GUID cannot be used as the key for the directory, the same low tech unique name is used as is used for the profile.  Temporary directories for the target are TGT_n and stored below the top space described earlier.

In HRP1, during "Finalizing your profile", the profiler back end would CAB up the contents of the Target and place it into the PKG_n directory and then the PKG_n directory would be copied to the destination location, presumably on a file server.   I just tried this in the upcoming Delaware level code and the intermediate step seems to have been optimized out by the Streaming Development team - I send kudos.

If you go to edit things while they are being edited, then you'll find the good disk stuff below one of the TGT_n directories and the registry contents below the AIE key.  Be sure to close out your editing program or it will prevent the Streaming Profiler from deleting the temporary space when it terminates. 

Cleaning up 

If the Streaming Profiler "dies" mid streaming - right, this would never happen!, but if it did, there can be "stuff" left around in the temp space.  Future executions of the Streaming Profiler will treat those left around directories as "it must be someone elses" and they will go for a bigger number until they get their own space for profiling. 

You can SAFELY obliterate the Disk contents used by the profiler temporary storage, at any time that you are not profiling. 

Example command:

RD /s /q  "%TMP%\Citrix\Packager"

Registry temporary space used in profiling is actually in the same space as AIE execution on PS 4.0 servers and PS 4.5 servers.  Cleaning up these (where the profiler didn't do it for you) is a bit more work.

The keys to whack are below HKLM\Software\Citrix\AIE.  If you're not on a PS server or not on a PRODUCTION server, you can use this command to delete the temporary AIE space.

reg delete hklm\software\citrix\aie

In my experiment, some of these keys aren't going away.  There's a lock held!  Hum.  In theory, they can go away. 

I don't know if stuff like this is useful for the general community.  Mostly I expect it to be useful for the streaming developers, but they already know it already.  If you find this useful or want some more details, let me know.

Joe Nord
Product Architect Application Streaming
Citrix Systems, Fort Lauderdale, FL

Filling the execution cache is an obvious job of the streaming service and is an obvious item to discuss.  Since the obvious item is not as interesting as the unobvious, deleting from the cache is covered in this post in detail.

Warning: Geek speak is turned on for this post.   I hope people find it useful. 

The Application Streaming client has the mission of maintaining its execution caches which support the execution of applications under Application Streaming.  Yes, that's rhetorical.  The streaming client has the same cache management logic regardless of its execution platform and manages the cache in exactly the same manner for both server side execution and client side.

Most administrators understand pretty well that the middle layer of the isolation spaces represents the "installed application" and this layer is "not really present" at runtime.   I've posted a few other blogs that show a graphic of this, so I won't repeat it here but you should be able to find it up or down a few screens.
The installed contents (installation image) are presented to the application as if they are "present" and are only truly brought into the execution machine when the application actually "touches something".  That is, the arduous job of actually copying installation image content from the central server to the execution machine is put off until the last possible moment, or as a more elegant term, "just in time populated" into the cache.  This is classic computer science stuff: If you put work off long enough, you may be able to avoid it completely.  In college, I did my homework with this same methodology.

At runtime, the execution cache starts empty and grows and then retains its contents for future executions.  The cache is maintained even across boots so that the later sessions will have execution content "already there" and avoid the need for a cache fill.  Cache fills equal network traffic, equals slow, so we prefer to have 2nd time launch experience rather than a first time.  Notice that cache fills are also shared across users.  Consider a Presentation Server hosted execution where content is added to the cache for UserA.  The execution cache is shared across the users, so the cache addition for UserA, will benefit UserB.  The "first time launch penalty" of using streaming and isolation really applies only to the first user on the entire server, and there are ways to reduce that impact.

Deleting content from the cache

When running an unlimited number of different applications, for an unlimited number of potential users, from an unlimited number of separate streaming profiles, the streaming service must support them using finite space in which to run the applications.

How much space does it get? 
What is the maximum size of the RadeCache?

The answer is ...  that it depends.  The RadeCache limits are implemented as a size constrained high water, low water system where the low and high limits are determined at streaming client installation and possibly overridden by an administrator.  The max size limit (high water mark) is installation time written to the registry and defaults to 5% of allocated disk space of the primary boot volume ( e.g. C: ), or a minimum of 1GB.  The low water limit defaults to 95% of cache size.

Right - what does that mean?

The Streaming Service (RadeSvc.exe) keeps track of the space being used by the execution cache and where that value grows ABOVE the high water mark, the service unleashes a "purge thread", or "delete thread" to free some space.  Notice that it does not fail or even delay the cache fill for the application that triggered the growth beyond the high water mark.   The application that is trying to run is immediately put back to doing useful work and this means that the cache is temporarily allowed to grow beyond the high water mark.  The delete activity is done by the streaming service too, but it is done on a separate thread from the cache fill logic.   The delete actions are also done at idle priority.  The delete thread is persistent though and will continue chugging along until the deleting is finished.

The streaming service is aware of the cache contents of ALL of the execution caches and the size of each file in each target, and for each file, the age of when that file was most recently accessed.    These execution caches are all of the subdirectories of \Program Files\Citrix\RadeCache.  Notice that there can be many caches and even cache content for applications that are no longer published to any user that is presently logged onto that server or possibly even for applications that are no longer published to anyone anywhere.  The point is that "new stuff" is more important than "old stuff" and eventually, the old stuff will age its way out of the cache. 

If someone runs an application that uses old stuff, the old stuff is new again and is no longer the best candidate for erase.  Low tech, but easy to implement which should read as "it doesn't go boom".

Low water mark

The cache manager delete thread repeatedly deletes old things from the cache until a "low water" mark is achieved.   Once low water mark is achieved, the delete thread goes back to sleep.   New cache fills can be occurring concurrently with cache deletes and all the while, the streaming service has to keep track of what is in the cache.  This is one of the reasons that: If you want to purge things from the cache, you should use tools like RadeCache.exe to do the delete rather than just deleting the files. This lets the streaming service retain its self stated importance as the keeper of the cache and lets it know what is presently occupying space in the cache.  Those are good things, but more importantly, it protects against windows in time where an application can start opening a file and then the file getting erased by the deleter before the file open has occurred.   This would be a long aside, so I'll get back on subject of deleting stuff from the cache.

Default low water mark is 5% below full.  Strangely, it's not implemented as 95% of full, which is bazaar, but that's how it is. This value is configurable via registry, it defaults to "5" and you generally shouldn't mess with it.  If you do, understand that it is how much space should be FREE before the delete thread stops deleting stuff rather than the percent full after the deletion stops.

Low disk avoidance

In addition to filling the cache and deleting stuff from the cache, the cache manager also tries to notice when the disk is crazy full and takes steps to be a good citizen.  The default here is 200MB. If you're down to this limit of disk space, the cache manager will dispatch the purge logic to start freeing up space on the disk and otherwise to try to keep the machine from buckling.  Once the minimum disk space is achieved, the delete thread goes back to sleep.

Thrash avoidance

Notice that deleting stuff for purposes of managing the cache is a good thing.  Deleting lots of things to help the system not run out of disk space is also a good thing.  It's possible though that all this good citizen stuff will result in endless cache deletes followed by fills followed by cache deletes, followed by fills, ...

The cache manager includes thrash detection logic to prevent this scenario which says:  If EVERYTHING in the cache was touched in the last 24 hours, then we're thrashing, don't delete anything. This may not be perfect - actually, it isn't perfect - but it is an attempt to do the right thing and effectively support streamed applications while automating the cache cleanup. 

Registry keys
Here are the registry keys that control the streaming service cache management.  They are all items in HKLM\Software\Citrix\Rade

Registry item     Type       Default and comments

CacheLimitMb      REG_DWORD  5% of disk space or 1GB.
                             Value is in MB (mega bytes) even though
                             key name indicates Mb (mega bits).

CacheLowWaterPct  REG_DWORD  5.
                             Value is percent of cache to make full
                             when start deleting

LowDiskThreshold  REG_DWORD  200.  Value is in MB.

Enjoy. 

Joe Nord
Product Architect, Application Streaming. 
Citrix Systems, Fort Lauderdale, FL

Citrix Hands-on Technical Workshops are also being made available with on demand streaming video. The very popular Citrix Hands-on Technical Workshops allow you to Learn step-by-step from the product experts how to navigate through the features and capabilities of Citrix's portfolio of products, and there all now being made available on demand!

Continue to Synergy on Demand

iForum Track breakout sessions from this year's Citrix Synergy conference are being made available to you. That's right, if you missed out on attending the Synergy event in Houston, don't despair, because Citrix will be offering access to the content with on demand streaming video. This year's breakout sessions offer detailed technical content, best practices, demos and helpful tips on Citrix products as well as information you need to optimize and enhance your existing environment.

Continue to Synergy on Demand

A customer recently reported the desire to use Windows Scripting Files as the "installer" for Application Streaming profiles.  The report was that the installation could not be done under the Streaming Profiler because the profiler refused to trigger the execution of the script.

A quick reproduction confirmed the report.  Solution follows, I hope positing it here can help other folks who hit the same issue.

Experiment installer:  HelloWorld.wsf

<job id="HelloWorld">

  '** Hello world in VB as a Windows Script File

  <script language="VBScript">

        WScript.echo "Hello!  Fantastic, it worked."

  </script>

</job>

First - Confirm the failing behavior.

In the Streaming Profiler, tell it to use this file as the installer and the result is
"This is not a valid Win32 application".  HUM.

Meanwhile, "Double Clicking" on this file is known to work to trigger installations when the Streaming Profiler is not involved.  What's up with .WSF?

How to solve:

Open a command prompt and peek inside .WSF.  Two commands to get the answer

C:\>assoc .wsf

.wsf=WSFFile

C:\>ftype WSFFile

WSFFile=%SystemRoot%\System32\WScript.exe "%1" %*

Okay, the Windows application for installer really WScript.exe, not HelloWorld.wsf.

To get this installer to run under the Streaming Profiler, two steps are required.

1)      The "installer" is wscript.exe

2)      The "parameter" to the installer is HelloWorld.wsf

Click on Next,

Click on Launch Installer

Disclaimer:  This *SHOULD* work for triggering the installers that are commanded via the script.  In writing this blog entry, I have not taken it to the next step of actually installing (profiling) something.

OKAY - How's this work?

When launching installation programs, the Streaming Profiler takes the "installer" parameter and the "parameters" and feeds them to the Win32 CreateProcessEx API, run under the context of isolation.    It would appear that .WSF is not a known extension for CreateProcessEx. 

The solution is to feed CreateProcessEx the WScript.EXE file (which CreateProcessEx knows how to launch) and to give that EXE file a parameter of the script that should be executed.

This same process should be possible for other extensions that provide similar results, possibly perl, rexx and a variety of other scripting languages.

Out of the box, .EXE, .MSI, .VBS, .BAT, .CMD work when launched.   The full list is variable, but this is the general idea.

Joe Nord

Product Architect Application Streaming, Citrix Systems, Fort Lauderdale, FL