Installing a printer 2003 server updates all print drivers

I have a windows 2003 sp2 domain controller that we also use as a print server. there is about 20 printers, Ricoh, HP, Lanier. I installed a new printer, and clients on the network were prompted on Windows 7 to install the driver for all or most of the other printers that I didn't touch at all. The windows xp machines also seemed to install the driver over again, but there was no prompt. I found articles that point to disabling the prompt for driver install, but what I need to know is:

Why do clients get prompted to reinstall the same driver from printers that I didn't touch, after installing a new printer on the server. I haven't seen this before in the past. Thanks
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

its probably  due to windows 7 you need to isolate the issue whether it happens on win 7 or xp then work on the solution
IX_LongBowAuthor Commented:
On XP, the user isn't prompted, but the load on the machine and delay in printing indicates the driver is updating on xp also.
How are you deploying the printers per user or per computer if GPO.

When you update a driver for one printer of one manufacturer, all the printers of that manufacturer will see the new drivers.

i.e. you have 6 HP, 7 ricoh and 7 lanier.

the drivers are stored \\printserver\print$

If you look at the driver tab under the print manager, you will not see individual references to drivers based on the number of printers to which they apply.

Since that will be messy. printer1 ricoh will have driver version 1 while printer2 ricoh will have driver version 1.1. and so on.

The driver should be auto-installed the next time the system reboots and the user logs.

The user is prompted because the driver on their system for this printer no longer matches the driver on the print server.
unpublishing and republishing the printer should resolve the driver conflict.
The Five Tenets of the Most Secure Backup

Data loss can hit a business in any number of ways. In reality, companies should expect to lose data at some point. The challenge is having a plan to recover from such an event.

IX_LongBowAuthor Commented:
Arnold. no GPO was used to deploy printers. I can understand that drivers or dll's were updated on the printers prompting users for installation of the new drivers thanks. The unpublish replublish is confusing a bit. I installed the printers on each machine by using \\server\printersharename on each machine. The XP machines aren't much of an issue, but I have windows 2003 servers in AD functionality 2000 and believe windows 7 GPO setting to remove the administrator login requirement isn't available. Any work around for the windows 7 machines so I don't have to sign in as the domain admin on each windows 7 machine so the driver can install?
If you are not using a GPO to push the printers, the shared printer and the driver that it is using will not match the driver version on the print server which points to a conflict that can only be resolved through the update of the windows 7 local drivers.
i.e. you have a person call a number where they speak one language.  Without telling the person, you replaced the person on this phone number who now speaks a different language. This is what happens with the windows 7 it now sees the print server speaking a different language and tries to update its by accessing the driver share \\servername\print$
The only way around this is you have to unshare the printer and then reshare it.
This will prompt the reinstall of the drivers.

IMHO, using GPO to push printers to users simplifies things i.e. you add a server and the new server will be the print server.  In your case, you would need to go to each workstation to modify the installed printers. while with a GPO you can have printers deployed/pushed to the user such that they will only have printers they need as opposed to all printers that exist in the environment.

one caveat is make sure you add both 32 and 64 bit (itanium if you have those servers as well) drivers for the printers

i.e. you have a billing group of printers, engineering, customer service, etc.
GPO based deployment speeds up transition in the event the current print server is overburdened and you would like to use another.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Is your Windows Server correctly updated? is not, try to apply the updates on your server.
He is applying the updates on the server which is why there is a driver mismatch and the user is prompted to update the printer drivers.

i.e. printera has driver4.3
The shared printera is added to workstation7 with driver4.3
printera's driver has been upgraded on the sever to driver4.5
When user on workstation7 tries to print to printera, there is a driver mismatch between the locally installed driver4.3 and the driver4.5 that is presented by the shared printer.

Basically I agree to most of what arnold wrote.
On regard of the drivers, it may depend on the manufacturer and the driver, if it is a "packaged" driver or a "standalone" driver. One has to be really careful, when updating or installing new drivers, especially if they are packaged and of a differend version. As you seem not to have any other issues on regard of printing, reconnecting to the updated share should normally do this. If the user does not have sufficient rights, you might eventually use a script that has the rights to do the installation, if you do not want to go through GPO.

But the main thing you should take out of this discussion is, that a print server should not be on a domain controller. This is per se not the best of ideas to place a print server on, as if you break something it might affect all applications and users. Whilst you put it on a different server, separately, even (better) a virtual one, you can handle this without having to fear to brake something on the domain controller. Just as a recommendation.

And, yes, if you have a mixed environment of  64 / 32 bit, you'd require the alternative drivers for the other system as well, which you can install, when you create the shared access in the printer object.

While coming back to my beginning, should something have been going wrong during the install of the new driver it can happen, that the driver update did not work out, and you have a partly updated driver (i.e. you installed a new driver of a package, the other, older drivers on the system have DLL's open, the new driver tries to upgrade the package, but can't to those DLL's which are accessed, and the update is not complete) I hope this is not the case, but if, you might find various difficulties in printing, showing the options/printer properties or other miracles. Some drivers offer an Update or Installation, in such a case (of driver packages with shared DLL's) Update would be the path to go.
As long as everything is fine, once you reconnected, forget what I wrote, but if it comes over and over, it might be worth while to look into this direction as well. (check for the driver description)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Legacy OS

From novice to tech pro — start learning today.