User Data: Here, there, everywhere
But rarely where you need it
This is where the concept of “roaming profiles” starts take hold Roaming profiles synchronises the local copy of the user profile to the server, in essence making a backup copy of all that information every time a user logs off. If this sounds like the ideal solution to the remote user problem then be warned that roaming profiles does have its flaws. Some applications leave temp files, caches, buffers or other large files in folders that get replicated to the server.
There is nothing quite so frustrating as waiting patiently for your computer to log off over the VPN, only to realise Acrobat decided that Application Data (a folder that gets replicated to the server,) was the best possible place for 4GB worth of temp files. Conversely, roaming profiles doesn’t actually copy the complete user profile to the server. Many programs that don’t play by Microsoft’s rulebook won’t have their information stored on the server.
Firefox is one such; if the copy of the profile on your local computer is lost or corrupted for any reason, there go all your Firefox bookmarks or settings. Some of the more severely misbehaved programs can actually refuse to release locks on the user’s portion of the registry upon log-off which in some cases this has the effect of preventing the profile from being copied to the server at all. Microsoft has created the profile hive cleanup service to help administrators deal with this issue, but the local computer can often still require a reboot after log-off to complete unlocking of the user’s profile.
An issue that is mostly one of user training, but still quite a common problem, is the reality that roaming profiles are only as current as the last time that user logged off their local computer. (Assuming they were even connect the corporate network at the time.) With laptop hibernation, users can sometimes go months before logging off or rebooting their laptops, again with no guarantees that when they do so they are connected to the corporate network so that profile synchronisation can occur. Systems administrators must also take into account that the user generally feels secure in the knowledge that their information is “backed up on the server” regardless of the procedures they personally follow. This can result in a policy and training issue which has proven very hard for some organisations to overcome.
The other scenarios that break roaming profiles are those in which the same user logs onto multiple machines; the results are generally not pretty. To illustrate, I will detail for you the very common “desktop folder” scenario:
Alice logs into both Computer A, creates a file and saves it to the desktop. Alice goes for lunch, logs Computer A off; the file on her desktop synchronises with the rest of her profile to the server. She returns from lunch, logs back onto Computer A, finishes her day but forgets to log off of Computer A. When she returns in the morning, she logs onto Computer B, the server supplies her the last copy of the profile it had, (circa lunchtime the previous day.)
At some point, Alice notices the file on the desktop. Having no further need of it, she deletes the file. When Alice goes to lunch, she logs off Computer B. Noticing she left computer A logged in from yesterday (oops) she logs it off as well. When she returns from lunch and logs back on to Computer B, the file she deleted off the desktop is back again!
When Alice deleted the file on Computer B, there were two other copies of that file in existence, one on the server, and one on Computer A. While the copy on the server would have been deleted during the synchronisation process of Computer B’s logoff, it was Computer A that was logged out last. Computer A did exactly what it was designed to do: it copied all the files it had over to the server, including the copy of the file that Alice had deleted. The synchronisation process can rapidly lose track of what it should or should not delete in such scenarios and defaults to “just don’t delete it.”
The long story short is that the only way you are ever getting rid of that file is to kill it out of every copy of the profile that exists on the server and all local machines Alice had logged on to. To complicate the scenario a bit, to widening the number of potential computers that Alice may log into by 5. Let’s also assume that one or two of these computers she only logs onto every few months.
The strangled scream you hear in the background is that of administrators who have dealt with this one before. It is generous to say that getting rid of the detritus that can accumulate in a profile under these conditions is exceptionally tedious.
Overall, the task of ensuring that user data is stored on (or at least regularly backed up to) the server is generally a nightmare, with actual implementation having to be tailored to your individual usage cases. Logon and logoff scripts can help a great deal, and if your usage scenarios allow for it, judicious use of a combination of both folder redirection and roaming profiles can really help.
Roaming profiles are a huge step forward in this, and this feature is one of the many reasons why Windows servers running Active Directory are so popular. Roaming profiles do however have a very long way to go before they are easy, efficient and bug free. For some of these issues, it is tempting to lay all complaints at the feet of third party application developers; roaming profiles for remote user usage cases would probably work great if everyone just played along.
Even with that in mind, I can’t find it within myself to absolve Microsoft of all guilt or blame. Roaming profiles have been around for a long time, long enough for Microsoft to have given us much finer grained controls over what gets replicated, how, and what can trigger it. Considering the plethora of usage cases, what is available either for Microsoft or its competitors is just too clumsy and primitive.
My next article will delve into the details of making the best use of the tools available to us; to overcome the inherent limitations of these technologies by combining them with each other and throwing in some simple scripting.
Sponsored: The Nuts and Bolts of Ransomware in 2016