Citrix User Profile Manager 5 Years Ago: Birth

Citrix User Profile Manager is pretty well-known in the SBC space today. Five years ago, things were quite different. Citrix did not have a user profile solution, and neither did sepago. But we had an idea spinning in our heads we soon came to call Smooth Profiles. Slowly that idea became code, then was renamed to sepagoPROFILE, was acquired by Citrix and renamed again to User Profile Manager and then again to Profile management (with capital P and lower-case m!). You may have heard the latter part of the story. Here is a little something from the very beginning. A few days ago I stumbled upon an old notebook containing, to my surprise, the very first notes about what was to become sepago's profile management product: For those that either do not read German or my handwriting here is a transcript: Smooth Profiles Requirements:

  • User has a mandatory profile
  • Directory on file server for storage of .reg file

Logoff:

  • If .reg file exists it is imported to HKCU\$SmoothProfile
  • Recursively iterate through HKCU and compare each key's timestamp with %LOGONDATE%
  • If key in HKCU is newer:
    • Copy subkeys (without children) and values to HKCU\$SmoothProfile
  • Unload HKCU\$SmoothProfile to .reg file

Please note:

  • Backup and restore privileges (work around that by using a service)
  • Multiple concurrent logoffs (wait if .reg file is locked)

End of transcript. It is not dated, but it should be from April 2005.

Remarks

As you may have guessed from the transcript we initially thought it would be sufficient to store registry data since the relevant folders of the profiles would be redirected to a file server anyway. But apart from that this first draft already shows some characteristics of the later sepagoPROFILE:

  1. Code everything in a Windows service, which gets us all the privileges we need and has the additional advantage of not having to modify logon scripts when deploying the solution.
  2. Use the timestamps on registry keys to determine what has changed during a session.
  3. Robustly handle concurrency in Terminal Server environments (multiple sessions per user).