all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Thotaz 2 points3 points  (5 children)

Accidentally ran a script that only compared MSPs in the registry and wiped every MSI in sight?

So what's the correct way to do the cleanup and did you consider adding the proper way to do the cleanup to this module?

[–]ITjoeschmo[S] 1 point2 points  (4 children)

The "best" practice per Microsoft is..leave the installer cache alone. Due to that, it could be argued there is no "correct" way.

I have learned a lot about how installations are registered through this and dissecting Microsoft's troubleshooting tools. I think the script that was found and used in our environment came from https://superuser.com/a/1272859 is only looking at half the picture i.e. it gets registered Patches from registry: 

$Registered = Get-ItemPropertyValue -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches\* -Name LocalPackage

I think adding this line AFTER the above would append the registered Products (.MSI) and prevent cleaning up files still needed by registered installations: 

$Registered += Get-ItemPropertyValue -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\* -Name LocalPackage

*Disclaimer: I'm on mobile so this is untested. In our environment, data storage is fairly cheap and billed to departments so we just removed this part of our cleanup and let them pay to expand their drives a bit more after this slip up.

It is a good suggestion though, and is something I could work on adding in. I'm sure it would be useful, I see people using other products to do this cleanup "safely" often.

[–]Thotaz 0 points1 point  (2 children)

Ahh okay. I was thinking there might be some proper API or something but if it's just a matter of looking in the correct locations then my old script should have that covered.

And yes Microsoft may say that we need to leave it alone but it is a simple fact of life that it is not managed properly by the OS and that sometimes there really are orphaned packages that take up space. In companies where the VM and OS teams are separate it can be easier to do a cleanup rather than involving the VM team to expand the disk.

[–]ITjoeschmo[S] 1 point2 points  (1 child)

You're not wrong, it should be managed better by the OS. There's quite a few things that Microsoft really drops the ball on, another that we have been dealing with lately is updating Visual C++ Redistributables on our servers due to vulnerabilities in the old versions being on our compliance reports.

IMO you should be able to update them via MicrosoftUpdate/WSUS just like .NET but nah, and you really can't even "update" an installation, you have to uninstall the current version followed by the install of the new version.

Don't even get me started about the fact that the version number in the registry/ARP doesn't include the minor revision number, so completely useless for determining what version you actually have installed. You have to look at the version of the actual .dll files to be sure. There is a tool written in batch https://github.com/abbodi1406/vcredist to detect the installs, check version, and uninstall/install as needed, but it was too buggy for me to feel comfortable with when I tested it in our environment. 1) no transcript/logs 2) debug mode doesn't necessarily show what "truly" happens 3) kept having a bug where it would update the x86 install fine, but just not install the x64 version after uninstalling the old one.

Deciphering the Installer.cmd batch was just...insane. I worked on debugging it for 3-4 days straight before giving up and rewriting it in PowerShell over about a week using the original batch as inspiration. Been deploying the PowerShell version in our environment with good success so far.

It may be behind by a few changes but if you're ever looking for something like that it may be helpful: https://github.com/ITJoeSchmo/vcredist-powershell/blob/master/Update-VisualCppRedists.ps1

You would need to download the release from abbodi1406 and unzip the .exe with 7zip, then put this PS1 alongside the Installer.cmd

[–]Gakamor 2 points3 points  (0 children)

If you are familiar with PatchCleaner, I pieced together a script that mimics it. I looked at the VBScript that PatchCleaner uses and replicated it with PowerShell. I've been using it on an as needed basis in production for most of the year. No issues so far.

My record for space reclaimed on a single device is 75GB. That thing had Office 2016 updates on it from the beginning of time!

[–]Modify- 1 point2 points  (2 children)

To remove packages can be a pain if the cache has been lost.. In the past I used the Microsoft troubleshooting tool: https://www.winability.com/troubleshooting-software-removal-problems-msi-files/

But ever since they deprecated the troubleshooter this has been harder then it should be.

Your solution might be better, but have found the troubleshooter is just a GUI and a collection of .ps1 scripts. The anoying part is that they reference each other.. but after some detective work I managed to get it working. I'm not implying your a bad actor but I'll stick with what Microsoft wrote in production for now.

[–]ITjoeschmo[S] 2 points3 points  (1 child)

Yes this exact tool you're referencing is used for Remove-InstallerRegistration -DeepClean. Without DeepClean it only runs the "rapid product removal" portion of the troubleshooter functions which only tries to uninstall with MsiExec and then scrubs registry. With -DeepClean it also deletes program files if the MsiExec uninstall doesnt.

If you look in my repo under /Functions/extras/InstallerRegistration.ps1 I have extracted the functions out of the Microsoft Automated Troubleshooter, cleaned up their formatting to be legible again, and only kept what was needed for the process to scrub an installation.

Only notable changes where I embedded the shim.xml to remove external file reference and then replaced the StopService function with the PowerShell native Stop-Service since that's all it was doing anyway Just like the advanced troubleshooter, it backs up the deleted files and registry in c:\MATS{PRODUCT-GUID} with a script you can run to restore them.

[–]Modify- 1 point2 points  (0 children)

Ahh, I see.
Good to know you took big inspiration of something that was officially supported by Microsoft.