Lieven
Enthusiast
Enthusiast

Appvolumes causes problems with UEM

Hi DEMdev​ and ijdemes

I have some issues with DEM when appstacks are being attached:

1. The error "Async DEM actions or user environment settings refresh in progress" is logged in my log file. (similar issue as UEM applied Shortcuts - How to you DEL them from the desktop ? )

It seems that the async operations don't end. I can not open the async log as it is in use by another process. The only way to open it is to kill the VMware DEM engine process.

2. Printers and not being mapped: i followed VMware Knowledge Base

3. Elevated tasks do not run as expected

I am using the latest version of DEM (2006) and AppVolumes 2.18

Do you have any idea what could be wrong here?

0 Kudos
11 Replies
DEMdev
VMware Employee
VMware Employee

Hi Lieven,

When the async instance of FlexEngine.exe hangs, that's usually due to a hanging printer mapping. That, in turn, might be related to App Volumes restarting the print spooler service. There are checks in DEM that try to deal with printer mapping issues caused by changes in the spooler service's state, but those can't handle each and every scenario, unfortunately.

The most robust workaround for this would be to skip mapping printers during logon, and postpone that till the moment App Volumes has completed attaching its AppStacks:

  • Use the advanced ADMX template (or the NoAD equivalent​​ UEMActionPrinterMappingDuringLogon="0") to disable printer mappings during logon:
    pastedImage_3.png
    (Make sure to pick the "during logon" variant, or printer mappings will be skipped always.)
  • Configure a triggered task to refresh (well, more like process for the first time, in this case) printer mappings when all AppStacks are attached:
    pastedImage_9.png

As for "Elevated tasks do not run as expected": what happens, exactly?

Lieven
Enthusiast
Enthusiast

Hi DEMdev​,

I tried the suggestion that you gave me around printers:

  • when an appstack is being attached: works 50% of the time
  • when no appstacks are being attached: works 100% of the time

With the elevated tasks: same here:

  • when an appstack is being attached: works 50% of the time
  • when no appstacks are being attached: works 100% of the time

I now adjusted the triggered task to not only refresh printers when all appstacks are attached, but also refresh the privilege elevation settings. I'll see what it gives tomorrow

2020-08-21_09-22-44.jpg2020-08-21_09-22-25.jpg

