Skip to main content

Running ProfileUnity and FlexApps at boot using a Service Account

Glen Porter
  • Created:
  • Updated:
Running ProfileUnity Client Tools as a Service

ProfileUnity can execute a separate policy configuration at machine startup, running as a Windows service under a domain service account. This allows ProfileUnity to prepare the desktop before any user logs on — useful for RDSH, XenApp, and non-persistent VDI pool deployments, or layering FlexApps at boot to distribute load bewteen on boot and at login.

ℹī¸ What the startup configuration can do
  • Install DIA (Dynamic Application Installation) applications — including FlexApp DIA for RDSH/XenApp
  • Configure HKLM registry keys
  • Execute CMD, VBScript, or batch scripts at system startup
  • Apply any other system-level changes before user logon

Prerequisites

  • The ProfileUnity GPO is configured to run LwL.ProfileUnity.Client.Startup.exe as a Computer Startup script
  • A domain service account is available for the ProfileUnity service to run under
  • The ProfileUnity ADM/ADMX template (ProfileUnity.adm) is added to the GPO (see Step 5 below if not already present)
  • The domain service account has the appropriate rights to the following paths:
    • Startup INI path — Read access to \\<domain>\netlogon\ProfileUnity\Startup
    • Deployment share — Read access to the main ProfileUnity deployment path (where LwL.ProfileUnity.Client.Startup.exe and the .creds file reside)
    • ProfileDisk / VHD paths — Read/Write access to the share where ProfileDisk VHDX files are stored. If CAC/SmartCard authentication is in use, see the ProfileDisk & CAC Authentication section below for additional requirements.
    • FlexApp package share — Read access to the FlexApp application share (where FlexApp VHD packages are stored)
    • Profile store / portability share — Read/Write access to the user profile portability share if startup configuration includes portability operations

Setup — Domain-Joined Machines

Follow these steps in order. Steps 1–4 are performed in the ProfileUnity Management Console; Steps 5–6 are in Group Policy Management.

Step 1 — Create the Startup Configuration

In the ProfileUnity Management Console, go to Configuration Management and create a new configuration containing only the settings to be applied at machine startup. This is a separate INI file from the standard user logon configuration.

Step 2 — Deploy the Startup INI

Deploy the secondary startup configuration (INI file) to the Startup subfolder in your ProfileUnity deployment share:

\\<domain>\netlogon\ProfileUnity\Startup

Step 3 — Configure the Service Account

In the ProfileUnity Management Console, navigate to Administration → ProfileUnity Tools. Under Run Client Tools As Service:

  1. Enter the service account username in the form domain\username.
  2. Enter the account password. Note: if the password changes, Steps 3–4 must be repeated to regenerate and redeploy the .creds file. A service account with a long or non-expiring password policy reduces this overhead.

Step 4 — Deploy the Service Configuration

Click Deploy Service Configuration or Download Service Configuration:

  • Domain or Cloud option — the service configuration file (LwL.ProfileUnity.Client.Service.exe.creds) is placed directly in the Deployment Path you specify.
  • Download option — the file is downloaded through your browser for you to extract manually to the Deployment Path.
By default, the .creds file is placed in the same directory as LwL.ProfileUnity.Client.Startup.exe. When Startup.exe runs (via GPO or manually on a domain-joined base image), it reads the .creds file and installs the ProfileUnity client service on the machine. For this to work, the System INI Path must also be set in the GPO (Step 5) and the license path must point to the main deployment path.

Alternatively, you can specify a custom path for the .creds file using the Client Service Credentials Path setting in the ProfileUnity Computer GPO, under both the 32-bit and 64-bit sections (Computer Configuration → Administrative Templates → Classic Administrative Templates → Liquidware Labs → ProfileUnity → 32 Bit / 64 Bit). This is useful when the credentials file needs to be stored in a location separate from the main deployment share.
Group Policy Management Editor showing Client Service Credentials Path setting under ProfileUnity 64-bit GPO

Client Service Credentials Path setting in the ProfileUnity Computer GPO (64-bit section shown).

