VMware Horizon Community
TAB_ROCvT
Contributor
Contributor
Jump to solution

UEM Windows 10 Start Menu not working with APP-V 5

Hello,

We are using UEM 9.4 icm Windows 10 1709 on VDI and normal desktops.

After implementing https://kb.vmware.com/s/article/2150422 we are having a problem with loading de shortcuts of the App-V 5 applications.

When the user logs on, the shortcuts is loaded and available in “AppData\Roaming\Microsoft\Windows\Start Menu\Programs”, but is not shown in de Start Menu.

After a logoff and new logon, the shortcut is shown in de Start Menu.

When we disable the Start Menu layout profile, the new App-V 5 applications are shown in the Start Menu with the first logon.

We can’t find wat is keeping the Start Menu form refreshing the shortcuts.

Has someone had the same problem and fixed this?

1 Solution

Accepted Solutions
TAB_ROCvT
Contributor
Contributor
Jump to solution

Hello UEMdev,

Sins the last post, we made some changes and now the Windows 10 Start Menu is working good with App-V 5.

The changes we made are:

- Updated to UEM 9.4.0.

- Switched to run UEM as a Group Policy client-side extension.

- Tested all the UEM-profiles and modified them to work with UEM as a Group Policy client-side extension.

This took a lot of time, but now the profiles load and save good and the Start Menu is updated at logon.

Thx for the help UEMdev.

View solution in original post

12 Replies
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi TAB_ROCvT,

Does the Start Menu behave any better if you use the Windows 10 Start Menu Windows Common Setting

pastedImage_3.png

rather than the config specified in that KB article?

0 Kudos
TAB_ROCvT
Contributor
Contributor
Jump to solution

Hi UEMdev,

We tryed that too, but same effect and got errors in the flexengine.log.

error win 10 start menu.JPG

Here is the settings for the profiel for this log.

[IncludeRegistryTrees]

HKCU\Software\Microsoft\Windows\CurrentVersion\CloudStore

[IncludeIndividualRegistryValues]

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\EnableAutoTray

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\SlowContextMenuEntries

[IncludeFolderTrees]

<LocalAppData>\Microsoft\Windows\Caches

<LocalAppData>\Microsoft\Windows\CloudStore

<LocalAppData>\Microsoft\Windows\Explorer

Looks like the "<LocalAppData>\Microsoft\Windows\Explorer" adds files that are in use when the user is logging on and can't be replaced by UEM.

0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Looks like the "<LocalAppData>\Microsoft\Windows\Explorer" adds files that are in use when the user is logging on and can't be replaced by UEM.

Hmmm, interesting... How are you running UEM at logon? As a Group Policy client-side extension, or in NoAD mode? Can you share a log file (at log level DEBUG) covering the full logon, either in this thread or via a private message?

0 Kudos
TAB_ROCvT
Contributor
Contributor
Jump to solution

We are running UEM at logon.

As a logon-script and not as a group policy client-side extension or in NoAD mode.

The reason for this is, because we use App-V 5 applications and if we then run UEM as a group policy client-side extension or in NoAD mode, the App-V 5 user setting are not captured by UEM.

Log file is added.

0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Since you're running as a logon script, but (as the path-based export log fragment indicates) Policy "Run logon scripts synchronously" is not configured, UEM is importing settings while Explorer is starting – hence the access denied errors on some Explorer files.

Can you elaborate on the issue you see with capturing settings for App-V 5?

0 Kudos
TAB_ROCvT
Contributor
Contributor
Jump to solution

We looked at the settings for the UEM client and found that in our production environment we have the Policy "Run logon scripts synchronously" configured and there the errors are not in the log.

The log we send is from our test environment and there we found it was not configured.

We changed the policy, so it is the same and now the errors are also not in the log of the test environment.

Still the problem with the shortcuts remains.

The problem was first reported in de production environment and we are troubleshooting it in the test environment.

First to elaborate about the issue we seen with capturing settings from App-V 5 applications.

When we run UEM As a Group Policy client-side extension, with some App-V 5 applications there was no profile created or the settings where not added to the profile.

An example was 7-ZIP, we have it as an App-V 5 application with file type association and shell extension for the right click menu’s.

We use the UEM settings below.

[IncludeRegistryTrees]

HKCU\Software\7-Zip

HKCU\Software\Microsoft\AppV\Client\Packages\7b09c68f-97e2-44ba-b089-43deadcf239d\REGISTRY\USER\S-1-5-21-1384873935-1042564227-850052234-85394\Software\7-Zip

DirectFlex is on, App-V 5.0 support is enabled and set to the file “7zFM.exe”.

