ADMX Policy to Allow Registry to run silently no longer working

[GTO455]

We have had an ADMX policy set since we created our VDI environment to disable registry editing for users, but still allow it to run silently.

It has been working fine until today when I logged into VDI and noticed that I could not see any history in Chrome or any bookmarks. It looks like it is happening for other apps too like MS Word.

Checking the DEM logs I found entries like this...

[INFO ] Importing profile archive 'Chrome.zip' (\\Server1\UEMProfiles$\User1\Archives\Applications\Chrome.zip)
[FATAL] Policy prevents access to registry editing tools -- please disable this policy
[FATAL] ImportRegistry::Import: Error creating command line
[FATAL] Error importing archive '\\Server1\UEMProfiles$\User1\Archives\Applications\Chrome.zip'

I verified it was the admx policy because I toggled the setting off and logged back into VDI and was able to see history for certain apps. And the errors in the DEM logs went away.

Has anyone else run into this? What was your approach to resolve it?

Environment into:

• Horizon 7.10
• DEM 9.9
• Windows 10 1909 VDI

[DEMdev]

Hi @GTO455,

To import registry settings, the DEM agent use regedit.exe by default. Depending on UAC settings, regedit.exe can't be used, in which case DEM switches to using reg.exe.

Both executables are controlled by that particular Group Policy setting, but with an important difference: reg.exe is not allowed to run if the setting is enabled, even if the sub-setting allows running silently...

If this was working fine previously, I assume that DEM was previously using regedit.exe, and a recent UAC-related change made it switch to reg.exe.

[GTO455]

Hi DemDev,

For clarification, are you saying I should disable UAC in the image ompletely? Currently, UAC is set to default. I checked our previous image and it is set the same way. I also checked the registry on both images and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA is set to 1.

Also, if I elevate my privs to Admin while in a VDI session, I can run regedit.exe from a CMD prompt.

[DEMdev]

Hi @GTO455,

No, please do not disable UAC on my behalf! 🙂

All I'm saying is that some UAC scenarios (I forget which) result in DEM not being able to launch regedit.exe. That's why we have the fallback to reg.exe, but unfortunately that is less configurable via Group Policy.

If you temporarily disable that regedit-related ADMX-based setting, do you see references to reg.exe in the DEM log file where previously (when things were still working correctly with that ADMX-based setting in place) you saw regedit.exe?

[GTO455]

If I disable the policy, I do see an entry in the logs for Chrome using reg.exe

2021-02-08 10:30:30.639 [INFO ] Importing profile archive 'Chrome.zip' (\\server1\UEMProfiles$\User1\Archives\Applications\Chrome.zip)
2021-02-08 10:30:30.645 [DEBUG] ImportRegistry::Import: Calling '"C:\Windows\System32\REG.EXE" IMPORT "C:\Users\User1\AppData\Local\Temp\FLX5054.tmp"' (RPAL: l=1 (P), r=0)
2021-02-08 10:30:34.934 [DEBUG] Read 1097 entries from profile archive (size: 9232980; compressed: 3111493; took 4290 ms; largest file: 733772 bytes; slowest import took 7 ms; registry took 140 ms)

I checked logs of other users and found that these errors do not exist with the policy enabled, which is weird. However, I delete my profile consistently during image testing, so that may have something to do with it.

[DEMdev]

Hi @GTO455,

OK, so that explains why you're getting the "Policy prevents access to registry editing tools -- please disable this policy" error messages if that ADMX-based setting is configured.

If your users don't get the error even if the ADMX-based setting is configured, I assume their logs show that regedit.exe is being used instead of reg.exe?

Also, I guess you're an admin and your users aren't? That would affect the UAC-related impact on DEM, which causes it to decide whether to user regedit.exe or reg.exe.

Would it be an option to put a condition on that ADMX-based setting to make it only apply to (non-admin) users?

[GTO455]

Hi @DEMdev 

