Installing Printers with Active Directory
-
I'm trying to "install" all the printers on my network to all the users on my network, all at once.
I have a GPO called
Printer Deployment
that lists all my printers.The GPO is linked to the
Authenticated Users
group.But if I log in to a freshly imaged computer, none of my printers are listed. I have to specifically go to the
Devices and Printers
window, and hitAdd Printer
to get a printer listed. Once I do that, Windows is smart enough to find all the printers in the GPO.But how do I make it so that the user does not need to
Add Printer
? Users are on Windows 7 Pro, server is Windows Server 2012 R2.
-
@Captain Did you check this?
-
Yes, I followed that, and https://community.spiceworks.com/how_to/77664-so-you-need-to-deploy-printers-with-group-policy-windows-2012-r2 side by side, since the latter has a bit more detail for a n00b like me.
-
@Captain How long did you allow this to occur? How many computers and how many printers do you have? How many domain controllers?
-
@Polygeekery said in Installing Printers with Active Directory:
How long did you allow this to occur?
Was going to be my next question. If the printers are assigned per-user instead of per-machine, it might be that the background policy update is taking a while because of other GPOs or something.
-
One domain controller. About 60 clients. Maybe 5 printers to deploy globally. I don't know when the behavior started to change. Maybe the previous ops manager installed printers manually on my computer. I know they're not showing up on new images.
-
@e4tmyl33t Yeah. If the domain is not huge, he could try "gpupdate /force" and see what happens. That should take care of it. If the domain is huge though...that can cause problems.
Considering he said he wants to deploy all printers to all of the users, I am going to guess it is a small domain and should just force a Group Policy update.
-
@Captain If you are going to deploy them to all computers, just put it in your Default Domain Policy. That will take care of it.
-
@Polygeekery said in Installing Printers with Active Directory:
@Captain If you are going to deploy them to all computers, just put it in your Default Domain Policy. That will take care of it.
I guess my concern is that it "should" be working now, but it isn't. So I don't know if there's a broken setting.
-
Does it matter that I'm trying to "deploy" printers that are shared from a different machine?
So I have a machine called
fs
, and it has the printer drivers installed.dc01
is my domain controller, and it has thePrinter Deployment
GPO that correctly lists thefs\\Copy Room (HP)
etc printers. Do I need to do anything special onfs
to get this to work?
-
@Captain Well, those settings can take a little bit to propagate. Your domain is small enough, force an update of Group Policy and then reboot your test image and see what happens. If it is still not applied, force a Group Policy update on the client and see what happens.
-
@Captain said in Installing Printers with Active Directory:
Does it matter that I'm trying to "deploy" printers that are shared from a different machine?
So I have a machine called fs, and it has the printer drivers installed.
dc01 is my domain controller, and it has the Printer Deployment GPO that correctly lists the fs\Copy Room (HP) etc printers. Do I need to do anything special on fs to get this to work?You shouldn't have to. Is there a difference in OS between the machines? 32-bit versus 64-bit can cause issues in printer deployment, and IIRC it is more difficult to add additional drivers when not shared from the server with the Print Management role installed.
-
@Captain said in Installing Printers with Active Directory:
Do I need to do anything special on fs to get this to work?
AFAIK, it needs to be a "Print Server" as recognized by AD.
If you open Print Management and expand Print Servers, does fs appear there?
-
@Captain Is the printer physically attached to fs? Or is it a network printer?
-
@Polygeekery said in Installing Printers with Active Directory:
@Captain Is the printer physically attached to fs? Or is it a network printer?
They're network printers.
I just went to FS > Print Management and adjusted the Group Policy settings to Deploy per User instead of per machine. Will try
gpupdate /force
now. I should run that on the domain controllerdc01
, right?
-
@e4tmyl33t said in Installing Printers with Active Directory:
AFAIK, it needs to be a "Print Server" as recognized by AD.
If you open Print Management and expand Print Servers, does fs appear there?That is not necessary. We work with medical clients that have label printers all over their fucking buildings attached to workstations and we can share them out via GP and the workstations do not show up as print servers.
Yes, it is a mess. But it works, most of the time.
-
@Captain said in Installing Printers with Active Directory:
Will try gpupdate /force now. I should run that on the domain controller dc01, right?
The client.
-
@Polygeekery said in Installing Printers with Active Directory:
@e4tmyl33t said in Installing Printers with Active Directory:
AFAIK, it needs to be a "Print Server" as recognized by AD.
If you open Print Management and expand Print Servers, does fs appear there?That is not necessary. We work with medical clients that have label printers all over their fucking buildings attached to workstations and we can share them out via GP and the workstations do not show up as print servers.
Yes, it is a mess. But it works, most of the time.
Ah. TIL then.
-
@Captain said in Installing Printers with Active Directory:
They're network printers.
So why not install it to the domain controller?
Stupid question time: If you manually install the printer, you can print to it. Correct?
@Captain said in Installing Printers with Active Directory:
Will try gpupdate /force now. I should run that on the domain controller dc01, right?
Yes. Then on the client if it does not show up after a reboot. (log off and log on should work, but does not always. NFC why.)
-
-
@Polygeekery said in Installing Printers with Active Directory:
medical clients that have label printers all over their fucking buildings attached to workstations
the zebra's are hunting me!
-
@Captain If you open the Group Policy that you setup and drill down to Computer Configuration > Policies > Windows Settings > Printer Connections, do you see the printer you are trying to deploy? If you are trying to do it per user, same path but substitute User Configuration at the beginning.
-
@Polygeekery said in Installing Printers with Active Directory:
@Captain said in Installing Printers with Active Directory:
They're network printers.
So why not install it to the domain controller?
I could, but I'd rather avoid configuration churn. One problem at a time.
Stupid question time: If you manually install the printer, you can print to it. Correct?
Yes
@Captain said in Installing Printers with Active Directory:
Will try gpupdate /force now. I should run that on the domain controller dc01, right?
Yes. Then on the client if it does not show up after a reboot. (log off and log on should work, but does not always. NFC why.)
So far,
gpupdate /force
worked on my desktop, where I removed a printer and AD re-added it. It looks like the problem was the mismatch between per user and per machine configurations. The GPO was linked to a list of users, not machines. I think.I'll test on a fresh box.
-
@Luhmann said in Installing Printers with Active Directory:
the zebra's are hunting me!
I thought of you as I wrote it. I almost paged you, but I did not want to trigger the PTSD. ;)
-
@Polygeekery said in Installing Printers with Active Directory:
(log off and log on should work, but does not always. NFC why.)
Those "policies" are more like...suggestions.
-
@Polygeekery
we try to push most of the off to the downstream IT service teams ... but it is literally like rowing up stream in shit creek. You could make landfall and try to find a short cut through the Forrest of Scanners but that place is haunted too.
-
@Captain said in Installing Printers with Active Directory:
So far, gpupdate /force worked on my desktop, where I removed a printer and AD re-added it.
You have a small domain. Get used to using "gpupdate /force". It is the next best thing to hitting your DC with a sledgehammer.
-
@Polygeekery said in Installing Printers with Active Directory:
but does not always
I thought there was some timer shit involved so that rebooting a machine several times didn't trigger a machine policy pull in all cases. Or something like that.
-
@Luhmann said in Installing Printers with Active Directory:
I thought there was some timer shit involved so that rebooting a machine several times didn't trigger a machine policy pull in all cases. Or something like that.
I believe so, but I do not think it comes in to play on small domains.
GP/AD mostly works via magic, as far as I can tell.
-
@Polygeekery said in Installing Printers with Active Directory:
@Captain said in Installing Printers with Active Directory:
So far, gpupdate /force worked on my desktop, where I removed a printer and AD re-added it.
You have a small domain. Get used to using "gpupdate /force". It is the next best thing to hitting your DC with a sledgehammer.
Yeah, I might need to.
It seems like the previous admin had lots of things set up 'per machine,' whereas I have adopted a policy of fully roaming profiles to lower maintenance costs. I hope I'm near the end of the transition. (But I doubt it, since drive mappings are getting lost too...)
-
@Captain said in Installing Printers with Active Directory:
It looks like the problem was the mismatch between per user and per machine configurations. The GPO was linked to a list of users, not machines. I think.
I think you are correct. Your GP was assigned to authenticated users, but you did it on a computer basis. Not sure how that works out. Never tried it.
To be honest, for something as simple as that, on such a small site, where it is that global, I would just stick it in the Default Domain Policy and be done with it. I get that you were playing around trying to figure out how it works though. :tips:hat:
-
@Polygeekery said in Installing Printers with Active Directory:
@Captain said in Installing Printers with Active Directory:
It looks like the problem was the mismatch between per user and per machine configurations. The GPO was linked to a list of users, not machines. I think.
I think you are correct. Your GP was assigned to authenticated users, but you did it on a computer basis. Not sure how that works out. Never tried it.
To be honest, for something as simple as that, on such a small site, where it is that global, I would just stick it in the Default Domain Policy and be done with it. I get that you were playing around trying to figure out how it works though. :tips:hat:
The configuration was already done, but I've been swapping machines in and out of the network. I'm sure there's a list of machines somewhere in AD, and I'm sure printing worked perfectly fine on all of those.
-
Anyway, thanks everybody. Big help.
-
@Captain said in Installing Printers with Active Directory:
But I doubt it, since drive mappings are getting lost too...
How are they assigned now? I usually break people up in to OU's and then apply a GP to them based upon that with security filtering based on Authenticated Users and then the OU it should apply to.
-
@Polygeekery said in Installing Printers with Active Directory:
@Captain said in Installing Printers with Active Directory:
But I doubt it, since drive mappings are getting lost too...
How are they assigned now? I usually break people up in to OU's and then apply a GP to them based upon that with security filtering based on Authenticated Users and then the OU it should apply to.
I don't know, I haven't looked into it yet.
-
@Captain Hit me up if I can be of any help. I am a shitty dev, but a half decent sysadmin.
-
@Polygeekery said in Installing Printers with Active Directory:
AD mostly works via magic, as far as I can tell
Try using an AD-connected Mac like I do.
I'd describe it more like voodoo than magic. It works perfectly most of the time, but when something goes wrong, it goes wrong.
-
@loopback0 said in Installing Printers with Active Directory:
Try using an AD-connected Mac like I do.
I usually like a challenge, but I gave up on that one. "Here's your Mac. Don't fuck it up."
-
@Polygeekery said in Installing Printers with Active Directory:
"Here's your Mac. Don't fuck it up."
We get the same.
A colleague accidentally deleted the AD computer account from his. That worked out about as terribly as you'd expect.
-
@loopback0
When i was a young and naive sysadmin i joined a linux fileserver to AD with samba and permissions well mapped.
That was straight on the "drink the blood from virgins" black magic.
I never knew how the fuck i managed to make it work
-
@Jarry said in Installing Printers with Active Directory:
That was straight on the "drink the blood from virgins" black magic.
In certain ways, it still is.
Every time I reboot my NAS, I have to be absolutely sure the domain is extremely ready for the NAS to join the domain (Yes, it deletes its' own user account and rejoins the domain, because why would you remember that you joined), and if it's not and the NAS tries (and fails, obviously) to join, it's f'd until a reboot, bar none, don't pass go, pay $200 in taxes.However, if it does everything right the first time, it's (mostly, almost, kinda) painless.
-
@Captain said in Installing Printers with Active Directory:
how do I make it so that the user does not need to Add Printer?
I have completely given up on trying to make Group Policy work reliably enough to do this; out of 120 workstations there would always be some randomly selected ten where it failed.
In my experience, the only thing AD actually does manage to do reliably is run logon scripts at logon time. Policy often gets forgotten about and only works on the next logon (or startup, for Computer Policy) after a refresh.
I would regularly see workstations get into some weird state where they completely ignored policy changes, or sometimes even existing policy settings. Including the following early on in the logon script has essentially cured that:
start "Policy refresh" /min cmd /c "echo n|gpupdate /force"
though it still sometimes happens that a startup or shutdown script won't run until the next startup or shutdown.
So at my site, anything that's more complicated than a policy-related registry change, and has to apply per-user or per-user-per-computer, just goes in the logon script.
At the end of the standard logon script I have this:
:: Do computer-specific logon set computer-logon="\\curricserver\netlogon\Computers\%COMPUTERNAME%.logon.cmd" if exist %computer-logon% call :copyrun %computer-logon% :: Do user-specific logon set user-logon="\\curricserver\netlogon\Users\%USERNAME%.logon.cmd" if exist %user-logon% call :copyrun %user-logon% :: Do user-at-computer-specific logon set user-at-computer-logon="\\curricserver\netlogon\Users@Computers\%USERNAME%@%COMPUTERNAME%.logon.cmd" if exist %user-at-computer-logon% call :copyrun %user-at-computer-logon% goto :eof :: Copy a command script to %temp% and run it from there. When cmd is running :: a script it repeatedly opens it, reads one line and closes it; this is :: terribly inefficient for scripts from network locations. Copying them to :: a local drive first causes a substantial speedup. :copyrun type "%~1" >"%temp%\%~nx1" && C: && cd \ && "%temp%\%~nx1" %2 %3 %4 %5 %6 %7 %8 %9
Here's the whole of
\\curricserver\netlogon\computers\2011-01-04-rm16.logon.cmd
, which is fairly typical:set printer1="\\2011-01-13-rm16\Samsung ML-3470 Series PS" set printer2="\\2011-01-13-rm16\hp psc 1300 series" set printer3= set printer4= set printer5= start "Connecting printers..." /min cscript /nologo "%ProgramFiles%\sthomas\set-printers.js"
And here's set-printers.js. If it will be of use to you, please feel free to steal and adapt.
-
@Captain said in Installing Printers with Active Directory:
I have adopted a policy of fully roaming profiles to lower maintenance costs.
That was one of my first moves as well, as a budding Windows netadmin.
Undid it four years later; got sick of dealing with all the bullshit failure modes. Turned out that automating per-user access to stuff that my users actually cared about was less work than keeping on top of everything that seems specifically designed to blow roaming profiles out to titanically unmanageable proportions.