Network printers via GPO.

[sch]

We recently lifted the domain functional level to 2008 R2. We are starting to see more windows 7 clients in our domain, but we still have lots of clients with windows xp.

 

Although we had this problem before we lifted our functional level (then running in mixed mode with 2003), it has become even worse now.

 

The problem is network printers via GPO. I'll try to keep it short

 

Basically, it won't work on either win7 or winxp computers when pushing the printers out on user configuration. However, it DOES work on win7 computers if i push the printers out via Print Services installed on the printserver on computer level, and then using the "add network printers" function in the GPO to set the printers as standard, for example. This does not work on winxp computers.

 

But, using the only GPO to add the printers, and only on user level, like i want to, won't work at all. And this is a massive headache to me. The printservers are spread out on various locations, all connected with fiber connection and running either server 2003 32bit or 2008 32bit.

 

Here is the setup i am currently using in my GPO's:

 

Computer configuration -> Administrative templates - Printers ->

 

Point and Print Restrictions Enabled

Users can only point and print to these servers: Disabled

 

Users can only point and print to machines in their forest Disabled

 

Security Prompts:

When installing drivers for a new connection: Do not show warning or elevation prompt

When updating drivers for an existing connection: Do not show warning or elevation prompt

 

Computer configuration -> Administrative templates - System -> Driver installation

 

Allow non-administrators to install drivers for these device setup classes Enabled

Allow Users to install device drivers for these classes:

{4d36e979-e325-11ce-bfc1-08002be10318}

{4658ee7e-f050-11d1-b6bd-00c04fa372a7}

 

User configuration -> Administrative templates -> Control Panel -> Printers

Prevent addition of printers Disabled

 

User configuration -> Administrative templates -> System -> Driver installation

Code signing for device drivers Enabled

When Windows detects a driver file without a digital signature: Ignore

 

I have confirmed that it's not any UAC or something like that that prevents the users to add the printers, because they can do that without any hickups when doing it manually.

 

Has anyone encountered this problem before, and got it to work? I'll provide you with as much information i can, so please ask. Thanks for the help in advance!

[danrhodes]

Why not use a script to deploy the printers once.

 

Just keep it simple and it will work fine. You can run this remotely and it will add a permenant connection to the specified printer for who ever loggs on, wether pupil or staff.

 

RUNDLL32 PRINTUI.DLL,PrintUIEntry /c \\MachineName1 /ga /n "\\ServerName\PrinterShare"

RUNDLL32 PRINTUI.DLL,PrintUIEntry /c \\MachineName2 /ga /n "\\ServerName\PrinterShare"

RUNDLL32 PRINTUI.DLL,PrintUIEntry /c \\MachineName3 /ga /n "\\ServerName\PrinterShare"

RUNDLL32 PRINTUI.DLL,PrintUIEntry /c \\MachineName4 /ga /n "\\ServerName\PrinterShare"

 

Or you can run it locally.

 

RUNDLL32 PRINTUI.DLL,PrintUIEntry /ga /n "\\ServerName\PrinterShare"

 

D

[Stuart_C]

I go with the below. It seems to work OK for me.

 

For script to run on computers use Loopback processing in Merge Mode

That would allow you to apply a script to a Computer Account but using the User section of the policy.

To set it up what you need to do is:

1. Create a Group Policy with the Loopback Policy enabled:

Computer Configuration --> Administrative Templates --> System --> Group Policy

User Group Policy loopback processing mode: Enabled & Merge

2. Create a Group Policy attached to the OU containing the computer account with the script in the: 

User Configuration --> Windows Settings --> Scripts Logon --> printers.vbs.

The Replace operation stops all other User based policies applying there and only uses those that would apply to the Computer OU.

The Merge operation uses the normal User based policies as well, but any policies set on the Computer OU take precedence.

Script for automated mapping of printer according to room number:

rem ** Next line must not be deleted ** 
Set WshNetwork = CreateObject("WScript.Network")
rem ** This will delete existing printers **
On Error Resume Next
Set oPrinters = WshNetwork.EnumPrinterConnections
       For i = 1 to oPrinters.Count - 1 Step 2
             WshNetwork.RemovePrinterConnection oPrinters.Item(i)
       Next
