Understanding the Default Printer in Windows 7 VDI
Getting control over your Default Printer in a Windows 7 VDI environment is a little more difficult than I would have expected. There are a lot of different factors that can come into play and, depending on the type of client connection, you can get some unexpected results. Here are the factors that I know of that can set a desktop’s default printer:
1) The user’s Profile
2) A logon script/GPO
3) Windows’s spooler behavior when the default printer that it expects is missing
4) The TPAutoConnect.exe program (which executes automagically at PCoIP session connection)
My current customer is intending to use a combination of #2 and #4. The logon script is setting their network printer based on who they are and is responsible for 90% of the printer assignment. TPAutoConnect.exe is used to install direct-attached client printers and map them into the VDI desktop. The simple fact that the plan doesn’t involve #1 and #3 doesn’t remove them from the equation… they’re still happily churning around, trying to do their work and setting unexpected default printers for these virtual desktops.
On fat desktop clients, things are working fine. TPAutoConnect always runs last and sets their default printer to match whatever the client machine uses, but that’s fine. The logon script installs all of the printers in their area and TPAutoConnect installs a duplicate of one of them that routes through the Client device. If the user has a locally attached printer as their default, then it’s not even a duplicate. The problem came about when users connect by Thin Clients (or tablets); for whatever reason, the desktop was setting its default printer as the alphabetically strong “Adobe PDF Printer” in that scenario. If I manually execute TPAutoConnect, it throws an error (that it can’t properly read the Client) and then it quits out without changing anything. If I run the printer deployment logon script after the logon process is completed, the default printer is set correctly. I know that the profile has an accurate default printer, as I set it myself last time I logged in.
It is this very issue that has increased my understanding of Windows 7’s printer behavior to its current level. I hadn’t considered #3 as a particularly important factor, as I had assumed that the logon process would be as follows:
1) User logs in, already has a default printer set in their profile
2) The VDI Desktop does not have that printer installed, fails over to the alphabetically strongest printer as default
3) Logon script runs, installs printers and sets appropriate default printer
4) TPAutoConnect sets the user to use a local printer, if one is available
You’ll notice that my assumed order has flipped #2 and #3 from my observed order of events. It actually takes the spooler a while to process the failure, which is happening right away (before the script can install the printers). What this has meant is that, when my client has no default printer assigned (such as an iPad or a Thin Client), #4 does nothing, leaving the desktop in whatever state #3 left things. I had assumed that #3 was my logon script, but it turns out that my logon script was completing before the print spooler had completed its failure process, but after it had detected the failure. This meant that the script was setting the correct default printer, but then the print spooler was setting it back to the best alphabetic printer.
My solution? I delayed the logon script by 1 minute before executing. Am I proud of it? Not really… but does it work? Yep.