Asynchronous Printer Mapping fails to remove at logoff

[rcscott44]

Hi,

We are using UEM 9.6 with Horizon 7.7, AppVolumes 2.15 and Writable UIA+ Profile (I already know UEM and UIA + Profile is not recommended, but we have a few business critical apps that UEM cannot profile fully)  Our desktop pool is Win10 LTSC 2019. We are assigning network printers through UEM with conditionals set by Client pc hostname (all clients are named based on a location code.)  All Printer Mappings are set to be asynchronous mounting and remove at logoff. 

The challenge I am running into is that the VDIs are logging off before the printers are unmounted.  Then when a user logs in again, UEM fails to update the printer mappings and the legacy mapping shows printer unavailable.  We run asynchronously because about 7% of logins have the print spooler restarted by AppVolumes before network printers are fully mapped and UEM hangs.   We replaced our UEM Refresh desktop icon with a script that kills any existing UEM Flexengine process and then runs ...\flexengine.exe -uemrefresh.  That solves the failed printer mappings for the user.   When we try to map printers synchronously with logon, those 7% of users never logon because UEM has hung.  However, if the user does logon correctly, printers mount as expected, and are always properly unmounted at logoff.

Is there any way to map asynchronously at logon, but force the unmapping to complete before the VDI can be logged off?  Or is there way to force a pause in the logoff process that grants enough time for the asynchronous printer unmap to complete?

Thanks,

Bob

[DEMdev]

Hi rcscott44,

Regardless of whether a printer is mapped synchronously or asynchronously, the undo at logoff is always synchronous, so there is no need to "force a pause" to get that to complete. For the cases where printers fail to unmap (completely), does UEM run to completion at logoff, i.e. does the log file end with a message like [INFO ] Done (67 ms) [<<IFP#7d548623-T5]? Are you maybe also managing printer-related settings via a personalization config file?

As for your trick to kill any running FlexEngine processes and perform a printer refresh, it might be worth a shot to look at the Disable UEM Printer Mappings during logon policy setting from the Advanced Settings ADMX template instead:

If you configure that setting, printer mappings are not processed during logon. You can configure a Triggered Task to refresh (or, in this case, "process") the printer mappings, based on the All AppStacks attached trigger.

[rcscott44]

Thanks,

When the printer fails to unmap, we do not see a completion message in the logs.  I see the network drives detach, and profile info being uploaded, but no printer unmapping or [Info[ Done message.

We will give the "Disable UEM Printer Mappings at logon" a try.  However, I am not sure it will solve the unmapping problem.

-Bob

[DEMdev]

Hi rcscott44,

If you don't see the "Done" log message that means that UEM either crashed at logoff or was forcefully terminated by something. How long does the export at logoff take if it's successful?

Even though this is a non-persistent setup: any chance of getting to the Windows event logs to see if there's anything interesting there?

[VDINinja311]

rcscott44​

I believe we are seeing the same issue with UEM hanging during logon due to the run asynchronously being unchecked which is preventing some user logons from completing all the way. (We will see desktops in Horizon admin that have appstacks attached but the desktop is still set to Available). The end user side it will hang at Welcome or Preparing windows until the UEM client side processing bombs out at 60 minutes (must be a default timeout). Is this your symptom, when this is happening?

We are only unchecking the run asynchronously setting for some mapped printers because it was preventing the default printer to be set correctly and unchecking that setting was "fixing" it, but I bet this is a side effect of the setting.

Almost to the point of installing all of the same drivers that are on our Print Server on the Master Image so it maps the printers much faster.

[rcscott44]

UEMdev​

When it completes normally, our times are 7-14 seconds for UEM export.  I have seen one or two outliers that were close to 3 minutes (1 in 1000+), but almost all of them involved exporting browser AppData (Chrome, Firefox, etc)  When we have a user with printer mapping issues, the flexengine log will not show a "path-based export" was even attempted.  It will show an import process, followed directly be another import process.

VDINinja311​

Yes, that is the same idea, but we know why that happens and eliminate the failed logon by running all printer attachments asynchronously (normally).  AppVolumes restarts the print spooler when the last volume is attached.  If that happens while a network printer is being mapped by UEM, the UEM agent hangs.  When running asynchronously, the logon continues, but the printer never maps correctly.  If you uncheck the asynchronous setting, then the logon fails as you describe (in our case about 7% of the time) 

-Bob

[rcscott44]

I have deployed the ADMX setting to block printer mapping at logon (I had to find and download it, odd that the advanced ADMX is not part of the full UEM AMDX...) and have deployed the triggered task to refresh UEM-printers once all volumes attached.  No reports of issues yet, but its only been 1/2 a day.  I will test for another day or two before calling that an answer.

I am curious how this is actually different then running printer mappings asynchronously.  If UEM triggers a refresh as soon as all volumes attach, which is the same trigger for print-spooler restart, what is to prevent the UEM refresh from hanging like the asynchronous mapping does?

-Bob

[DEMdev]

Hi rcscott44,

"All AppStacks Attached" fires after the AppVolumes agent has restarted the spooler. I'm not sure whether that means that the spooler has "completed" its restart, but this definitely changes the overall timing of UEM's printer mapping actions and that restart. But, as mentioned before, I did not consider this a potential fix for the issue, just a slightly cleaner approach to your current printer-mapping-hanging-at-logon workaround.

Still, let's see what happens over the next few days...

[rcscott44]

Unfortunately this has not resolved the issue.  It may have actually made the resolution more difficult.  Now, we need to restart the print spooler manually to be able to refresh the printer and restore service.

Everything seems to point to a conflict with the print spooler restart at logon.  My next attempt at a fix is to try a delay of the spooler restart via App Volumes. 

Unless there is a better way via UEM.

[DEMdev]

Hi rcscott44,

Sorry to hear that. I'd be interested to see the printer-mapping-related log entries in the UEM debug log.