Everything you always wanted to know about Scense but were afraid to ask

Menu

User Profiles (and the way we have to live with them)

Most of you reading this will recognize this situation:
Finally the long awaited IT infrastructure upgrade budget is granted and you can start thinking about the way some details will be handled. The big scopes, like which iron (servers, storage, inhouse or in the cloud) are going to be used are known, but when focusing on the desktop the most detailed choice made is: We have laptops and a RDS/VDI/Citrix/… platform. And it has our business apps. And it has to be fast!

Whow. Not that much to care for, right?
How hard can it be? We are going to use Windows and all our apps are supported, we know. Deployment of the applications and personalizing the desktop (populating the start menu, background)… Simple, as we of course use Scense for that (hey, you are reading my blog), but I accept if you borrow the knowledge gathered here for other management tools. You dig-in and start building the environment – COOL!

Do you know however that picking the optimal profile for your platform will have a huge impact on the logon experience for users. And with this logon experience comes the way you will have to configure or even deploy application(settings).

For example: If you roam only the profiles roaming part (HKCU registry and %AppData%), you will have to accept users will lose some settings or even applications (ever heard about OneDrive). These will have to be re-installed or configured every time a user starts the first time after logon, or might not be workable at all.

Most likely known knowledge, but to refresh all possible options:

Local profiles
The oldest user profile solution, from the time we had ‘our own’ desktop. Everyone came to work every day and used ‘their’ computer. No-one dared to (or was allowed) to use this machine and on that machine all personal settings were stored. As long as you are working on a single system this is a perfect setup. All personal data is present at logon and the profile is always matching with locally installed apps.

Roaming profiles
As larger companies had the need for flex-pooling resources a solution was needed to be able to incidentally work at some other desk. The profile was split in a ‘local part’, which stayed on the computer (or gets removed after logoff) and a roaming part, which contains all my personal preferences. Your background image of your kids, the favorites in your browser and documents.
The documents were quickly removed from the roaming part, as it reduced the biggest issue: long logon- an logoff times. These were redirected to your homedrive on the network.

Mandatory profiles
Even as roaming profiles were a gods gift for some, it was a burden for IT. Corrupted profiles as users did not wait till the profile were copied at logoff, and just 4-sec-powerbuttonpush shutdown triggers the next days corrupted profile. Also minute long logon times, limitations on data to roam and later on security leaks due to sensitive data in left-behind local copies of profiles triggered the need for something else. In tandem with profile management tools the mandatory, IT provisioned optimized profile, was implemented.
With it came hard to solve, or even explain, problems, like why the numlock-state was ‘always wrong’, or why personal certificates are not possible. Also IT had it’s issues, as the profile management tools to deploy the users settings have to be trained…

Network stored profiles (UPD, FSlogix, Citrix/VMware profile mgmt, …)
The latest breed of profiles is to have these stored and used from the network directly. Initial trials were done redirecting AppData to the network, which works fine during a POC with few users. But after deploying it company wide (>50 users) the fileservers started to complain. The solution was to put the files in a personal disk and redirecting there. The network load (bytes to transfer) was similar, but the advantage was the way files are accessed. Instead of having to create network handles all the time, for almost every file action, now this is locally handled.
These personal profiles are loaded/mounted in seconds, no matter how big they are and how many files are included. They are (able to) hold both the roaming as well as the local profile part.
Again this triggered another issue: How to access a disk with the user profile simultaneously from multiple systems, or if we have multi-site hosted datacenters…

If you read this you might get the impression that I am negative and nothing is ‘good enough’ for a corporate production environment. Partially I am, as the above does not give a singular solution that could be applied in every desktop environment. Stating that, let’s take a step back. What kind of desktop environments are nowadays used in business environments…?

Desktops (fat clients)
Even as these are not the most beautiful, these are still the ones you find in every company. They are the most economic desktops available. They exist in several versions:

Access device
Even if you have a virtualized environment, you still need something to connect your screen and keyboard/mouse to. Often these are either re-purposed desktop systems or Thinclients.

Dedicated power-machines
Graphical designers, developers and some other professions just are so special or require special hardware. These would not be helped with a ‘one-size-fits-all’ desktop. These are often personal machines with dedicated configurations.

Shared flex-workspaces
For those that come in and need access to ‘their’ company data, often some flex systems are available. Some companies even made this a philosophy. Those who come early can pick a favorite spot (most likely a corner one with the back to a wall for ‘privacy’). This way you auto-implement clean desk, uniform workstations and allow IT to apply upgrades fast, as all systems are identical.

Laptops
The ultimate ‘personal’ desktop. Your machine, always operational thanks to the built-in battery and nowadays even with always-on internet connectivity. The only problems are the ones that are lost. The next version of laptop will be the ultra-mobile devices that are communication device (phone), data consume device (tablet) and workspace (desktop) in a single device.

