12

While running multiple Windows Server 2008 R2 RDSH farms we are experiencing an issue where the RDSH servers all are having their Registry bloated to the maximum value 2048MB. Using Sysinternals Registry Usage (ru.exe) we were able to determine over 1000MB of the registry being used up by Samsung Universal Printer related keys.

  • Samsung Universal Print Driver: Version 2.3.90
  • Samsung Universal Print Driver 2: Version 2.50.2.0

Registry Sections where the bloat is occurring:

HKEY_USERS\.DEFAULT\Software\SSPrint\
  spe__\
  spd__\
  ssp6m\
HKEY_USERS\S-1-5-8\Software\SSPrint\
  spe__\
  spd__\
  ssp6m\

Each of those subkeys has over 500+ keys where Registry Usage is reporting they are taking up 30-40MB each.

Example subkey: HKU\.default\software\ssprint\spe__\{BCC489E0-E2CA-442B-A5A5-9B849579BE1F}

Looking into the data of the keys "Capabilities", "MUIData", etc. You can definitely tell they are Samsung Universal as the values reference Samsung Universal when you view them.

Taking one of the servers out of the mix I tried cleaning up these keys and was able to. Cleaning the ".Default" section also cleaned the "S-1-5-18" keys, so I'm thinking these are a reference link within the Registry. When I did it I cleared the HKU\.default\Printers\DevModes2 as well since this section would not even open in Regedit. In order to remove I had to CLI the to remove the "DevModes2" key and then recreate the key in Regedit.

As soon as I login with an account that has a printer deployed to them with the Samsung Universal Print Driver these keys start appearing and bloat out the registry. Because the registry is so filled up we have been experiencing User Profile issues causing Temporary Profiles to load. When we disabled the ability to have a Temporary Profile the users then may run into a "The User Profile Service service failed the logon. User Profile cannot be loaded." message.

Has anybody out there experienced this issue?

Is there some setting in the Samsung Universal Print Driver to prevent this behavior or to have it clean up after itself?

user353gre3
  • 103
  • 4
Arachnid
  • 193
  • 2
  • 10
  • I feel your pain. HP Universal Drivers weren't much better some years ago, where the spooler would crash with _thousands_ of HP processes running. I'll be watching this question for sure. – pauska Oct 04 '13 at 19:49
  • Samsung support created a case today when I called in. Hopefully, they will have an answer soon. – Arachnid Oct 04 '13 at 20:59
  • After some research found the DevModes2 key issue was related to http://support.microsoft.com/kb/2871131 and we did have the hotfix installed. However, the hotfix doesn't clean up the mess it apparently just keeps it from growing. When it comes to the Samsung SSPrint they are back growing after cleaning up. In order to get the registry down below the 2048MB we had to perform some registry hive cleanup (http://support.microsoft.com/kb/2498915). Now we're just monitoring and preparing to put servers in drain mode until we have a solution with the Samsung drivers. – Arachnid Oct 08 '13 at 12:42
  • @Archanid Interesting! How are you monitoring the situation? – pauska Oct 08 '13 at 14:34
  • Pauska, we have a repeating powershell script setup monitoring the number of users and the logon state (Allow new Logons; Allow reconnections...) that we added the PowerShell commands to lookup the Registry Size and add that to our status tables. Get-WmiObject -Class Win32_Registry -ComputerName {COMPUTERNAME} Now we can have our monitoring page show the number of users, logons status & registry size. – Arachnid Oct 08 '13 at 17:13
  • Interesting! I'll look into this for our own usage, as we're quite RDS heavy our selves. After you found a solution to this I had to check the default user hive on our servers, and it looks like we are safe - abeit HP UPD drivers storing quite a number of keys. – pauska Oct 08 '13 at 19:05
  • BTW - you should post your third comment here as an answer instead, and then accept it as your preffered one. – pauska Oct 08 '13 at 19:06
  • Pauska, well I'm actually waiting for a solution to the driver issue. I love workarounds, but I really want to get a fix from Samsung for their Universal Driver. So I'll keep this open. So far I've left multiple messages for my case # with Samsung and they haven't even called me back. – Arachnid Oct 31 '13 at 15:54
  • 1
    NOTE for anybody else out there using Samsung Universal Print drivers and Windows Server 2008 R2 for Remote Desktop Session Hosting (RDSH). You will also experience registry bloat on individual user profiles. If you are using Roaming User Profiles you may experience issues where the registry will bloat to the point that a Registry HIVE load and Export is necessary with Group Policies defined to Delete SSPrint related keys. HKCU\Software\SSPrint\spe__ HKCU\Software\SSPrint\spd__ HKCU\Software\SSPrint\ssp6m The keys above refer to specific Samsung Print Processors used by the drivers. – Arachnid Feb 11 '14 at 19:37
  • I think I just ran into a similar problem - `HKU\.DEFAULT\Software\SSPrint\sst3c` had 24194 keys and 48168 values totalling 923,435,598 bytes - incredible! Only 2 keys and 2 values (628 bytes) appear to be necessary. – Neil Mar 24 '14 at 12:02
  • What reason do you have to *not* use a different universal print driver? – MDMoore313 May 02 '14 at 17:52
  • Per a discussion in the comments on Wes Sayeed's answer - has anyone tried installing the drivers in TS installation mode? http://support.microsoft.com/kb/320185 – Thomas May 30 '14 at 05:32