Changes made to the settings of 7-ZIP are not captured by UEM when we run it as a Group Policy client-side extension and are captured by UEM when we run it as a logon script.

We have tested this with more applications and had the same result, so we run it as a logon script.

I hope this helps to elaborate the issue for App-V 5 settings and why we are running UEM as a logon script.

Now about the shortcuts, we tested some more and even shortcuts added by UEM are not shown in the Start Menu after the first logon, but are available in “AppData\Roaming\Microsoft\Windows\Start Menu\Programs” when the profile “Windows 10 Start Menu” is active.

You have to logoff and logon again to see the new shortcuts in the Start Menu.

When we disable the profile, all App-V 5 and UEM shortcuts are available after the first logon, nog logoff and logon is required.

We tested this on the following system types:

Windows 10 Enterprise 1709 build 16299.248 with UEM client 9.4.0

Windows 10 Enterprise 1803 build 17134.286 with UEM client 9.4.0

0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

We use the UEM settings below.

[IncludeRegistryTrees]

HKCU\Software\7-Zip

HKCU\Software\Microsoft\AppV\Client\Packages\7b09c68f-97e2-44ba-b089-43deadcf239d\REGISTRY\USER\S-1-5-21-1384873935-1042564227-850052234-85394\Software\7-Zip

With UEM's App-V integration, you can just use the "normal" registry and file system paths; you don't need to capture the locations that App-V has redirected.

Can you try with just the "normal" profile locations, and see whether that fixes the issue with (not) capturing settings for App-V applications?

0 Kudos
TAB_ROCvT
Contributor
Contributor
Jump to solution

With UEM's App-V integration, you can just use the "normal" registry and file system paths; you don't need to capture the locations that App-V has redirected.

Can you try with just the "normal" profile locations, and see whether that fixes the issue with (not) capturing settings for App-V applications?

Thanks for this info, but as you can see we also have the "normal" registry.

The App-V registry location is extra and we just checked one of the profile zip files and only the "normal" registry is captured.

Sorry but we don't see the connection between this and the Windows 10 Stat Menu profile and new shortcuts not shown in the Start Menu after logon.

Do you mean that the Windows 10 Start Menu profile will not work if we run UEM as a logon script?

0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

I don't see a connection between App-V settings and the Start Menu, but I can very well imagine that running UEM from a logon script could be too late for the Start Menu.

0 Kudos
TAB_ROCvT
Contributor
Contributor
Jump to solution

Hello UEMdev,

We tested with running UEM as a Group Policy client-side extension and now the shortcuts of new AppV-5 applications are shown in the Start Menu after logon.

So there is an problem with the buildup/refresh of the Start Menu, when you run UEM as a Logon Script, running UEM as a Group Policy client-side extension solves the problem.

But running UEM as a Group Policy client-side extension gives us problems with some of the AppV-5 applications we have.

For example the application Yenka.

We use the profile:

[IncludeRegistryTrees]

HKCU\Software\crocodile-clips.com

HKCU\Software\Trolltech

DirectFlex is enabled, AppV-5 support is enabled and it is looking at the executable “Yenka.exe”.

With UEM as a logon script it will make a zip-file and with the same profile and UEM as a Group Policy client-side extension, there is no zip-file created.

In total we have 13 applications that don’t work anymore when we switch to Group Policy client-side extension.

List of the applications that don’t work.

  • CDburnerXP
  • Claroread Pro
  • Codesys
  • Filemaker
  • Irfanview
  • LogoSoftComfort
  • MPlabIDE
  • Snagit
  • VLC Player
  • Winfact
  • WinSCP
  • XprotectSmart
  • Yenka

So with UEM running as Logon Script we have problems and running UEM as a Group Policy client-side extension gives us other problems.

We can switch to Group Policy client-side extension, but we need to fix the problems with the profiles of these applications first.

Any advice what can be the problem with some of the AppV-5 applications?

0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi TAB_ROCvT,

For the App-V 5 apps, do you see the DirectFlex launch and exit logging in the "main" log file, and the details for the import and export in the -AppV5 log?

0 Kudos
TAB_ROCvT
Contributor
Contributor
Jump to solution

Hello UEMdev,

Sins the last post, we made some changes and now the Windows 10 Start Menu is working good with App-V 5.

The changes we made are:

- Updated to UEM 9.4.0.

- Switched to run UEM as a Group Policy client-side extension.

- Tested all the UEM-profiles and modified them to work with UEM as a Group Policy client-side extension.

This took a lot of time, but now the profiles load and save good and the Start Menu is updated at logon.

Thx for the help UEMdev.