Centrally hosted desktops
IT always prefers to be able to manage systems easiest. Biggest advantage is data security, as sensitive data is only available in the datacenter itself. Also in case of disaster these can relatively fast be re-activated in a different DC. If it weren’t that these systems are by definition more expensive, as they not only need to be operational as hosted desktop, but you also need an access device.
There are 2 versions:

Dynamically assigned machines (floating pool, …)
In the last years the common belief is that a centrally hosted desktop (personal (VDI) or shared (RDS, XenApp)) is the best available solution. These offer quite some advantages, as they can be easily upgraded at night, as no-one is active then.

Personally assigned machines, often persistent
I would categorize these as (fat client) desktops, just not located under your desk…

If we try to merge the lists above we can identify 3½ workspaces:

Personal workspaces (dedicated power systems, laptops)
Why would we even want to bother to make our lives harder. These systems have a single purpose: help me do my work. These systems are so unique, that the information on these systems would not be usable on another system at all, so why bother to roam them? Ok, maybe have some backup of highly appreciated or hard to repair settings in case of a system failure, but for the rest: who cares?
A local profile would be the optimal profile in this case!

Centrally hosted desktops (VDI, RDS/XenApp)
In general there is only a single session per user (silo’s as exception) and these systems are hosted in the datacenter, with huge datahighways to the storage. So why not give them a profile on the storage system using personal disks? Perfect match (it seems)

Access devices
These should have a non-existing profile: The ‘no profile’ option…

Flex systems…?
This is where I wanted to talk about… All before is just introduction. I close this bullet 🙂

So… what is my advice for the flex systems…?
In general the roaming profile is not a bad solution. There is just this tiny issue: some application developers did not understand the difference for the ‘roaming’ part and the ‘local’ part.
Also technology grew in such a pace that nowadays even a simple document viewer is allowed to be of a size, that systems a few years back did not have as total storage for the entire system. Let’s not even discuss the complex applications or even games.

To re-iterate: The Roaming part should contain settings that you would like to have remembered after logging on to another system. Local is for cache, to make actions in this session on this computer faster, the next time I might need them again. For some reason however the local part is starting to become ‘required’ as well, as rebuilding it takes ages, or a lot of resources (CPU, network, …) as well… Or where is your OST file stored?

The mandatory profile did have some promising advantages. Fast profile logon times for example, lightweight on the server, both on storage as well as logon-processing load. But even the tiniest personal setting (registry or files) needs to be placed by 3th party tools.

How about mixing things up!
In my opinion the roaming profile is not a bad start at all! Not convinced?
The profile has 3 parts:

Registry (HKCU, Current User)
This is essential, so we keep it. It is also a tiny part, so loading is fast.

Files: Local(Low) part
Hey, this should stay local, so we will not even bother about this at this moment

Files: Roaming part
The problem is not the Windows Essential files. Also some (larger) files transfer relatively fast. Thousands of tiny files however suck… At least on resources.

How about ditching the files as well?
All files, I mean… Never include them in the Roaming profile!

In that case only the registry has to be copied at logon by the roaming profile. This is extremely fast, sometimes even faster as a (not perfectly optimized) mandatory profile.
You might say that you miss out on the files. This is where the 3th party tools (like Scense Live Profiles) come in, which we would usually use on a mandatory profile. We could limit the syncing so these should sync just the required files (registry is there, right?), but I still would ‘suggest’ to capture all desired/required settings, including the registry.

Are you still with me? This has some advantages:

Common settings not possible using mandatory profiles (numlock, screen zoom factor 150%, …) now work out of the box.

You only have to take care of the files, registry is all-done
As noted, still include the registry settings as it is a form of backup (if the roaming profile is ‘lost’). Also LiveProfiles helps you during migrations or Multi-platform logins (ever applied a roaming profile on Win7 and Win10?)

The lots of tiny files will be moved faster
These will be moved to the local system in a zip, in general. Extracting these locally is extremely fast, compared to a ‘file copy from a network location’, like a roaming profile sync would do.

You can split applying and capturing files between logon and application start/stop
This helps getting an even faster logon!

For IT the burden to optimize the mandatory profile is removed
An outdated mandatory profile can impact logon a lot, as non-included applications will be ‘pre-initialised’ at logon… Every logon, every day again!

A last note:
Even on local or profile disk based user profiles, solutions like Scense Live Profiles can be great, as they can be used for backup purposes in case a profile is corrupted or the system has crashed. The settings would be recovered and the user is up-and-running again in seconds… Even in migration scenarios or when multiple platforms live next to each other (RDS <> Win10 <> Win7) Scense Live Profiles can roam and even translate settings between the various environments!