Skip to main content

Default User Profiles (Windows)

Frame administrators may need to customize their users' Windows application and/or desktop experience by configuring the Windows default user profile. Updating the default user profile allows administrators to:

  • customize the Windows Start menu and task bar
  • set registry key values
  • configure "run once" PowerShell scripts
  • and/or pre-configure application settings and then provided them to each user when each user logs into their Frame session. If the user is accessing persistent desktop VMs or non-persistent VMs with enterprise profiles enabled, then the default user profile is copied by Windows to the user's profile on the first Frame session.

With Frame, the location of the default Windows user profile for your users will depend on how the Frame account was created and configured. This page discusses how to configure a Windows default user profile based on one of the following Frame account configurations:

Non-persistent, non-domain-joined Frame Account

With a non-persistent, non-domain-joined Frame account, the Frame administrator is automatically logged into the Sandbox as the local Windows user Frame (a member of the local Windows Administrators group) to manage the image. When the Sandbox is published, the production VMs will be clones of the Sandbox. Since the production VMs are non-persistent, anything users do to their workload VMs during the session will be lost once their session is closed.

Enterprise Profiles Disabled (default)

Default Profiles configuration (no Enterprise Profiles)

With enterprise profiles disabled (default), users connecting to the production VMs using Frame Remoting Protocol will be automatically logged into the production VMs as the local Windows user Frame. As a result, if the Windows user profile must be customized, Frame administrators must customize the user profile located in the Sandbox under C:\Users\Frame.

Enterprise Profiles Enabled

Enterprise Profiles

When enterprise profiles are enabled, users connecting to the production VMs using Frame Remoting Protocol will be automatically logged into the production VMs as the local Windows user FrameUser. By default, FrameUser is not a member of the local Windows Administrators group. Frame administrators can choose to add this Windows user to the local Windows Administrators group, if desired. If the Windows user profile must be customized, Frame administrators must customize the Windows default user profile in the Sandbox under C:\Users\Default.

When a user connects into a production VM for that Frame account for the first time, Frame will create a profile disk for the user and mount that disk on the assigned production VM. Windows will then copy the default profile in C:\Users\Default to the user's profile disk before the user is automatically logged into production VM. Once the user has a profile disk, changes within the user profile (e.g., registry settings, credential manager entries, application settings, etc.) under %USERPROFILE% will persist between sessions.

note

The local Windows user Frame must still be a member of the local Windows Administrators group in the production VMs for running the Frame services.

Non-persistent, domain-joined Frame Account

With a non-persistent, domain-joined Frame account, the Frame administrator is automatically logged into the Sandbox as the local Windows user Frame (a member of the local Windows Administrators group) to manage the image. When the Sandbox is published, the copy of the Sandbox is created and sysprep is executed using the Unattend.xml located in C:\ProgramData\Nutanix\Frame\Sysprep\Unattend.xml for FGA 8.X. The generalized Sandbox image is then used to create the production VMs.

note

Customers are allowed to join their Sandbox to their domain. In that case, Frame administrators will login to the domain-joined Sandbox as a domain administrator and not the local Windows user Frame. Frame Administrators must remember that Frame will run sysprep to generalize a copy of the Sandbox image, as described previously, during the publish process.

Non-persistent, domain-joined Frame Account diagram

With domain-joined production VMs where users are required to authenticate to a Windows domain, users will be logged into the production VMs as a domain user after authenticating to their Windows domain. If the default Windows user profile needs to be customized, Frame administrators can customize the default user profile in the Sandbox under C:\Users\Default. Alternatively, Frame Administrators can deploy customizations using local or domain policy objects (GPOs).

note

If the user does not login to the domain-joined VM (Disable Require login with domain user account setting in Account Settings > Domain), then the user will be auto-logged as local Windows user Frame in the Windows Administrators group, regardless of whether enterprise profiles are enabled or not.