2 Answers2

1

HP has this exact same problem. The issue is that the driver is not very smart when it comes to multiple users connected to the same printer mapping at the same time and it keeps trying to reinstall itself for each user. We never figured out exactly how to fix this, but we came up with two workarounds:

Solution A (easy fix but is a total hack)
Set the Windows Installer service to disabled. Stops the problem dead in its tracks. The downside is obvious though. As soon as you need to do an install or run updates, you must turn the service back on and the registry will immediately begin swelling again.

Solution B (ugly fix but is stable and supported)
Enforce the Remote Desktop EasyPrint driver via Group Policy. This makes print jobs render on the clients instead of the server. The downside here is that you will then need to manually remove every user's printer connection from every printer on every server in the farm, and then delete the drivers. I hope you're good with scripting!

Wes Sayeed
  • 1,862
  • 6
  • 27
  • 41
  • Have you tried installing the driver in terminal services installer mode? At the command prompt, type `change user /install` and then install the drivers. Then type `change user /execute` to return to regular user mode. http://support.microsoft.com/kb/320185 I'd really like to know if that works. – Thomas May 29 '14 at 16:06
  • The drivers don't get installed that way. They get pushed by the print server when a user connects to a particular printer so there is no changing the execution mode. Even aside from that, HP's driver is still wonky even on workstations. If you look at your registry, under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations, there's almost always something there from HP. Just FYI, that key is used by installers to delete/modify system files on the next reboot. HP's driver is always trying to do something. I just wish I knew what it was. – Wes Sayeed May 29 '14 at 20:47
  • I see, you're using a print server. The OP is using RDS, so setting installation mode might make a difference in his case. – Thomas May 30 '14 at 05:29
  • From my experience, the Remote Desktop EasyPrint is not much of a solution for anybody using a non-Windows RDP Client such as a WYSE OS Thin Client. Because of this limitation we have actually completely stayed away from Remote Desktop EasyPrint as it just will not work in our environment We deploy the printers via Group Policy Printer Connections (User Configuration Level) {Deployed Printers in Print Management}. Some research was done to change this to use Group Policy preferences but the targeting/testing of users for each site has not been completed. – Arachnid Jun 10 '14 at 13:35
1

I had the exact same issue and can confirm it is fixed in the new version of Samsung Universal Print Driver 2 (2.50.5) . I was also running 2.50.2 and the key in question was using 275MB. Simply uninstalling the old version and installing the new version on the server (I did not update any client drivers) reduced the size of the key to 3MB. I also tried logging on and back off and can confirm it now deletes the keys when you log off, unlike before.

If you're curious, before it would not delete the keys. In a single user environment this isn't a problem but since the printers are named for the user and the session, it is an exponential problem (for a 20 user server like mine you generate up to 400 keys... and that's if you only have 1 printer per client)

edit: the new key is called usp01 instead of spe__

Jared Epp
  • 26
  • 1
  • JaredEpp, glad to hear Samsung managed to fix their issue. Perhaps, sad for Samsung we made a company-wide decision to not purchase Samsung printers due to this issue and have not purchased any since. I ended up making a number of Group Policy Preferences Registry Cleaners and some handy PowerShell scripts for loading Roaming User Registry Hives which then would clean and compress the users NTUSER.DAT files. – Arachnid Jun 03 '15 at 12:57