VMware Horizon Community
Imitkov17
Contributor
Contributor
Jump to solution

Environment Variables are set after UEM processes it's conditions

Hi,

I have two environments:

     1. Horizon 6.2.1 with UEM 9.0.0.156 and App Volumes 2.11.0.122

     2. Horizon 7.1 with UEM 9.2 and App Volumes 2.12.1.103

I am migrating from environment #1 to environment #2. I have an existing Windows 7 golden image that I cloned and updated with the latest View, UEM and App Volumes agents. I also migrated the existing UEM config. There are some conditions and condition sets that are looking for the ViewClient_Machine_Name variable to map printers, map drives etc. Everything is working fine in the old 6.2 environment but in the new 7.1 environment the Environment Variables are set after UEM processes it's conditions. In the log files I see many of the following lines right after logon:

2017-06-12 14:46:54.925 [DEBUG] Conditions: Check for environment variable 'ViewClient_Machine_Name' = false (variable not set)

If I execute "UEM User Environment Refresh" after logon - all printers and drives are mapped correctly.

Then in the logs I see the following  lines:

2017-06-12 14:07:41.666 [DEBUG] Conditions: Check for environment variable 'ViewClient_Machine_Name' = false ('ZC-0030' is not equal to 'ZC-0011')

Which is the expected behavior.

Also I have a shortcut that is added to the startup folder. The application starts automatically in environment #1. In environment #2 the application is added to the startup folder but it doesn't start automatically.

Any help will be greatly appreciated.

1 Solution

Accepted Solutions
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi Imitkov17​,

Indeed, UEM runs before the ViewClient_ env vars are available. However, you can achieve what you're looking for by using the Horizon Client Property condition, which does have access to the relevant information at the right time.

Something like the following should do the trick:

pastedImage_3.png

(Just be sure to leave out the ViewClient_ prefix in the property text box... 🙂

View solution in original post

10 Replies
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi Imitkov17​,

Indeed, UEM runs before the ViewClient_ env vars are available. However, you can achieve what you're looking for by using the Horizon Client Property condition, which does have access to the relevant information at the right time.

Something like the following should do the trick:

pastedImage_3.png

(Just be sure to leave out the ViewClient_ prefix in the property text box... 🙂

Imitkov17
Contributor
Contributor
Jump to solution

Thank you so much UEMdev. That did the trick. Just curious - did something change between 9.0 and 9.2. The environment variables used to work.

Do you have any suggestions how to start an application upon logon. That used to work as well by adding a shortcut in the startup folder but now the shortcut is added but it never starts. I also tried to start it with a logon task but in this case the application starts before the profile and the settings are missing. The logon task is configured to run after profile archive import.

Thanks for your help! I appreciate it.

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Happy to hear it now works, Imitkov17​! I can't think of any relevant changes in this behavior between UEM 9.0 and 9.2... Could it be that with UEM 9.0 you were maybe running it from a logon script instead of as a Group Policy client-side extension?

You can't use UEM logon tasks to launch "interactive" applications; this functionality is meant for scripts or tools that don't need to show any UI, as we launch these tasks before the shell has started.

Creating a shortcut in the startup folder should still work just fine for this, though. Can you provide the relevant bit of FlexEngine logging at DEBUG level?

Reply
0 Kudos
Imitkov17
Contributor
Contributor
Jump to solution

Hi UEMdev

I did some more troubleshooting and discovered that the reason for the application not to start is that the "Programs Menu" folder is redirected to a file share via UEM (see below). If I disable the redirection the application starts upon logon as expected. Is there a way to keep the redirection but still be able to start the application upon logon?

pastedImage_2.png

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Thank you for finding this bug... Not sure yet how we will address this in the product, but we'll definitely pick this up in a future release.

The Startup folder is its own separate entity w.r.t. folder redirection (even though it's a sub folder of the programs menu). When it comes to UEM's shortcut creation, any sub folder you entered in the Programs folder text field will just be appended to the effective location of the programs menu folder.

If the programs menu is redirected, we'll create your startup shortcut in <redirectedlocation>\Programs\Startup. But unless you also redirected your Startup folder (using GPO, as UEM does not support that) to that particular folder, Windows will look in the original %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup location...

For now, my suggestion would be to add a value under HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce.

Thanks again, and apologies for the issue.

Reply
0 Kudos
Imitkov17
Contributor
Contributor
Jump to solution

UEMdev​,

For now I am using a Registry Setting that redirects the StartUp folder to the redirected Programs Menu folder <redirection share>\%USERNAME%\Programs Menu\Startup instead of the default %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup. That seems to work well. If no objections I will keep doing that. This way users can also add their own applications to the startup folder and I don't need to capture those using UEM.

Maybe in a future release you can add the StartUp folder as an option in Folder Redirection if the registry hack above proves to be a viable option.

DEMdev
VMware Employee
VMware Employee
Jump to solution

Although we use official API calls to configure folder redirection, tweaking the registry directly has pretty much the same effect. Just didn't want to suggest that, as it's slightly hacky 🙂 It should work just fine, though.

I'll pass your feature request along to PM, and I'll file a bug for the underlying issue.

Reply
0 Kudos
Imitkov17
Contributor
Contributor
Jump to solution

Thank you UEMdev​. It was pleasure working with you.

I have some other questions that I hope brainstorming with you and the community will lead to a solution that can help me and other fellow VDI-ers. 🙂 They are unrelated to this thread so I will open a new one.

Thanks again!

Ivo

DEMdev
VMware Employee
VMware Employee
Jump to solution

Imitkov17​: Just wanted to let you know that I just fixed the "Startup" bug (instead of creating the shortcut in a "Startup" sub folder of the (possibly redirected) Programs Menu, we'll create it in the actual "Startup" folder). This bug goes all the way back to the initial implementation of the shortcut creation feature which is now more than five years ago, so: good find 🙂

I can't make any statements regarding release dates, but you already found a functioning workaround for now. I've also filed your feature request about folder redirection for the Startup folder.

As for brainstorming on your other questions: by all means! But indeed, please start a separate thread for that (or maybe even multiple ones?), just to keep things clear. (And, most important, to be able to score some more Correct Answer points 🙂

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Just wanted to let everyone know that this bug has been fixed in UEM 9.2.1, which was released a few days ago.

Reply
0 Kudos