My Windows 10 Printer Deployment Nightmare!

Remember when adding Printers to domain computers was nice, simple and easy to do? No, me neither. But it was never as difficult as it now seems to be with Windows 10. Specifically speaking build 1511. Don’t get me wrong, I am sold on Windows 10. It’s fast, efficient and I use it on all my computers. That doesn’t change the fact that there are many issues when using it on large networks.

I help to administer two large domains over three sites within an educational establishment. One for Admin Staff and one for Students. We have thousands of clients and a couple of hundred printers. Over the summer after months of testing we made the move from Windows 7 to Windows 10 (1511) on the Student network. We have always added our printers by Group Policy. This makes it easier to add printers to every PC without having to go around each one individually. Up until then we had used a batch file in GP to copy a VBS script to the start-up folder on the client which subsequently added the printer via command line. It wasn’t perfect, but it worked. Most of the time…

With Windows 10 we found this to be very unreliable during the early testing stage and decided it was time to move to the ‘correct’ way of connecting clients to printers via Group Policy. But how? There are at least 7 ways to do this using GPP (Group Policy Preferences) or Deployment in various combinations. We have printers associated with specific rooms and the students move from one classroom to another. That ruled out for us adding the Printers via User.

For months I experimented with all methods available and came to one conclusion. That they are all as bad, inconsistent and as unreliable as each other. In the end we decided to use the deployment method. The main reason being was that there were changes to be made at the server end which I will get to later. When these changes are made using the deployment method, they are automatically picked up by the client. If you use GPP, the printer needs to be removed and re-added for them to work. Deployed printers are controlled by the print server. GPP locally. Something worth remembering.

After numerous experiments and even more failures I started to scrape together information of what is required to get this to work. There are so many blogs and walkthroughs and forums giving advice, but NONE of them carry the full story. Here is everything I had to do get over 100 printers attached to the 1000 student clients in the correct rooms, every time a new user logged in and of course have them printing correctly.

Step 1: Prepare your environment.

So you have your computers nicely imaged with Windows 10 and your old, reliable print server hasn’t changed. You may even have gotten a printer to appear on the odd client. But some clients simply refuse to add them. Some, there are no errors at all. Others complain about drivers and print processors.

 Here is what you need to do:

Set up Point and Print:

You will find this answer on every webpage dedicated to this issue. Disable Point and Print, Disable Point and Print they say. This is not the full story, even if they have been kind enough to tell you how to actually do it.

I found Point and Print has to be enabled to work! Use Group policy to enable this feature and then disable the restrictions. This will enable the client logged in as a user to install printer drivers on the quiet, without prompts or any user intervention.

The trick here as well is to create TWO separate Group Policies. One for Computer Configuration (see above) and one for User Configuration. Attach the computer policy to the top of your client hierarchy in AD and the user policy to the top of your Users OU.

The fun doesn’t stop there. To enable Point and Print to work properly with Windows 10 you may have to make changes to your Print Server. NOTE: We have three Print Servers. Each is currently running a different operating system. Server 2008, Server 2008 R2 and Server 2012 R2. These fixes worked on all three.

Reconfigure your Print Server:

Drivers:

This isn’t as scary or as intrusive as it sounds. But there are some significant changes to be made. I will say to first backup and/or snapshot your server before you begin. The first is drivers: Please note here that Windows 10 does NOT like TYPE 4 drivers, so avoid these if you can (we were lucky and didn’t have any). Older versions of Print Management as I found on 2008 do not list Driver Types and can make things harder to identify. I got around this by managing that server as an additional print server on the 2012 R2 box.

I was getting an error in my event log: Error code “0x80070bcb. The specified printer driver was not found on the system and needs to be downloaded”. This is what Print and Point is supposed to do for us.

However: Print and Point with Windows 10 does NOT like ‘unpackaged’ drivers. On your Print Server expand your server name and select the drivers section. You are looking for the column labelled “Packaged”. If the print driver for the printer which you are trying to deploy is marked as “False”, then it is most likely NOT appearing at all on the client.

The obvious fix here is to download a new driver for Windows 10 from the printer manufacturer. But if your printer is a little older or you already have the latest driver this won’t help much. Have no fear there is a nice, simple work around in the form of a registry fix that got me out several deep, dark holes where printers didn’t exist.

