Printer Mapping Refresh Issue

[simpss]

I'm using DEM 9.11 in a new Horizon environment using published apps and testing printer mappings for floating users.

Current Scenario:

- User1 logs on to Endpoint A and receives "Printer01" from the conditions of endpoint name. (Printer is successfully mapped)

- User1 moves to another department and logs in to Endpoint B where "Printer02" gets mapped from the conditions of endpoint name. (Printer is successfully mapped). The old printer mapping (Printer01) still appears in the printer list.

- If User1 disconnects and logs in again on Endpoint B, Printer01 will disappear.

Just curious as to why I would need to reconnect twice to the same endpoint to undo the previous printer mappings?

The printer Mapping Settings are configured to "Run asynchronously" and also "Undo at logoff and refresh during printer mapping refresh"

I have a triggered task to refresh printer mappings at Session Reconnect.

I have attached the debug log incase I am missing something.

Anyone's input would be much appreciated!

[DEMdev]

Hi simpss,

At logon, we see that the IT Lunch Room printer is skipped due to conditions (line 5 below), and that Test Printer is scheduled to be mapped asynchronously (line 7):

2020-06-16 08:39:53.129 [INFO ] Performing path-based import
[...]
2020-06-16 08:39:53.308 [DEBUG] Skipping disabled DEM printer mapping ('IS01 to Computer GP - Test.xml')
2020-06-16 08:39:53.310 [DEBUG] Conditions: Check for endpoint name = false ('VDIKIOSK01' is not equal to 'VDIKIOSK02')
2020-06-16 08:39:53.310 [INFO ] Skipping printer mapping due to conditions ('IT Lunch Room.xml')
2020-06-16 08:39:53.311 [DEBUG] Conditions: Check for endpoint name = true ('VDIKIOSK01' is equal to 'VDIKIOSK01')
2020-06-16 08:39:53.311 [INFO ] Scheduled printer mapping for async processing ('Test Printer.xml')
[...]
2020-06-16 08:39:53.954 [DEBUG] Processed 3 DEM printer mappings (1 scheduled, 1 skipped, 1 disabled)
[...]
2020-06-16 08:39:54.001 [INFO ] Done (872 ms) [<<IFP#02bc10ba-T5]

The effective result (line 9) is that we scheduled one printer to be mapped.

At refresh, we collect undo information for the previously mapped Test Printer (line 3), schedule IT Lunch Room for async mapping as its conditions now match, and skip Test Printer as those conditions no longer match (line 8.)

We then unmap Test Printer (line 9), using the undo info collected previously.

2020-06-16 08:40:37.823 [INFO ] Performing user environment settings refresh [IFP#9a1db5d9-20e263f>>]
[...]
2020-06-16 08:40:37.862 [DEBUG] User environment settings refresh: Collected 1 DEM printer mapping undo action
2020-06-16 08:40:37.864 [DEBUG] Skipping disabled DEM printer mapping ('IS01 to Computer GP - Test.xml')
2020-06-16 08:40:37.869 [DEBUG] Conditions: Check for endpoint name = true ('VDIKIOSK02' is equal to 'VDIKIOSK02')
2020-06-16 08:40:37.869 [INFO ] Scheduled printer mapping for async processing ('IT Lunch Room.xml')
2020-06-16 08:40:37.871 [DEBUG] Conditions: Check for endpoint name = false ('VDIKIOSK02' is not equal to 'VDIKIOSK01')
2020-06-16 08:40:37.871 [INFO ] Skipping printer mapping due to conditions ('Test Printer.xml')
2020-06-16 08:40:37.873 [DEBUG] Successfully unmapped printer '\\nbyvprt03\IS08' ('Test Printer.xml')
[...]
2020-06-16 08:40:37.877 [DEBUG] Processed 3 DEM printer mappings (1 scheduled, 1 skipped, 1 disabled; 1 undo action (1 successful))
[...]
2020-06-16 08:40:37.877 [INFO ] Done (54 ms) [<<IFP#9a1db5d9-20e263f]

The effective result (line 11) is that we scheduled one printer to be mapped, and undid/unmapped another.

In the second refresh, we do pretty much the same, but now notice on line 6 that IT Lunch Room still applies (i.e. conditions say that it should be mapped, but undo info from line 3 indicates that that is already the case.) Conditions for Test Printer still do not match, so we skip it (line 😎 – no need to unmap it this time, as it's no longer showing in the undo info.

2020-06-16 08:41:46.487 [INFO ] Performing user environment settings refresh [IFP#55724af9-20e263f>>]
[...]
2020-06-16 08:41:46.527 [DEBUG] User environment settings refresh: Collected 1 DEM printer mapping undo action
2020-06-16 08:41:46.534 [DEBUG] Skipping disabled DEM printer mapping ('IS01 to Computer GP - Test.xml')
2020-06-16 08:41:46.543 [DEBUG] Conditions: Check for endpoint name = true ('VDIKIOSK02' is equal to 'VDIKIOSK02')
2020-06-16 08:41:46.543 [INFO ] Printer mapping still applies -- not refreshing ('IT Lunch Room.xml')
2020-06-16 08:41:46.550 [DEBUG] Conditions: Check for endpoint name = false ('VDIKIOSK02' is not equal to 'VDIKIOSK01')
2020-06-16 08:41:46.550 [INFO ] Skipping printer mapping due to conditions ('Test Printer.xml')
2020-06-16 08:41:46.550 [DEBUG] Processed 3 DEM printer mappings (1 still applies, 1 skipped, 1 disabled)
[...]
2020-06-16 08:41:46.551 [INFO ] Done (63 ms) [<<IFP#55724af9-20e263f]

The effective result (line 9) is that we did not make any changes.

As a matter of fact, we did not call any printer-related Windows functions for that second refresh (as there was nothing to map or unmap), so it's really confusing that Test Printer only disappears by this time.

I'm not at all familiar with printing on RDSH – hoping that someone else in this forum might have any ideas...

[simpss]

Hi DEMdev​​, thanks for the reply and looking into the Debug log.

I do find it strange that the log shows the printer successfully unmapped, but doesn't disappear until a disconnect/reconnect again.

Hoping to find some helpful input.

[DEMdev]

Hi simpss​,

I do find it strange that the log shows the printer successfully unmapped, but doesn't disappear until a disconnect/reconnect again.

I couldn't agree more – it's quite strange.

If you are willing to do some more testing, we can try and pinpoint whether it's the second disconnect/reconnect or the second DEM printer refresh that makes the printer disappear.

The latter is the easiest to test: after the "first refresh" where you see both the correct and the incorrect printer, does the incorrect one disappear after you run "C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -uemrefreshprinters within that session?

For the other test: while seeing both the correct and the incorrect printer, can you temporarily disable your Refresh Printers at reconnect triggered task in the DEM Management Console, run "C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -uemrefreshtriggeredtasks within the RDSH session, and then disconnecting and reconnecting? DEM should no longer perform a printer refresh at reconnect, and I'd be interested to know whether "just" the reconnect affects the issue you're seeing. (Oh, and don't forget to re-enable your triggered task after this test...)

[simpss]

DEMdev​

The latter is the easiest to test: after the "first refresh" where you see both the correct and the incorrect printer, does the incorrect one disappear after you run "C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -uemrefreshprinters within that session?

The old printer remains after I run "C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -uemrefreshprinters
Once I disconnect/reconnect from the same endpoint, the old printer disappears again.

***If I perform the same steps above (both printers visible but the triggered refresh task disabled) and manually run the -uemrefreshprinters it works!

For the other test: while seeing both the correct and the incorrect printer, can you temporarily disable your Refresh Printers at reconnect triggered task in the DEM Management Console, run "C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe" -uemrefreshtriggeredtasks within the RDSH session, and then disconnecting and reconnecting? DEM should no longer perform a printer refresh at reconnect, and I'd be interested to know whether "just" the reconnect affects the issue you're seeing. (Oh, and don't forget to re-enable your triggered task after this test...)

When I perform this task when both printers are visible and the triggered task disabled. A disconnect and reconnect again solves the issue. :smileyconfused:

[DEMdev]

Hi simpss,

Thank you for testing, even though the results are kind of weird

If I perform the same steps above (both printers visible but the triggered refresh task disabled) and manually run the -uemrefreshprinters it works!

You mean:

• Logon (get one printer)
• Reconnect from different client (nothing changes, as you don't have a triggered task configured)
• Manual -uemrefreshprinters: get the other printer, without the initial one?

[simpss]

DEMdev​

You mean:

• Logon (get one printer)
• Reconnect from different client (nothing changes, as you don't have a triggered task configured)
• Manual -uemrefreshprinters: get the other printer, without the initial one?

That's correct! If I disable the triggered tasks and manually run -uemrefreshprinters. This works every time. I'd assume that the triggered task would work in a similar fashion when enabled?

[DEMdev · Accepted solution]

Hi simpss,

If I disable the triggered tasks and manually run -uemrefreshprinters. This works every time.

That's so strange...

I'd assume that the triggered task would work in a similar fashion when enabled?

... because that is indeed exactly what that triggered task does...

Looks like there's some timing issue at play here. Can you try switching your triggered task (at least for the printer refresh part) from performing a user environment refresh to running a custom command, pointing to a batch file that first waits a few seconds (timeout.exe /T 5, or something like that) and then calls FlexEngine.exe -UEMRefreshPrinters? You might need to tweak the delay a bit, assuming this works at all...

[simpss]

Hi DEMdev​,

Appreciate all your help!

I created a triggered task with a 5 second timeout to refresh the printers at reconnect and this seems to work as well without any issues.

[DEMdev]

Hi simpss,

Happy to hear it works!

[simpss]

DEMdev​,

Would this be the method to use instead of the User Environment Refresh Triggered task? There should be no reason that the other triggered task via User Environment Refresh shouldn't work right?

Thanks again for your help.