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.
Jason, thanks for the info. I'm having a similar issue with my default printer script: the script runs during logon and sets the default printer, but then 30 seconds later it reverts to the Microsoft XPS Document Writer. Running the script manually works fine.
ReplyDeletePart of me is glad to hear that I'm not the only person with this issue. I guess that I didn't exactly go into detail about how I delayed the logon script. I'm actually using the Windows 7 Task Scheduler to kick these off, rather than a GPO. I'm doing so because you can set the triggers very precisely through Task Scheduler (which is where I configure the 1 minute delay). If you set the task to run as the local machine's "Users" group and set the trigger as "At log on" for any user, it seems to kick off just fine. As I bemoaned in the post, it is not an elegant solution, but it does get the job done.
DeleteI'm triggering the script from Scheduled Tasks in the GPO, which seems to work also. I delay for 1 minute. A 30 second delay didn't yield reliable results.
DeleteI didn't realize that you could do scheduled tasks through GPO. I learn something new every day.
DeleteJason could you please link your logon and logout scripts and what you did to implement the script to apply during login and logout? Just want to mimic this in my test environment to see if it resolves our problem. Thanks!
DeleteHi Tom - this was many years and even more customers ago, so I don't have access to those scripts any more. I think that we actually ended up using Windows Task Scheduler on the gold OS image to create scheduled tasks that trigger at log on, with a 1 minute delay, which execute the printer mapping script. As I said, it was quite some time ago though, so my memory could certainly be incorrect.
Deletedang thanks anyhow. I am struggling with this same thing. We have a pdf printer locally on the gold image and it always takes priority again after a use logs out and logs back in. I'm currently trying to see if i can pull the pdf printer out and add it as a managed printer on the printserver so that the only printer that adds to the session is the GPO'd printer they're assigned to. That way I won't have to fight with multiple printers as they only get the one.
Delete