Scenario: As an administrator, you are providing applications to your users through Frame’s desktop experience, application experience or any hybrid of both. Some of these applications are client-server applications and have input requirements on a per-user basis, such as server name, etc. You want to remove the extra complexity of manually entering this information from your end users experience. With Frame, how can you accomplish this?
This blog series centers around Frame Image Management. Image Management is “How do I set up my environment in the most optimal way, to minimize the number of images I have to manage?”. Part 1 of this series covered how to onboard and configure SaaS applications, while Part 2 covered how to install persistent applications in a non-persistent environment. This blog will cover another common virtual desktop use case: how to preconfigure user-specific settings for all users from the Sandbox.
What are the caveats to doing this?
Because of the way Windows profiles work, there is one stipulation for the instructions below to work properly. Simply put, the information below will only work on new user profiles. If a users’ profile already exists, either via Frame Enterprise Profiles or a 3rd party Profile Management solution, the triggering mechanism will not run.
What are the differences between machine and user settings?
Most applications, when installed and used, have two separate settings groups based upon whether they are machine-specific settings (those settings that apply to the entire machine) or user-specific settings (those settings that apply only to the currently logged in user).
What makes the settings machine- or user-specific is based upon location. Most modern applications install machine-specific settings, if they are file-based settings, to either C:\Program Files, used for 64-bit applications, or C:\Program Files (x86), used for 32-bit applications on a 64-bit Windows Operating System. If the machine-specific settings are registry-based, then the settings are in the HKEY_LOCAL_MACHINE (HKLM) hive. Likewise, most modern applications install user-specific settings to either the Roaming, Local, or more rarely the LocalLow AppData locations if they are file-based, or in the HKEY_CURRENT_USER (HKCU) hive if they are registry-based.
So, what makes pre-configuring the user-specific settings any different than the machine-specific settings? Well, since Frame utilizes a Sandbox, a master image VM, to provision the image for all workload VMs, the name of the account used to logon to the OS is most likely different between the Sandbox and the workload VMs. Because the AppData locations listed above exist separately for each Windows user account that accesses the environment, at C:\Users\[AccountName], you can’t configure all settings for an application in the Sandbox for all users by configuring the account that has a session to the Sandbox.
Let’s break this down a little bit. When you start a session into the Sandbox, you are using a local Windows administrative user account called Frame. This account user’s folder would therefore exist at C:\Users\Frame. This location is commonly called the user’s profile.
Alternatively, if you were to start a session on a workload VM using an account called Test, the account user’s folder would therefore exist at C:\Users\Test. As such, the settings configured under C:\Users\Frame wouldn’t exist under C:\Users\Test.
In addition, the registry hive HKCU for each user that accesses the operating system is based upon a NTUSER.DAT file that exists within the user’s profile, a hidden file that exists in the root of the user’s profile folder.
When a user logs in, the NTUSER.DAT is loaded into the registry into the HKEY_USERS (HKU) hive, of which the HKEY_CURRENT_USER is a sub-hive. You can confirm this with a combination of the Registry Editor and a command you can run in PowerShell:
wmic useraccount get name,sid.
So, now that you know the above information, how could you possibly preconfigure user-specific settings for a Windows user account that has not logged in or doesn’t even exist yet?
Luckily, there are mechanisms to do so, if you understand how to do it.
Alright, I understand, now what?
So, let’s think about this logically. How does Windows create a profile if one doesn’t already exist, i.e., a user that is accessing their very first session? Is it created from scratch?
Not at all. The profile is copied from a template. This template profile exists in the operating system, located at C:\Users\Default, where Default is a hidden folder. When an account that has never logged into the operating system logs in for the first time, the new profile is created by copying C:\Users\Default to C:\Users\[UserName]. We are going to take advantage of this mechanism to preconfigure settings for all users.
This goes back to the caveat listed above. If a user’s profile already exists and is persisted via a profile management tool, such as Enterprise Profiles, then Windows has no need to copy the Default folder to create a new user profile. For this scenario, you have two options: (1) input these settings in an alternative way or (2) delete the user’s profile and start again. The latter, while a quick fix, is a bit of a nuclear option and is not generally recommended outside of testing or proof of concept scenarios.
Now, there are two possible pieces to configure, depending on whether you need to configure folders/files or need to configure registry keys/values.
First, the folders/files, as this is by far easier. Let’s say you have an application called XYZ PDF for which you want to preconfigure settings. These settings are based upon a file, which contains configuration items such as whether the application opens maximized or minimized and whether the application starts on user logon. This file exists in a structure under AppData\Roaming with a folder path of XYZ PDF\Settings and a file called Settings.xml.
Therefore, the full path where the Settings.xml file needs to exist is C:\Users\Default\AppData\Roaming\XYZ PDF\Settings.
Both the Default and AppData folders are hidden folders, so the easiest way to access this location, within File Explorer, is to type the entire folder structure. Alternatively, you can show hidden items from the menu bar. You can then create the XYZ PDF\Settings folder structure and place/create the necessary Settings.xml file there.
So, with the file configuration pre-set, let’s talk about doing the same in the registry. This one is a little more complex, but still fairly straightforward.
Continuing the example with the application from above, XYZ PDF, you wish to preconfigure some settings that are registry-based. When the user opens the application the first time, you wish it to be configured to company standards. This includes disabling Auto Updating and Hardware Acceleration, as well as defining the licensing server.
These registry values exist for each user under the HKCU hive, in the Software\XYZ PDF\Configuration key. The Auto Updating and Hardware Acceleration settings live under a registry key called User Experience, while defining the licensing server exists under a key called Licensing. The values need to be configured as per the below.
Now, as stated previously, the registry hive for HKCU is a sub-hive of HKU. When you look under HKU, you notice there is a .DEFAULT key. Eagle-eyed viewers may have seen it in Figure 3 above. This must be the place where you configure registry settings for all users, as the folder structure used Default as its name, right?
Unfortunately, this .DEFAULT key is a bit of a red herring that has been perpetuated for years as the location where you preconfigure users’ registry settings, and I would know, as I have inadvertently perpetuated it myself! But alas, that information is incorrect.
While I could attempt to explain the .DEFAULT registry key, I believe I’ll let Helge Klein explain it, as he does it justice.
Okay, so the .DEFAULT key is not for the default profile, so where is it?
Honestly, it’s not actually listed in the registry at all, at least not yet. That’s because the only user hive that is loaded is the currently logged on user. We must load the default user hive into the registry to even be able to view the hive. To do this, from the Registry Editor, highlight the HKEY_USERS hive, click File, then choose Load Hive. Please note the Load Hive function requires elevated permissions to the Registry Editor.
Then, using the location of the default profiles’ registry file we discussed previously, browse to C:\Users\Default, then find and open the NTUSER.DAT file. Remember that the Default folder is hidden.
You will then be prompted to provide a name for this hive. This name is temporary and arbitrary, but necessary. For my example, I called it DefaultUser. Once complete, you will see the registry hive loaded into HKU.
From here, we can create the registry key structure necessary, adding the necessary registry values where required.
Once all configuration items are complete, you next unload the registry hive by highlighting the DefaultUser hive, clicking File, then choosing Unload Hive. Please note that failure to unload the hive may cause issues during or after the publish process.
Once you have unloaded the temporary registry hive, close the session to your Sandbox session and publish. When you grab a new session to the workload VMs, the files and registry values will exist in the location you preconfigured.
What’s next?
In this blog post, we covered a common ask by Frame customers, providing a way for administrators to preconfigure user-specific settings for all users from the Sandbox. Next, we will be covering another image management technique used in customer environments, implementing a pilot testing methodology.
Contact Us
Need help with your Frame deployment, have an idea for a new use case, or just want to learn more about Frame?
Email us at frame-sales@dizzion.com and one of our experts will reach out!
Follow Us
More content created by
Jake Norman© 2024 Dizzion, Inc. All rights reserved. Frame, the Frame logo and all Dizzio product, feature and service names mentioned herein are registered trademarks of Dizzion, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). This post may contain links to external websites that are not part of Dizzion. Dizzion does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such a site. Certain information contained in this post may relate to or be based on studies, publications, surveys and other data obtained from third-party sources and our own internal estimates and research. While we believe these third-party studies, publications, surveys and other data are reliable as of the date of this post, they have not independently verified, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from third-party sources.