![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Active Directory and Printing: need documentation
- Thread starter Slade
- Start date
printer's aren't "stored" in AD.
you install the printer on a server. Share the printer. User's connect to it via browsing \\servername then right-clicking on the printer and selecting "Connect"
permissions are set on the printer, from the server-side, to allow specific users/security groups to print, manage print jobs, etc.
you install the printer on a server. Share the printer. User's connect to it via browsing \\servername then right-clicking on the printer and selecting "Connect"
permissions are set on the printer, from the server-side, to allow specific users/security groups to print, manage print jobs, etc.
StarTrek4U
Gawd
- Joined
- Jan 8, 2003
- Messages
- 1,011
Printers can also be published via AD so your users don't have to do all those steps- which is what the OP is talking about.
You can do some searches for something like "printer publishing in AD" to see what you get, I guess I'm a bit confused on what you mean when you say "how it works" are you talking about the technical aspects of how AD publishes/manages printers, etc or is it more like a HOW TO doc so your users can connect/add the printers.
ah crap... that's right, you can publish them via AD. That's not how it's setup here, so I forgot
While I cant say for sure. When you publish to AD it is just that. You are publishing it so that you and others can find printers easily in one location. They dont have to know that its \\server24643\myPrinterRoxYourFace. But once the printer has been added to a machine it operates no different than any other network shared printer. And from there its just you and the server it is shared from to handle permissions and the like.
QwertyJuan
[H]F Junkie
- Joined
- Aug 17, 2000
- Messages
- 11,285
As I said before, I will say it again, USE CON2PRT.EXE!!!!!!!!!!!! No one needs to do ANYTHING but logon to their machines, and VOILA they have their printers installed for them!!!
While this has nothing to do with the OPs question, it is always important to stay current. The con2prt tool is old, super crazy old(nt4). As such it is not supported any more and is not in vista / 7. It should not be used. Here are two methods that are still supported and will work with everything xp and up.
The traditional user login script, and the way most people add their network shared printers. This method will probably stay current until they totally replace vbscript with powershell.
Or the method added in XP, prnmngr.vbs. In XP this is located in the system32 folder in vista / 7 its system32\printing_admin_scripts\en-US\
The traditional user login script, and the way most people add their network shared printers. This method will probably stay current until they totally replace vbscript with powershell.
Code:
Set objNetwork = CreateObject("WScript.Network")
objNetwork.AddWindowsPrinterConnection "\\server34534\ohLookAPrinter"Or the method added in XP, prnmngr.vbs. In XP this is located in the system32 folder in vista / 7 its system32\printing_admin_scripts\en-US\
Code:
cscript prnmngr.vbs -ac -p "\\server34534\ohLookAPrinter"
Last edited:
I don't need a how to, just documentation of the process going on between client and server. I've found some documentation on ms technet, but it was outlining windows 2000 server, AD and printing, but need something a bit more descriptive and in depth to how it goes about.
If you have book references to this process, it would be appreciated as our department will go and purchase such documentation.
We require documentation to support our request to have another department add our samba share printers installed into AD. We're going along the line that our network printing is slow because since our printers don't exist in AD, AD has to go through DNS to find the printer, all the while indicating back to our clients that it doesn't exist.
If you have book references to this process, it would be appreciated as our department will go and purchase such documentation.
We require documentation to support our request to have another department add our samba share printers installed into AD. We're going along the line that our network printing is slow because since our printers don't exist in AD, AD has to go through DNS to find the printer, all the while indicating back to our clients that it doesn't exist.
Unfortunately, I dont think you are going to find any documentation on this exact subject.
I still stand by my other post in that publishing a printer to active directory only acts as an organizational tool. The clients still have to resolve the server name that the servers are on.
I think a better direction for you to go is to read up how AD uses DNS. AD is built around the idea that its domain controllers are the DNS servers. If you have non ad machines on a different DNS it has to be setup just right so that names can be resolved going both ways. Also "AD has to go thought DNS to find the printer" is the wrong thinking as its not AD that is going through DNS to find the printer, its the clients.
do some tests, see if you can resolve the print server from both netBIOS name and FQDN. If one of these cannot resolve there is your problem right there. If you can, when you goto \\server01 do you see the folders and printers that are being shared from that machine? I have seen slow printing / extremely slow printer properties be a result of bad drivers. We have a plotter printer that had this problem a few months ago. When accessing printer properties it would sometimes not work, or take mintues for the dialog to show up.
I still stand by my other post in that publishing a printer to active directory only acts as an organizational tool. The clients still have to resolve the server name that the servers are on.
I think a better direction for you to go is to read up how AD uses DNS. AD is built around the idea that its domain controllers are the DNS servers. If you have non ad machines on a different DNS it has to be setup just right so that names can be resolved going both ways. Also "AD has to go thought DNS to find the printer" is the wrong thinking as its not AD that is going through DNS to find the printer, its the clients.
do some tests, see if you can resolve the print server from both netBIOS name and FQDN. If one of these cannot resolve there is your problem right there. If you can, when you goto \\server01 do you see the folders and printers that are being shared from that machine? I have seen slow printing / extremely slow printer properties be a result of bad drivers. We have a plotter printer that had this problem a few months ago. When accessing printer properties it would sometimes not work, or take mintues for the dialog to show up.
We have multiple printers, so its not exclusive to a set of drivers. We have multiple machines and configurations so its not one particular setup. We have noted that there is some mismatches in DNS and as such are moving to resolve them. The shares and printers appear quickly when you type in \\servername01\.
We're dealing with some pig headed red tape guys that want documentation and proof before they proceed to make changes to their beloved setup which according to their department is performing flawlessly. If we had the authority to make the suggested changes you speak of, we would have done so months ago.
Just yesterday they had us test if Windows Firewall was the problem. According to their end from their network it responded and printed fine if the firewall was off. Yet to them its simply a hop from their subnet to ours, while for printing here it goes to their subnet then back to ours. Not exactly consistent testing here. It's an uphill fight for us here.
We're dealing with some pig headed red tape guys that want documentation and proof before they proceed to make changes to their beloved setup which according to their department is performing flawlessly. If we had the authority to make the suggested changes you speak of, we would have done so months ago.
Just yesterday they had us test if Windows Firewall was the problem. According to their end from their network it responded and printed fine if the firewall was off. Yet to them its simply a hop from their subnet to ours, while for printing here it goes to their subnet then back to ours. Not exactly consistent testing here. It's an uphill fight for us here.
QwertyJuan
[H]F Junkie
- Joined
- Aug 17, 2000
- Messages
- 11,285
It won't work with Vista or 7?
I have 70+ machines that use con2prt.exe EVERYDAY, and 10 or more are Vista and 3 are running 7.Why everyday? Because each machine removes ALL printers at startup then add them back... it takes a total of MAYBE 15 seconds, and this way I can ensure that each machine is running the latest driver(if I decide to update the drivers on my server) and it also ensures that all the machines in the building have the newest printer installed... install a new printer?(which we did a few months ago... two Xerox multifunctions) 30 seconds later the login scripts are changed, and VOILA, the machine deletes the old printers and they have the new printer on their machine in perhaps a minute flat.(initial driver install takes a bit longer than subsequent printer installs at every boot)
QwertyJuan
[H]F Junkie
- Joined
- Aug 17, 2000
- Messages
- 11,285
con2prt /f
con2prt /cd \\schoolserver\school
con2prt /c \\schoolserver\publications
con2prt /c \\schoolserver\office
Done.
/f deletes all shared-printers
/cd installs printer and sets default
/c installs rest of printers and leaves default printer alone
con2prt /cd \\schoolserver\school
con2prt /c \\schoolserver\publications
con2prt /c \\schoolserver\office
Done.
/f deletes all shared-printers
/cd installs printer and sets default
/c installs rest of printers and leaves default printer alone
the print job gets sent to the server sharing the printer. Regardless if it's published in AD or not. The job has to go somewhere to get sent to the printer.
unless it's installed on the desktops as an IP printer, then the print job gets processed and sent to the printer by that computer that's being printed from.
publishing the printer in AD just means it can be found (easier) by "Browse for printer" when attempting to add a printer to a desktop.
It won't work with Vista or 7?
there's a difference between not supported and won't work
YeOldeStonecat
[H]F Junkie
- Joined
- Jul 19, 2004
- Messages
- 11,330
Well login scripts like logon.bat doing net use commands are old from NT 4 days, and still easily and widely used.
QwertyJuan
[H]F Junkie
- Joined
- Aug 17, 2000
- Messages
- 11,285
there's a difference between not supported and won't work
I was kinda getting at the point where he said it "should not be used". If something works, and works well, why "shouldn't" it be used?
YeOldeStonecat
[H]F Junkie
- Joined
- Jul 19, 2004
- Messages
- 11,330
Those who are experience with Microsoft products will know that there are several different ways to skin a cat...several approaches to getting the same end result. Just because some methods may be older methods does not mean that the old methods are incorrect. For those of us that live in free countries...we can choose the methods we're comfortable with and utilize those methods.
Back to the OPs question, stemming from one of his other threads about printers in AD....the question seems to be if it's using AD or of it's using DNS. As my answer in that other thread was....IMO the two (AD and DNS) are inseparable, they are married together, one cannot live without the other.