UEM 9.0 Import Never Runs on Physical Desktop

[VDIMega]

I installed UEM agent on a physical desktop for testing, and I find that the Import never runs.  The export runs, but the flexengine.log file says the import failed so it cannot export.  That means that the logoff script is working, but for some reason "flexengine.exe -r" is not running on login.

If I manually run "flexengine.exe -r" after I log in, the import happens, but its obviously too late to matter at this point.

I double-checked and gpresult shows "Run FlexEngine as Group Policy Extension" is enabled.  Therefore I should not need a logon script to run "flexengine.exe -r" manually.

Does anyone know what could cause the flexengine.exe to not read the UEM config at logon?  This works perfectly fine on the virtual desktops.

[VDIMega]

I checked the group policy logs and it appears that the client-side extension for UEM is not being detected.  There are no errors in there so I don't understand why this is.

[Pim_van_de_Vis]

Have you enabled the computer GPO 'always wait for the network at computer startup and logon'?

This is needed for the GP Extension to work correct.

[VDIMega]

Yes, that GPO setting is applying.

This is now happening on two desktops.  if I do a repair install of the UEM agent, then it works fine.  These machines are deployed from a Mirage base layer.  I didn't get any errors in Mirage when assigning the base layer to the desktops, but it appears that there is something going wrong when the UEM agent comes from a mirage base layer.  Has anyone else experienced this?

[VDIMega]

I found that the following registry values exist on the machines where the UEM agent works, but not on the machines where the UEM agent does not work:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{007F7799-28F8-4c22-AF9D-C80E8555723E}]

@="VMware UEM FlexEngine"

"DllName"=hex(2):43,00,3a,00,5c,00,50,00,72,00,6f,00,67,00,72,00,61,00,6d,00,\

  20,00,46,00,69,00,6c,00,65,00,73,00,5c,00,49,00,6d,00,6d,00,69,00,64,00,69,\

  00,6f,00,5c,00,46,00,6c,00,65,00,78,00,20,00,50,00,72,00,6f,00,66,00,69,00,\

  6c,00,65,00,73,00,5c,00,46,00,6c,00,65,00,78,00,45,00,6e,00,67,00,69,00,6e,\

  00,65,00,2e,00,64,00,6c,00,6c,00,00,00

"NoBackgroundPolicy"=dword:00000001

"ProcessGroupPolicy"="ProcessGroupPolicy"

If I import that key and those values into the desktop where UEM doesn't work, the problem goes away.  Is there a better way than this?

[HartmutEhl]

Did you check the Event log for policy errors?

e.g. there is a known problem with  "Mutual Authentication" that can prevent this policy from being applied

[VDIMega]

Yes there are no errors in the Microsoft --> Windows --> Group Policy events.  My last post shows that for some reason Mirage isn't putting in the registry key and values for enabling the GP extension.  Maybe I should post this in the Mirage forum.

[VDIMega · Accepted solution]

I found the problem:

by default, Mirage does not capture the [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon] key in a layer.  I'm going to test and see if its safe to use a layer rule that includes just this specific registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{007F7799-28F8-4c22-AF9D-C80E8555723E}]