We have had a huge saga with printer installation when trying to automate that and control these through logon scripts or the various Group policy settings. Some way back a few years ago, in the days of Windows Server 2003 R2, Microsoft added the Print Management MMC tool along with the ability to manage printers using Group Policy. Later on, after buying out a company, Group Policy Preferences were added as a means of managing printers through Group Policy. Each of these has its own problems. The most serious problem you will encounter with Windows 7 is the dreaded hang when processing Group Policy Printers Policy. We have had numerous experiences where this simply freezes. I can leave a computer and come back the next day and it will still be stuck on this screen. This is a very debilitating experience for the user who cannot log on to their computer. All that will happen is that there will be entries in the events log talking about a long time spent processing Group Policy but when you try to find help to solve this problem there will not be any to find.
Microsoft has made a complete dog’s breakfast of centralised print management for domain administrators, although the early Print Management MMC approach that came in Windows Server 2003 R2 was a promising start. It is mainly the issue that the limitations of this, in particular removing printers which does not actually work properly, has been compounded by the further problems when using Group Policy Preferences, which leads to the situation mentioned above with the logon freeze. In short the possibilities of being able to effectively centrally manage printer installation in Windows 7 have been kneecapped by what is now becoming a typical Microsoft cost cutting approach to resourcing these capabilities adequately. Therefore the only real option is to return to login scripting to install or remove printers, although this can also be managed through Group Policy settings.
I have started out by using a Powershell script, as Windows 7 / Server 2008 R2 has built in support for these in GPOs. Here I ran into the dreaded black screen after logon where the computer appears to freeze. Using some of the more reliable GPP settings like pushing across the registry key for DelayedDesktopSwitchTimeout and setting login scripts to run synchronously seems to be doing the trick after a lot of mucking around. However you should also check the event log on target computers in Microsoft-Windows-PrintService and if there are a lot of errors referring to malformed registry keys for specific printers then go into HKEY_CURRENT_USER \ Printers \ Connections and remove the subkeys for specific printers. In my test case deleting all these keys stopped the errors from appearing in the Event Log and allowed the printers being mapped in the login script to appear in the Printers folder.
The next step will be to have more printers being added in the login script. Just why this appears to be successful when GPP Printers does not work isn’t particularly clear. For us as system administrators a series of experiences where Windows 7 technologies appear to be lacking proper resourcing or support from Microsoft demands we respond with a “back to basics” approach and revert to tried-and-true, in this case logon scripting (which I thought had gone out with the ark). I don’t consider myself to be a programmer but that script will be getting updated and added to in future in order to make sure that printer installation and configuration can be relied upon. This is very important because incorrect printer installation will cause a lot of strange errors and problems with lots of everyday applications. I have seen these numerous event log errors before and deleting the keys from the Registry is not a new experience. I wrote about it here in fact. And looking back at that situation it is by remarkable coincidence (NOT!!!!) that the latest problems involve another Brother printer…
UPDATE: The saga continues because even though we have switched the server and clients over to driver isolation, the print spooler is still failing. The types of events now being logged are an inability to load the Brother print processor, even though it is not actually being used. In order to deal with this some registry keys that cause print processors to be loaded will need to be removed. I hope this fixes the problem as we have already paid for this printer and don’t want to have to return it. Here is the info about the registry keys:
The summary of this is to look for and remove registry keys under HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ Print \ Environments \ Windows NT x86 \ Print Processors. There will be subkeys named for each print processor in use in the system. The content is part of a much larger article on how to debug print spooler crashes. I hope this will be successful as the only other option is to get rid of the particular printer.
UPDATE 2: The above didn’t work in this case, as the registry keys didn’t exist. Although we are using x64, a search of the registry for the BrPrint processor failed to find its key, and there are no recent events for this print processor’s DLL failing to load. I can only assume with applying the isolation settings, the Brother print processors are not actually being loaded.
The solution now being tested is to do away with Brother drivers altogether. Most printers are compatible with HP drivers, and this printer turns out to work satisfactorily with the HP Universal Print Driver for PCL5. So far all testing is good. If it all turns out then all the Brother 64 bit print queues on our print server will be changed over to HP drivers.
