Within a VDI environment, it is a delicate procedure to configure printers with user personalization through VMware’s User Environment Manager (UEM). That is because every customer has specific needs regarding the printer setups in their VDI environment.
We frequently come across situations like this:
A user accesses his virtual desktop from within the corporate network and gets his network printers assigned (for example based on Active Directory groups). The first time, the user chooses a default printer. This printer should be saved in the UEM to avoid that the user must set his default printer every time he logs on.
Then, the user logs off or disconnects from his virtual desktop and reconnects or logs on again from his home office. The user now wants the local printer to be mapped in his virtual desktop session and to be set as default printer.
As soon as the user arrives back at the office, he wants to use the default network printer he previously set.
Enabling client printer redirection
To configure this in UEM, we enable the network printer personalization and create a new Horizon policy that will enable the client printer redirection when working externally (not in corp. network range). When a user does a logoff, UEM personalization will always save the default printer used at that time. This is ideal for situation 1 (see image above), but there are issues in the other two situations.
Issues with the logon action
In situation 2 and 3, the horizon policy will have redirected the client printer as default printer. Thus, UEM saves the client printer. When the user logs onto his corporate PC the next day, UEM will push the default printer in the session. When the printer is not available, the first printer mapped by Windows during logon will be chosen as default. This behavior caused some legacy applications to break.
How to solve this issue? We had to create a method where only the corporate printer is ‘saved’ during logoff.
Therefore, we started experimenting with the implementation of logon/logoff actions. We quickly experienced a timing issue when trying to push/import the network printer personalization to the user’s session. This is unfortunately because the UEM personalization import is running too early when configured as a GPO policy. This causes the reg keys to be pushed into nothing as the user profile is not yet created in the VDI.
After a lot of testing with Batch Processing files (BAT), timeouts and conditions, we eventually solved this by creating a ‘RunOnce command’ with GPO user preference. This Run command will replace the UEM printer import.
The default printer is now pushed into the session without any issue. So, we are glad to report that the solution above is a viable workaround for the logon UEM timing problem.
The logoff action
For the logoff action, we reused the same flexengine.exe call but with export parameters. We probably only want to export when the user chooses a corporate network printer, so a specific condition should be included. For instance: \\SVRPRT001\PRxxx.
Command:
| C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe -s “\\FILESERVER\TST\%username%\Archives\Windows Settings\Network Printers.zip” -i “\\FILESERVER\TST \general\Windows Settings\Network Printers.INI” -b \\FILESERVER\TST \%username%\Backups\Windows Settings\Network Printers.zip” |
Remark: the order of the argument is very specific, as changing them will result in an export failure.
Help, the legacy application can’t find the home printer anymore
With the logoff and logon actions covered, we encountered another problem regarding disconnecting a user session. Solving this issue turned out to be a bigger challenge. This is due to the way triggered task conditions are checked when logging onto a user session.
Let me explain this more thoroughly: When a user logs on to the internal network (1), the UEM condition check is run. ‘The default printer’ will be a corporate printer and the condition will , therefore, be true.
When the user goes home and reconnects his session (2), the condition will still be true. But actually, his home printer is mapped.
When the user does a logoff, his home printer will be exported to UEM.
This behavior caused a problem with a specific legacy application that reacted badly to this export and no longer found the ‘home printer’.
We reached out to VMware to find a solution. After many hours of testing, we eventually found a workaround to execute the condition check at the time of export itself instead of at the beginning of the user session.
To reconnect, we reused the same command as for the logon run action because we only needed to import the ‘network printer’ personalization of the user.
At the disconnect event, we triggered a BAT script instead of calling the flexengine.exe with conditions.
In this BAT file, the following is being executed:
| reg query HKCU\Software\Microsoft\Windows NT\CurrentVersion\Window\Device /f “\\SVRPRT001”if %ERRORLEVEL% EQU 0 goto INSTALL
GOTO END :INSTALL “C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe” -s “\\FILESERVER\TST\%username%\Archives\Windows Settings\Network Printers.zip” -i “\\FILESERVER\TST\general\Windows Settings\Network Printers.INI” -b “\\FILESERVER\TST\%username%\Backups\Windows Settings\Network Printers.zip” :END |
The script will first query the registry for the ‘windows default printer’ key. If this key starts with the corporate print server, then the export is allowed. This method solved all the issues regarding the condition check that was not executed at the moment we wanted. This is one of the advantages of working with similar products such as AppSense, where you have more flexibility when a condition is checked.
Conclusion
As this blog was written in May 2017, the timing issue within UEM was eventualy resolved with release 9.2.
Therefor the most part of the script could be removed and integrated in UEM itself. I will be writing a follow part that explains a simplified printer setup.
Note: This blog was initialy posted on my employers (securelink) blog: a link can be found here