Printer Deployment So Slow!

[eddyc]

We use Kix to deploy our network printers which deploys based on user, user group and then machine OU.

 

On the Windows XP machines which we still have running in our network, we have found that Kix runs through very quickly deploying the printers without an issue.

 

With Windows 7 however we are finding that printers are taking 2 minutes per printer to appear and sometimes the script is not even finishing before the end of the lesson.

 

We thought that we would investigate more by writing a new script with just the printers for one room in it and just run that script over the room, again it takes around 5 minutes per printer to map.

 

We have also written a small vb script to one room and tried this too, same results - xp machines are seconds, 7 machines are minutes.

 

Anyone have any suggestions, been playing with this for days now and am slowly going out of my mind!

 

Thanks, Ed.

[jsnetman]

Found the same issue with con2prt, so now use GP preferences to deploy printers for Win 7 machines.

[irsprint84]

I just use Deployment through Group Policy then default with group policy preferences, why not that way? the more vanilla the better!

[eddyc]

Having a GPO for every room isn't really a runner for us, also could never get it map printers to just user X using group policy unless someone knows how we can do this too?

[jsnetman]

Having a GPO for every room isn't really a runner for us

 

that is the beauty of GP preferences you don't need a policy for each room there are criteria you can add to the prefernces target to only apply printers to say computers starting with the name A1 then A2 and so on. I presume but have not tried you could even only deploy a printer for specific users or a group to a room using preferences.

 

An example of this is say our admin network which all the comps are in the same OU, however I only want to deploy 1 printer to the heads machine which no one else gets. The possibiliies using the targeting settings in preferences are endless or pretty much so.

Edited May 21, 2010 by jsnetman

[eddyc]

that is the beauty of GP preferences you don't need a policy for each room there are criteria you can add to the prefernces to only apply printers to say computers starting with the name A1 then A2 and so on. I presume but have not tried you could even only deploy a printer for specific users or a group to a room using preferences.

 

Can you provide more information on this please?

[eddyc]

OK I have sucessed this now and deplyed a printer to computers with an OU - the issue is now that this one printer makes logon sit there for 5 minutes saying "Applying Group Policy Printers" or something along those lines - any ideas?!

[ZeroHour]

OK I have sucessed this now and deplyed a printer to computers with an OU - the issue is now that this one printer makes logon sit there for 5 minutes saying "Applying Group Policy Printers" or something along those lines - any ideas?!

 

Out of interest whats your print server running?

[eddyc]

It is 2008 R2,

Printers are a mix of 2015n using its own Win 7 Driver,

HP 2600n using its own driver

and HP1320n using the universal hp drive.r

[ZeroHour]

It is 2008 R2,

Printers are a mix of 2015n using its own Win 7 Driver,

HP 2600n using its own driver

and HP1320n using the universal hp drive.r

 

Did you use standard queues (tcp) or did windows try to stick them all on that new standard (cant remember its name)?

[eddyc]

I had set them all up on TCP

[jsnetman]

I know this won't help but I had nightmares setting up printers with a whole load of problems like clients not downloading drivers and finding the right 64 bit and 32 bit, In the end I went all HP universal.

[eddyc]

We've tried that before, but had the same issue with that too

[murty]

I too have been having these problems, tried mapping the printers with GPO, Con2Print, and VBS scripts, the problem does not seem to matter what mapping method is used. We used Con2Print with our XP clients and the same print server for years with no issues, now that we've taken our computer labs to Win7 we have this problem. If we use GPO, the login time can vary anywhere from 30 seconds to 5 minutes, con2print the login is instant but the mapping process can again take 30 seconds to 5 minutes, though more often than not it fails on the mapping almost instantly and once it fails that workstation cannot connect to any printers off the printer server until it is rebooted (or the spooler server is bumped).

 

It almost seems like some kind of DNS or network problem. Our print server is 2k3 32bit, but I tried setting up a 2k8 64bit over the summer and the issue was even more pronounced. Just for experimentation's purpose, I tried running a 2k8 32 bit, and a 2k3 64 bit server as well, again the issue persisted, more pronounced from 2k8 servers.

 

The only variable that changed was taking our client workstations to Win 7 32bit from XP 32bit. I've dug all over the internet and found people with the same issues, but no real resolution.

 

Quite frustrating.

[edutech4schools]

We use Kix to deploy our network printers

 

Odd that you have issues. I am using Kix to deploy to Win7 and its very fast. Wonder what the difference is?

[McBridge]

I had the same problem. The only way I manged to fix the long map times was to use all universall drivers as HP did not have any specific Win7 drivers for my printers, some of which are brand new expensive colour laserjets. I am still of the opinion that there is definatly a bug of some sort with Win7 in the way it handles printers as I was also having the problem of not being able to delete any printers that had been deployed using GP and vbs scripts, in the end I had to write a script that deleted them from the registry. Printing in Win7 can be a total nightmare.

[Willott]

I had this issue, seems to be related to HP drivers, most probably the UPD. I think what helped with ours was (on the print server) renaming cioum32.msi to cioum32.bak, creating a zero byte file as cioum32.msi (you may need to stop the print spooler whilst doing this) within c:\windows\system32\spool\drivers\W32X86\3

 

Try mapping one of the ones which uses the inbuilt Windows driver and compare the logon times, may confirm if the above is where the issue lies. If not, it may be point and print permissions.

 

Cheers

 

Will

[witch]

Ours are all deployed using preferences and they all work fine EXCEPT for the ridiculously long time that the machines stay on 'applying printer policies'. We have identical printers and I am wondering whether to change the driver to the universal one if that would be quicker.

[ZeroHour]

The universal and HP's w7 drivers have major issues. I would source as many printer drivers as possible from Microsoft Update Catalog (IE only) as that what we had to do. Basically HP's drivers (inc UPD) have a routine when they are installing the driver which requires user input, as its a logon process it is denied asking the question which holds the installer up until it times out which is why the logons are slow. The update catalogue drivers dont have this.

Before changing drivers though it may be worth trying this: http://www.edugeek.net/forums/windows-7/47835-windows-7-gotchas-tips-fyi.html#post624624 as it seems to imply it will disable any of these elevations which could fix the issue but I have not revisited the upd/hp site supplied drivers yet to confirm.

 

Some thoughts on the UPD (although old version) http://www.edugeek.net/forums/windows-7/60264-windows-7-printers-hp-upd-time.html

[Willott]

@ZeroHour - that's exactly what we're planning to do, however I wasn't sure whether Windows XP clients would be supported by that (teacher laptops are in the process of being upgraded... but obtaining a laptop to do work on it reminds me of "cold dead fingers"). Interestingly, the x64 machines seem to suffer less with this issue.

[ZeroHour]

@ZeroHour - that's exactly what we're planning to do, however I wasn't sure whether Windows XP clients would be supported by that (teacher laptops are in the process of being upgraded... but obtaining a laptop to do work on it reminds me of "cold dead fingers"). Interestingly, the x64 machines seem to suffer less with this issue.

 

In regards to the UPD issue, it wont be a problem in XP or vista tbh as neither block the interactive routine where as w7 wont allow and interactive process access until your logged in.