VMware Horizon Community
smith_ll
Enthusiast
Enthusiast
Jump to solution

UEM - Printers

I'm currently looking to move away from having printers installed by .bat or GPO and have been playing with UEM.

I can get the printers to install based on client IP without any difficulty, but is there a way for the printers to be removed also?

E.g user logs in on 192.168.1.10 and receives PRINTER1

user reconnected on 192.168.2.10 and receives PRINTER2, whilst also having PRINTER1 removed from their Devices and Printers.

Tags (2)
1 Solution

Accepted Solutions
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi smith_ll,

Thank you for the log files.

Looking at the three UEM refresh runs, we see that the first one results in the Bolton printer to be mapped because of the 10.1.9.172 IP match:

2019-01-17 15:32:43.177 [INFO ] Performing UEM refresh [IFP#cfc5acef-559052>>]

[...]

2019-01-17 15:32:43.366 [DEBUG] Conditions: Check for endpoint IP address = true (10.1.9.172 matches 10.1.9.1 - 10.1.9.255)

2019-01-17 15:32:43.366 [INFO ] Scheduled printer mapping for async processing ('Print Anywhere (Bolton).xml')

[...]

2019-01-17 15:32:43.409 [DEBUG] Processed 6 UEM printer mappings (1 scheduled, 5 skipped)

2019-01-17 15:32:43.410 [INFO ] Done (233 ms) [<<IFP#cfc5acef-559052]

From async log:

2019-01-17 15:32:44.659 [INFO ] Successfully mapped printer '\\svr-print\Print Anywhere' ('Print Anywhere (Bolton).xml')

For the second refresh, 192.168.251.35 does not match the conditions for the Bolton printer, which is then Successfully unmapped, and the Stoke printer is then mapped because its conditions match:

2019-01-17 15:34:34.805 [INFO ] Performing UEM refresh [IFP#e82bd846-559052>>]

[...]

2019-01-17 15:34:34.877 [DEBUG] Conditions: Check for endpoint IP address = false (192.168.251.35 does not match 10.1.9.1 - 10.1.9.255)

2019-01-17 15:34:34.877 [INFO ] Skipping printer mapping due to conditions ('Print Anywhere (Bolton).xml')

2019-01-17 15:34:35.013 [DEBUG] Successfully unmapped printer '\\svr-print\Print Anywhere' ('Print Anywhere (Bolton).xml')

[...]

2019-01-17 15:34:35.018 [DEBUG] Conditions: Check for endpoint IP address = true (192.168.251.35 matches 192.168.251.1 - 192.168.251.255)

2019-01-17 15:34:35.018 [INFO ] Scheduled printer mapping for async processing ('Print Anywhere (Stoke).xml')

[...]

2019-01-17 15:34:35.033 [DEBUG] Processed 6 UEM printer mappings (1 scheduled, 5 skipped; 1 undo action (1 successful))

2019-01-17 15:34:35.034 [INFO ] Done (229 ms) [<<IFP#e82bd846-559052]

From async log:

2019-01-17 15:34:42.144 [INFO ] Successfully mapped printer '\\SVR-PRNT-03\Print Anywhere (Stoke)' ('Print Anywhere (Stoke).xml')

For the third refresh, 10.1.4.155 matches the conditions for the Bolton printer (which is therefore (scheduled to be) mapped), but does not match the conditions for Stoke, which is Successfully unmapped:

2019-01-17 15:37:24.834 [INFO ] Performing UEM refresh [IFP#e9096325-559052>>]

[...]

2019-01-17 15:37:24.906 [DEBUG] Conditions: Check for endpoint IP address = true (10.1.4.155 matches 10.1.4.1 - 10.1.4.255)

2019-01-17 15:37:24.906 [INFO ] Scheduled printer mapping for async processing ('Print Anywhere (Bolton).xml')

[...]

2019-01-17 15:37:24.911 [DEBUG] Conditions: Check for endpoint IP address = false (10.1.4.155 does not match 192.168.251.1 - 192.168.251.255)

2019-01-17 15:37:24.911 [INFO ] Skipping printer mapping due to conditions ('Print Anywhere (Stoke).xml')

2019-01-17 15:37:24.915 [DEBUG] Successfully unmapped printer '\\SVR-PRNT-03\Print Anywhere (Stoke)' ('Print Anywhere (Stoke).xml')

[...]

2019-01-17 15:37:24.931 [DEBUG] Processed 6 UEM printer mappings (1 scheduled, 5 skipped; 1 undo action (1 successful))

2019-01-17 15:37:24.932 [INFO ] Done (98 ms) [<<IFP#e9096325-559052]

From async log:

2019-01-17 15:37:25.816 [INFO ] Successfully mapped printer '\\svr-print\Print Anywhere' ('Print Anywhere (Bolton).xml')

Per the above, UEM's logic to unmap previously mapped printers whose conditions no longer match seems to work fine. Are you maybe using printer redirection, or could there be something on RDSH 2016 that is causing this?

View solution in original post

Reply
0 Kudos
11 Replies
HussamRabaya
VMware Employee
VMware Employee
Jump to solution

if i understand your request.. this can be done with UEM..check

Configure a Printer Mapping

Reply
0 Kudos
schepp
Leadership
Leadership
Jump to solution

correct, you can configure UEM to unmap the printers before logoff.

Only problem is when you save the users network printers with UEM, then the UEM mapped printers will be safed in the users profile as well.

To workaround look at this thread: Network Printer unmap vs. export

Cheers

Tim

Reply
0 Kudos
ijdemes
Expert
Expert
Jump to solution

You can definitely do this.

Create your printers using the "Undo at logoff and refresh during printer mapping refresh" option.

pastedImage_0.png

Also configure a "triggered task" to refresh the printers after reconnect.

pastedImage_1.png

Keep in mind the implications mentioned by Tim.


\\ Ivan
---
Twitter: @ivandemes
Blog: https://www.ivandemes.com
Reply
0 Kudos
smith_ll
Enthusiast
Enthusiast
Jump to solution

Hi ijdemes,

I have the triggered task doing this already. My issue is that it doesn't remove the previously mapped printer having detected a new client IP and mapped the printer following a matched condition.

We have a large number of remote offices so it could result in some users having dozens of printers.

My plan is for them to only have the printer at the site they are currently at mapped through for them. When they move to the next site, the triggered task runs, maps the new printer but also removes the previously mapped.

I'm looking at article Tim posted earlier now to see if that does what I need but first impressions that only works if the user actually logs off. Mine will only be disconnecting/reconnecting at multiple sites, not logging off.

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi smith_ll,

I have the triggered task doing this already. My issue is that it doesn't remove the previously mapped printer having detected a new client IP and mapped the printer following a matched condition.

Can you provide a FlexEngine log file (and the corresponding async log), at log level DEBUG, so we can see what's going on?

From your requirements it doesn't sound like you would need to manage the user's printer preferences through personalization, so Tim's scenario (while very valid for his use case) probably is less relevant for you.

Reply
0 Kudos
smith_ll
Enthusiast
Enthusiast
Jump to solution

Log files attached.

Printers are mapping fine but my aim is for them to be removed if they no longer match the condition previously met.

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi smith_ll,

Thank you for the log files.

Looking at the three UEM refresh runs, we see that the first one results in the Bolton printer to be mapped because of the 10.1.9.172 IP match:

2019-01-17 15:32:43.177 [INFO ] Performing UEM refresh [IFP#cfc5acef-559052>>]

[...]

2019-01-17 15:32:43.366 [DEBUG] Conditions: Check for endpoint IP address = true (10.1.9.172 matches 10.1.9.1 - 10.1.9.255)

2019-01-17 15:32:43.366 [INFO ] Scheduled printer mapping for async processing ('Print Anywhere (Bolton).xml')

[...]

2019-01-17 15:32:43.409 [DEBUG] Processed 6 UEM printer mappings (1 scheduled, 5 skipped)

2019-01-17 15:32:43.410 [INFO ] Done (233 ms) [<<IFP#cfc5acef-559052]

From async log:

2019-01-17 15:32:44.659 [INFO ] Successfully mapped printer '\\svr-print\Print Anywhere' ('Print Anywhere (Bolton).xml')

For the second refresh, 192.168.251.35 does not match the conditions for the Bolton printer, which is then Successfully unmapped, and the Stoke printer is then mapped because its conditions match:

2019-01-17 15:34:34.805 [INFO ] Performing UEM refresh [IFP#e82bd846-559052>>]

[...]

2019-01-17 15:34:34.877 [DEBUG] Conditions: Check for endpoint IP address = false (192.168.251.35 does not match 10.1.9.1 - 10.1.9.255)

2019-01-17 15:34:34.877 [INFO ] Skipping printer mapping due to conditions ('Print Anywhere (Bolton).xml')

2019-01-17 15:34:35.013 [DEBUG] Successfully unmapped printer '\\svr-print\Print Anywhere' ('Print Anywhere (Bolton).xml')

[...]

2019-01-17 15:34:35.018 [DEBUG] Conditions: Check for endpoint IP address = true (192.168.251.35 matches 192.168.251.1 - 192.168.251.255)

2019-01-17 15:34:35.018 [INFO ] Scheduled printer mapping for async processing ('Print Anywhere (Stoke).xml')

[...]

2019-01-17 15:34:35.033 [DEBUG] Processed 6 UEM printer mappings (1 scheduled, 5 skipped; 1 undo action (1 successful))

2019-01-17 15:34:35.034 [INFO ] Done (229 ms) [<<IFP#e82bd846-559052]

From async log:

2019-01-17 15:34:42.144 [INFO ] Successfully mapped printer '\\SVR-PRNT-03\Print Anywhere (Stoke)' ('Print Anywhere (Stoke).xml')

For the third refresh, 10.1.4.155 matches the conditions for the Bolton printer (which is therefore (scheduled to be) mapped), but does not match the conditions for Stoke, which is Successfully unmapped:

2019-01-17 15:37:24.834 [INFO ] Performing UEM refresh [IFP#e9096325-559052>>]

[...]

2019-01-17 15:37:24.906 [DEBUG] Conditions: Check for endpoint IP address = true (10.1.4.155 matches 10.1.4.1 - 10.1.4.255)

2019-01-17 15:37:24.906 [INFO ] Scheduled printer mapping for async processing ('Print Anywhere (Bolton).xml')

[...]

2019-01-17 15:37:24.911 [DEBUG] Conditions: Check for endpoint IP address = false (10.1.4.155 does not match 192.168.251.1 - 192.168.251.255)

2019-01-17 15:37:24.911 [INFO ] Skipping printer mapping due to conditions ('Print Anywhere (Stoke).xml')

2019-01-17 15:37:24.915 [DEBUG] Successfully unmapped printer '\\SVR-PRNT-03\Print Anywhere (Stoke)' ('Print Anywhere (Stoke).xml')

[...]

2019-01-17 15:37:24.931 [DEBUG] Processed 6 UEM printer mappings (1 scheduled, 5 skipped; 1 undo action (1 successful))

2019-01-17 15:37:24.932 [INFO ] Done (98 ms) [<<IFP#e9096325-559052]

From async log:

2019-01-17 15:37:25.816 [INFO ] Successfully mapped printer '\\svr-print\Print Anywhere' ('Print Anywhere (Bolton).xml')

Per the above, UEM's logic to unmap previously mapped printers whose conditions no longer match seems to work fine. Are you maybe using printer redirection, or could there be something on RDSH 2016 that is causing this?

Reply
0 Kudos
smith_ll
Enthusiast
Enthusiast
Jump to solution

Hey!

I was previously using GPO to deliver printers. I've denied the user within that policy but it's possible there are some remnants of the policy kicking around in the profile or registry for my test account.

So long as UEM is capable of delivering the printer, and removing it when it doesn't meet the conditions which as per your findings it is trying to do I'm happy.

I'll accept that as an answer.

Thanks for your help.

simpss
Enthusiast
Enthusiast
Jump to solution

smith_ll  Just curious if you found any issues with your current configuration? I have the same scenario happening where it's showing a successful unmap of the old printer on reconnect, but the printer is still appearing along with the new printer mapping based on the new location.

Thanks!

Reply
0 Kudos
smith_ll
Enthusiast
Enthusiast
Jump to solution

Hi Simpss,

To be honest I got caught up on other projects so never fully implemented it. I've still got the old policies in place but not enable yet.

I've just updated to DEM so might take the time to test this again now.

Reply
0 Kudos
simpss
Enthusiast
Enthusiast
Jump to solution

Thanks for the reply!.

I have a new setup and DEM 9.11 in place and I see the unmap successful at reconnect in the debug, but the printer is still there. Please let me know if you ever get this working.

Reply
0 Kudos