I am not an admin in my environment (unless I elevate to admin) and neither are my users. And I am not elevating in this case.

As a test, I completely deleted my profile and logged in, basically as a new user. ADMX policy to prevent editing the registry is enabled and allowing registry tools to run silently is enabled.

I turned debugging on and I found in the log that regedit is in use successfully;

2021-02-08 11:58:52.603 [DEBUG] ImportRegistry::Import: Calling '"C:\Windows\REGEDIT.EXE" /S "C:\Users\User1\AppData\Local\Temp\FLX5AD4.tmp"' (RPAL: l=0 (F/E), r=1)
2021-02-08 11:58:52.654 [DEBUG] Read 1 entry from profile archive (size: 700; compressed: 288; took 58 ms)

However, further down the log, I see that I am still getting the error when launching Chrome

2021-02-08 12:00:47.018 [DEBUG] Found 'FlexDebug.txt' - changed log level to DEBUG
2021-02-08 12:00:47.018 [INFO ] Performing DirectFlex import for config file '\\Server1\UEMShare$\general\Applications\Chrome.ini' [IFP#ffc5e26c-49b0663>>]
2021-02-08 12:00:47.019 [DEBUG] User: Domain\User1 (A/L), Computer: VDI-059, OS: x64-win10 (Version 1909, BuildNumber 18363.1316, SuiteMask 100, ProductType 1/4, Lang 0409, IE 11.1198.18362.0, VMware VDM 7.10.0, App Volumes 2.18.0.25, DEM 9.9.0.905, ProcInfo 1/2/4/4, UTC-05:00S), PTS: 11012/11540/1C
2021-02-08 12:00:47.019 [DEBUG] Using profile archive '\\Server1\UEMProfiles$\User1\Archives\Applications\Chrome.zip'
2021-02-08 12:00:47.019 [DEBUG] Triggered by 'C:\Program Files\Google\Chrome\Application\chrome.exe'
2021-02-08 12:00:47.038 [INFO ] Importing profile archive 'Chrome.zip' (\\Server1\UEMProfiles$\User1\Archives\Applications\Chrome.zip)
2021-02-08 12:00:47.043 [FATAL] Policy prevents access to registry editing tools -- please disable this policy
2021-02-08 12:00:47.043 [FATAL] ImportRegistry::Import: Error creating command line
2021-02-08 12:00:47.044 [FATAL] Error importing archive '\\Server1\UEMProfiles$\User1\Archives\Applications\Chrome.zip'

[DEMdev · Accepted solution]

Hi @GTO455,

> I am not an admin in my environment (unless I elevate to admin) and neither are my users. And I am not elevating in this case.

That "A/L" in "2021-02-08 12:00:47.019 [DEBUG] User: Domain\User1 (A/L), ..." indicates that the user is an Admin with a Limited token (i.e. the non-elevated admin UAC scenario.) That's exactly what DEM checks for in its decision to use reg.exe instead of regedit.exe.

The log fragment you pasted was for a DirectFlex run. Does a path-based import at logon also show "A/L" in that "User: ..." line?

[GTO455]

@DEMdev 

OK, I found the issue, rather, YOU found the issue.

At some point in the past I must of added my normal user account into a group that has admin rights on the desktop for testing. Once I removed my user account from the Admins group, everything works as expected. Apologies for making you go in circles!

It was a beneficial exercise for me though. I picked up from another thread your trick for adding the flexdebug.txt file to the users profile to turn on debug mode. Very useful tip!

Thanks!

[DEMdev]

Hi @GTO455,

Happy to hear you tracked it down, with learning about FlexDebug.txt as a nice benefit 🙂

It's always a bit of a tricky combination to figure out, what with UAC affecting our choice of reg(edit), and that policy setting being interpreted differently between the two tools. At some point in the (far...) future I'd like to drop our dependency on reg(edit), but that's a non-trivial amount of work...