To remove a service configuration, click Remove Service Configuration.

Step 5 — Add the ProfileUnity Administrative Template to GPO

Skip this step if the Liquidware Labs template is already present in your GPO. Otherwise:

  1. Log on to a Domain Controller and open Group Policy Management.
  2. Edit the ProfileUnity GPO.
  3. Expand Computer Configuration → Policies → Administrative Templates, right-click and select Add/Remove Templates.
  4. Click Add, browse to \\<domain>\netlogon\ProfileUnity and select ProfileUnity.adm, then click Open.
  5. Click Close.
  6. Browse to: Computer Configuration → Administrative Templates → Classic Administrative Templates → Liquidware Labs → ProfileUnity → 32 Bit or 64 Bit.
    If the Liquidware Labs template is not visible, go to Action and unselect Filter On.
  7. Enable the policy and set the System INI File Path to:
    \\<domain>\netlogon\ProfileUnity\Startup
    This is the path where the secondary (Startup) INI file is located.
  8. Close the Group Policy Management Editor.

Step 6 — Refresh Desktops or Restart

Refresh non-persistent desktop pools or restart the RDSH / server for the startup configuration to take effect on next boot.

Non-Domain Parent Image (New Installs & Upgrades)

When building a parent or gold image on a machine that is not joined to the domain, the service account setup in Step 3 will fail — a domain service account cannot be granted the Log on as a service right on an unjoined machine. Handle this as follows.

⚠ī¸Â  The .creds file must be temporarily removed during parent image installation to prevent the service configuration step from failing. The service is installed automatically when the first pool machine starts up and runs Startup.exe after domain join.

New Installs

  1. On the deployment share, copy out or renameLwL.ProfileUnity.Client.Service.exe.creds so it is not present during installation.
  2. Run the ProfileUnity client tools installer on the parent image per the standard base image installation guide.
  3. Rename the .creds file back to its original name in the deployment share.
  4. Confirm LwL.ProfileUnity.Client.Startup.exe is defined in the Computer GPO as a Startup script per the standard ProfileUnity GPO settings.

When machines are provisioned from the pool (Citrix or VMware Horizon), Startup.exe runs at first boot, reads the .creds file, and installs the ProfileUnity client service automatically.

Upgrades

The upgrade process follows the same steps 1–4 above for handling the .creds file during installation. Follow the standard ProfileUnity upgrade guide, temporarily removing the .creds file from the deployment share before running the upgrade installer on the parent image, then restoring it afterward.

ProfileDisk & CAC / SmartCard Authentication

When ProfileDisk is used in an environment requiring CAC or SmartCard authentication, additional configuration is required to allow the service to mount and access ProfileDisk VHDX files. Two options are available.

Option 1 — Use the Computer Account for ProfileDisk Access Recommended

Delegates ProfileDisk VHDX access to the machine computer account rather than the service account, avoiding credential pass-through issues with CAC.

  1. Adjust the ProfileDisk path so it resides outside the folder containing user profiles. In the ProfileUnity Management Console under Administration, update the ProfileDisk path and re-download ClientSettings.xml:
    From: \\server\share\%username%\VHDX-ProfileDisk\%username%.vhdx
    To:   \\server\ProfileDiskShare\%username%_ProfileDisk\%username%.vhdx
  2. Enable ProfileDisk System Mount/Unmount in the Computer GPO under both 32-bit and 64-bit sections:
    Computer Configuration → Administrative Templates → Classic Administrative Templates → Liquidware Labs → ProfileUnity
    Set ProfileDisk System Mount Unmount to Enabled.
  3. Grant the Domain Computers group Create / Read / Modify permissions on the share and folder containing the ProfileDisk VHDX files.
  4. Enable SmartCard logon notification events. On the master image (or via GPO + reboot), verify or create:
    Key HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify
    Type DWORD
    Value SmartCardLogonNotify
    Data 1

Option 2 — Use the Domain Service Account for ProfileDisk Access

