Managing persistent user profiles (Part 1)

User profiles on computers running Microsoft Windows has long been a subject that’s interested me. So much so in fact that I was the one who authored the chapter on user profile management (chapter 15) of the bestselling Windows 7 Resource Kit from Microsoft Press (which I was also the lead author for). User profiles have continued to evolve however with the release of more recent versions of Microsoft Windows, and the methods for managing user profiles in various kinds of environments (e.g. traditional desktops, classrooms, lab environments, standalone kiosks, etc.) have also continued to evolve.
I haven’t worked on a project yet that involves managing Windows 10 user profiles (especially persistent user profiles) so I’ve lost touch a bit with this subject. But others out there in the world of IT still have to wrestle with this as part of their own Windows 10 deployment or migration, so I’ve asked an expert who works in the field to describe how he has approached the problem of managing user profiles in a specific kind of client computing environment: a lab where computers are shared.
Mark Van Noy is a Technical Lead/Architect at the University of Colorado Boulder in the Greater Denver Area, and as an Information Technology generalist he thrives on architecting new tools and services in ways that allow his customers to realize gains in efficiency, productivity, and cost savings while ensuring that IT remains a division that provides a competitive advantage. In this first part of this two-part article Mark will explain what the problem is with managing persistent profiles and some common approaches for doing this. Then in Part 2 Mark will describe a custom approach he developed for managing the persistent user profiles needed for the labs at his university.

What’s the Problem?

Everyone in IT is likely familiar with user profiles. Unix type systems have the /home directory structure and current Windows systems use the \Users directory to store user specific data. This sounds great. Everything that pertains to an individual user can live in a directory under the root directory \Users including any data files they own and we will have world peace. Unless, of course, there is some reason not to have a user’s data persist. Those same persistent profiles also store all the customizations a user might make to their environment ranging from their desktop wallpaper to the default font in Word. In situations such as training labs or kiosks all of that persistent data starts becoming problematic.
For an example, assume that thirty students are taking a week long class in how to use Office. On day one, five people in class get bored and start to make little changes to the Ribbon, font type, letter spacing, and so forth. On day three the instructor leads all the students through a task, that they are demonstrating using their own computer and a projector, at which point all five of the people that decided to make changes raise their hands calling out, “My computer does not look like that!” Had their profile data not persisted from day one then all the computers would look and behave the same way at the start of each day of training assuming that the computers are not left logged in overnight; a different discussion altogether. Then in Part 2 Mark will describe a custom approach he developed for the labs at his university.
Let’s now look at some common solutions…

Mandatory Profiles

The use of Mandatory Profiles would seem to be the obvious solution. The IT department can simply create the look and feel needed for the environment, place that profile on a network share, and mark the share as read only. Even if you are not bothered by the fact that Mandatory Profiles use the same technology as Roaming Profiles, the network requirement should raise some concerns. Any loss of network connectivity to the server where the Mandatory profile lives causes this method to fail which is a problem for training labs that travel to conferences or laptop based labs that may not have reliable wireless connectivity.

Guests Group Account

At least as far back as Windows NT 4.0 there has been both a Guest account and a Guests group. Administrators have been told so many times that they should not enable the Guest account that it is a wonder it ever existed. The Guests group, however, was genius. Any Active Directory groups that were added to the local Guests group would then become guests on that local computer. Because members of the Guests group are inherently temporary users of the computer, Microsoft did us the favor of deleting the profile of any member of the Guests group upon their logging off the computer. Thus members of the Guests group get the Default profile at every login. Problem solved.
Or rather, the problem would be solved except Microsoft stopped reliably deleting profiles on logout for members of the Guests group with the release of Windows 7 and some companies, most notably Adobe, began failing to validate their software licenses if the user account was a member of the Guests group. So accounts no longer have their profiles deleted and some software that is licensed will refuse to run claiming that it is not licensed. The Guests group is now approximately as useful as the Guest account. The Windows 10 description of the Guests group says that, “Guests have the same access as members of the users group by default.” It is like a vestigial group; what is the point?

Deep Freeze

Deep Freeze and similar products can solve the consistency problem by simply either preventing or rolling back any changes to the system. This type of solution sounds great until the number of computers begins to grow past one, because any changes to the computer requires some form of administrative intervention to unlock the computer and then perform the changes. Patching requires intervention. Updating third party software requires intervention. Changing the look and feel requires intervention. The list goes on and on because literally any change must be done after the computer is unlocked, thawed, and then the computer must be again made immutable once the changes are made. This type of solution has worked for a number of administrators I have talked with over the years with the only real complaint being that the tools have been labor intensive.

Delete the profile

A simple deletion of the profile by deleting the %userprofile% or even deleting all the profiles in the Users directory path on each computer can also solve the problem of persistent profiles. The single biggest challenge of deleting profiles is: when is the profile to be deleted? If profiles are deleted on a schedule, say with a Scheduled Task, then they should be safely cleaned up, but until that task runs any additional logins from the same individual will receive any changes that individual made during previous sessions. Removing profiles on a schedule can cause end user confusion because their settings persisted the last few logins and then were reset. To keep user expectations consistent, the profile needs to be deleted on logout so that each login provides a new profile built from the Default profile. However, a log off script will fail to delete the profile because the script will be running as the logged in user and the profile cannot be deleted until the user’s Registry hive has been unloaded; the file lock on the hive will win and the profile will persist.

Virtual Desktop Infrastructure (VDI)

Use non-persistent desktops in VDI. Every time any user logs off the machine the entire virtual machine is deleted and a new copy of the virtual machine is spun up to await the next connection. This option is fantastic. We use it and I could not be happier with it. Not only does it solve the problem of providing a consistent experience from a look and feel perspective, but it is effectively re-imaging every computer between every login which eliminates any drift in computer settings due to administrative changes that may not have been made to all the computers. VDI does have three catches: the cost of the infrastructure, the complexity of the infrastructure, and the loss of performance that comes from sharing resources. The gap is closing on the performance concern to the point that highly demanding applications such as CAD/CAM, mathematical analysis, or similarly resource intensive applications are going to potentially to be a suitable fit for VDI in some circumstances such as when Grid cards are available for effective 3D graphics processing. The cost and complexity are still relatively big hurdles. In my experience, if you can get over the hurdles to implementing VDI the end users do not know the difference.

To be continued

Coming up next in Part 2 of this article, Mark will describe a custom approach he developed for managing the persistent user profiles needed for the labs at his university.

About The Author

3 thoughts on “Managing persistent user profiles (Part 1)”

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top