Harry1980 Posted February 12, 2015 Posted February 12, 2015 Hi All, I have noticed that printers are not deploying properly on the network. I have checked the event viewer and there was a warning regarding Group Policy Printers. The message is below: Log Name: Application Source: Group Policy Printers Event ID: 4098 Description: The computer preference item in the '{GUID}' Group Policy object did not apply because it failed with error code '0x80070bcb The specified printer driver was not found on the system and needs to be downloaded.' This error was suppressed The printers usually deploy. I have noticed in the past that at times certain printers would not deploy but thought nothing of it and manually added the printers. But today after imaging a new laptop (win 8.1 x64) and added it to the correct OU in AD and after GP update realised the printers were not installing and identified the above error. The printers are installed on Server 2012, clients are Vista business, Win 7 and Win 8.1 x64. Printer drivers x64 and x86 are installed on the server. I can manually add the printer without any problems. I have tried the below but still no luck 1. Go to your local GPO (type gpedit.msc in the search box) 2. Go to Computer Configuration / Administrative Templates / Printers 3. Find a policy named "Extend Point and Print connections to search Windows Update" and Enable it 4. Then run gpupdate /force in the command prompt and see if all of your printers are installed on this computer via your GPP Any suggestions will be helpful. Thanks in advance.
TriggerHappyUK Posted February 12, 2015 Posted February 12, 2015 How are you deploying your printers? Group Policy Preferences or Login Script?
Ephelyon Posted February 12, 2015 Posted February 12, 2015 We noticed things got considerably better if the printers were installed after the desktop has been presented, so we're now using Group Policy INI Files Preferences (for OU targeting) combined with a logon script to deploy printers. That has the added advantage of a shortcut to the same script in the Start Menu, so if it does still fail for some reason, people can use "Redeploy Printers" to restore them without logging off and on in 99% of cases. 1
TriggerHappyUK Posted February 12, 2015 Posted February 12, 2015 Have you tried typing in the fully qualified domain name when you add the printer? Instead of \\server\printer Try \\server.domail.com\printer Hope this helps
MartynJ Posted February 12, 2015 Posted February 12, 2015 Would like to know what the solution was also as we're having the same issue.
ghafoor Posted February 12, 2015 Posted February 12, 2015 He is not telling you... you will have to pay him..hehe
ghafoor Posted February 13, 2015 Posted February 13, 2015 Harry is no where to be seen now that he has got his issue sorted. next time he will have to sign a contract to disclose the solution before he gets any answers on here.
Boredguy Posted February 13, 2015 Posted February 13, 2015 Check that your print server queue has both 32 and 64 bit drivers. We installed a new printer onto a 2012 server and deployed it to a Windows 7 32 bit client and got the same error.... as I'd only assigned 64bit drivers to the queue! Added the x86 ones and message disappeared. We only use GPP for printer deployment.
mattpant Posted February 19, 2015 Posted February 19, 2015 Thanks guys, all sorted. What was your solution in the end? A few people, including myself have this same issue so would be good to know what fixed it for you!
xenonive Posted February 19, 2015 Posted February 19, 2015 We had the same issues , we redeployed with Print Management tool in administrator tools rather than our previous manual entries in group policy printer section and they work fine now. Guide here . https://technet.microsoft.com/en-us/library/cc755424%28v=ws.10%29.aspx
mattpant Posted February 21, 2015 Posted February 21, 2015 We had the same issues , we redeployed with Print Management tool in administrator tools rather than our previous manual entries in group policy printer section and they work fine now. Guide here . https://technet.microsoft.com/en-us/library/cc755424%28v=ws.10%29.aspx I've just tried deploying printers to one of our IT Rooms using this method but I'm STILL getting inconsistent results - sometimes it works - sometimes it doesn't!!
mattpant Posted February 25, 2015 Posted February 25, 2015 These B****Y printers and doing my head in and giving me sleepless nights... I'm STILL having issues with them randomly mapping when logging in... Sometimes a user can login and they get them - other times they can't, it's becoming a right pain in the backside! I've tried deploying the printers with a VBS logon script (which we used under Windows XP and worked EVERYTIME), I've tried deploying them with GPP, under a loopback policy so they install to the computer and not the user, they've been setup under the user side for the loopback so that a Shared Printer can be setup and set as default printer (which I understand you can't do it setting up purely under the computer side of group policy settings). I've also tried as suggested to deploy them using the Deploy with Group Policy option in the Printer Management Console, but whichever option I use I still get the random results. The workstations are Windows 8.1 Enterprise x64 with all the latest update, the option in Group Policy has been setup about the Point and Print settings - the driver share has both the 32bit and 64bit version of the same driver, the drivers have been updated from the Kyocera Website. ANYTHING else I can try?!?!?!? I'm tearing my hair out! Thanks Matt
Ephelyon Posted February 25, 2015 Posted February 25, 2015 If you can definitely guarantee that printer deployments should always be location-based, i.e. based on the computer and not the user, what about a startup script?
pow Posted February 25, 2015 Posted February 25, 2015 These B****Y printers and doing my head in and giving me sleepless nights... I'm STILL having issues with them randomly mapping when logging in... Sometimes a user can login and they get them - other times they can't, it's becoming a right pain in the backside! I've tried deploying the printers with a VBS logon script (which we used under Windows XP and worked EVERYTIME), I've tried deploying them with GPP, under a loopback policy so they install to the computer and not the user, they've been setup under the user side for the loopback so that a Shared Printer can be setup and set as default printer (which I understand you can't do it setting up purely under the computer side of group policy settings). I've also tried as suggested to deploy them using the Deploy with Group Policy option in the Printer Management Console, but whichever option I use I still get the random results. The workstations are Windows 8.1 Enterprise x64 with all the latest update, the option in Group Policy has been setup about the Point and Print settings - the driver share has both the 32bit and 64bit version of the same driver, the drivers have been updated from the Kyocera Website. ANYTHING else I can try?!?!?!? I'm tearing my hair out! Thanks Matt I'm in EXACTLY the same position, drives me bl**dy mad. One of these days, when I get some time, I'm going to find one that doesn't map and sit there with ProcMon and find out WTF is stopping it. Just finding the time. Can't believe this isn't a known fault with a fix.
mattpant Posted February 25, 2015 Posted February 25, 2015 If you can definitely guarantee that printer deployments should always be location-based, i.e. based on the computer and not the user, what about a startup script? I'm happy to give ANYTHING a go!! I'm guessing I would just use the VBS script that I have been using and add it as a startup script then instead of a logon script? The VBS script I have been using looks at the computer name - and if the name ='s to the criteria, it install's the relevant printer for that room.
Ephelyon Posted February 25, 2015 Posted February 25, 2015 Need to make sure you're adding it as a computer connection, not a user connection (else it would add for the SYSTEM user only and not be visible to others), but yes, it should be possible.
TheCrust Posted March 15, 2015 Posted March 15, 2015 Did you get any further with your problem @mattpant ? We have the same problem with our Windows 8.1 clients: inconsistent deployments. We map printers as part of our login script process. This vbs script worked faultlessly for our Windows 7 clients, but since we moved to 8.1 I've noticed it is not as reliable. A suite of 30 computers may see half of them map fine with no issues and the rest are a little wayward either partially mapping (we have two queues, one colour, one mono) or not at all.
computer_expert Posted March 16, 2015 Posted March 16, 2015 Did you get any further with your problem @mattpant ? We have the same problem with our Windows 8.1 clients: inconsistent deployments. Have you tried using the add-printer powershell cmdlet for windows 8.1/server 2012 r2 in your logon script?
TheCrust Posted March 24, 2015 Posted March 24, 2015 I haven't, I'll be honest - we were using a legacy VBScript proceedure. Hadn't touched it for years as it "just worked" but I'll build a test script featuring that cmdlet when I get a moment and see what happens. I get the impression the Windows 8.1 printing model is a bit flakey at times anyway. Sometimes when adding a printer manually, even one listed in the directory, it doesn't appear under Devices and Printers until the machine in question is restarted. Same goes for making a print device the default printer - changes just aren't always reflected in the window as instantly as you might have expected under, say, Windows 7.
mattpant Posted April 24, 2015 Posted April 24, 2015 Hi - no didn't get anywhere with it - still the same old issue that sometimes it works - sometimes it doesn't! I'd love to find the cause!!
Ephelyon Posted September 28, 2015 Posted September 28, 2015 [Responding to Jollity's PM just now, posting here so I can attach files. Shout-out to @ZeroHour: is there any way to enable sending files through PM please? ] Quoting PM: "The way the 'after the desktop is presented' approach is achieved is by not using a logon script per se, but instead placing a link to the script in our redirected Start Menu's Programs > Startup folder. Those startup items are executed by Explorer, not by the WinLogon process, so it will inevitably execute once the desktop has been presented." I'm attaching a screenshot of a sample GPP INI Files entry for a printer along with the script I've written to apply them. We write to the INI file in %AppData% and append to the [Default] INI file section. The property name is the printer's share name on the print server, e.g. \\print-server\Room1 yields the property same "Room1". The value is Yes if the printer is to be set as default, and anything else (I tend to use No ;D ) if not. The disadvantage of that approach is in how you order the GPP INI Files entries, though we've never had an unworkable situation so far... The script reads these entries and uses "con2prt" to add the printers - deploy this utility (Google it) to workstations through GPP Files if they don't have it already. It also logs to %AppData%. Modify the script to replace "mhs-print" with your print server name and place it somewhere globally accessible (it's on the NetLogon share in our case). Set the GPP Preference Shared tab option to run in user context and target as appropriate. You can then create a shortcut to the script in a redirected Start Menu's "Programs > Startup" folder, choosing to minimise by default so it's not painfully obvious to the user logging on that the script is running. Bonus: this fixes our issues 99% of the time, but for those exceptional situations where it doesn't, you can always add another shortcut to the script in another Start Menu folder, so you can instruct users to run e.g. "Redeploy Printers" (as we've termed it) as a first-response fix if they don't get all the printers they're supposed to the first time round.DeployPrinters.zip 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now