rem ** Setup new printer connection **
WshNetwork.AddWindowsPrinterConnection "\\server\HP"
rem ** Setup default printer **
WshNetwork.SetDefaultPrinter "\\server\HP"

[sted]

Why not use a script to deploy the printers once.

 

Just keep it simple and it will work fine. You can run this remotely and it will add a permenant connection to the specified printer for who ever loggs on, wether pupil or staff.

 

RUNDLL32 PRINTUI.DLL,PrintUIEntry /c \\MachineName1 /ga /n "\\ServerName\PrinterShare"

RUNDLL32 PRINTUI.DLL,PrintUIEntry /c \\MachineName2 /ga /n "\\ServerName\PrinterShare"

RUNDLL32 PRINTUI.DLL,PrintUIEntry /c \\MachineName3 /ga /n "\\ServerName\PrinterShare"

RUNDLL32 PRINTUI.DLL,PrintUIEntry /c \\MachineName4 /ga /n "\\ServerName\PrinterShare"

 

Or you can run it locally.

 

RUNDLL32 PRINTUI.DLL,PrintUIEntry /ga /n "\\ServerName\PrinterShare"

 

D

 

does that work on windows 7 as ive had nothing but trouble with printer scripts on win7?

 

though ive now started using the priinter deployment method that came with 2003 r2 and a quick script to set default which seems to work well

[danrhodes]

Only tried it on one W7 install and it worked, that not to say it would work again though!

[sch]

This is a very big network, and lot's of locations with lots of users and computers. And i have spent the last 6 months cleaning AD and it's policies up after starting in this job. A big part of the cleanup was to remove all scripts, and find other solutions to it. Like for example removing scripts for mapping network drives, and using policies instead. We found that this was much more stable than scripts.

 

Going back to scripts is not an option in this case, i don't see why there is GPO settings for pushing printers when we can't use it. It should be a cakewalk, yet it's not.

[danrhodes]

Try follwing a few guides to make sure no steps have been over looked?

 

Deploying printers using Group Policy

[sch]

Hello, thanks for the replies! It seems we've resolved this issue now, and i am ashamed to say it was due to my own nubeness . It was a security issue that caused the problem. Using the settings already applied, and then choosing in the printer connection witch you apply in the GPO, you choose to it to run with Run in logged-on user's security context (user policy option) enabled.

[jsnetman]

We have mostly win 7 clients but have a few classrooms still on XP. To get functionality for the two types we use group policy loop back mode for the seperate ou's containing XP and Win 7 Clients. We then use group policy preferences to deploy printers on the win 7 computers in the user portion of the policy, you get an extra level of choice using item level targeting wich allows you to deploy the printer by machine name or OU or a whole host of other options. On xp machine we are still deploying via script, but there is no reason they could not also get printers deployed via this method.

 

One more point of deploying printers via GP prefernces is you can specify a default printer which you can't using the other method.

Edited May 10, 2010 by jsnetman

[sch]

We have mostly win 7 clients but have a few classrooms still on XP. To get functionality for the two types we use group policy loop back mode for the seperate ou's containing XP and Win 7 Clients. We then use group policy preferences to deploy printers on the win 7 computers in the user portion of the policy, you get an extra level of choice using item level targeting wich allows you to deploy the printer by machine name or OU or a whole host of other options. On xp machine we are still deploying via script, but there is no reason they could not also get printers deployed via this method.

 

One more point of deploying printers via GP prefernces is you can specify a default printer which you can't using the other method.

 

Before i called it today, i managed to test it on xp clients. It seemed to work, but you get prompted for a user with admin rights. I read somewhere on the MS forums that if you disable Point to Print Restrictions it will go without the prompting in xp, i will test this tomorrow. If i can manage to remove that prompt, it will go smoothly.

 

Oh, and yeah, item-level targeting is supernice. We already use this to define the power settings on laptops in our domain. I'm sure we will use this more and more in the future

Edited May 10, 2010 by sch