Open Regedit on the Print Server:

Navigate to: HKLM\System\CurrentControlSet\Control\Print\Enviroments\[Windowsx64] or [Windowsx86]\Drivers\...\[Driver name]\

You are looking for an entry called “PrinterDriverAttributes” on the right hand side and will probably be set with a value of “0”. I had one set to “4”, but it made no difference. Change this to “1”.

Now close regedit, reboot your Print Server and open Print Management again. See, your Print Driver is now marked as “True” under the Packaged column.

What this change has done is create a CAB file containing the driver, and all the other information about your printer which Point and Print can send to the Windows 10 client. Windows 10 likes the CAB file and adds the Printer. Everybody’s happy.

Maybe…

Print Processors:

You get the nasty business of your print driver inconsistencies out of the way and you find some printers are still not appearing on your clients. Only this time you get the error:  "Unable to install printer. The print processor does not exist" in your event log. This is exactly what it says on the tin. The Print Processor is simply a DLL file that isn’t present. It can’t be just copied over and registered either. It can be fixed with this workaround:

Open the properties of the Printer (right click) on the Print Server, select the Advanced tab and click the Print Processor button at the bottom:

See this HP 1505n is using its own Print Processor. However, unlike Windows 7 (or below) this is NOT always available on Windows 10. When you install a driver it copies everything you need including the PP to the C:\Windows\System32\spool\prtprocs\x64\ folder. At least it should. I found this to not always be the case. Simply changing this to Windows Own PP seems to do the trick. Change this to winprint – RAW. Winprint is available by default on ALL Windows 10 installations.

Click ok, reboot your client and test the Printer. I did find on some that they printed garbled symbols until the Print Spooler was restarted in the Print Server. I will add here that this is one of the changes that does NOT work straight away on the client if the printer has been added as a local or TCP/IP printer. This is because in that case the client is managing the Print Processor and the printer will need to be removed and re-added from the server. If you are using deployed, it should just work.

Step Two: Deploy your Printers.

Create your Group Policies:

With your server’s setup it is now time to deploy your printers if you haven’t already done so. This can be done to users or computers. As I mentioned before, we had to use Computer Policy. I will add that we tried Local Printers via User Policy with Loopback enabled. I won’t go into the details; I just don’t recommend it. Save yourself a lot time and premature baldness by not going down that route.

·         Create a new policy, name it and Navigate to: Computer configuration > Policies > Windows Settings > Deployed Printers

·         Right click, select deploy printer, type in the printer path and click ADD. Repeat this for all printers for that policy.

·         Click OK and you’re done.

The same can be done by deploying directly from the Print Server to Group Policy by right clicking the printer and following the wizard.

Step Three: Check your Clients:

You’re set up ready to go and maybe some of your clients are now printing away merrily. But what if they are not? Here are a couple of things to check and one fix you won’t see coming.

Group Policy:

Obviously network connectivity is a must. Check your printer is connected and switched on. You may wish to run a GPUpdate /force on troublesome clients and make sure it is also connected to the domain and it’s computer account is in the correct OU with the GPO attached (and enabled).

Windows Updates:

There have been numerous Windows Updates curtesy of Microsoft which have broken Point and Print settings. Even set up correctly your clients will refuse to pull down a driver and add the printer to the client if these patches are installed. They are:

kb3163912 – Windows 7
kb3170455
kb3170005
kb3172985

kb3172985 is the patch we had problems with. It is a cumulative update that carries one or more of the other KB’s in that list. Uninstalling this from the Windows 10 client and rebooting had an immediate effect. This can be done manually or via script using Group Policy.

%windir%\system32\wusa.exe /uninstall /kb:3172985 /quiet /forcerestart

Above is the uninstall command for removing windows updates silently (just change the KB number). BUT: KB3172985 seems to have problems with this and ignores the /quiet switch. This is due to how the KB has been signed. I found the only way to get this to work was to download the MSU and run the commands against that from a server.

%windir%\system32\wusa.exe /uninstall \\[File Path]\windows10.0-kb3172985-x64_006b20fc4c418499afa25248edacff2ef7dab963.msu /quiet /forcerestart

