Follow

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

 

Problem:

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

 

Symptoms:

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 "client-tools.zip" 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, the user MUST be part of "ProfileUnity" Security group listed in "profileunity.lic" file.

lmconsole2_-_Remote_Desktop_Connection_2015-10-07_17-03-42.png

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

lmconsole2_-_Remote_Desktop_Connection_2015-10-07_17-03-31.png

 

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: Default:...Netlogon\ProfileUnity
      • Note: This is the path were is the current ProfileUnity License
  10. template_4.png

 

Step 7) Close Group Policy Management Editor

Step 6) Refresh Desktops or RESTART Server!

 

DIA - VHD:

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.

 

DIA - VMDK:

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

0 Comments

Article is closed for comments.