How to setup separate ProfileUnity configuration to execute on machine startup for XenApp/RDSH or non persistent desktop.

Product: ProfileUnity

Product Version: 6.5+

Expires on: 365 days from publish date

Updated: Oct 8, 2015



ProfileUnity 6.5 has an ability to execute separate configuration to execute on startup. This will allow faster user's logon and allow ProfileUnity to prepare the desktop during system startup.This could be applied to RDSH, XenApp or Windows non persistent desktop pool. (Run ProfileUnity as a service)


Some of the features/changes that could be done to the machine during startup:

  • Installation of DIA applications (ie - XenApp)
  • Configuration of HKLM registry keys
  • Execution of cmd, vbs and Bat Scripts during system startup
  • Any other system level changes



Pre installation checklist:

  • VM client machine is NOT a XP/2003, 2008 non-R2 machine
  • .Net 4.5.2 is installed on the base image
    • Note: .net 4.5.2 is included in "" when extracted. Its also located in ..netlogon\Profileunity\NDP452-KB2901907-x86-x64-AllOS-ENU.exe
  • GPO is configured to use "LwL.ProfileUnity.Client.Startup.exe" and NOT "startup.vbs"


Possible Resolution(s):

Step 1) Go to Configuration Management in console and create a separate configuration with settings that need to be applied during system startup.

Note: Only system level filters inside the configuration can be applied here. Example: Computer name begins with...

Step 2) Download this secondary (ini) configuration to your Startup folder located in ....netlogon\ProfileUnity\Startup

Step 3) In ProfileUnity Console go to "Administration" page.

lmconsole2 - Remote Desktop Connection_2015-10-07_13-40-10.png

Go to "ProfileUnity Tools" section and fill our the missing information "Run Client Tools As Service" 

Use any domain user or create service account.

Before ProfileUnity 6.8: The user MUST be part of "ProfileUnity" Security group listed in "profileunity.lic" file.


Step 4) Select "Deploy Service Configuration or Download Service Configuration



Note: This will download "LwL.ProfileUnity.Client.Service.exe.creds" file to ...netlogon\ProfileUnity (Deployment) directory (same directory where "lwl.ProfileUnity.Client.Startup.exe" is located)

Note: When lwl.ProfileUnity.Client.Startup.exe will run (GPO or manual on base) it will read the .creds file and setup ProfileUnity client to run as a service on the machine. 

Step 5) Configure Properly GPO - Add Computer Configuration Administrative Template

  1. Logon to Domain controller and Open Group Policy Management
  2. Edit "ProfileUnity" GPO
  3. Expand Computer Configuration, Policies, Administrative Template, (Add/Remove Templates)
  4. Template.png
  5. Add, Browse to ..netlogon\profileunity directory and select. "ProfileUnity.adm" > Open
  6. template2.png
  7. Close
  8. Browse to: Computer Configuration > Administrative Templates > Classic Administrative Templates > Liquidware Labs > ProfileUnity > 32 Bit or 64 Bit
    • Note. If "Liquidware Labs" Template is not visible, go to "Action" and un-select "Filter On" 
  9. Enable and specify paths:
    • System INI FIle Path: Default: ..Netlogon\ProfileUnity\Startup
      • Note: This is path where is the secondary (Startup) ini is located
    • System License Path (Pre PU 6.8): Default:...Netlogon\ProfileUnity
      • Note: This is the path were is the current ProfileUnity License and it does not need to be configured if the profileunity is version 6.8 or later
  10. template_4.png


Step 7) Close Group Policy Management Editor

Step 6) Refresh Desktops or RESTART Server!



To deploy VHD DIA applications just add the DIA to the DIA module in startup configuration.

Filters: There is a possibility of using "computer name" based filters within that startup configuration.



Assign DIA VMDK applications to a single "Service Account" (From Step #3) Those applications will deploy to the RDSH servers when they are restarted. 

 Filters: There is possibility to use different credential files on different OU’s to force different apps, then do  VMDK Assignments to different "Service Account" users. So as many filters there are than that many OU's are needed and different credential files.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Article is closed for comments.