And driving a car in a safe and sane manner is Driving 101. What’s your point? 

From: J- P 
Sent: Saturday, August 24, 2013 7:06 PM
To: [email protected] 
Subject: RE: [NTSysADM] MSIEXEC CPU on TS-Solved

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 
   
    

<<wlEmoticon-smile[1].png>>

Reply via email to