UEM Logoff GPO doesn't run

[vJoeG]

I've searched to see if someone else has encountered this but nothing in the Forums.

I have a situation where we have UEM 9.1 deployed to a Horizon View 6.2.2 environment.

Everything in UEM is working properly with the exception of the Logoff script in the GPO that executes flexengine.exe -s

As a current workaround we put a Local machine GPO logoff in the Base image for our linked clones pool and that is allowing the client to function.

Suggested the client call MS for AD/GPO troubleshooting. Currently client believes this is a UEM/VMware issue.

Any thoughts, feedback?

Thanks in advance

Joe

[Pim_van_de_Vis]

Any progress on this? Logoff scripts not running sounds like a MS problem. Have they contacted Microsoft?

[vJoeG]

We put the command in the local GPO for logoff to get them around this and we're no longer on the project.

I've been trying to reproduce in my lab but haven't been successful yet.

Will ping the client to see if they contacted MS and have an update.

[vmb01]

Hi

in my lab I have the very same situation: during logoff the "C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe -s "

is not executed even if I put it in User Configuration > Windows Settings > Scripts >  LOGOFF

If I execute it manually before logging off, UEM works like a sharm.

[Pim_van_de_Vis]

Did you configure the logoff script like this?

[vmb01]

Yes, in the same way

.

[mikeayoung]

Is there any update on this?

I have a customer in the same position where application changes aren't captured at logoff.

Customer is running Horizon 7.02, UEM 9.3 and AppVol 2.12

When using a standard user the logoff script for UEM doesn't run. However if you add the user to Local Administrators the logoff script works and captures application changes.

Have tried setting the UEM logoff script as a Local GPO but still doesn't work.

If the user runs the flexengine command from within the VDI sesson the application modifications are captured.

Permissions on the profile share have been checked and checked again.

Not sure what else to modify to get a standard user to run the logoff script via the GPO.

Any suggestions?

[sjesse]

Check the GPOs, anyone who has the problem is the loopback mode set to replace. IF you look at the defination of the replace mode

Replace Mode

In this mode, the user's list of GPOs is not gathered. Only the list of GPOs based on the computer object is used.

https://support.microsoft.com/en-us/help/231287/loopback-processing-of-group-policy

I'm using UEM in NoAD mode, but I have one GPO on all my computer objects setting this, to do exactly what it says. I have no user based policies running, and anything I need runs through UEM or local policies. I can see if loopback is set to replace there may be a way that your removing the logoff script with this setting.

[DEMdev]

Hi mikeayoung,

Can you attach a registry export of HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts?

[mikeayoung]

Hi UEMdev,

Attached is an export of the registry key requested.

Just as a note I could only get this if I added the test user to the local administrator group, if I tried to browse to the registry key with out local admin I got an access denied error.

Not sure if this is what might be causing the issue but have the Windows guys looking into maybe a permissions issue.

I have checked that the mandatory profile has Authenticated Users with Full Control which it does.

Regards,

Mike

[mikeayoung]

Hi UEMdev,

Have checked the mandatory profile down to the key level as posted by you and found that Authenticated User wasn't at this level just a broken SID link.

Reapplied Authenticated User from the top level of the loaded hive and now my test user can read the registry key.

Not sure why this had happened as the customer had created the mandartory profile.

Tested application modifcation could be captured after the mandatory profile update which is now possible.

Thank you for pointing me to what I had over looked.

The logoff script is now working. :smileycool:

Many thanks,

Mike

[DEMdev]

Hi mikeayoung,

Happy to hear that it works now!

Also, thanks for mentioning that it was caused by registry permissions. I'm considering adding some logic in the UEM agent to validate that a logoff script is configured (correctly) – this is a good reminder that I also should take permissions into account 🙂