• View Communities
    • Citrix Developer Network
      The place for unfiltered straight talk on Citrix products. Blogs, code downloads, best practices, APIs, and more can all be found here.
    • Citrix Ready Community Verified
      Does it work with Citrix? Application compatibility questions are a thing of the past with the new Citrix Community Verified site.
    • Blogs
      Learn the latest from the Citrix employees who are building application delivery infrastructure technologies.
    • Blogosphere
      The Citrix Blogosphere is a window into the thousands of conversations taking place about Citrix and Application Delivery.
  •  Sign In
The Citrix Blog
Blogs for tag 'profile management'

Permalink | Twitter Post to Twitter | Comments (9) | Views (1330) |

posted by David Wagner

While a mandatory based profile solution was the original approach (something we leveraged in the earliest releases), we are not going to return to that method. Let me explain why and get your thoughts and opinions on this.

One request that has been commonly voiced has been around a mandatory style implementation. While previously we had leveraged a mandatory profile as the base, for many reasons we moved away from that approach. One key reason was to save time that the merging process required (the copying of the mandatory down first and then copying of all the net changes). All in the spirit of logon speed. Another key reason is that it really was not a mandatory profile anymore. Profile management captured all the net changes from that base mandatory. So no settings were enforced or re-written at next logon. Basically it was a holder of starting settings when a profile was loaded. But the net changes were always re-applied over the base so nothing was ever enforced. So in the end, you needed to leverage Group Policy to enforce any permanent settings anyway.

It's also been explained that having a mandatory approach enables customers without Group Policy delegation to have a means to control the profile settings. And mandatory by itself is a great solution albeit the limitations on the breadth of personalization - which the amount of personalization afforded by a mandatory solution is probably adequate for many scenarios. While you can redirect folders like My Documents, Favorites, Cookies and others, the ability to change anything registry related is prevented e.g. wallpapers, application configurations and such. But if you try to combine this with something like Profile management to enable those changes, how are you going to restrict what does not get saved? You would need to create an exclusion list of all the settings you want enforced (and thus excluded from being saved). Doable on a few settings but it will get unwieldy really fast. And I am willing to bet it's going to be harder than Group Policy to manage before long. In the end, it seems capturing all the settings and using Group Policy to enforce setting as required is the way to go and thus the direction for our profile management solution.

Finally, let's address the capability of having a base profile to start with. We do offer a template profile capability which you could think of as a Global Default User profile. When a user logs onto Windows and does not have an existing profile (be it local, mandatory, roaming or TS), Windows creates a new profile for that user based on the Default User profile located on that current machine. The fun of this is unless you want to sync all the Default User profiles across all the machines a user might likely log onto for the first time, the starting profile will different (although often only slightly) from user to user. Might not be a big deal initially or on smaller scales, but will be more problematic as your environment expands and grows.