When a user connects into a production VM for that Frame account for the first time, Frame will create a profile disk for the user and mount that disk on the assigned production VM. After the user is presented with the Windows login screen and authenticates to their Windows domain, Windows will then copy the default profile in C:\Users\Default to the user's profile disk. Once the user has a profile disk, changes within the user profile (e.g., registry settings, credential manager entries, application settings, etc.) under %APPDATA% will persist between sessions.

With domain-joined Frame accounts, the user always runs in the domain user context, regardless of whether enterprise profiles are disabled or enabled.

Persistent, non-domain-joined Frame Account

Persistent, non-domain-joined Frame Account diagram

With a persistent, non-domain-joined Frame account, the Frame administrator is automatically logged into the Sandbox as the local Windows user Frame (a member of the local Windows Administrators group) to manage the image. When the Sandbox is published, the production VMs will be clones of the Sandbox. The user will also be auto-logged into their assigned persistent desktop as the local Windows user Frame. This user must be a member of the local Windows Administrators group in order for Frame server updates to be successfully executed, to extend the disk size, and other maintenance tasks the Frame Guest Agent performs. Every server customization script is run in Frame user context and some of the task may fail to execute because they requires administrative permissions. If the Windows user profile must be customized, Frame administrators must customize the user profile located in the Sandbox under C:\Users\Frame.

Persistent, domain-joined Frame Account

Persistent, domain-joined Frame Account diagram

With a persistent, domain-joined Frame account, the Frame administrator is automatically logged into the Sandbox as the local Windows user Frame (a member of the local Windows Administrators group) to manage the image. When the Sandbox is published, the production VMs will be clones of the Sandbox.

Users will be logged into their domain-joined production VMs as a domain user after authenticating to their Windows domain. If the default Windows user profile needs to be customized, Frame administrators can customize the default user profile in the Sandbox under C:\Users\Default. Alternatively, Frame Administrators can deploy customizations using local or domain policy objects (GPOs).

note

If the user does not login to the domain-joined VM (Disable Require login with domain user account setting in Dashboard > Settings > Domain), then the user will be auto-logged as local Windows user Frame in the Windows Administrators group. Frame administrators must configure the user profile in the Sandbox under C:\Users\Frame.

Profile Customization

Windows administrators may wish to customize different elements of the Windows user profile. The following subsections highlight the common areas of Windows that administrators often customize.

Start Menu

Administrators may want to change the Windows Start menu layout for their users, following Microsoft's document on customizing the Start layout. In order to make these changes, the Windows administrator needs to add a LayoutModification.xml file to the Sandbox in the appropriate default user profile (e.g., C:\Users\Default\AppData\Microsoft\Windows\Shell subdirectory). The XML file can be generated by exporting the existing Start Menu layout and then modified per Microsoft guidelines:

Export-StartLayout –path $yourPath exampleFile.xml

Task Bar

In order to modify the Windows Task Bar for all users, follow the Configure Windows 10 taskbar instructions.

Fonts

Adding fonts is straight-forward. Install fonts as usual but make sure to install the fonts for all users.

Background Wallpaper

For non-domain-joined production instances, Frame Administrators can change the background wallpaper by simply changing it in the sandbox and publishing.

Alternatively, admins can place their wallpaper files in a custom location on the Sandbox and update the wallpaper location by using gpedit.msc in the Sandbox to set a local group policy under User Configuration > Administrative Templates > Desktop > Desktop > Desktop Wallpaper.

For domain-joined instances, Frame Administrators can set the wallpaper through a GPO.

note

Depending on how the workload VMs are configured to show the custom wallpaper, changes to the wallpaper may or may not apply to users with existing enterprise profiles. Administrators may need to delete the existing enterprise profile disks and have the users start new Frame sessions. When a user starts a Frame session, Frame will provision a new enterprise profile disk and Windows will initialize the user's profile using the Windows default user profile, as defined in the Sandbox.