TIP: Run this out of hours. You WILL need the /ForceRestart switch. If Windows doesn’t reboot right after running the command the patch will NOT remove probably and you will have to be done again.

Print Spooler service:

By now you are probably a little cheesed off and heaving a sigh of relief as you printers start to appear and your users are printing to their hearts content. Until… yes, someone logs in and shock, horror there is no printer available.

This was a problem I hadn’t seen coming at all. I found an error in the event logs on the client claiming that the printer could not be added as the Print Spooler (on the client) had not started in a timely fashion and could not contact the print server. I checked and the service was running away happily. But still no printer.

As far as I can tell this is just another Windows 10 inconsistency and annoyance. What’s happening is that the GPO is applying before the Print Spooler service has finished starting; therefore, failing. We are probably talking a microsecond difference and we have had this in more rooms than I care to count. As far as I could see there was only one thing for it: Restart the Print Spooler!

But when? How?

Easy. Back to Group Policy again. This is where we get clever:

Create another GPO. We experimented at first in just a couple of problem rooms and linked it to their OU’s then moved it higher up the OU hierarchy.

Navigate to: Computer Configuration > Preferences>Control Panel Settings > Scheduled Tasks

·         Create a New Scheduled Task (At Least Windows 7)

·         Call it whatever you like: “Restart PrintSpooler” worked for me.

·         Set it to run as NT AUTHORITY\SYSTEM and tick the “Run with highest privileges” box.

·         I set it to run a batch file from a server containing the following commands:

net stop spooler
net start spooler

That’s it. Now the clever bit. We know that by the time the user has logged in the Print Spooler has started and the GPO has attempted to connect the printer. Upon testing if the Print Spooler service was restarted manually at that time I could see the printer reconnecting without having to log off or reboot etc.

·         Set the schedule to run 30 seconds after any user logs on to the client by changing the dropdown box at the top and ticking delay task (set to 30 seconds) at the bottom.

·         OK everything, reboot (and/or GPUpdate) your clients and watch the magic happen.

Finally:

A Note on Default Printers:

We get a lot of questions regarding default printers and Windows 10. Firstly, if you are connecting your printers by Computer Configuration in Group Policy, default printers CANNOT be specified there. In addition, you can’t do this with Deployed printers on User Configuration either.

Next, Windows 10 sets its own default printer. It will either be the Last Printer Used or the Last Printer added. If you have more than one printer to add via GP, separate then into different GPO’s and order them accordingly. The last to apply will become default.

This feature can be disabled on Windows 10 either on the client or in GP.

Windows 10 (1608 Anniversary Build):

Preliminary testing has found some of these issues to have improved. Although that maybe because we have very few clients running that build. It is something that must be tested before rolling out the anniversary update. That is another set of problems entirely.

To conclude, our printers are still not 100%. But using these methods has reduced complaints and we are gradually pulling ourselves out of a pit of printing despair. I hope my trials and tribulations into the world of Windows 10 printer deployment will help some other poor IT analyst’s soul suffering the same fate. I feel your pain!

Now go forth and print…

Additional:

Since I wrote this (this morning), two more problems have raised their ugly heads in the complicated realm of Windows 10 Printing. The first is where a printer does connect to the client but errors upon printing. We found this to be a driver issue on the client after making changes on the server (so try to get these all in place before you deploy). To correct the problem, we needed to remove the driver. This is not as simple as just removing the printer and requires some split second timing.

·         Load Print Management on the client.

·         Load the Services MMC.

·         Expand the drivers section of Print Management and find the driver in question.

·         You need to place these windows side by side.

·         Restart the Print Spooler service in the services MMC. Before this finishes, right click the driver in Print Management and select “Remove Driver Package”. Time this right and the driver will uninstall. You may need to try this a few times to get it right.

·         Once it has gone, reboot the client, let the Group Policy reapply and your printer should be back up and running on the client.

Next we had a very strange problem where some printers wanted to install an App from the Windows 10 App store.

A store which we block access to (with Group Policy). Regardless of that, the drivers required are on the Print Server and clients should be working fine with those. Other printers of the same model and configuration are working correctly and I have found in some cases these do too. In others it is best to simply remove the deployment from the Group Policy and re-add it. The next time the Clients reboot they seem to pick up the printer without further issue.

Weird huh!