When I was an SE in Southern California back in the day, I had a toolkit that I always referred to for specific things. If you know me from those days, you knew that my biggest tool was the wtsuprn.ini file that I had created to map printers in NT 4.0 and Windows 2000 to the correct drivers on user devices. I was addicted to amassing as many mappings as humanly possible. But I had other things too - for example, a set of utilities that I would use to help troubleshoot applications that I wanted to install on XenApp servers. Well, I was talking to a customer today and it made me think back to those days and consider what my application validation toolkit would look like today.
First and foremost, my number one prescription for any application is application virtualization. This, in my experience, has offered the highest level of application compatibility with the least effort. Basically, what this entails is using the profiler tool in XenApp to package your applications. You create a single package that targets multiple operating systems. What's cool about this is that you can include registry keys, scripts, files, and anything else that you want into the application package. Examples might include a specific version of a system DLL that the application requires but which makes other applications fail. You would just isolate the file in the application package and it is made available to the application during run-time without overwriting the system DLL on the target device. Another great benefit of application virtualization is local and offline application delivery. I can essentially deliver apps to servers much faster but also to PC's and even for use while users are disconnected. This is ALWAYS my first step at delivering any application with XenApp... even those that I know will install directly without a problem.

Alas, application virtualization isn't a silver bullet for everyone. Maybe your vendor won't support it and that's a problem for you. Or maybe the application uses a service that can't be isolated. Well, in that case you might need to use a hybrid approach. You have three choices (I've listed them below in order of my preference).

1. Profile the app and stream it (we've already talked about that)
2. Install the service onto target machines and virtualize the application components (basically profile the app and stream it. It will be able to communicate with the installed service on the target device at run-time)
3. Install the application (this is the traditional method of delivery to XenApp servers)

If you have to go with 2 or 3, then you might need tools to help coerce some "poorly written" applications into working in a multi-user environment. Here is my list of utilities and resources that I would use to give customers and partners advice or to troubleshoot the applications myself. Some are resource lists, others are built into XenApp, others are available as free/shareware or for purchase. If you have a tool that you use, add it to this list as a comment. Let's build a list of resources together.

I hope this core list helps you. If you've got other tools, by all means... please list them below as comments and give us a little information about them. Also, I'm interested in knowing how many of you are using application virtualization and profile management. To that end, I'd appreciate if you could complete the quick poll's below. Here's to the community.

UPDATE: You may also wish to check out the TechTalkthat Dan Feller is doing on Application Validation.

Vinny Sosa

Calling all DC & MD (NON-FEDERAL) Organizations!!!

RIGHT NOW Citrix is hosting our Annual #CitrixSynergy event in Las Vegas where there's a LOT of very exciting news, demonstrations, and thought provoking strategies being presented to our audience!

Just because you weren't able to attend Synergy doesn't mean you should be starved of knowledge!!! 

Our Team is ready to come onsite to deliver the messaging to you in a 1:1 format.  Think of it as your own personal Synergy! 

If you are based in DC or MD and are NOT a Federal customer please contact us so we can set up a 60-90min meeting.  We can use a whiteboard, a projector, a combo of the two or no medium other than conversation to convey our messaging.

Please reach out to my Inside Sales Representative Jose Parada to coordinate a date & time!

jose.parada@citrix.com or 954.229.6849

Thank You!

JessICADemers

Field Sales Manager | DC & MD

CiTR!X Systems, Inc

_________________________
Keep IT Fresh!
Upcoming Citrix seminars & webinars in North America

Hear from Citrix experts, top IT industry partners & our customers

Updated every two weeks at www.citrix.com/NAevents

While it may seem a bit callus to underscore Citrix's products and services in a time when people are sick and in some cases dying from Swine Flu (H1N1 Virus);  I would be remiss in my duty as a Citrite if I did not offer the help and resources of our local DC & MD Sales Team.  We are fielding many quote and order requests from new and existing Citrix customers, looking to enable and protect their businesses via Citrix.  If you have ANY questions about how to size and scope what your company will need to either implement or expand your Citrix environment please call us so we can help you sort it out!
 

An in-depth look at Citrix XenApp ::: How XenApp application virtualization and application delivery works

2:24 Whiteboard Video | http://www.citrix.com/English/ps2/products/feature.asp?contentID=1684340

XenApp is an application delivery system that virtualizes applications in the datacenter and delivers them as an on-demand service to users anywhere. With XenApp, organizations can deliver any 32-bit or 64-bit Windows or UNIX application to any device including Windows, Mac and Linux PC's---and even Smart Phones.
 

Inside Sales Representative:  Jose Parada | 954.229.6849 | jose.parada@citrix.com

Thank You,

Jessica Demers

お客様を訪問したり、イベントなどでお客様と会話したりする時に時々感じることなのですが、Citrix XenAppに関するご理解がMetaFrameの時代のままであることが時々あります。実際かなりの進化を遂げているのですが、頻繁に名前が変わりますのでここで簡単にまとめてみます。私も改めて思いましたが、日本でリリースしてから、ほぼ10年がたっている製品なのです。

お客様のMetaFrame、いえXenAppに対するご理解が、どのバージョンのものかはそれぞれだと思いますが、時々このような声を頂く場合があります。

「アプリケーションによっては動作しないんですよね？」
「アプリケーションストリーミングを一度使ったことがあるけれど、オフラインでは使えないんですよね？」
「一度、動画やマルチメディア系のアプリケーションを動かそうとしたけれど、、、」
「やはり印刷面が弱いですんか？」

確かに、以前はあったかもしれませんが、現在最新バージョンXenApp 5.0 FP1です。過去にあった懸念事項などは本当に大幅に改良されています。例えば、印刷まわりですが、日本のプリンタベンダ様と検証等を一緒にはじめたのがちょうど、MetaFrameXP FR1頃だったと思います。私は、その頃サポートエンジニアとして勤務していましたが、ラボにあるプリンタベンダから送られてきた10種類以上のプリンタに囲まれて、汗をかきながら、検証作業の支援を行っていた事を覚えていますし、色々なプリンタベンダ様をご訪問して当時のMetaFrameXPの印刷の機能を説明にまわりました。

それからほぼ8年がたっています。本当に機能改良されている部分がたくさんありますので、一度に紹介することができないのですが、これらのビデオは、その機能の一部を紹介しています。英語もクリアですので英語の勉強もかねて一度ご覧になっていただければと思います。

ちなみに、Mythとは「間違った理解」とかそういう意味です。

XenApp Myth Busters - Value of Application Delivery
http://www.citrix.com/tv/#video/291

XenApp Myth #1 - My apps don't work with XenApp
http://www.citrix.com/tv/#video/259

XenApp Myth #2 - Apps don't work offline
http://www.citrix.com/tv/#video/257

XenApp Myth #3 - Doesn't Support Multimedia
http://www.citrix.com/tv/#video/256

XenApp Myth #4 - Doesn't support printing and local devices
http://www.citrix.com/tv/#video/255

XenApp Myth #5 - User expereience not as good as installed
http://www.citrix.com/tv/#video/290

Myth Busters - Video series summary
http://www.citrix.com/tv/#video/269

We're quite pleased with the new version 2 release of User Profile Manager, but of course there are new features being planned already. (Note that going forward, the name User Profile Manager will be dropped, and future versions will carry the name "Profile management" or Pm.)

Without going into details, we're looking at features to improve both performance and usability. What does that mean for current users of Pm, though, and what provision should they make as they roll out their v2 deployments to minimise the disruption when versions 3 and 4 come along?

First of all, there's the design of the User Store. If you're using Windows XP and/or Windows 2003, you'll be using "version 1" profiles, and if you're using Windows Vista or Windows 2008, you'll be using "version 2" profiles. That's Microsoft's terminology, but it can get really ambiguous when I'm also talking about Pm versions, so I'll refer to Windows XP and Windows 2003 profiles as Win5 profiles. Likewise Windows Vista and Windows 2008 profiles can be grouped under the term Win6 profiles. As an aside, it's looking like Windows 7 profiles share the same format as Vista and 2008, so at the time of writing, it looks like Windows 7 is also covered by the term Win6.

So what we're expecting is that you'll put both your Win5 and Win6 profiles on the same server, and we expect that you'll set up your User Store as suggested by Microsoft's article http://technet.microsoft.com/en-us/library/cc757013.aspx (Security Recommendations for Roaming User Profiles Shared Folders). For the sake of example, let's say you have the User Store set up as the share //OutlawSrv1/profiles/ . Pm lets you configure paths using Active Directory attributes, so you might use either #cn# or #sAMAccountName# to define the next level. Again, for the sake of example, let's use #cn#, giving us a path of //OutlawSrv1/profiles/#cn#/ . If we do this, all the different Pm directories we're going to create will just inherit the permissions from the top level directory, which is exactly what we want.

Now we recommend setting up a System Environment variable to differentiate between Win5 and Win6 profiles at the next level. Pm lets you incorporate System Environment variable into the profile path, by enclosing the variable in percent signs. In our example, we'll set up a System Environment variable %ProfileVer% which will take the value "v1" on Windows XP and Windows 2003 systems and "v2" on Windows Vista and Windows 2008 systems. So now the complete path you configure in the Pm GPO is //OutlawSrv1/profiles/#cn#/%ProfileVer%/

Here is the User Store layout that results:

//OutlawSrv1/profiles/William/v1/
                     .       /v2/
                     /Douglas/v1/
                     .       /v2/
                     /Henry/v1/
                     .     /v2/
                     /Ginger/v1/
                     .      /v2/

Sorry if that's a bit long winded, but it's important to understand that this is the basis of our planning for the next versions of Pm. We're going to assume that new features will be able to slot in alongside the v1 and v2 directories above, so that Pm v3/v4 will build per-feature data on the directory structure above, giving:

//OutlawSrv1/profiles/William/v1/
                     .       /v2/
                     .       /feature1/
                     .       /feature2/
                     /Douglas/v1/
                     .       /v2/
                     .       /feature1/
                     .       /feature2/
                     /Henry/v1/
                     .     /v2/
                     .     /feature1/
                     .     /feature2/
                     /Ginger/v1/
                     .      /v2/
                     .      /feature1/
                     .      /feature2/

That's the first recommendation. If you're only interested on how to future-proof your Pm installation against future Pm feature updates, you can stop reading here.

The next recommendations are about how you might manage upgrade scenarios. Typically, you've got Pm v2 deployed, and you'd like to take advantage of the new features in Pm v3 or Pm v4. Unfortunately, we don't expect to be able to offer co-existence of different Pm versions. Specifically, for any given user, all machines that he uses must be managed by the same version of Pm. Otherwise, older versions of Pm will just ignore the new feature directories, and will make changes in the v1 or v2 directories without making corresponding changes in the feature directories. Result: a corrupt profile - precisely what Pm is supposed to avoid!

The first step in solving this problem is that we'll be providing compatibility flags in the configuration of all future versions of Pm. If Pm v3 (say) can't find a configured compatibility flag, it reverts to the Pm v2 functional level. Similarly, if the flag is turned off, it operates at the Pm v2 functional level. So it's OK to install newer versions of Pm over the top of older versions - they'll work correctly. Likewise, the configuration of Pm v3 will be designed to be a superset of Pm v2, so you can replace the v2 ADM template with a v3 ADM template and Pm v2 will continue to operate correctly. (BTW, you're probably better off removing INI files, they could cause problems. My personal opinion is that INI files and production farms don't mix.)

There are two difficulties:

• AD changes don't propagate through the forest instantaneously, so we have to avoid the situation where some instances of Pm v3 have been told they can now operate at Pm v3 level, while others haven't seen the group policy update and continue to operate at Pm v2 level.

• You can't (in general) be sure that you've found and updated every copy of Pm v2 to Pm v3, so regardless of what group policy says, some copies of Pm can only operate at Pm v2 level

There are two obvious ways around this problem.  Neither solution is particularly elegant (so we're working on improvements), but these give the flavour of how to do it.

The first is applicable in small networks, where you can be sure that you've managed to upgrade every machine.

1. Replace the Pm v2 ADM template in the GPO with the new Pm v3 template. Set the compatibility flag to off (0)
2. Upgrade all machines to Pm v3
3. Make whatever other changes you need to migrate (as per Pm v3 administrator guide)
4. At a scheduled maintenance period, log everybody off
5. Make the necessary configuration changes and set the compatibility flag to 1
6. Wait for the group policy changes to propagate - maybe run gpupdate on each machine to force the update
7. Let everybody log on again, and watch the fun.

Hmm, that might work in a small network, but you don't have much of a backup plan if it goes wrong. It's a "Big Bang" approach.

There's another way, which gives you a bit more safety, and makes it easier to revert if something goes wrong. It makes use of the processed user group feature of Pm.

The idea is to create a new OU to contain all machines that have been upgraded to Pm v3 and a new group which contains the all the users allowed to use those machines. Initially the OU is empty and the group has no members.

(The OU will most likely be a set of OUs, covering each of the different OS types, but we'll keep it simple for now. We'll call that OU "V2OU")

Step 1: If you have not already done so, ensure that all the users of the Pm v2 machines belong to a group, and configure this group as the processed group in the Pm v2 configuration. Let's call that group "V2Users"

Step 2: Create a "mini-farm" in the new OU. We'll call that new OU "V3OU" - again it could be several OUs, but we're keeping it simple. You could move some unused machines from V2OU into V3OU, or you could build fresh machines. Ensure that V2Users are directed to machines in V2OU, and V3Users are directed into V3OU (this will involve some XA / XD changes outside the scope of this article). Install and configure Pm v3 on all the machines in the mini-farm, with the v3 feature level enabled. For this OU, make the processed group V3Users.

Step 3: Now you can migrate your first department of users. Get them all to log off and remove them from V2Users. Back up their profiles.

Step 4: Add them into V3Users and ensure that their sessions are now directed to V3OU.

Step 5: Let the users from the first department log on. Pm v3 will migrate their profiles on-the-fly to the new structure.

Step 6: Having transferred some users out of V2OU, you should now have a bit of spare capacity in V2OU. Transfer some more machines out of V2OU, upgrade them from Pm v2 to Pm v3, and transfer them in to V3OU. Migrate your next department (steps 3-5)

Step 7: Repeat step 6 above until all machines and all users are using Pm v3.

Phew!!

Hopefully there weren't any problems with that. You migrated your users in small batches and if a problem did show up, you could revert that department to their backed-up profiles until you could fix the problem.

Job done!

We were doing a benchmarking exercise recently, comparing the performance of an (untuned) User Profile Manager against standard Roaming Profiles.  I say "untuned", meaning that we hadn't set up any include or exclude rules against particular files or directories, nor were we doing any special processing on the registry, and while that's missing out one of the key benefits of UPM (the ability to exclude unwanted files, etc from the profile), that wasn't the point.

We assume that many Citrix admins would want to do a like-for-like comparison of UPM against Roaming Profiles to ensure that generally performance is comparable.  Better would be nice, but if there's a small price to pay for improved functionality, then that's probably acceptable.

You can imagine our shock when the first benchmark results appeared to show Roaming Profiles was twice as fast, and we had visions of a major re-architecting of the product, just weeks before we were due to release.

Of course, it turned out that we'd not made a proper comparison, which we realised as soon as we looked at the Citrix User Profile Manager 2.0 Logon-Logoff Chart - see http://support.citrix.com/article/ctx119466.

What that chart tells you is exactly what UPM does at logon and logoff time.  It tells you the circumstances in which UPM will create a brand new profile, or migrate an existing local / remote profile, and what processing is associated with that.

So we'd set up a template profile, with a set number of files of various sizes, which gave us the ability to measure repeatably the time it took to log on, compared to an equivalent Roaming Profile.  It should be the same, because all we're doing is copying files across the network, right?

Wrong!

We'd been tripped up by the extra function of User Profile Manager, in particular, the ability to write back only the changed profile data at the end of session, which helps UPM avoid the dreaded "last write wins" scenarios.  If there's no existing profile, UPM has to create one, and write it back immediately to the User Store, so there's something for other sessions to use straight away.

That, of course, means a second network copy, on the first logon only.  So whereas Roaming Profiles performs one full network copy-read at the start of each session, and a full network copy-write at the end of every session, UPM performs a full copy-read and a full copy-write at the start of the very first session.  For all subsequent sessions, UPM performs a full copy-read at session start, and a differential merge-write at session end.  It's that last merge-write that's the clever bit, of course, that lets UPM merge changes from multiple simultaneous sessions and avoids overwriting changes from earlier sessions.

Once that was sorted out, we were able to satisfy ourselves that logon times for UPM were very similar to logon times for Roaming Profiles.  The next step was to start adding include / exclude rules to reduce logon times ... but that's another blog post.

Group Policy Object (GPO) configuration is an option in addition to INI files for managing your User Profile Manager environment.  While the INI configuration approach provides a quick and easy way to get started on a few machines, if you wish to evaluate or try on more than a few machines, you should leverage the GPO configuration approach.  If using GPO for configuration you should rename or delete the INI files.  A GPO setting will always take precedence, but if a GPO setting is Not Configured and that setting exists in the INI, it will use the INI setting.  Thus this situation could result in unexpected behavior if not watching both configurations reliably.  Although with logging enabled, the log file will contain details of the source for applied settings.  E.g. the setting came from the GPO or from an INI file.
In order to use a GPO for configuration, you need to import the ADM template.  So first thing is to place the "UserProfileManager 2.0.0.adm" template somewhere easily accessible (e.g. you will need to search and select this file when importing into the GPO so place it somewhere easy to get like on the desktop where you will be running the Group Policy Management Console).

Launch Group Policy Management Console (GPMC) and either create a new GPO or select an existing GPO to manage your User Profile Manager settings.  I'll leave the discussion of balancing the number of GPOs against managing GPOs on a single functional role for another day J.  There are good arguments for both sides of keeping a GPO functionally specific versus having too many GPOs bogging down the logon.  Also, if you do not already have GPMC on your Windows Server 2003 or Windows XP system, download it here.  That console is by default already on Vista and Windows Server 2008.

Once your GPO is created (or selected if using an existing GPO), you need to import the ADM template which will then expose all the User Profile Manager settings.  Details on importing an ADM template can be found here under the Custom ADM Files paragraph/section: http://support.microsoft.com/kb/816662.  Once imported, all the ADM settings will be available for configuration.  Details of all the available UPM GPO settings are located here: http://support.citrix.com/article/ctx118944.

You can now enter edit mode for that GPO and view the settings and configure as desired.  You will find these settings under Computer Configuration/ Administrative Templates/ Citrix/ User Profile Manager.  If you are using a Windows Server 2008 or a Vista machine to manage your GPOs, the path will be Computer Configuration/ Policies/ Administrative Templates/ Classic Administrative Templates (ADM)/ Citrix/ User Profile Manager.  A good start is to have a look at the INI file and use the settings provided there in your GPO.

Side note: Keep in mind that by default, everything in the user profile is included.  Therefore you do not have to define anything in the include section except in certain circumstances.  For example, you would use inclusions to include any sub folders within excluded folders (e.g. you exclude Local Settings since this contains mostly temp garbage but then turn around and include the folders that actually contain useful application settings data like Local Settings\Application Data\Microsoft\Feeds and Local Settings\Application Data\Microsoft\Outlook).

Best practices suggest that configurations should be done on a per OS basis as Windows XP and Vista do not have compatible profiles.  For example create two OU's, one containing XP Desktops and one with Vista desktop and apply a GPO to each OU.  Here is a specific example on how to the design the user store for this scenario: http://blogs.sepago.de/helge/2009/01/23/citrix-user-profile-manager-released-user-store-design-recommendations/

Although you can share profiles between Win2k3 & XP and between Vista & W2k8 please refer to this FAQ on potential repercussions to take into consideration: http://support.citrix.com/article/ctx119039.

Once you have completed your configured to your desired state, you are ready to go.  To force a target machine to collect this updated configuration, run "gpupdate /force" in a command shell.  Or typically after about 90 minutes, group policy will refresh by default.  Once again you are ready to evaluate and test.

This will give you a very basic setup to get you up, running and evaluating.  I will cover using INI files in this article and post a second article on using Group Policy Objects(GPO).  While the INI configuration approach provides a quick and easy way to get started on a few machines, if you wish to evaluate or try on more than a few machines, you should leverage the GPO configuration approach

Step 1: You need to download the package.  User Profile Manager (UPM) may be found in both the XenDesktop and XenApp download pages (listed below).  Depending on the status of your Subscription Advantage, you will have access to up to two links.  One link is for those with an entitled Subscription Advantage status and the other link available to all for evaluation purposes.  Also I should mention that you will start seeing us reference this technology as the Profile management feature (for both XenApp and XenDesktop).

-          XenApp https://www.citrix.com/English/ss/downloads/results.asp?productID=186&c1=pov1349748&c2=sot8218

-          XenDesktop https://www.citrix.com/English/ss/downloads/results.asp?productID=163057&c1=sot8218

The zip package you download will contain the install packages, ADM template for Group Policy and supporting documents (all of which are available in the Knowledgebase and the respective links are at the bottom of this article).

Step 2: You need to install the profile service. This service must be installed on each endpoint that you want to have user profiles managed by UPM (e.g. XenApp server, Desktops (XP, Vista), etc).  There are two MSI packages - one for 32-bit platforms and one for 64-bit.  The install is simple and straight forward.  After clicking next a couple times, the package will be installed.  There is nothing to configure at this point other than the target install directory if you desire something different than the default (which is c:\program files\citrix\user profile manager{}).

The target install directory is also where the INI files are located.  The settings in the INI files provide a default configuration.  The INI section naming translates directly to the GPO configuration settings.  By using the INI file, you have a basic configuration ready to go.  It is relatively easy to read and interpret what the INI configuration settings are having User Profile Manager capture and track.

Per the default configuration, UPM will capture the user's entire profile (files and registry) and store it in the user's home directory under a folder called 'windows' (you may change this to any folder name desired or use a fully qualified UNC target).  For files and folders this means everything in the user's profile directory.  For example, on WinXP or Windows Server 2003 that would include everything in /Documents and Settings/%USERNAME%/.  For the registry this is the entire HKCU (NTUSER.DAT).  Thus you only need to be concerned with what to exclude (keeping the bad and bloating things out).  There are a few defined exclusions in the INI file for both file system and the registry which will provide you a good starting point for your test environment.

Side note: Keep in mind that by default, everything in the user profile is included.  Therefore you do not have to define anything in the include section except in certain circumstances.  For example, you would use inclusions to include any sub folders within excluded folders (e.g. you exclude Local Settings since this contains mostly temp garbage but then turn around and include the folders that actually contain useful application settings data like Local Settings\Application Data\Microsoft\Feeds and Local Settings\Application Data\Microsoft\Outlook).

Step 3: There is one setting change required to enable the service to start working - this is the 'ServiceActive=' setting.  By default, the service sits idle enabling customers to push this service out before enabling it (even though the service is 'running' in the services list, it does not manage anything).  Enabling the service is done by setting ServiceActive=1 in the General Settings section of the INI.  Also remove the semicolon at the beginning of the line otherwise the line will be interpreted as a comment.

And with that you are off and running.  All user accounts will be processed by default unless you assign an AD domain group in the configuration.  Also, Administrator accounts will be ignored (again by default).

You are ready now to test and evaluate away!  Enjoy.

To get a sense for what User Profile Manager is doing and to verify your settings you can enable the logging mechanism of User Profile Manager. This will be achieved by the setting LoggingEnabled=1. Logging details can be enabled by the remaining settings all in the Log Settings section.  '=1' is on and '= ' or '=0' is off.

CTX Articles (Documents and FAQS):

-          http://support.citrix.com/article/ctx118943 Admin Guide

-          http://support.citrix.com/article/ctx118944 Group Policy Template Reference

-          http://support.citrix.com/article/ctx119466 Logon/Logoff Chart

-          http://support.citrix.com/article/ctx119791 Technical FAQ

-          http://support.citrix.com/article/ctx119747 Licensing FAQ

-          http://support.citrix.com/article/ctx119039 Cross Platform Considerations FAQ

-          http://support.citrix.com/article/ctx119038 Troubleshooting FAQ

You may have noticed that Citrix recently released User Profile Manager v2 (UPM).  Those of you using the Technology Preview or a previous sepagoPROFILE product are probably wondering what exactly has changed in this release.  There are six key changes to this v2 release you should be aware.

The biggest change is UPM no longer uses a mandatory profile.  The previous method of loading a mandatory profile and merging settings has been replaced with a mechanism that behaves much more like the mechanics of a roaming profile (plus saves time since it no longer has to merge settings).  Since a mandatory profile also served as a good 'base' profile, we added the capability of a 'template profile'.  This is what would be used as a 'default profile' for creating a new users profile.  You can actually use your mandatory for the template profile if you just rename NTUSER.MAN to NTUSER.DAT.  Please remember that it does need to be a 'whole' profile and not just the NTUSER.DAT file (HKCU registry settings).

You should also make note that once a template profile is used to create a profile, that profile is then copied to the user's store (the target location defined when configuring UPM) and is no longer connected to the template profile.  Meaning that you cannot change the template profile after a user has their profile built and expect those updates to replicate to existing users - only new users would see the changes.  If you desire to enforce settings, configurations or other environmental items, this would be a job for Group Policy.  Thus when Group Policy is updated or changed, this new policy would be applied to all applicable users or computers.

The next significant change is the support of wild cards in the configuration.  Whereas before if you wanted to add only INI files to the profile, you had to literally type each file name in entirety.  Now you can use *.INI to configure that same behavior.  The standard wild cards are supported such as '*' and '?'.

Next we added the ability to synchronize folders outside of the user's profile directories.  Such in the case when you have an application storing user settings improperly such as in 'c:/badapp/'.  Now the administrator can define these 'rogue' folders as part of the user's profile and they will roam with the user.  Just make sure they don't roam with you into a dark alley - they really cannot be trusted.

We significantly improved logging so that you can view your log files in an application such as Excel and be able to sort and filter the files for better reviewing and analysis.  I will post separately on all the details around logging.

We added language independent storage of profiles on the Windows Server 2003 and Windows XP platforms (Windows Server 2008 and Vista already do this).  What this does is append folders such as favorites with '_upm_var' so that when roaming between different languages, you do not end up with multiple folders since on these platforms Favorites would get localized and treated as unique folders.  E.g. on German you would have Favoriten while on English you would have Favorites.

We also had one casualty that we will honor with a moment of silence.  That would be the archiving functionality being dropped in v2.  This was the capability to compress files within a folder into a ZIP file and then copy that ZIP file to the user's central store.  Unfortunately this introduced last write wins since the last zip file written would overwrite any previous file.  But fret not, we will certainly be focusing on areas to improve speed and performance as we continue to build out this technology.

One of the common questions and quests around user profile solutions is improving logon speed.  Often there is an expectation that if the profile load time is addressed, my logon time issues are addressed.  This is not always the case.  There are other factors that influence the logon time.  Group Policy objects, global logon scripts and user logon scripts are other critical areas that have significant influence on logon times.  So let's take a closer look at the influence the user's profile has on logon speed.

User Profile Manager 'might' help improve logon time but it really depends on what is in the profile and what is consuming the time to load it.  Also keep in mind if you are currently using a mandatory profile (a size controlled profile that does not store any new settings from a user's session) then moving to User Profile Manager will likely increase the size of the user's profile (since now the user can add and create new settings, files and folders in their respective profile).  A larger profile means it will then take longer to load than the previous mandatory profile.  Of course the upside is the user now has a much more customizable and personalized experience.

Let's compare User Profile Manager to roaming style profiles where the user's profile settings are stored and will follow the user from computer to computer.  User Profile Manager may improve logon time significantly if these profiles are being weighted down by bloat.  User profile bloat is when there are many extra settings, files and folders in the user's profile that are not needed but are still being captured and stored (here is a blog on profile bloat: http://community.citrix.com/x/A4AaAg).

With User Profile Manager, you can granularly define what is included and what is excluded in a user's profile. This includes using combinations of includes and excludes to further refine and target only what is absolutely required to be in a user's profile.  Thus by managing the size, the time it takes to copy down is optimized and improved.

But if everything in the profile is necessary and needs to remain in the profile, now we have a traditional bandwidth challenge.  How do you get data from point A (on the network) to point B (on the windows device) more efficiently and more quickly?  As there is much improvement that can be done in this area, it will be a focus area of User Profile Manager over future releases.

Next let's cover the question of how do I know if the profile is dragging out the login time.  It could be the profile is very large and the time it takes to copy down to the system creates logon lag (which often feels exactly like jet lag).    One option is to allow Windows to cache the user's profile.  By caching and thus retaining the profile on the local drive, only changed or updated files in the profile are copied down on next logon to the device.

While caching profiles may be fine on individual devices and desktops, not so much on a XenApp server when you could have 100s or 1000s of users (or even more) passing through.  In fact on XenApp based deployments you almost never want to cache the user profile (is there ever anything in technology that is an absolute).  While caching will certainly speed up logon time, it turns your server into a profile storage device which can easily translate into gigabytes and gigabytes of storage on that local drive.

So how do you figure out how much overhead the profile (or even part of the profile) is adding to the logon?  Based on finding this answer you will better be able to determine whether User Profile Manager will benefit logon time.  User Profile Manager offers the ability to extensively log the activities during logon including the time each activity required.

Not only is the profile loading process logged (NTUSER.DAT, files and folders) but also times querying AD, getting correct paths, etc. will be logged with time stamps.  In order to capture the user specific logging, please ensure that users have write access to %systemroot%\system32\LogFiles\UserProfileManager (the default Windows log directory).  Since users do not typically have write access here, you should add the user group "Authenticated users" to have write access to this directory.

So now that logging is enabled and you have logged on and off with some user accounts, let's take a look at what you have now.  At the end of the loading process of the profile, UPM summarizes this. Here's an example log entry:

2008-10-12,15:44:46.552,INFORMATION,SEPAGO,Joe,2,DispatchLogonLogoff: ---------- Finished logon processing successfully in [s]: <2.28>.

*Tip*: Always search for "-------- " to get starting and end points of logon / logoff events with accumulated information.
Wow, 2.28 seconds to process the logon -- this would be a great performing environment (this example was only processing the Registry and not files).  If the time captured was similar to "Finished logon processing successfully in [s]: <20.00>." (or more) you should have a look at the single timestamps in the logfile and identify if a big gap exists between two entries.  That is presumably the point you can start searching for what is going wrong.

If there is no such gap, have a look at the profile size. Back to the earlier discussion, if everything needs to be in a 2 GB profile, then this becomes a different discussion.  A discussion we should have someday soon.

Today many users access their productivity applications using multiple methods.  This includes installed locally, published and/or streamed via XenApp (either as the mechanism to publish the app on XenApp or directly to the end point client).  So who is tired of re-creating their auto-signatures over and over?  One of the challenges is making sure your auto-signatures always follow you no matter how you launch Microsoft Outlook (as well as your other Office settings).

We also need to consider the other application settings like toolbar settings.  In Office 2007, changes to the toolbar are saved to a .qat file.  Microsoft has more details on these Office settings - http://support.microsoft.com/kb/926805/en-us

The below paths are for WinXP and WS2003.  For Vista, use AppData\Roaming\... instead of Application Data\... AND use AppData\Local\... instead of Local Settings\Applications Data\...  Although keep in mind in most scenarios you do not want to 'roam' local settings hence the name.  You would add (or verify they already exist) the below files and folders (or just the parent folder to capture everything) to the User Profile Manager settings to have them tracked and managed.

Files

• Local Settings\Application Data\Microsoft\Office\Access.qat
• Local Settings\Application Data\Microsoft\Office\Excel.qat
• Local Settings\Application Data\Microsoft\Office\Olkaddritem.qat
• Local Settings\Application Data\Microsoft\Office\Olkapptitem.qat
• Local Settings\Application Data\Microsoft\Office\Olkdistitem.qat
• Local Settings\Application Data\Microsoft\Office\Olklogitem.qat
• Local Settings\Application Data\Microsoft\Office\Olkmailitem.qat
• Local Settings\Application Data\Microsoft\Office\Olkpostitem.qat
• Local Settings\Application Data\Microsoft\Office\Olktaskitem.qat
• Local Settings\Application Data\Microsoft\Office\PowerPoint.qat
• Local Settings\Application Data\Microsoft\Office\Word.qat
  
  

Folders (Outlook)

• Application Data\Microsoft\Outlook
  • There are a number of files here that control/track configurations such as auto-complete, send/receive settings and tools, utilities and other add-ins configurations/settings
• Application Data\Microsoft\Signatures
  • These are all your signatures in various formats
• Local Settings\Application Data\Microsoft\Outlook
  • This folder (and all those in Local Settings) can be tricky since it stores offline folders (OST) and Personal Folders (PST files).  You may want your PST files to follow you but pending their size this can be an expensive file to roam.  And you can imagine the situations that will arise when two or more sessions are active simultaneously for these types of files - last write wins will definitely be a factor here and thus lost emails in the PST files.  For this reason Local Settings should probably not be roamed unless you are absolutely sure it is safe for a particular application.  Use file exclusion here as needed.
    
    

Folders (Office in general)

• Application Data\Microsoft\Office
  • ACL files (Auto correct entries) - http://support.microsoft.com/kb/926927
  • PIP files (personalized toolbar and menu settings) - http://support.microsoft.com/default.aspx/kb/193006
• Application Data\Microsoft\Templates
  • These are your office template files such as normal.dot/.dotm for Word and blank.pot/.potx for PowerPoint etc.
  • Again be careful here when using multiple versions (e.g. Office 2003 and Office 2007) - mixing can result in unpredictable results.
• Local Settings\Application Data\Microsoft\Office
  • Keep in mind in most scenarios you do not want to 'roam' local settings hence the name.  You would want to do this very selectively on a file by file basis.
    
    

I expect I covered the key areas for ensuring your Office settings follow your users.  Please let me know if there is anything missing or overlooked.

Finally the much awaited release of XenApp 5 can now be downloaded from MyCitrix download page (needs MyCitrix credentials).

XenApp 5 for Windows Server 2008 needs a full install and since this is the first time we are supporting Windows Server 2008 platform, there is no upgrade from previous versions. And, this comes in a DVD. No more Server CD and Component CD. Everything is one DVD for the Windows Server 2008 platform. And don't forget to check out this technical guide for a step by step approach in migrating to XenApp 5.

XenApp 5 for Windows Server 2003 does not require a full install and supports upgrading from previous XenApp versions (4.0 and above). In fact there have been no server side updates and the core server install still uses Presentation Server 4.5 install. All the new functionality can be implemented using the new clients and components (like Web Interface 5.x, EdgeSight 5.x, Streaming Profiler/Client 1.2 etc). So, why did we call this release XenApp 5 for Windows Server 2003 and not something like Presentation Server 4.5 Feature Pack 2 for Windows Server 2003? Let's not go there  and I think that deserves a blog post of its own. Anyhow, the good news is that all this new functionality on Windows Server 2003 can be adopted without doing a fork lift upgrade/migration. Again, for step by step instructions on implementing the new functionality, check out the technical guide for migrating to XenApp 5.

Btw, don't miss out on the first ever XenApp 5 virtual event on Sept 9th. More than 2500 customers and partners (and still counting) have already registered for this online virtual event.

Since I blogged about Health Monitoring and Recovery (a.k.a. Health Assistant) feature of XenApp, I received several requests on the internals of the 10 test packs. So, here you go.

• Logon/Logoff test

This test detects failures (typically external to XenApp) that cause users to rapidly logoff the system and potentially create a black hole in the farm. The test will monitor logons and logoffs to a XenApp server. If logoffs are rapid and consistent, the test will throw an error condition.

This test has the following three unique parameters that must be updated through command line arguments. These arguments can be managed centrally using the Access Management Console.

1. SessionTime -  specifies the time spent in each session.  If the amount of time spent in the session is less than this value, it is treated as an error.
2. SessionThreshold - specifies the session error threshold at which the service should throw an error condition.
3. SampleInterval - specifies the time for which the session time sampling is done.  After each interval, the monitor checks to see if the SessionThreshold has been reached.  If it has, it will signal an error when queried by the logon monitor test.

• Terminal Services test

This test enumerates the list of sessions running on the server and queries session information (such as user name).  It is similar in functionality to the "quser" utility. The test communicates directly with Terminal Services by using the "WTSEnumerateSessions" API call.

• IMA test

The IMA test queries the IMA service to ensure that it is up and running by performing an app enumeration on the IMA service. It uses an internal API call to enumerate the applications.

• XML Ticket request test

This test queries the Citrix XML service on the local machine.  The service responds with XML data that includes a XenApp ticket. This ticket is checked for validity. If the ticket check fails or if a server/port fails to respond to the request (e.g. a socket timeout occurs) the test returns an error. This test communicates directly with the XML service through a TCP socket via the Winsock API.

• Microsoft Print Spooler test

The Print Spooler test attempts to ensure MS printer spooler reliability.  It will enumerate printers on the local server, enumerate printer drivers and printer processors using Microsoft Windows APIs.  Exercising these tasks is fundamental to ensure that the MS printer service is running smoothly.  The reason we enumerate these three different items is because enumerating just printers may not give us any information as we will only be able to enumerate printers that an administrator gives Local Service permission to read. However, drivers and processors can be enumerated by Local Service.

• Citrix Print Manager Service test 

This test is responsible for ensuring that the Citrix Print Manager service is operating properly.  The Citrix Print Service test calls internal APIs to ensure reliability.  Specifically, the test will use RPC to call Citrix Print Manager service to enumerate all printers on the local machine. If enumeration does not complete successfully the test will throw an error condition.

• Check DNS test

By default this test will run a forward DNS lookup that is guaranteed to go over the wire to the local machine's DNS server. Optionally, users may run a reverse DNS lookup. For either test, we gather the locally configured information and then make a DNS query to compare the results.   

The forward DNS lookup will gather the IPv4 address of the local machine from the installed NICs. The test will then make a DNS query based on the locally configured hostname and compare the resulting IP address to the one we grabbed locally. If these two IP addresses do not match, the forward DNS lookup will throw an error. 

The reverse DNS lookup will gather the hostname from the local machine.  It will also take the locally configured IPv4 address.  Using the local address, it will convert it to the reverse DNS address and query for the hostname.  The test will then compare the resulting hostname with the one it originally queried from the local machine. The reverse DNS look up will not be set to run by default as many organizations neglect configuring this and which may lead to false negatives. 

Successful completion of this test will ensure DNS is working properly on the local server.

• ICA Listener test

The responsibility of the ICA Listener Test is to ensure clients can make a successful connection to the local server via the ICA protocol.  We will validate this functionality by pinging the ICA listener and monitoring the response.  When idle, the ICA listener emits the text "ICA". By looking for these characters we can verify that the ICA listener is in a good state.

• Check XML Threads test

The Check XML Threads test will run as a monitor test.  This means that we will look for unwanted behavior over a period of time.  The Check XML Threads test will look for too many XML worker threads to be running for a prolonged time period.  By default we set this time to be one minute.  If the test determines that the worker threads are past the default threshold of 10 threads for over a minute this will indicate that the XML service is being stressed too much.  The administrator may wish to add an extra server to handle some of the load.  When the threshold is met, the corrective action will execute. 

This test aims to monitor XML service trafic load.  When the service is overloaded, Web Interface connections will suffer. This test will alert administrators that they may need to address XML performance. This test will make use of a new performance counter that we added with the test pack. The performance counter will measure the number of active worker threads running in the XML service. There were recent changes made to the XML service where worker threads are not killed when they are done being used. Instead, they are kept alive but are made idle. This change was made to improve performance. However, the old performance counter still reflects the total number of worker threads. This value is not what we are interested in because there may exist worker threads that are idle. With data from the new performance counter, the test will simply poll the counter for the number of worker threads that are actually doing work.

• Check Local Host Cache test

The Check LHC test is responsible for recognizing and responding to LHC corruptions and inconsistencies on the local machine that could result from stale data left when removing a server and/or published app.  LHC corruption refers to compromised integrity of LHC object(s). The test will check what the object size should be versus the actual size of the object.  LHC inconsistencies occur when there are duplicate entries or when entries do not match the datastore objects. To verify inconsistencies we focus on four contexts:  MfServer, CommonServer, MfApp, and CommonApp. If we detect an error when running these checks, we perform an LHC refresh. After the refresh is complete, we check the integrity and consistency to ensure that the problem has been resolved. If the problem persists, the administrator configured corrective action will be executed.

In a previous post I posed the question "If you could wave a magic wand and have any one single feature in the next release of Citrix XenApp, what would it be?".
It is clear many of you would like to wave that magic wand. There have been just over 650 votes and 26 comments so far. This post has been in the Top 5 in total post views since it was posted. Clearly there is a lot of interest in this topic.
I guaranteed you in that post I would share the results with the XenApp product team and I have done that. I also promised to follow up on the feature requests.
I am still working on getting a high level developer or software architect to talk about "live migration of individual sessions". I do have some further info on "Speed Screen Multimedia across all client platforms", the second most popular option in our poll.

Derek Thorslund, our Multimedia Virtualization Strategist, has written numerous posts about SpeedScreen Multimedia and related technologies. According to Derek, support for SpeedScreen Multimedia Acceleration on the Linux client is currently being developed. Derek was not able to give me a definitive time line for the general release of this capability, but I think they can see the light at the end of the tunnel. In fact, our Technology Licensing Partners now have access to a Technology Preview of SpeedScreen MultiMedia Acceleration for the Linux client. I will keep prodding Derek to provide more info as this project reaches completion.

In case you are not aware, SpeedScreen Multimedia Acceleration is currently available for the Win32 Client and the Windows CE WBT client (according to the client matrix). You can see in that document that Image Acceleration, Flash Acceleration and Browser acceleration are all support on multiple clients beyond Win32 and Win CE CBT.

Here are a few relevant blog posts on this topic in case you have not seen them -

SpeedScreenMultiMedaiAcceleration and Rave Video

How Do I Know if RAVE is Working?

What is SpeedScreen Image Acceleration?

Secrets of Optimizing Flash Part 1

Secrets of Optimizing Flash Part 2

Secrets for Optimizing Flash Part 3

Secrets for Optimizing Flash Part 4

Secrets for Optimizing Flash Part 5

New HRP Enhances Flash Support

SpeedScreen Progressive Display Delivers PACS Images



For deeper background technical information, here are some Knowledgebase articles on this topic

Troubleshooting the SpeedScreen Multimedia Acceleration Feature

Windows Media Player Cannot Play the file\


And finally, here is a technical video (narrated by Brian Madden) I found on the SpeedScreen topic -

Deep Dive into Citrix XenApp SpeedScreen Technologies

(47 minute video)

If you could wave a magic wand and have any one single feature in the next release of Citrix XenApp, what would it be?

While XenApp has literally hundreds of features that have been added over the last 10 years as the product has evolved from MetaFrame 1.0,1.8, XP, FR1 though FR3, 3.0, then 4.0 and now 4.5, is there one feature you really want to have but have not seen yet?

I pulled in a few ideas I have received into a poll. If you would like to add others to the list, post them in the comments and I will add your suggestion. I am looking for big home run features, but ideas that help you in your day to day job are fine as well.

From my past experience, many of you just do not have the time to keep up with every feature added to XenApp/CPS over time, especially if you are migrating to every other release. I have a theory about that as well (but I am saving that theory for a later post). It will be interesting to see if any feature ideas are submitted that have already been added in a past release.

Of course, there is no guarantee anything on this list can or will be included in the future (since I am not on the XenApp product team). I do guarantee I will communicate the results of this poll to that team.

This is a very preliminary list based on an informal survey I took recently. Instead of editing it, I am just posting it to get the discussion (and voting) started. If you want to add a feature to this list, post it in the comments and I will add it. Focus on the problem you need to solve.

If you could wave a magic wand, what feature would you put into the next release of XenApp?	Choose
SpeedScreen Multimedia support across all client platforms
Enhanced smart phone integration
Enhanced Mac integration
Live migration of individual sessions
Diff tool for Microsoft and Citrix patch levels on all servers
Integration with third party app virtualization solutions (MAV or SVS)
Greatly enhanced scalability
Security Analysis and Lockdown Tool
Pool of Pre-Launched Sessions for Faster Launching
Management through an Active Directory OU

Follow me on Twitter.

UPDATE:Two Additional Choices offered based on comments.

If there is a lot of interest in this poll, I will post follow ups on the features requested and similar polls for other products. My goal here is to get unfiltered feedback from you about what you want to see in the product and how we can improve the product to solve the problems you face.

UPDATE:The response to date on this poll has been excellent. Votes are still coming into the poll. I have sent a screen shot of the results to date to a member fo the XenApp team to ensure the product team is aware of these requests. I am working to get some members of that team to discuss of these requests and the comments posted here.

Previously I covered an overview of User Profile Manager as well as how it addresses last write wins.  Now I will cover profile bloat which is one of the more common user profile pain points.  Profile bloat creates unwieldy growth in user profiles and resulting storage and management issues (and the performance impact as profiles continue to grow in size).  So let's take a closer look at how User Profile Manager gives you control over this challenge.

Typically when using Folder Redirection or a roaming profile, the user's profile folders follow them as they move from system to system.  In a perfect world all your applications would behave properly and there would be no profile bloat. We know this is not the case and thus certain folders lend themselves to becoming very bloated fairly quickly.  Application Data is one of those folders, as applications may use it as a temporary folder (instead of the system's temp folder) and do not clean up the folder after the application ends.  This folder can become a graveyard of files no longer wanted or needed.  Or become a repository of files not really needing to be kept from one session to the next - temp files or cached data.  This folder can quickly become 100s of MB in size.

In a roaming profile scenario, this is a lot of data to be dragged around with a user.  With folder redirection, this becomes a lot of data to have to store somewhere - particularly if it's not really needed.  This becomes a painful process since the data may be getting copied back and forth with every logon and logoff event (although some optimizations within the profile contain the copying back to only files that changed).  In the case of XenApp servers where profile caches are almost always deleted upon logoff, all this profile data will have to be copied down again upon next logon.  Situations like this compound the pain we experience with unwieldy profile sizes.

With User Profile Manager you configure to exclude this 'extra baggage' causing that data to be ignored.  The payoff will be better management of the central storage resources (not storing extraneous files back to the user's central store) and this can translate to improved logon times since this extra baggage is not processed with the user's profile (which unless it is already cached on the machine the user is logon into, it will be copied down).

User Profile Manager provides the capability to fine tune the files and folders in a user's profile.  Now an administrator can explicitly include or exclude folders and files within a user's profile (and the ability to combine these such as to include a specific folder and exclude a subfolder within that folder).  For example, you might have an application called MyApp that creates and stores a multitude of supporting files in the \Application Data\MyApp directory (of which the subdirectory called '\MyAppStuff' is not needed).  You could include the root MyApp_ directory but then define an exclusion of the _\Application Data\MyApp\Stuff folder and upon logoff these files are left behind and not transferred to the user's central store.  If you have configured local profiles to not be cached, this extraneous data is just deleted at logoff with the cached profile.

By fine tuning and adjusting over time what is kept and not kept in the profile enables the profile size to be managed more efficiently.  For a start have a look at the INI files installed with User Profile Manager (in the target install directory) provided with UPM as they provide some good initial settings. And of course the profile size being reduced and less data being copied back at logoff can contribute to improved logon and logoff time.

There are two primary components to a user's profile - registry information and files.  This article will focus on the registry portion where last write wins becomes an issue.  While session sharing will mitigate this issue since only a single profile will be loaded (e.g. one session being shared by all apps equals one profile), there will be scenarios where multiple sessions occur or may be required and thus the potential for last write wins.  Specifically I will discuss the differences in how User Profile Manager functions over traditional roaming profiles when it comes to managing the NTUSER.DAT file (the user's registry settings also known as the HKEY_CURENT_USER or HKCU registry hive). 

During logon the NTUSER.DAT is copied down to the local machine the user is logging on (as well as the profile's files).  The NTUSER.DAT file contains the user's registry settings (HKCU) that are unique for every user (user being defined as a security account GUID).  The exception is when a mandatory profile is applied where all users share the same NTUSER.DAT (but then it's renamed to NTUSER.MAN).

During logoff, a roaming profile will copy the entire NTUSER.DAT file back to the central network share.  In this situation, the last session to end will have its NTUSER.DAT file saved.  Thus any settings in the 'previous' NTUSER.DAT on the network share will be lost if it happens to have changed since being copied down to the current session.  If the user has modified any profile settings in any of their active sessions, then the NTUSER.DAT file will have changed since the original version was copied down.

The difference with User Profile Manager is it will scan the current user hive (HKCU) and only writes back the changed registry settings.  User Profile Manager does this is by loading the 'centrally stored' DAT file called the 'user store' (file name is %USERNAME%.DAT) within the user's active session (in other words with the currently active HKCU hive) and performing a diff against that HKCU.  The results of the diff are then written into the user store.  It does not overwrite the previous NTUSER.DAT file.  So is this good?  It seems good, so let's take a closer look and see.

Let's look at roaming profiles and User Profile Manager using a simple example.  I have two separate XenApp sessions - one session has Microsoft Word and the other has Microsoft Excel (work with me for now on why there would be two sessions).  I make changes to my Microsoft Word application settings in the first session.  In the second session I make changes to Microsoft Excel application settings.  I close out the Microsoft Excel session first.  My roaming profile unloads and the NTUSER.DAT file is written back to the network share replacing the existing copy.  Then I close out the Microsoft Word session.  And again the NTUSER.DAT file is then written back to the network share replacing the one just copied back from the Excel session.  I've just lost my Microsoft Excel settings.  While I've used Microsoft Office applications for simplicity sake, this would be true for any two applications in this scenario.

What User Profile Manager does is as simple as easy: only save the net changes and merge them to the user store.  User Profile Manager's method is to scan the registry for changed settings and then write these settings to the user store DAT file on the network share.  Thus User Profile Manager 'merges' these changed settings into the user store instead of categorically copying back an entire DAT file over any previous DAT file at each logoff.  Thus different sessions being logged off will have their net changes written back to that central DAT file.  Goodbye to last write wins!

User Profile Manager provides an easy and reliable way to manage user personalization settings in Windows environments (the user's profile).  A user's profile consists of registry settings (stored in HKEY_CURRENT_USER) along with the files and folders (favorites, My Documents, cookies, Application Data etc).  The purpose of this article is to provide an overview and some details around User Profile Manager.  This will provide you enough to understand its core propose and for preparation to take a deeper dive into the technology.  The Technology Preview is available today for download (go here for links to the download site, Technical FAQ and other related items). 

User Profile Manager is a Windows service that monitors the logon and logoff process.  That means any user that logs onto a Windows environment with this service will have their profile managed by User Profile Manager.  E.g. installing the service on a XenApp server will enable all the users with sessions on that XenApp server to have profiles managed by User Profile Manager.

Let's start with the core files that are installed.  The MSI package (one for 32-bit platforms and one for 64-bit platforms) installs a Windows service (UserProfileManager.exe), two DLLs for Windows XP and Windows Server 2003 (upmHook.dll and upmLogonMonitor.dll) and some supporting files that I will cover a bit later (INI, ADM and ChangeLog.txt).  All of these are installed by default to \Program Files\Citrix\User Profile Manager.  Once installed, a new service will be listed (in the MMC Services plug-in or in Computer Management under Services) called Citrix User Profile Manager.

The service receives its configuration defining which users and what to manage in these users' profiles through a Group Policy Object (GPO) or an INI file.  The service will first read the GPO for its configuration and then check the INI file for any settings not configured in the GPO.  Typically you would use one or the other to manage configurations.  INI files are great for simple pilots and evaluations.  GPOs will offer better manageability and scale as you move into larger production deployments.  If neither the GPO nor INI exists, User Profile Manager will just manage the registry (and thus ignore any files or folders in the profile).  Please note that once you install User Profile Manager it will begin working using a default configuration (based on the INI files that were installed).

The INI files are installed in the target directory with an initial configuration.  There are two types of INI files installed: v1 (Windows Server 2003 and Windows XP profile) and v2 (Windows Server 2008 and Vista profiles).  Also installed in the same directory is the ADM template to be imported into your policies for creating User Profile Manager GPOs.

By virtue of these INI files, User Profile Manager works out of the box with a base configuration (HKEY_CURRENT_USER, My Documents, Favorites, Cookies, Desktop and Application Data etc - just read through the INI files for the full details).  This also means that if you choose to use or move your configuration to GPOs, you should delete or rename these INI files to avoid inadvertently having settings applied.  These INI files can be used as a starting point for your configuration and as a template for your GPO settings.

Once User Profile Manager is installed and a user logs onto that computer, User Profile Manager will manage the user's profile (registry settings, files and folders).  Within GPO settings the administrator has granular control over which users utilize User Profile Manager through AD Groups.  If the user does not belong to the specified AD Group, User Profile Manager will just ignore the user.  By default, all users (including local accounts) are managed and administrators are ignored (also can be configured in GPOs). 

Upon logoff, any net changes within the profile will be copied back to the central share (and only items that have changed).  The user's settings (DAT files, files and folders) are all centrally stored on the network in their defined HOME directory (which can be configured to be any UNC path).  The user now has all their settings and profile data (as defined in the configuration) following them reliably and consistently throughout their sessions.

Stay tuned as I will follow up this article with one that will dig deeper into how the registry settings are handled (NTUSER.DAT) in order to alleviate the 'last write wins' challenge.  As well as a look at how files and folders can by optimized to mitigate the 'extra baggage' challenge creating profile bloat issues (trust me, a bloated profile is not a pretty thing).

I look forward to any and all feedback on your experiences with this Technology Preview.

Are you interested in running Autodesk products on Citrix XenApp (previously known as Presentation Server)? If you do, please read on.

Citrix and Autodesk have been working together to make sure our products can work well together. It's exciting to work in this project because both Autodesk and Citrix users can really benefit from such efforts.

AutoCAD Map3D 2009 is now Citrix-ready for XenApp. It is the first fruit of this effort. And if successful, you can expect more Autodesk products to become Citrix Ready. If you like the direction we are going, I'd appreciate your help by giving us feedbacks.

The joint site is at http://www.citrixandautodesk.com/. You can find useful information such as installation guide, FAQ, sales contact etc.
There are some post-installation changes you will need to make after installing Map 3D on XenApp. To make it easier, I wrote a script to automate such steps. The up to date script can be found here.

I created a short video demo of map 3D running on XenApp.

Click here to see all of my videos.

I'd love to hear from you about your experience running map 3D on XenApp including the script and what other Autodesk applications you would like to run on XenApp or other Citrix products. I will try my best to answer your questions.

At the recent Citrix App Delivery Expo in Sydney, Australia, Michale Harries (AKA Dyson), Steve Parry and Adam Jacques have a virtual meeting in Second Life. "Dyson" and his team deliver applications inside this virtual world.