⚠ī¸Â  This option cannot be used if the Secondary Logon service is disabled on the endpoint. If that is the case, use Option 1.

Uses the same domain service account configured in Step 3 for ProfileDisk VHDX access. In addition to standard service account setup, complete the following:

  1. Ensure the service account has at least Read/Write permissions on the ProfileDisk share. Place ProfileDisks in a dedicated location (as described in Option 1) rather than the general user profile share.
  2. Enable ProfileDisk VHD CAC Support in the Computer GPO under both 32-bit and 64-bit sections:
    Computer Configuration → Administrative Templates → Classic Administrative Templates → Liquidware Labs → ProfileUnity
    Set ProfileDisk VHD CAC support to Enabled. This instructs ProfileUnity to impersonate the service account when connecting to the file share during Kerberos pass-through authentication.
  3. Enable SmartCard logon notification events using the same registry key as Option 1 above.
  4. Password management: If the service account password expires or changes, the .creds file must be regenerated and redeployed (repeat Steps 3–4 of the main setup). Consider provisioning two service accounts that can be rotated at password change time.

6.9.5+ Alternative: Run as LocalSystem (No Credentials File)

Starting in ProfileUnity 6.9.5, you can configure the on-boot client service to run as NT AUTHORITY\SYSTEM (LocalSystem) instead of a domain service account. This eliminates the need to generate or maintain a .creds file, removing the requirement to rotate credentials when service account passwords change.

New in 6.9.5: The ProfileUnity.admx template includes a new GPO setting, "Install On-boot Client Service as Local System", under both the 32-bit and 64-bit ProfileUnity policy nodes. When enabled, Startup.Update installs the client service as LocalSystem — no service account or .creds file required.

Step 1 — Update the ADMX Template

Ensure you have the 6.9.5 version of ProfileUnity.admx (and its .adml language file) deployed to your Group Policy Central Store or local PolicyDefinitions folder. The new setting will not appear in the GPO editor until the updated template is in place.

Step 2 — Enable the GPO Setting

In your ProfileUnity GPO, navigate to:

Computer Configuration → Policies → Administrative Templates → Classic Administrative Templates
→ Liquidware Labs → ProfileUnity → 64 Bit (and/or 32 Bit)

Set "Install On-boot Client Service as Local System" to Enabled.

The System INI File Path setting (pointing to your deployment share's \\server\share\Startup subfolder) must still be configured in the same GPO, as Startup.Update reads configuration from that path at boot.

Step 3 — Remove or Skip the .creds File

With this setting enabled, no LwL.ProfileUnity.Client.Service.exe.creds file is needed in the deployment share. If one exists from a prior configuration, it will be ignored when the LocalSystem GPO setting is active. You may remove it to keep the share tidy, but leaving it in place does not cause errors.

Considerations when running as LocalSystem
  • The client service authenticates to network resources using the machine computer account (DOMAIN\machinename$), not a named service account. Ensure the deployment share and ProfileUnity INI path grant read access to Domain Computers.
  • ProfileDisk and CAC/SmartCard environments that require a specific domain identity for the service may still benefit from the credentials file approach described in the Setup — Domain-Joined Machines section.
  • This setting applies only to the on-boot client service installation. The LwL.ProfileUnity.Client.Startup.exe Computer Startup script still runs under SYSTEM by virtue of being a GPO startup script, as it did in prior versions.

FlexApp DIA at Startup

To deploy FlexApp VHD-based DIA applications at machine startup (for example, on RDSH/XenApp servers), add the FlexApps to the FlexApp DIA module within the startup configuration created in Step 1. That startup INI must be placed in the System INI File Path configured in the GPO so ProfileUnity reads it during system boot.

ℹī¸Â  DIA applications assigned in the startup configuration are installed in machine context (SYSTEM) rather than user context. This is required for RDSH servers where the application must be available before any user session begins.
Product Liquidware ProfileUnity with FlexApp
Applies To RDSH, XenApp, Non-Persistent VDI
Updated May 14, 2026

Related articles