W2K8 Server Shared Printers won't install if drivers not in Win7 C:\Windows\System32\DriverStore\FileRepository?

Question

We have Windows 7 64 bit computers in two domains that just recently will not install printers (Windows 2008 R2 print servers) if the driver folder for the printer does not already exist in C:\Windows\System32\DriverStore\FileRepository. This
is under a domain administrator account logged onto the workstation.
If the driver folder exists then it will install but if the printer is brand new and doesn't use an existing driver or uses a new driver, the folder will not be populated in the FileRepository. For example if you rename the Lexmark Universal Printer Driver
folder lmud0c40.inf_amd64..... to another name and delete try to reinstall the same printer you had working 5 minutes earlier, it will not install.  The C:\Windows\System32\Spool\Drivers\x64\3 folder STILL contains all the drivers for the printer
but for some reason it won't 
The error is: Connect to Printer: Windows cannot connect to printer: Operation Failed with Error 0x00000057
All the "googled" solutions say to add the folder to the FileRepository manually but that is unrealistic with 19,000+ computers.
This exists across multiple domains, with multiple printer types and is not related to Group Policy as the issue still exists in a computer no policies applied except that had point and print=disabled. It also doesn't appear to be permissions based
as I granted the user "full control" of the FileDepository folder and it didn't make a difference.
They are signed drivers. The Print$ is shared on the server.
The odd thing is that in another domain we have, it works just fine even with regular user accounts (with point and print disabled). The server serves up the printer driver to the spool folder and it is copied to the FileRepository
lforbes

Answer 1

I was suggesting pkgmngr just to confirm on one machine that it could stage the package.
The package drivers are copied to the client from the PCC share on the print server 
\\Server\print$\x64\pcc
The cab file is copied to client , extracted , then staged to the filerepository.  At this point the spooler will install the print driver from the package and copy the file to the \system32\spool\drivers\x64\3 directory and loaded into the spooler
process from there.
For drivers that are not package aware, there is not a digital signature copied with the file set.
Package aware print drivers contain this data in the printer inf file
[PrinterPackageInstallation.amd64]
PackageAware=TRUE
The spooler does some secure validation using the asyncRPC protocols with package aware drivers and I've hit odd issues when stale machine accounts exist cross domain.  I know you are not hitting this exact issue but verifing someone did not disable
the protocol in some domain policy (through reg entry) was the request.
Regarding the Point and Printer Restrictions policy.  Disabling (or configuring) the policy disables the Restrictions around point and print.  There is also server information that can be included in the policy.  There are also another
policies to verify
Computer\Admin Templates\Printers\Only use Package Point and print
Computer\Admin Templates\Printers\Package Point and Print - approved servers
With Windows8 and Server 2012, the Version 4 drivers are loaded directly from the driverstore.  Version 3 drivers still use the same path.
Hope that's not too much info.
Alan Morris Windows Printing Team
Thanks for the info:
So an update on this on the "fix" which really isn't a fix at all.
If you take Admin ownership of the C:\Windows\System32\DriverStore folder, set Admins=Full Control and delete the 4 added .dat files in there and then restart the print spooler service, you can add printers as an administrator.
Basically this defeats the entire purpose of adding printers to the FileRepository under the SYSTEM account.
It is at this point that it fails "The cab file is copied to client , extracted , then staged to the filerepository."
The drivers are digitally signed, in fact they are the "default" windows drivers from the default store.
I verified the driver cab files are in the
\\printserver\print$\x64\PCC folder
I did a test and this "fixed" it although it is not something we can implement.
If gave Administrators ownership of the C:\Windows\System32\DriverStore folder, set Admins=Full Control and deleted the 4 or 5 added .dat files in there I renamed the existing FileDespository to "old" and created a new one and then restarted
the print spooler service.
The printer had never been added before so it didn't exist in the registry.
On the restart of the spool service the folder a folder was created in the File Repository called
ntprint.inf_amd64_neutral_4616c3de1949be6d
Then on the install of the driver, by an administrator account, two more were created downloaded from the  \\printserver\print$\x64\PCC
prnms001.inf_amd64_neutral_9fe8503f82cd60fa
prhp002.inf_amd64_neutral_04d05d1f6a90ea24 (printer driver)
So basically whatever gives SYSTEM access to "add" drivers to the DriverStore seems to be broken. It works OK if the Administrators have full control of all the files but not if it is running under SYSTEM.
I tried to disable the AsyncRPC protocol and then undid the disable. It didn't make a difference.
I have found hotfixes for Windows 7 Printer issues and have applied them all and the rollup and they didn't make a difference.
http://support.microsoft.com/kb/2647753
http://support.microsoft.com/default.aspx?scid=kb;en-US;2388142
KB982728
lforbes