Hi,
Our setup:
Windows Server 2008 x64 terminal servers with Citrix XenApp 5.5
Windows Server 2008 R2 file/print servers
x64 printer drivers
Network printers are mapped with RES PowerFuse
Our problem:
When installing or updating products using msiexec the process uses hours to complete, with about 50% cpu usage on a dual cpu terminal server.
We used process explorer to monitor the msiexec process to find out what it was doing, and found that it was enumerating a huge amount of GUIDs in the HKLM\Software\Microsoft\Windows NT\Current Version\Terminal Server\Install\RefHive.
After some digging on the internet we found that the GUIDs came from HKU\.Default\Software\PrintVendor\CSR|Printserver\{GUID}. With another vendors driver they are created directly under the "printvendor" key.
We found the same keys under HKU\S-1-5-18.
We then set up a testenvironment to find out why that huge amounts of GUID were created under the HKU\.Default... key, and it seems it is created each time a user logs on and connects a network printer.
On further investigation we found that RES PowerFuse disconnects the network printer at each log off, so there is a new network printer connection each time the user logs on and hence we get a new GUID each time. The disconnect feature is a good thing as
we don't have to worry about removing mapped network printers when they are phased out.
But even if we disable the disconnect feature we'll have the same problem, but it's limited to the number of users logging on the terminal servers or Citrix servers for the first time. So if there are 1000 users with a couple of print mappings each
the number of GUIDS will eventually be the number of users multiplied with the number of print mappings pr user on each server.
Since this is created under the HKU\.Default key, all users getting a new profile also get the GUIDS in their user registry that makes the ntuser.dat file grow.
We are able to reproduce this in a lab environment without Citrix or Res Powerfuse by deleting the print mapping and then connect the printer again. The printer drivers have also been tested in several different versions, with and without native print
processor and with and without CSR enabled.
The workaround is to delete the offending keys in HKU\.Default, but this is a very cumbersome procedure and we don't know what effect it has on the users print setup.
So far we have seen the issue with some Sharp drivers, HP Universal Printer v5.0 drivers and Konica Minolta drivers.
On the Sharp driver an equal amount of GUIDs are created under HKEY_USERS\.DEFAULT\Software\Microsoft\Windows NT\CurrentVersion\ICM\ProfileAssociations\Print, but it's only one key with some sub values (key: CSR|printserver,{GUID}).
It seems that this is vendor related, but I'm wondering if anyone else have seen this behavior and found some way to fix it or work around it?
I think it's strange that all the keys that are created does not get cleaned up when a printer connection is deleted...
Regards,
Martin Eilertsen