The script I am using in the elevated task is a simple bath file that copies some files over from the netlogon share to the VDI and stop/start a service (See https://www.ituda.com/fslogix-copy-application-masking-rules-with-vmware-dynamic-environment-manager... )

copy /Y \\dc-01\netlogon\FSLogix\*.fx* C:\"Program Files"\FSLogix\Apps\Rules

net stop frxsvc

net start frxsvc

exit

0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi Lieven,

After implementing the workaround, what exactly is the failure mode if printer mapping does not work correctly? Same as before, as in: async FlexEngine.exe instance hangs, or something else?

Does this seem related to a particular printer? Can you "divide and conquer", by temporarily disabling individual printer mappings in DEM to see if there's a particular problematic one?

How do elevated tasks fail? Does DEM's log indicate success with running your logon task and the referenced elevated task, but does the script not have the intended effect?

If you launch that batch file from a command prompt that you have elevated "manually" (as in, Run as Administrator via standard Windows functionality), does it always work?

BTW, refreshing does not serve a purpose here, unless you have modified elevated task definitions in the Management Console in the meantime.

0 Kudos
Lieven
Enthusiast
Enthusiast

Hi DEMdev

After implementing the workaround, what exactly is the failure mode if printer mapping does not work correctly? Same as before, as in: async FlexEngine.exe instance hangs, or something else?

Same as before: async FlexEngine.exe instance hangs

You will see in the attached async log, that it suddenly stops logging. From that moment on I am unable to open the fog file as it is in use by another process. After the user logs off and the machine is deleted by Horizon vIew, I can access the log again.

Does this seem related to a particular printer?

Not 100% sure, but I have the impression that it might be related to printers that are offline at the moment we are trying to map

Can you "divide and conquer", by temporarily disabling individual printer mappings in DEM to see if there's a particular problematic one?

Very difficult to do as I am working remote and it's hard to choose a "victim" to test. Additionally there's about 80 printers around

How do elevated tasks fail? Does DEM's log indicate success with running your logon task and the referenced elevated task, but does the script not have the intended effect?

According to the blogs, the elevated task launched successfully. Attached are the logs

If you launch that batch file from a command prompt that you have elevated "manually" (as in, Run as Administrator via standard Windows functionality), does it always work?

Yes, this always works

BTW, refreshing does not serve a purpose here, unless you have modified elevated task definitions in the Management Console in the meantime.

Ah, yes. That's true. My mistake.

0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi Lieven,

Looks like the "Disable DEM Printer Mappings during logon" policy setting did not get applied. If it had been, there would have been a

[DEBUG]    Disabled DEM actions: Printer Mapping (during logon)

message in the log. Also, the log shows that the printers were processed during the normal logon:

2020-08-21 07:45:43.995 [INFO ] Starting FlexEngine v10.0.0.945 [IFP#44857c0e-T5>>]

2020-08-21 07:45:43.995 [INFO ] Running as Group Policy client-side extension

2020-08-21 07:45:43.995 [INFO ] Performing path-based import

[...]

2020-08-21 07:45:51.544 [DEBUG] Processed 98 DEM printer mappings (3 scheduled, 77 skipped, 18 disabled)

Elevated task: the DEM logs indeed seem to indicate that the logon task ran successfully, as well as the elevated task itself. I'd suggest to have your batch file redirect its output and error output to a log somewhere, to see if that helps identify what's going on here.

jhol5
Enthusiast
Enthusiast

We are also using DEM 2006 and are having the same issues. After about a month support suggested the same thing @DEMdev did. Did you use DEM to deploy the skip printer mapping on login gpo through AD or DEM?

 

We originally were trying to use DEM to deploy the setting but were still seeing async tasks and such hang. I didn't know about the "Disabled DEM actions: Printer Mapping" message that DEMdev stated so I went looking for that. Turns out you can't deploy the setting using DEM.

0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi @jhol5,

> Turns out you can't deploy the setting using DEM.

As this configuration setting affects the behavior of the DEM agent itself, it can indeed not be configured using DEM. You'd have to add it to your DEM GPO or NoAD config, depending on the agent configuration mechanism you're using.

0 Kudos
Eric_Xing1
Contributor
Contributor

Hi @DEMdev ,

We got the exactly printer async mapping issue when AppV involved. Couple questions here:

1. To make the change on "disable printer mappings during logon", do we have to change it on the image? 

2. Do we need apply this KB for this workaround? (https://kb.vmware.com/s/article/2137401)

3. How can we map the printer to AppV user and non-AppV user if they share the same image? Since the trigger won't work for those non-AppV users.

Thanks,

Eric

 

0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi @Eric_Xing1,

  1. No need to tweak the image – you configure this in GPO (using the advanced ADMX template) or in the NoAD.xml file on your config share if you're using NoAD mode.
  2. My guess is that that shouldn't be necessary, and that postponing DEM printer mapping to when all AppStacks have been attached should be sufficient. But please realize that I pretty much only know DEM, so take my opinion on App Volumes with a grain of salt 🙂
  3. You could create a shortcut in the Startup folder of your non-App Volumes users to launch "FlexEngine.exe -UEMRefreshPrinters", similar to the triggered task action.
Eric_Xing1
Contributor
Contributor

Hello @DEMdev 

thanks for your reply and the workaround works for us as you mentioned. And we don't need use APPV to trigger the async. The shortcut in startup works for both APPV and nonAPPV users.

Another question: If we deselect mapping the printers through Async, will this change affect the login performance? (we have about over 100 network printer mapping on different endpoint clients)

Thanks,

Eric

0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi @Eric_Xing1,

The shortcut in startup works for both APPV and nonAPPV users.

In the App Volumes case, that shortcut might be launched before all volumes have been attached, though. That's why we added that particular trigger 🙂

> If we deselect mapping the printers through Async, will this change affect the login performance?

Mapping printers takes a bit (to a lot) of time, so doing that synchronously will definitely affect logon performance. Also, those synchronous mappings will still take place in parallel with some of App Volumes' processing, possibly resulting in similar issues as you're currently experiencing.

0 Kudos