I have have had a similar case to this in the past and it looks like TrustedInstaller.exe is connected to Windows Automatic Updates. If you have verified that Windows Automatic Updates is configured to never check for updates as is mentioned here Best Practice: Windows Automatic Updates (make sure that the settings look like what is mentioned in the document) then I found a few articles in my research that may help you diagnose what on your system is causing this issue. Please note that the content of these articles is not officially endorsed by Shavlik:
Thanks for the response David,
I believe that we have the Windows Automatic Updates configured properly during our last tests but I will review the link you have provided when time allows. ( I worked w/ you not long ago.)
I'm currently running another large test deployment after pushing the Shavlik Agent to our test system. I hope to have a point of comparison by this afternoon sometime.
In regards to the additional articles you have provided; I believe that I have already reviewed at least a couple of them but I will look them over as well.
To provide some additional details, learned during my last test on Thursday, 10/6/16 (before evacuating due to hurricane Matthew).
- Started: 10/5/2016 12:21:13 PM
- Status Update: 10/6/2016 10:53 AM – 209 of 273 executed.
- Resource utilization on the Console remains green; resource utilization on the test server is RED (CPU +/- 0% on average, Memory @ 4GB GB) 100% Physical Memory Used; 15GB Committed Memory.
- Summary: 209 patches deployed in 23 hours 14 minutes. (1,394 minutes).
- Note: Confirmed, the deployment process is absolutely crawling if progressing any further at all. Our test server’s physical memory (4Gb) is locked @ 100%, the committed memory is @ 15+ GB. The TrustedInstaller process is now showing a status of suspended.
- Summary: It seems that the "Committed" memory is slowly increasing during large deployments until such a point is reached that renders the entire deployment process inoperable. The resulting state finds our test server showing 100% physical & committed memory utilization; the "TrustedInstaller" process ultimately is "suspended" and we are unable to restart or resume the deployment process w/out interrupting the deployment process from the console. Looking forward, we could deploy needed patches in more manageable "blocks" (100 or less at a time) or we can test run a large deployment using the Shavlik Agent and compare the results. It should be noted that vCenter's performance monitoring capabilities did NOT show the actual physical state of our test server once it was locked up.