You're looking at an oversimplified picture of what's happening in reality.
With ProcMon and a registry changes monitor, it's possible to track what goes on during app installation. For example, things like creating the uninstaller reg keys. Without capturing them, then it's not possible to do a clean uninstall or upgrade afterwards.
The primary reason for not using this process is the extra work involved to deal with background noise. Snooping tools can collect a lot of data, and if you're not careful about filtering – it's possible to include too much or too little which is relevant. If your apps are fairly static (they don't get many upgrades), then the investment is acceptable.
There's also testing and validation. How do you know the minimum required changes are correctly captured? Do you want to be spending time maintaining this?
This concept like I've said isn't new. MSMG Toolkit does this (along with abbodi) with .WA add-on's. In a nutshell, they've deconstructed some apps into extracted folders and reg files which can be integrated into an image. Since this isn't an automated process, you have to trust whoever repacked the .WA did a correct job.
Whereas running the normal installer always does what the developer wanted.
I actually agree with you for the point of "background noise" and "testing and validation".
I agree one can monitor with procmon or whatever registry monitor to check what is going, but I think you know not ALL registry changes you captured are related to the installation because Windows is a multitasking system, and registry is constantly changing and modified by multiple process, so I do not think I trust anything using the "capture" method. E.g., you cannot prove the registry is related to 7-Zip without verifying it deeply in detail.
I think we are in agreement with this part.
Btw, as a system administrator with 20+ years of experience, who wrote installation scripts using Inno Setup (the same installer as NTLite uses) and maintain computers for a large corporation (think about >10000 PCs), I do not maintain a single PC for home use (probably unlike most of you). Maintainability is first concern for me. That is the reason I suggest using official installers and performing customizations later.
What I do not fully agree is your statement about "normal" installers does what the developer wanted. Firstly, it is security common sense that we do not download unknown software from unknown sources. Secondly, we can customize the official installers via parameters and transforms in a certain way to satisfy our own needs. Microsoft Orca and Adobe Customization Wizard are two examples of this kind of tools.
Btw, I do not really "trust" other builders, and I build my own Chocolatey packages for the following applications and using it with "Microsoft Deployment Toolkit" to create my own custom image. Just in case anyone is interested.
Code:
7-Zip
AcrobatReader
dotnet6
Firefox
Firefox-ESR
GoogleChrome
IrfanView
IrfanViewPlugins
IrfanViewTW
LibreOffice
LibreOfficeHelp_en-US
LibreOfficeHelp_zh-TW
microsoft-ui-xaml-27
microsoft-ui-xaml-28
microsoft-vclibs-140
microsoft-windows-terminal
Paint.NET
PeaZip
PowerShell
Thunderbird
vcredist
VisualStudioCode
VLC
winget-cli
Take an example. Below is the installation code for automated install of 7-Zip
Code:
$ErrorActionPreference = 'Stop'
# Localize Chocolatey environment variables
$chocolateyPackageVersion = $env:chocolateyPackageVersion
$chocolateyPackageName = $env:chocolateyPackageName
# Define other local variables
$softwareName = '7-Zip'
$fileName = '7z2301-x64.msi'
$fileLocation = '\\desktop\DS-Create$\Applications'
# Define source location
$file = "$fileLocation\$softwareName\$fileName"
# Define install parameters
$installLog = "$env:TEMP\$chocolateyPackageName.$chocolateyPackageVersion.MsiInstall.log"
$silentArgs = "/passive /norestart /l*v `"$installLog`"
# Define Chocolatey parameter hash table
$packageArgs = @{
packageName = $chocolateyPackageName
fileType = 'msi'
file = $file
softwareName = $softwareName
silentArgs = $silentArgs
validExitCodes = @(0, 3010, 1641)
}
Install-ChocolateyInstallPackage @packageArgs