The purpose of the template profile is to enable a consistence starting point for a new profile being created no matter the machine. The template profile can leverage a copy of the mandatory profile you use today but you just need to rename the NTUSER.MAN back to NTUSER.DAT (so no you can't use the same one as both the template and a mandatory). And the template profile has to be complete (e.g. the entire directory structure and NTUSER.DAT). Also keep in mind that this is used for profile creation. So changing the template is fine, but only affects new profile being created and not existing ones. Need to change or enforce a setting for all users? Then we are back to using Group Policy for those situations.

So that is where we stand today with our Profile management feature (a feature of both XenApp (Enterprise and Platinum) and XenDesktop (Advanced, Enterprise and Platinum). Of course this is always open to debate and discussion if you have scenarios that illustrate weaknesses to this approach that Citrix should pay more attention to addressing.

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (4) | Views (1585) |

posted by David Wagner

You may already know about this feature as it was previously called User Profile Manager. Profile management is the new name for User Profile Manager. This technology is a feature of both XenApp (Enterprise and Platinum Editions) and XenDesktop (Advanced, Enterprise and Platinum Editions). For a more detailed overview of what Profile management is and how it works to improve application virtualization, please read this article. For this article I will focus on the improvements in this updated feature that will first be available in XenApp 5 Feature Pack 2.

The improvements added into this release have focused around improved logging, Citrix product line integrations and Windows 7 support (really just testing and validation as the profile mechanism did not significantly change in this release from Vista and Windows Server 2008). And of course we have fixed many of the known issues and support concerns.

We've introduced EdgeSight counters to add visibility into the logon process and activities. Here is a summary of the counters that are provided:

  • Logon Duration - this is the total logon time.
  • Local Profile Setup Duration - aka the time to set up the user's local profile. Basically this compromises of the following steps:
    • Does the user have a local profile - if not create one
    • Is a profile migration required? If so migrate the profile
    • The time to copy down files from the user store to the local profile location
    • Synchronize with user store. This is only needed at logon for a new profile. While a Microsoft roaming profile copies a new roaming profile back to the network at logoff, Profile management performs this activity during that first logon.
    • At this point Profile management gets notified that this profile is ready to be managed
  • Time to Start Monitoring - this is the gap from the last step of notifying Profile management that a profile is ready to be monitored and until monitoring actually starts (meaning the user is allowed to start their session). This consists of processing the NTFS change journal entries (basically a start point for monitoring file changes). The purpose of this counter is to help narrow the area causing longer than expected logon times. This should be fairly short time period and if not, you know something is happening out of the ordinary here. How short should it be - defining your baseline will provide you that measurement.
  • Logoff Duration - this is the total logoff time
  • Stop monitoring profile - NTFS change journal processing. This time should be very short
  • Logon Bytes - total bytes in the user's profile copied down at logon
  • Logoff Bytes - total bytes from the user's profile copied to user store at logoff
  • Processed Logon Files - total number of files in the user's profile copied down at logon. How many files and their respective size grouping.
  • Processed Logoff Files - total number of files from the user's profile copied to user store at logoff. How many files and their respective size grouping.

We also focused and extended on XenDesktop and Provisioning Server testing and validation. A key aspect of this was the new log file redirection capability. Now administrators can configure the log file to any local drive instead of the default %WINDIR%/system32/LogFiles/ location. This addressed the critical issue of capturing a log file from a local drive that is reset at logoff. The log file being just another changed file from the session is thus lost when system is reset at logoff.

I also would like to add clarification around the extended synchronization capability. Extended Synchronization was introduced in the User Profile Manager v2.0 release. It become apparent we were not clear enough in the context of its purpose and often it was being leveraged beyond its scope and ability. It was designed to enable personalization settings that are not properly stored in the user's profile location to be captured as part of the user profile. So-called "bad applications", for example, store settings in non-standard locations. However, the capability was not documented clearly in the Version 2.0 administrator's guide, which resulted in attempts to use the feature in ways for which it was not designed. We have clarified the supported scenarios in this release.

Extended synchronization is not intended to manage multi-user access to these files or folders (for example, we are not compensating for an application that is not multi-user aware). Nor is it intended to become a file and folder synchronization mechanism (for example, one that allows you to synchronize the entire contents of c:\docs across machines). It is intended purely to extend personalization settings that exist outside the default user profile location and thus provide a consistent experience across all resources accessed by the user.

This latest version (2.1) will be available for download on September 29th 2009 via MyCitrix. So now that you know a little more about Profile management, I recommend you check back on the 29th to MyCitrix and grab a copy (logon required) to evaluate and consider for your environment. Please note that it is important to review the current profile technologies available and ensure a good match with your business needs. There are a broad range of solutions and ensuring a good match is critical in order to properly balance the administrative needs with user personalization needs. You should review this best practices guide covering profile options such as mandatory, roaming and of course Profile management.

Finally, if you would like to learn more about Citrix XenApp 5 Feature Pack 2 here are some useful links:

Follow XenApp on | | |

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (6) | Views (4489) |

posted by Bill Powell

When you're setting up a User Store for Profile Management, you configure the location in the GPMC under "Path to user store" (as described in http://support.citrix.com/article/CTX118944 ), and in the simple case, that's a single location, such as \\server1\profiles . 

(Actually, you'd also include the username and probably the userdomain variables as well, and a system environment variable to indicate the profile version or platform e.g. \\server\profiles \ %USERNAME%.%USERDOMAIN% \ %ProfVer . However, it all gets very verbose, and I'll assume you can add these bits yourselves in the discussion below.)

Anyway, we've had a couple of requests recently on how to load-balance User Stores for Profile Management across multiple servers, and we came up with a couple of approaches which might be helpful generally.

A couple of reasons for load-balancing came to light:

  • simply to balance the load across several servers
  • where an organisation operates several datacenters, each serving one or more geos.

The customers didn't want to use DFS, because they recognised that replication would take place of all profiles between all DFS servers, which would waste bandwidth. I seem to recall that Microsoft doesn't recommend DFS for storing profiles, anyway.

One administrator asked if he could use %homeshare% on the assumption that %homeshare% ought to reference a local server.  No, because %homeshare% is a user environment variable, and Profile Management can't see user environment variables ... but AD does have a property #homeDirectory# which holds the same information.  So if you're OK to put profiles on the same share as the users' HOME directories, configure the "Path to user store" as #homeDirectory#\profiles

The other approach is more general, and may require some AD configuration and/or some DNS hackery.

If you can find an AD attribute, such as #c# (country) or #l# (location - that's #L# but lower case), then the job may be easy - just set the "Path to user store" to \\FileServ#c#\profiles (say) - this should expand to \\FileServUS\profiles or whatever your country happens to be.  Similarly #l# could be used, but if your office is in "Ashby de la Zouch" or "Llanfairpwllgwyn..." (you know the place I mean, in Wales) that may cause grief when used as part of a server name!

So if there are spaces or just a very long name, you'll have to get your AD admins to create and populate a new attribute, such as #geo#

What if you've got a #l# attribute, short, with no spaces, but you want to map several different values to the same server?  In Citrix, for example, we have several geographically close offices sharing a single datacenter, and some offices which have had different names in their history, e.g.

Chalfont (CHF), High Wycombe (HW), Gerrards Cross (GX) and even London (LON) all actually refer to the same office, so \\FileServ#l#\profiles will expand to

\\FileServCHF\profiles or \\FileServHW\profiles etc...

The trick here is to configure multiple names in DNS with the same IP address, so that, regardless of what's configured in #l#, it all maps to the same physical server.

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (2224) |

posted by Vinny Sosa

XenApp Expert Series - Profile Management Part 1 - Informational, News, Interviews (2009) The show where we interview the experts to get you the latest research and technology news on XenApp application virtualization. Host Vinny Sosa (@vinnysosa) interviews Citrix Product Manager Dave Wagner on the Profile Management feature of Citrix XenApp and XenDesktop and why this is key technology in the application and desktop virtualization stack. This is part 1 of 2 where we will bring Dave and/or another expert in to dive deeper into Profile Management. Episode 2, Season 1.

ADDITIONAL BACKGROUND: My intro would have been funnier but I totally screwed it up. I have a strict one take policy on the show though so it stayed as is. Dave is a great character. He has been with Citrix for 8 years 6 months 15 days and 7 hours by the start of this recording. While here, he has managed a number of products including Access Essentials, MetaFrame for UNIX, Conferencing Manager, MetaFrame x64, Desktop Broker/Server, Password Manager, Profile management, Web Interface, and the Linux Client. He doesn't have a Twitter account (yet!). He says he's still too busy jumping on the JAVA/Linux Desktops/Webify Everything bandwagons. After which he needs to jump on the Facebook bandwagon. He loves photography followed closely by video games ... xBox addict at the moment but that usually shifts around every few months. Why? He says he likes video games primarily because it annoys everyone else to think that it's a total waste of his time. Join us for this interesting episode with David Wagner.

Listen to this episode

Follow XenApp on Twitter

Download XenApp technology previews

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (2106) |

posted by Vinny Sosa

XenApp Expert Series - Profile Management Part 1 - Informational, News, Interviews (2009) The show where we interview the experts to get you the latest research and technology news on XenApp application virtualization. Host Vinny Sosa (@vinnysosa) interviews Citrix Product Manager Dave Wagner on the Profile Management feature of Citrix XenApp and XenDesktop and why this is key technology in the application and desktop virtualization stack. This is part 1 of 2 where we will bring Dave and/or another expert in to dive deeper into Profile Management. Episode 2, Season 1.

ADDITIONAL BACKGROUND: My intro would have been funnier but I totally screwed. I have a strict one take policy one the show though so it stayed as is. Dave is a great character. He has been with Citrix for 8 years 6 months 15 days and 7 hours by the start of this recording. While here, he has managed a number of products including Access Essentials, MetaFrame for UNIX, Conferencing Manager, MetaFrame x64, Desktop Broker/Server, Password Manager, Profile management, Web Interface, and the Linux Client. He doesn't have a Twitter account (yet!). He says he's still too busy jumping on the JAVA/Linux Desktops/Webify Everything bandwagons. After which he needs to jump on the Facebook bandwagon. He loves photography followed closely by video games ... xBox addict at the moment but that usually shifts around every few months. Why? He says he likes video games primarily because it annoys everyone else to think that it's a total waste of his time. Join us for this interesting episode with David Wagner.

View this Episode and Subscribe to the XenApp Expert Series

Follow XenApp on Twitter

Download XenApp technology previews

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (3271) |

posted by David Wagner

I thought I would share some useful links that I tend to end up emailing around. Also a couple links to a some really useful tools for User Profile Manager (brought to you by our friends at Sepago).

First is a migration tool that enables customers to migrate from the sepagoPROFILE profile format to User Profile Manager v2 format. It also lets customers migrate from the Tech Preview version of User Profile Manager (as both the Tech Preview and sepagoPROFILE releases were based on a mandatory profile). Details and the tool are here: http://blogs.sepago.de/tools/category/citrix-user-profile-manager-migration-tool/

Next is a tool that helps prune your profiles of old or unwanted data. One of the biggest challenges with Windows profiles is removing unwanted items. All those registry settings or APPDATA files after an application is removed or just no longer used. Or perhaps some settings were captured unintentially and now you want to get them out of all your users' profiles. Let me introduce you to the ProfileNurse (stop your smirking) – full details and the tool can be found here: http://blogs.sepago.de/tools/category/profilenurse/.

While ultimately we will like to see this capability as part of the product, for now this nice tool helps fill this gap. Available operations in ProfileNurse include:
*Creating and deleting registry keys and values
*Altering registry values
*Deleting files or folders
*Copying files or folders into user profiles

And here is the basket of other links I've found useful:

General
http://www.citrix.com/upm Main Page with links to downloads (downloads are actually under XD and XA product sections)
https://www.citrix.com/English/ss/downloads/results.asp?productID=186 XA download page (Under Components and Evals)
https://www.citrix.com/English/ss/downloads/results.asp?productID=163057 XD download page (Under Components and Evals)
http://forums.citrix.com/category.jspa?categoryID=163 Support Forum

Product Docs
http://support.citrix.com/article/ctx118943 Admin Guide
http://support.citrix.com/article/ctx119791 Technical FAQ
http://support.citrix.com/article/ctx119747 Licensing FAQ
http://support.citrix.com/article/ctx119466 Logon/Logoff Chart
http://support.citrix.com/article/ctx119039 Cross Platform Considerations FAQ
http://support.citrix.com/article/ctx119038 Troubleshooting FAQ
http://support.citrix.com/article/ctx118944 Group Policy Template Reference
http://support.citrix.com/article/ctx119186 Using with XenDesktop
http://support.citrix.com/proddocs/topic/xenapp/upm-xa-wrapper.html Using with XenApp

Best Practices
http://support.citrix.com/article/CTX119036 Best Practices
http://support.citrix.com/article/ctx120285 User Profile Best Practices (XenApp 5)
http://support.citrix.com/article/CTX110351 User Profile Best Practices (CPS 4.5 and prior)
http://support.citrix.com/article/CTX114884 - Password Manager Best Practices

Overview
http://community.citrix.com/x/AoEAAg (overview and insight on UPM)
http://community.citrix.com/x/OIENAg Last Write Wins
http://community.citrix.com/x/A4AaAg Profile Bloat
http://community.citrix.com/x/SIOZAg UPM and Office Settings
http://community.citrix.com/x/HYXuAg Improve logon speed?
http://community.citrix.com/x/AwBeAw Differences from Tech Preview and v2
http://community.citrix.com/x/8ICsAw Using GPOs
http://community.citrix.com/x/3IGiAw Quick Setup Guide

Sepago
http://blogs.sepago.de/tools/category/adm2html/ - ADM to HTML
http://blogs.sepago.de/helge/2009/01/23/citrix-user-profile-manager-released-user-store-design-recommendations/ - User Store
http://www.sepago.de/citrix/upmwhitepaper.html Sepago White Paper
http://blogs.sepago.de/helge/2009/02/25/citrix-user-profile-manager-how-registry-exclusion-lists-can-mess-up-group-policy-processing/

Microsoft Office:
http://technet.microsoft.com/en-us/library/cc768089.aspx - Configure Outlook settings
http://office.microsoft.com/download/afile.aspx?AssetID=AM102105061033 - Outlook 2007 setup automation
http://office.microsoft.com/en-us/ork2003/HA011402061033.aspx - Office installation recommendations
http://support.microsoft.com/kb/926805/en-us - Office 2007 Toolbar settings
http://office.microsoft.com/en-us/ork2003/HA011402691033.aspx - Recommended strategies for Outlook roaming

Microsoft Profiles
http://technet.microsoft.com/en-us/library/cc784484.aspx - Best Practices for Roaming Profiles
http://technet2.microsoft.com/windowsserver/en/library/fd81008e-269a-4155-b81a-752242bec9ff1033.mspx?mfr=true - User Profiles Overview in User Data and Settings Management
http://technet2.microsoft.com/windowsserver/en/library/fd81008e-269a-4155-b81a-752242bec9ff1033.mspx?mfr=true - Folder Redirection Overview
http://blogs.technet.com/neilcar/pages/247903.aspx - SMB/CIFS Performance Over WAN Links
 
Microsoft
http://msdn.microsoft.com/en-gb/library/ms675090.aspx AD Attributes
http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx - AD Explorer

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (3221) |

posted by David Wagner

An update to User Profile Manager was released a few weeks ago (v2.0.1). This contains fixes and improvements for some known issues such as:

  • Support for the user variables %USERNAME% and %USEROMAIN%. This enables explicit paths to be defined for users when supporting multiple domains
  • Profiles are now migrated properly when defined by the GPO "Set path fopr S Roaming User Proifle"
  • Addressed the issue of unresponsive logons in certain cases with cloned images or provisioned shared images
  • Resolved the issue with default registry exclusions and the conflict it created with Windows caching of group policies

The full details are here: http://support.citrix.com/article/CTX120967

The documentation when using with XenApp is located here: http://support.citrix.com/proddocs/topic/xenapp5fp-w2k3/upm-xa-wrapper-v2.html

And the documentation when using with XenDesktop is located here: http://support.citrix.com/proddocs/topic/xendesktop/upm-xd-wrapper.html

This updated install package completely replaces the previously posted package (and thus the old one is no longer available). You may run this install on existing deployments and it will upgrade your service. As well as use it for a fresh install. BUT defintely upgrade any existing installs before rolling out this new version since you do not want to mix the versions in your deployment (and thus have some services that recognize variables like %USERNAME% and some that do not). I assure you it would not be a very pleasant experience. The UserProfileManager.exe binary version is 2.0.1.48.

The ADM template was updated but it was just helper text updates. Basically calling out items like the added support for %USERNAME% and %USERDOMAIN%. So you do not need to update the ADM template unless you want to read the new helper text or just enjoy updating ADM templates. Or you can just open up the ADM file in your favorite text editor and scroll to the end and read it there.

On a side note here are some links to the main page, support forum and XenApp/XenDesktop download site (you need to be logged on to MyCitrix to see the downloads – and it is the same download so pick either product and look in the in the Evaluations and Components sections). And yes, the official name for this is Profile management which you will see reflected in the next release.

Main Page http://www.citrix.com/upm
XA download page https://www.citrix.com/English/ss/downloads/results.asp?productID=186
XD download page https://www.citrix.com/English/ss/downloads/results.asp?productID=163057
Support Forum http://forums.citrix.com/category.jspa?categoryID=163

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (1) | Views (1089) |

posted by John Carthy

I thought I would let you know about a little gotcha that I bumped into this issue yesterday.

So you are using Citrix User Profile Manager (a.k.a Profile management), you have installed it on machines running on VMware, (possibly in your XenDesktop or XenApp set up) probably because no-one has told you that you can get XenServer for free! 

You have your User profile Manager GPO settings to delete the cached local profiles when the user logs off, only they won't.....

...read on.

I had VMware tools installed on my XenApp server running on ESX 3.5 (I have some on XenServers too, I have make this clear before the XenPolice come and get me...)

I had installed the tools using the complete install. Little did I know that with a roaming profile of any variety this can cause issues. The "Shared Folders" option in VMware tools put a little file in your users profile, which gets locked by a running process. Consequently if you have a GPO set up to delete the users profile at log off, the system can't because of this pesky little file, namely;

C:\Documents and Settings\userid\Application Data\VMware\hgfs.dat

Your Profile management log (C:\Windows\system32\LogFiles\User Profile Manager\UserProfilemanager.log) will probably have an entry in it like the following: (if you have all the log options enabled in your GPO that is!)

2009-06-03;11:44:31.456;ERROR;PCNAME;johncarthy4;3;3640;DeleteDirectory: Deleting the directory <C:\Documents and Settings\johncarthy4\Local Settings\Application Data\VMware> failed with: The directory is not empty. 

Here's the quick fix:

1. If its XenApp log all your users off the server, preferably politely, send a warning message or if your feeling particularly ruthless a quick "session reset" will surely get them ranting at the helpdesk...

2. Login as an Administrator go to Control Panel - Add remove Programs.

3. Find VMware Tools and choose the "change" option.

4. Change the "shared folders" to "This feature will not be available".

5. Click "next", Click "Modify" and click "finish".

6. Restart the server / PC and now it's a good time to clean up those half deleted profiles.

7. Its best to use the My Computer - Properties - Advanced - User Profiles and select the remnant profiles and delete from here, this way you will always see any issue as Windows will kindly inform you of any difficulties by means of an error message...


Now I also found this to be the case on an XP vm that I had running on the same VMware server. The bizarre thing is that even if you click over the tools icon next to the clock, and check the settings, it said that the shared folder option was disabled, herein lies the difference, you will still see this issue even if the system is set to use Shared Folders, you just have to make sure it isnt installed at all.

Here's the other slightly longer fix:


1. Download XenServer.

2. Install your VM's on that.

3. Install Profile manager.

 

I hope this helps some of you. 





















 

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (2) | Views (4194) |

posted by Vinny Sosa


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.

Resource
Description
XenApp's Profile Management feature
HOLD THE MOUSE cowboy. Before you move down the list, you need to read this. Profile management helps you prevent profile bloat. That's a given. You can read all about it at Dave Wagner's blog. However, profile management has a great utility called verbose logging and it's amazing! You turn it on and install an application. Then run the application as a user. You open the log and you have a list of every registry key and file that was written or touched (it's like regmon and filemon in one, just not as pretty). This is great for checking if the app is writing to HKLM or trying to overwrite a DLL or read-only file. Profile management is available in Enterprise and Platinum edition. Open the admin guide by clicking the link and then go to page 28 to see how to activate verbose logging. BUT WAIT... there's more. Profile management let's you include and exclude profile components. So, if an application is writing user settings to a global file somewhere it might be possible to copy it into the users profile for persistence between sessions and OS's. You owe it to yourself to check it out. (BTW... to help you shrink already-bloated profiles, check out profile nurse - free from Sepago)
App compat toolkit
The application compatibility toolkit is a step by step process for validating applications on XenApp. It utilizes best practices and a virtual environment to help make the process easier.
Citrix Ready. Community Verified.
This is a great resource for checking to see if other Citrix customers or partners have had experience with your application(s) and if there are some pitfalls you can avoid. Another great thing about this site is that it also covers hardware compatibility for things like printers. Please contribute if you can. It's only as good as the community makes it.
Terminal Server Microsoft KB Listing project
The holy grail for administrators and developers. It begs the question... Is there such a thing as too much information? Here, Jim Kenzig lists every single article he could find on developing, securing, troubleshooting, yada yada yada for applications running on Terminal Services.
App DNA
OK, so it's a 3rd party and it's for charge but if you're sufficiently in a jam and have nowhere else to turn, chances are these guys can help. If I were a customer though, I'd leave all the messing around here to my resellers/solution advisor because if you haven't figured it out by this point it's probably worth paying someone else to do so.

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

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (3) | Views (9681) |

posted by Bill Powell

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!

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (7462) |

posted by Jo Harder

You may have noticed that Citrix released its XenApp and XenDesktop feature called Profile Management in late January and we mentioned it again as a part of the XenApp 5 Feature Pack announcement that went out on February 23rd. As you read through the documentation, you may be asking yourself, "What's in it for me?  How will it benefit my organization?"

First, profiles is a subject area that administrators don't love.  Don't even like.  And, based on my field experience in Citrix Consulting, I'd say that at least 75% of all administrators don't fully understand profiles, although they're a necessary part of a successful IT infrastructure.  If you're looking for some basic information on profiles that's easy to understand, check out CTX120285.

Secondarily, as you consider profile management, ask yourself whether the standard Microsoft solution, i.e. local, mandatory, and roaming profiles, as well as Terminal Service mandatory and roaming profiles, will address your organization adequately. There's no sense in fixing something if it isn't broken, right? When addressing a profile decision, the solutions architect should consider not only the technical factors, but also the business aspects. Can and will the administrators maintain anything other than a standard Microsoft solution?  If you can't answer with a firm yes, then you can bet that the profile solution will become a mess within several months of the implementation.

So, where does XenApp and XenDesktop's Profile Management feature fit?  Basically, where the standard Microsoft solutions don't address your requirements AND where you can get consensus from your teams to stick with a non-Microsoft solution over the long run. If you can satisfy those two key requirements, then Profile management will be a great solution for IT and for your users.  For example, if users access XenApp hosted apps hosted from multiple servers or farms, last-write-wins issues can cause users to become dissatisfied (okay, downright angry).  Some standard options to address this are Terminal Services mandatory profiles and multiple roaming/mandatory profiles. If these solutions have proven unreliable or inconsistent and are just causing problems for you and your users, then Profile management is what you need.  If mandatory profiles work for you, then life is good.  If you've ever looked into how to implement multiple roaming/mandatory profiles, your head may spin - plus it may not definitively address your needs. Now consider the maintenance aspect. Here's where Profile management really shines.

Some use cases for Citrix Profile Management are:

  • User accesses multiple XenApp server silos or farms and opens multiple sessions that cause last write wins issues
  • User accesses multiple desktops, including XenDesktop where their user settings won't otherwise be carried over to additional desktops, especially where the OS is different
  • Roaming profile corruption issues are rampant

Before implementing Profile management, review the following environment considerations:

  • Going back to the Microsoft profile solutions, have you considered folder redirection? If you can redirect folders such as AppData and Documents and suffice with mandatory profiles, simple is good.
  • Because Citrix Profile Management will take control of the user profiles based on OU, will another administrator attempt to configure Microsoft-based profiles and wonder why they didn't work?  One administrator has to know what the other administrator is doing.
  • Although installation and management of Citrix Profile Management isn't difficult, how will maintenance be addressed?  For example, will installation of Citrix Profile Management be incorporated into the base XenApp server build? If not, the Profile Management service won't be available and started on new servers.

Is Profile management a great solution? Yes. Is it a silver bullet for every situation? Quite honestly, no. There are some considerations and maintenance aspects of Citrix Profile Management but where it fits these niche requirements and environment, it totally rocks! 

Want to learn more? Check out information regarding implementing Citrix Profile Management (CTX118943) or Best Practices for Profile Management (CTX119036). Also, take a look at Citrix.com/upgradetoxenapp5. Stay tuned for weekly blogs on XenApp 5 Feature Pack. As always, let us know your thoughts, questions and feedback below.

This post is part of a multi-part series on XenApp 5 Feature Pack:


Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (5613) |

posted by Bill Powell

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.




Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (4) | Views (9127) |

posted by David Wagner

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.

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (14) | Views (23574) |

posted by David Wagner

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

Expand Blog Post