Agreed, however, in some of my dabbling with python (again just me trying to 
get my feet wet) 
as well as in batch files, isn't that like fundamentals 101, 
#commenting things like this so you can see what its doing
 
Either way, its an unexpected "summer bonus"  for me :)

 

 

 

 

 

 

 

 

 

 

Jean-Paul Natola

 

 
From: [email protected]
To: [email protected]
Subject: Re: [NTSysADM] MSIEXEC CPU on TS-Solved
Date: Sat, 24 Aug 2013 19:00:10 -0500







Something like this is probably overlooked; in the code’s early development 
the coder took a shortcut and just hard-coded the printer name. As the project 
progressed with things being added and changed the memory of using that 
shortcut 
got lost. Since it always worked it never landed on the radar.


 

From: J- P 
Sent: Saturday, August 24, 2013 6:48 PM
To: [email protected] 

Subject: RE: [NTSysADM] MSIEXEC CPU on TS-Solved
 

I'll be the first to acknowledge that my "coding skills" using the 
term very very very loosly-
(took Access 97 and intro to UNIX back in '99 and 
have played with HTML as a hobby)but I cant see why anyone would hardcode 
specific device, as opposed to using "current_ 
default"
 
 
They will be basically paying for 1/2 of my next 
bottle of Louis 
XIII
:)
 
CHEERS!
 
 
 
 
 
 
 
 
 
 
Jean-Paul 
Natola
 

 



Subject: Re: [NTSysADM] MSIEXEC CPU on TS-Solved
From: 
[email protected]
Date: Sun, 25 Aug 2013 18:20:37 -0500
To: 
[email protected]
CC: [email protected]


Good catch!
 
Add this one to the book of "why never to hardcode addresses or names of 
devices not directly under the code's control"

On Aug 24, 2013, at 18:16, "J- P" <[email protected]> 
wrote:



  
  

  Ok, so after looking at thousands of procmon lines , I finally 
  figured out what was causing it-
This is not the normal bug thats been 
  around , but it did relate to an HP printer.

What tipped me off was the 
  spools process not doing anything other than "process profiling" no regquery 
  no create , no file create  and no imagepath , 

So I ran procmon 
  on a desktop and there it was,  Spoolsv.eve doing what it should be , 
  RegOpen, FileSystemControl, Regcreate, 
  etc.....

"HKLM\SOFTWARE\Microsoft\Windows 
  NT\CurrentVersion\Print\Providers\Client Side Rendering Print 
  
Provider\Servers\Print_Server\Printers\{3B2A2A60-72A2-4B70-99F3-1FE3E72FDB85}\PrinterDriverData

HKCU\Printers\Connections\,,Print_Server_Name,Shared_Printer_Name

and 
  heck of alot more entries-


Evidently the genius writing the front 
  end of the DB decided to make some upgrades (without telling anyone), like 
  hardcoding  default printers for various reports, queries etc.. and since 
  said printers did not exist on Box , thats when MSIExec would kickoff and 
  attempt the installation of the HP Printers.

After installing ALL the 
  printers on the box, print previews take about  1 second to load, and no 
  MSIexec.

This will be one costly lesson to the client :) as I spent 
  quite sometime on this.

Thanks to everyone for all the 
  feedback.

And now time for some cognac

Thanks 
  again

 
 
 
 
 
 
 
 
 
 
Jean-Paul 
  Natola
 



  
  
  From: [email protected]
To: [email protected]
Date: 
  Thu, 22 Aug 2013 08:25:47 -0400
Subject: RE: [NTSysADM] MSIEXEC CPU on 
  TS


  

  

  
  Not 
  local to the Citrix server, local to the RDP or Citrix client.
   
  
  
  From: [email protected] 
  [mailto:[email protected]] 
  On Behalf Of Daniel Chenault
Sent: Wednesday, August 21, 2013 
  11:14 PM
To: [email protected]
Subject: 
  Re: [NTSysADM] MSIEXEC CPU on TS
   
  
  
  
  Ahhhh... okay. Major 
  bummer.
  
   
  
  If this is only for 
  local attach printers then the only solution I see until MS issues a patch is 
  for the RDP/Citrix server to not have any local attach 
  printers.
  
  
  
   
  
  
  From: J- P 
  
  
  Sent: 
  Wednesday, August 21, 2013 3:20 PM
  
  To: [email protected] 
  
  
  Subject: RE: 
  [NTSysADM] MSIEXEC CPU on TS
  
   
  
  
  think I may have 
  stumbled onto something,I have afew 1000 of these, however, they are not 
  identical they seem to increment and all result in "NO MORE 
  ENTRIES"

HKU\.DEFAULT\Software\Classes\CLSID\{CAFEEFAC-0014-0002-0027-ABCDEFFEDCBB}\InprocServer32
HKU\.DEFAULT\Software\Classes\CLSID\{CAFEEFAC-0014-0002-0027-ABCDEFFEDCBB}
HKU\.DEFAULT\Software\Classes\CLSID\{CAFEEFAC-0014-0002-0028-ABCDEFFEDCBA}\InprocServer32
HKU\.DEFAULT\Software\Classes\CLSID\{CAFEEFAC-0014-0002-0028-ABCDEFFEDCBA}



 
 
 
 
 
 
 
 
 
 
Jean-Paul 
  Natola
 


  
  
  
  
  From: [email protected]
To: [email protected]
Date: 
  Wed, 21 Aug 2013 13:44:16 -0400
