Post to Twitter |
Comments (9) |
Views (1906) |
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.
Comments (9)
Oct 30
Claudio Rodrigues says:
Just a note. It is not true that a profile is created only based on the Default ...Just a note. It is not true that a profile is created only based on the Default User one located on the local server.
If a Default User folder exists in the NETLOGON share all machines will get that one when creating a new user profile, therefore the argument that you must manage every single server individually is not correct. You can read more about this here.
http://support.microsoft.com/kb/168475
If this is good or bad or if it makes life easier or harder is up for discussion.
But that you can indeed manage ALL Default User profiles from a single network location, that is a fact.
Oct 30
David Wagner says:
Thanks Claudio, Although the article does not call out Windows Server 2003 or 2...Thanks Claudio,
Although the article does not call out Windows Server 2003 or 2008, I suspect this is still suported on those OS version as well? That being said, it sounds like te only difference then between the template profile and this approach is where the default profile is stored (netlogon versus UNC path), correct?
Oct 30
Claudio Rodrigues says:
Yep, it still applies. I just finished working on a 2003 environment where that ...Yep, it still applies. I just finished working on a 2003 environment where that was the case. Comparing to the template profile, the UNC path seems to be the difference.
Note I do hate having that on the Netlogon share for several other reasons. But technically it is an option.
Oct 30
Helge Klein says:
The problem with Windows domain default profiles is that there can only be one d...The problem with Windows domain default profiles is that there can only be one default profile per domain. Since there are almost certainly different machine types (clients, TS, ...) in each real-world domain, Windows domain default profiles effectively cannot be used.
With UPM, templates (aka defaults for new profiles) can be assigned per OU, in other words per machine type. With that simple change the (good) idea of having centralized defaults is finally usable.
Oct 30
Stephen Greenberg says:
I am a little confused by this, are you saying that going forward UPM will actu...I am a little confused by this, are you saying that going forward UPM will actually rely on the roaming profile to store the personalization? If so, what exactly is the interaction between UPM and the profile itself? Is it flitering what gets written to the romaing profile? Is is separately storing pre-defined settings outside of the roaming profile? I am not clear on what and how this is being managed in the case of a roaming profile, i.e. where UPM picks up and where the roaming profiles ends....
Steve Greenberg
Oct 30
David Wagner says:
Hi Steve, While the mechanics of the way profile management operates are simila...Hi Steve,
While the mechanics of the way profile management operates are similar to a roaming (meaning the profile is a complete profile and not a base component plus a net changes component), we've initially addressed two of the more common challenges with a roaming profile (issues that are particularly visible in virtualized enviroments). Last writer wins and the profile bloat issues -- the all or nothing method that roaming does when capturing the profile and when redirecting directories -- commonly affecting AppData areas of the profile. Here are some links that cover a more general overview as well as sepcific on last writer wins and bloat:
http://community.citrix.com/x/AoEAAg - Overview
http://community.citrix.com/x/OIENAg - Last writer wins
http://community.citrix.com/x/A4AaAg - Profile bloat
Oct 31
Anonymous says:
David, So an unansered question above from Steve was do you actually rely on Mic...David, So an unansered question above from Steve was do you actually rely on Microsoft's roaming profile technology are is C UPM independent?
Nov 02
David Wagner says:
We do not leverage Microsoft's roaming profile. We just operate in a similar ar...We do not leverage Microsoft's roaming profile. We just operate in a similar architecture – e.g. the user profile is stored on the network in what we call the user's store (can be their home drive or any UNC path).
So if the user had a roaming profile and you configured that profile to be migrated for use in Citrix's Profile management, after it was migrated you would still see the roaming profile in it's original location as well as now the user would have a Citrix profile for use with our feature.
Nov 01
Anonymous says:
With the increased complexity of User Profiles, particularly under the comprehen...With the increased complexity of User Profiles, particularly under the comprehensive heading of "User Virtualization" (everything-User-related being virtualized in its own portable "bubble'), it's now more important than ever to find a complete Profile solution. We're finding that third-party add-ons are worth their weight in gold (as are Printing solutions) in any implementation of any significant size (e.g., more than, say, 3 Citrix servers). For ease-of-use, total User management, and (in some cases) additional terrific features, these third-party solutions are outstanding... AppSense's "Environment Manager" comes to mind... even allows for Security features on a per-App or per-User (or OU) basis...
As a comparison, imagine managing your VMware environment without the benefits of, say, the Vizioncore suite of tools... Work smarter, not harder... And once demonstrated to the Customer, these tools and add-ons are -- I've found -- not a hard sell at all.
Add Comment