Subject: RE: [NTSysADM] MSIEXEC CPU on 
  TS
  
  That’s 
  not the problem. 
   
  What 
  happens is that whenever a remote user (either citrix or RDP) prints (or logs 
on, I forget), the local 
  printers FOR ALL LOGGED IN USERS get GUIDs assigned that are unique for that 
  user’s session.  The stupid HP print drivers (maybe other too) 
  create  keys under HKU\.Default\Software\Hewlett-Packard  
  corresponding to ALL THESE GUIDS. This rapidly results in thousands of 
  keys.
   
  For 
  some reason, msiexec.exe likes to fully traverse that key OVER and OVER and 
  OVER resulting in msiexec using 100% of one CPU 
  AND msiexec taking forever to get anything done. 
  
   
  
  
  From: [email protected] 
  [mailto:[email protected]] 
  On Behalf Of Daniel Chenault
Sent: Wednesday, August 21, 2013 
  12:53 PM
To: [email protected]
Subject: 
  Re: [NTSysADM] MSIEXEC CPU on TS
   
  
  
  
  Maybe I’m missing 
  something or need more coffee...
  
   
  
  Set up a group of 
  the RDP users. Deny those users access to those printers using the printer 
  properties Security tab.
  
  
  
   
  
  
  From: 
  J- 
  P 
  
  
  Sent: 
  Tuesday, August 20, 2013 4:29 PM
  
  To: 
  [email protected] 
  
  
  Subject: RE: 
  [NTSysADM] MSIEXEC CPU on TS
  
   
  
  
  on the TS box 
  itself-
 
I guess disabling MSIExec wouldn't help 
  either
 
I'm up to 27 new guids in the last 
  hour

 
 
 
 
 
 
 
 
 
 
Jean-Paul 
  Natola
 

 
  
  
  
  
  From: [email protected]
To: [email protected]
Subject: 
  Re: [NTSysADM] MSIEXEC CPU on TS
Date: Tue, 20 Aug 2013 16:21:07 
  -0500
  
  
  
  Is it enumerating 
  printers local to the TS server or the workstation?
  
  
  
   
  
  
  From: 
  J- 
  P 
  
  
  Sent: 
  Tuesday, August 20, 2013 4:13 PM
  
  To: 
  [email protected] 
  
  
  Subject: RE: 
  [NTSysADM] MSIEXEC CPU on TS
  
   
  
  
  I get that, the 
  issue is that when a user logs into TS, the minute they try to print or print 
  preview their first job (its a report from Access ) - MSIExec hits 100% till 
  the keys get enumerated, during that time ,everyone on TS feels it and you 
  know how it is to just watch the hour glass 3-4 minutes seems like an 
eternity 
  to the user waiting for it.
 
 
Can I just disable the 
  server from even attempting to enumerate, the option of upgrading to a 
  new  OS is not really viable at the 
  moment.

 
 
 
 
 
 
Jean-Paul 
  Natola
 

 
  
  
  
  
  From: [email protected]
To: [email protected]
Date: 
  Tue, 20 Aug 2013 17:00:15 -0400
Subject: RE: [NTSysADM] MSIEXEC CPU on 
  TS
  
  Just 
  put the GP in place and relax. You can’t manually get rid of them – they just 
  keep coming back. 
   
  
  
  From: 
  [email protected] 
  [mailto:[email protected]] 
  On Behalf Of J- P
Sent: Tuesday, August 20, 2013 4:56 
  PM
To: [email protected]
Subject: 
  RE: [NTSysADM] MSIEXEC CPU on TS
   
  
  I did a manual 
  delete of the hP key, and sure enough after logging into to the TS when I 
went 
  to do a "pdf preview" it hung for about 4 minutes- and then about 11 new keys 
  showed up 
 
 
I'm open to options , users dont actually 
  need to print over TS, but they do require print preview for the PDF's they 
  email-
 
ROCK> me < HARD PLACE
 
open to all 
  suggestions
 
thanks 
 

 
  
  
  
  
  From: [email protected]
To: [email protected]
Subject: 
  RE: [NTSysADM] MSIEXEC CPU on TS
Date: Tue, 20 Aug 2013 15:54:06 
  -0400
  
  Yes they are in HP 
  gazillion 
 
Can you share your policy, did it delete before  
  or after user logon/off
 
And more importantly did it prevent 
  MSIEXEC from shooting to 100 during a new logon?
 
 
THANKS 
  SO 
  MUCH
 


 
 
 
 
 
 
 
 
 
 
Jean-Paul 
  Natola
 

 
  
  
  
  
  From: [email protected]
To: [email protected]
Date: 
  Tue, 20 Aug 2013 15:49:47 -0400
Subject: RE: [NTSysADM] MSIEXEC CPU on 
  TS
  
  IIRC, 
  my problem is HP printers and they create gazillions of keys under 
  HKU\.Default\Software\HewlettPackard.
   
  I 
  simply created a group policy object that deletes the  whole 
  HKU\.Default\Software\HewlettPackard  key.
   
  
  
  From: 
  [email protected] 
  [mailto:[email protected]] 
  On Behalf Of J- P
Sent: Monday, August 19, 2013 4:21 
  PM
To: [email protected]
Subject: 
  [NTSysADM] MSIEXEC CPU on TS
   
  
  I realize this is 
  has been around for a while, but it seems that there still has not been an 
  actual fix for this, so i am asking if anyone has had any successful 
  work-arounds, besides upgrading the server

http://social.technet.microsoft.com/Forums/windowsserver/en-US/c16e01d6-4b64-4dad-ba8f-479c9fea85c0/high-cpu-usage-in-msiexec-due-to-enumeration-of-print-guids-in-hkudefaultsoftware

I 
  literally have thousands of these guids on the TS

Environment, 2008 32 
  bit TS with Citrix fundamentals 


Any thoughts are appreciated 
  
 
  
                                          

Reply via email to