Observe Windows Installer Changes and Build Reproducible Deployments: MSIX, WinGet, and WiX

2026 maintenance note: This article now covers lawful, safe observation of Windows installer changes and reproducible deployment. The complete 2011 InstallRite text remains at the end for provenance; its download mirrors, localization patch, captured registration data, and self-extracting repackaging claims are not current guidance.

Table of Contents

Set the boundary first: observation is not redistribution permission

InstallRite 2.5c belonged to the Windows 9x/2000/XP era. The old article turned a before/after installation snapshot directly into a package for other machines and captured software registration state with it. That conflates technical observation, licensing, and sensitive data. A Ghost disk image, installer-change observation, and application deployment are three different problems; none substitutes for the others.

Create and distribute a new binary package only when you own the software and assets, its open-source license clearly permits it, or the publisher has given written authorization. Buying one copy, being able to install it on one machine, or being able to observe its changes does not automatically grant repackaging, fleet-deployment, or public-distribution rights. This guide is not legal advice; have licensing/legal owners review commercial software and cross-organization distribution.

Never capture or redistribute license keys, activation state, session tokens, browser/application profiles, user documents, passwords, certificate private keys, device/domain identity, machine SIDs, telemetry identifiers, paid components, or anyone else's data. If installation requires login or online activation, use the publisher's enterprise deployment route or a test tenant and treat conversion as potentially unsuitable.

Goal	Recommended route	Rights boundary
Install existing software	Publisher-signed installer, Microsoft Store, or a trusted package manager	Follow the original license; do not rebundle the binary
Automate a publisher installer	Use publisher-documented silent options; use only standard MSI options for MSI	Manifests/scripts must not embed keys or bypass activation
Make an existing installer discoverable in WinGet	Maintain a manifest pointing to the publisher's stable URL and SHA-256	A manifest normally does not carry the installer or create distribution rights
Convert to MSIX	Use MSIX Packaging Tool in a clean VM when authorized and compatible	The converted payload remains subject to the original license
Build MSI/EXE/MSIX for your own app	Build from source with WiX, MSIX/Windows SDK, or the project build system	Preserve dependency licenses, source, and build provenance

1. Record intake and provenance first

Before executing anything, record product name, publisher, exact version, architecture, installation scope (user/machine), original HTTPS download page and version-fixed URL, acquisition time, license/EULA, supported Windows versions, dependencies, upgrade/uninstall behavior, and the publisher's deployment documentation. Do not begin with an old mirror, forum attachment, unofficial localization patch, or mutable latest URL.

Verify the publisher signature and SHA-256 first. The following PowerShell only reads a named file in the isolated environment; replace the placeholder path with the installer obtained from the publisher:

$InstallerPath = 'C:/Staging/PublisherSetup.exe'
Get-FileHash -LiteralPath $InstallerPath -Algorithm SHA256
Get-AuthenticodeSignature -LiteralPath $InstallerPath |
    Select-Object Status, StatusMessage,
        @{Name='SignerSubject';Expression={$_.SignerCertificate.Subject}},
        @{Name='SignerThumbprint';Expression={$_.SignerCertificate.Thumbprint}}

Status = Valid is not sufficient by itself: the signer must be the expected publisher and the version must match its release notes. Stop if the file is unsigned, the signature is invalid, the hash differs from the publisher's value, a download redirects to an unknown domain, or antimalware reports it. Do not disable protection just to keep packaging.

If WinGet may already know the product, inspect its metadata before installing. Replace the placeholder with a verified exact ID:

winget show --id 'Publisher.Product' --exact --source winget

2. Use a clean, disposable, reversible environment

For a formal capture, prefer a clean Hyper-V/enterprise VM matching the target Windows release, patch level, architecture, and language, and create a named snapshot before installation. Do not join the VM to a production domain, sync a personal account, mount user profiles, or place signing keys in it. Restart every version from the same known baseline; do not capture several applications in sequence on a personal PC that merely “looks clean.”

Windows Sandbox is useful for quick observation because closing it discards its contents, but it is not a persistent snapshot or a complete target environment. Networking is enabled by default, and Microsoft warns that this can expose an untrusted application to the internal network. For a self-contained installer, a .wsb file can disable networking, vGPU, and clipboard redirection and map only a secret-free staging directory read-only:

<Configuration>
  <VGpu>Disable</VGpu>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:/Packaging/Staging</HostFolder>
      <SandboxFolder>C:/Staging</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
</Configuration>

A mapped folder still expands host exposure; put only an installer copy there. Sandbox evidence also disappears on close, so use a snapshot-capable VM for complete diffs, reboots, and upgrade tests. If installation requires networking, identify publisher domains and data flows first and use an isolated network/controlled proxy. Do not capture authentication traffic or connect to production for convenience. See Microsoft's Sandbox configuration documentation.

3. Create a minimal, comparable baseline

After the VM snapshot, create a private evidence directory and record the environment. This intentionally avoids exporting a whole user profile or registry:

$EvidenceRoot = 'C:/Observation'
New-Item -ItemType Directory -Path $EvidenceRoot -Force | Out-Null

Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture |
    ConvertTo-Json |
    Set-Content -LiteralPath "$EvidenceRoot/before-system.json" -Encoding UTF8

Get-Service |
    Sort-Object Name |
    Select-Object Name, StartType, Status |
    Export-Csv -LiteralPath "$EvidenceRoot/before-services.csv" -NoTypeInformation

Get-ScheduledTask |
    Sort-Object TaskPath, TaskName |
    Select-Object TaskPath, TaskName, State |
    Export-Csv -LiteralPath "$EvidenceRoot/before-tasks.csv" -NoTypeInformation

Get-CimInstance Win32_SystemDriver |
    Sort-Object Name |
    Select-Object Name, PathName, StartMode, State |
    Export-Csv -LiteralPath "$EvidenceRoot/before-drivers.csv" -NoTypeInformation

Those CSV files can still contain machine paths or product details; retain them in a controlled evidence store. For file and registry activity, Microsoft Sysinternals Process Monitor can be filtered to the installer process tree and expected publisher/product locations. Record the Procmon version, filters, and capture window. Raw PML/CSV can contain command lines, paths, URLs, or tokens and must never be dropped into a deployment package or public ticket.

4. Run one installation and observe—do not personalize it

Pause unrelated automatic updates and background software inside the VM and run exactly one installer. Record the installer UI and every choice, but do not enter a license key, personal account, or real customer data. Do not open browsers, mail, sync clients, or unrelated applications whose changes would contaminate the diff.

For an MSI, Windows Installer's standard logging option can support an interactive observation:

msiexec.exe /i "C:/Staging/Product.msi" /L*v "C:/Observation/install.log"

Logs may include properties, paths, or publisher-provided sensitive values; inspect and sanitize them before storage or sharing. EXE switches have no universal standard. Use only parameters explicitly documented by that publisher; do not guess /S, /silent, or an answer file.

Only when the file is genuinely an MSI, the publisher permits automated deployment, and no license property must be injected should you validate standard quiet mode from a fresh baseline:

$Process = Start-Process -FilePath 'msiexec.exe' -ArgumentList @(
    '/i', 'C:/Staging/Product.msi',
    '/qn', '/norestart',
    '/L*v', 'C:/Observation/install-silent.log'
) -Wait -PassThru
$Process.ExitCode

Stop the capture on a nonzero exit, unexpected restart, still-running child installer, download of an unknown payload, or demand for real activation. “It launches in this VM” is not evidence that redistribution, silent deployment, or every Windows release is supported.

5. Compare meaningful system changes

After installation but before user personalization, collect the same sorted evidence again:

Get-Service |
    Sort-Object Name |
    Select-Object Name, StartType, Status |
    Export-Csv -LiteralPath "$EvidenceRoot/after-services.csv" -NoTypeInformation

Get-ScheduledTask |
    Sort-Object TaskPath, TaskName |
    Select-Object TaskPath, TaskName, State |
    Export-Csv -LiteralPath "$EvidenceRoot/after-tasks.csv" -NoTypeInformation

Get-CimInstance Win32_SystemDriver |
    Sort-Object Name |
    Select-Object Name, PathName, StartMode, State |
    Export-Csv -LiteralPath "$EvidenceRoot/after-drivers.csv" -NoTypeInformation

Together with filtered events, inspect added/changed program files, DLLs, registry keys, services, drivers, scheduled tasks, Start/Desktop shortcuts, file associations, protocol handlers, COM registration, environment variables, firewall rules, certificates, and uninstall entries. Exclude Windows Update, antimalware, log rotation, and other baseline noise instead of packaging every difference.

Registry snapshots are especially likely to include MRUs, usernames, network paths, application tokens, and machine identity. Retain only confirmed publisher/product keys. Never export all of HKCU, SAM, SECURITY, browser credentials, DPAPI material, or user profiles. If a change cannot be explained, revert the VM, narrow the filters, and observe again.

6. Choose the deployment artifact for the actual goal

Route A: keep the publisher installer and write a WinGet manifest

This is usually the lowest-risk automation. The manifest points to a version-fixed HTTPS publisher installer and records ID, version, architecture, installer type, scope, silent options, and SHA-256. Microsoft's WinGet manifest specification requires InstallerUrl and InstallerSha256; the client compares the downloaded hash.

winget hash "C:/Staging/PublisherSetup.exe"

A matching hash establishes byte consistency, not safety, legality, or publisher identity. Use version-fixed URLs, follow the WinGet community repository policy, and validate with the current schema/tool before submission. Restrict access to private enterprise manifests as well; never place access tokens, signed temporary URLs, or license keys in YAML.

Route B: convert an authorized legacy installer with MSIX Packaging Tool

Microsoft's MSIX Packaging Tool workflow says to understand the installer first and supports a clean local machine, Hyper-V VM, or prepared remote machine. Begin each run from a clean snapshot, review captured files/registry, entry points, and the Services report, and remove clear baseline noise. Do not add secrets or unobserved user state.

MSIX conversion is not a lossless answer for every app. Microsoft's packaging decision guidance and known issues state that MSIX does not install drivers; services have target-version and account/dependency limits; kernel drivers, SYSTEM services, machine-wide COM, shell extensions, or complex self-updaters may require a traditional installer, external-location package, or publisher redesign. Do not force conversion for these components.

Route C: build from source you are authorized to maintain

For owned/authorized source, put the deployment definition under version control. WiX Toolset generates MSI, MSP, and bootstrappers from reviewable source. Components, upgrade codes, dependencies, conditions, uninstall, and rollback should be expressed by the build definition, not guessed from a used machine.

The open-source MSIX SDK can validate, pack, or unpack MSIX in an owned build pipeline; it does not obtain permission from a third-party installed state. Build only authorized content, pin tool versions, and make the result reproducible from source plus dependency lock files.

7. Provenance, SBOM, and signing

For every artifact, retain product/package ID, version, architecture, minimum target Windows version, original publisher URL, original installer SHA-256 and signer, license basis, build-repository commit, build tool/VM image versions, dependency locks, build time, capture filters, source of silent arguments, upgrade/uninstall semantics, and test results. Provenance must omit machine SIDs, usernames, and secrets.

Owned builds can carry an SPDX/CycloneDX SBOM. Microsoft's open-source SBOM Tool can generate SPDX, but automated detection still requires human review. An SBOM describes components; it does not grant redistribution rights or replace vulnerability and license review.

Microsoft requires deployable MSIX packages to have a valid signature trusted on the target device; see the MSIX signing guide. Self-signed development certificates are only for controlled testing. Use an organization-approved signing service/certificate and timestamp for production. Keep private keys in hardware/managed key storage, never in a capture VM, source repository, PFX command line, log, or output directory. Complete SBOM/content review before signing, then verify hash and signature again.

8. Test the complete lifecycle from clean state

Test	Required evidence
Clean install	Standard-user/admin scope, architecture, dependencies, exit code, reboot behavior, signature
Silent install	Documented options only; no UI, hung child process, or unsanitized log
Upgrade	Upgrade from every supported prior version; retain allowed user data, not secret snapshots
Uninstall	Files, registry, services, tasks, shortcuts, and firewall items clean up as designed
Repair/rollback	Interruption, low disk, denied elevation, and cancellation return to a defined state
Environment matrix	Supported Windows builds, x64/Arm64, languages, online/offline, domain policy
Application behavior	First launch, associations, protocols, updates, lock/reboot, and core workflows

Restore the named snapshot for every test; do not continue on residue from the previous test. Use only authorized test seats for paid software. Compare before/after evidence and inspect Defender/SmartScreen, event, and installer logs. Do not disable security products to make a test pass.

Deploy to an isolated test group, then expand in rings. Retain the original signed installer, prior deployment definition, uninstall/recovery path, and compatibility decision. If uninstall is incomplete, upgrade damages data, the signature is untrusted, or unexplained account/machine state appears, stop the release, roll back to the prior version, and rebuild from a clean snapshot.

When capture conversion is the wrong tool

Capture is usually unsuitable for kernel drivers, boot-time components, complex SYSTEM services, external service dependencies, machine-wide COM/shell integration, self-protection/anti-cheat, hardware binding, paid activation, user-profile migration, tightly coupled self-updaters, or dynamically downloaded payloads that cannot be fixed. Use the publisher's installer and enterprise documentation or ask for an MSI/MSIX/offline layout; for owned software, correct the installation design at source.

“The diff looks complete” and “the self-extracting package runs” are not correctness evidence. A maintainable deployment needs explicit rights, fixed inputs, a reviewable definition, trusted signing, complete lifecycle tests, and an executable rollback.

Official and project sources

Historical source archive (do not execute)

This is the complete visible body of the 2011 source export, with trailing whitespace normalized only. Seven unique dead/insecure HTTP targets were narrowly replaced: five image URLs with [REDACTED: dead insecure image URL], the InstallRite mirror with [REDACTED: dead insecure InstallRite download URL], and the localization-patch mirror with [REDACTED: dead insecure localization-patch URL]. Every occurrence of each URL was replaced; no other body text was rewritten. The archive includes an obsolete example of capturing registration state and repackaging paid software and is historical evidence only.

InstallRite：Ghost做不到的我来做

如果要备份系统，大多数人第一个想到的就是Ghost，可是Ghost仅仅能够备份某个分区，如果只要备份某个软件，我们又该怎么办呢？

很多软件在安装时除了在安装文件夹内拷入相关的程序文件外，还会在Windows的安装文件夹或Windows＼System系统文件装入一些.dll的链接库，有的还会在注册表或其地文件夹内写入信息，这样当你只是拷贝软件安装文件夹的方法来备份某个软件是没有用的，但是如果你使用InstallRite来备份软件那么就不存在这些问题了。

Table of Contents

Toggle

- [初识InstallRite](https://blog.lazying.art/en/html/computer_internet/software/443/installrite%ef%bc%9aghost%e5%81%9a%e4%b8%8d%e5%88%b0%e7%9a%84%e6%88%91%e6%9d%a5%e5%81%9a.html/#%E5%88%9D%E8%AF%86InstallRite)
- [InstallRite制作范例](https://blog.lazying.art/en/html/computer_internet/software/443/installrite%ef%bc%9aghost%e5%81%9a%e4%b8%8d%e5%88%b0%e7%9a%84%e6%88%91%e6%9d%a5%e5%81%9a.html/#InstallRite%E5%88%B6%E4%BD%9C%E8%8C%83%E4%BE%8B)

## 初识InstallRite

![]([REDACTED: dead insecure image URL])

InstallRite小档案

软件版本：2.5c 软件大小：4993KB

软件性质：免费软件 适用平台：Windows 9x/2000/XP

下载地址：[[REDACTED: dead insecure InstallRite download URL]]([REDACTED: dead insecure InstallRite download URL])

汉化补丁：[[REDACTED: dead insecure localization-patch URL]]([REDACTED: dead insecure localization-patch URL])
 软件安装之后，每当要安装新的应用程序时，通过它的安装监视功能，就可以将所有软件的安装资料储存起来，这些信息包括系统设置、使用者设置、软件的默认值及软件的注册信息等等。然后软件将所生成的安装映像文件用可执行文件的方式存储，你可以将这个映像文件储存在本地硬盘、光盘或者是服务器上，以后在本机或其他电脑上直接运行镜像文件就可以完成相应软件的安装、设置、注册等操作。怎么样，听完介绍是不是很想试试它呢？

## InstallRite制作范例

为了更好地说明InstallRite的使用和功能，下面我们以IT写作者最常用的抓图工具“SnagIt 6.2.0汉化版”的安装为例来说明。

第一步：

运行InstallRite，在主界面中选择“安装新的软件并且创建一个安装包”，在弹出的“配置在执行安装时如何进行‘监视’”窗口中点击“配置”按钮，然后在弹出的窗口中设置监视的磁盘、注册表、扩展名等，高级用户可以根据需要修改这些设置以捕获更多附加的信息,对于大多数用户来说，使用默认设置即可。

第二步：

单击“下一步”，InstallRite提示我们要跟踪一个软件的安装进程，必须在跟踪之前创建一个系统的快照。InstallRite的系统快照包含当前系统所处状态的信息，并且在随后的安装向导处理过程中根据快照来找到安装程序造成的所有改变，所以我们必须要为系统做一个快照。

单击“下一步”，InstallRite会自动建立快照。

第三步：

在建立完快照后弹出的窗口中，InstallRite就会要求提供安装软件的程序文件名称，在“要运行的安装程序”项下的文本框中直接填入路径及文件名，或点击其后面的按钮进行选择，设置完成后点击“下一步”。

![]([REDACTED: dead insecure image URL])

第四步：

这时InstallRite开始自动打开“SnagIt 6.2.0”的安装程序进行安装，如同平时我们单独安装“SnagIt 6.2.0″一样安装完英文版程序。

由于我们还没有安装“SnagIt 6.2.0汉化程序”及软件的注册和设置，所以在返回的InstallRite安装向导窗口中点击“请稍候….我仍未完成”并在弹出的选项中选择等待的时间，这时InstallRite会在任务托盘中静候我们的调遣。

![]([REDACTED: dead insecure image URL])

第五步：

关闭正在运行的SnagIt 6.2.0，运行汉化程序后打开SnagIt 6.2.0，进行软件注册及抓取图像的相关设置，设置完成后退出。

第六步：

点击任务栏中InstallRite的图标返回向导窗口，这时InstallRite会重新扫描系统磁盘、注册表等相关设置选项。

扫描结束后弹出“你要安装的软件的名称？”的对话框让我们输入创建安装包的名称，点击“确定”按钮。

第七步：

在“安装完成”窗口中单击“构建安装包”，选择安装包存放的路径，添入文件名，点击“保存”，然后在“选项”窗口中选择安装选项，如果你制作的安装包需要重新启动系统的话也可以在这里设定。

确定后，InstallRite一会儿就可生成包含软件运行程序、设置参数、注册信息等等数据的全新的“SnagIt 6.2.0汉化版”安装程序包。

以后再需要安装“SnagIt 6.2.0汉化版”时，只需运行安装包立刻就能把SnagIt 6.2.0安装、汉化、注册、设置完成。

![]([REDACTED: dead insecure image URL])

用InstallRite生成的安装包要较软件的程序大一些，至于大多少可能因软件的不同而不同；

在制作安装包时，除了必要的运行程序外，最好不要运行其他的应用程序，防止在安装包中增加无用的文件及信息。

![]([REDACTED: dead insecure image URL])

InstallRite的特色除了前面提到的外，还有另外一点，就是用它制作的安装包，在安装时，速度明显要比直接安装快得多。但软件也有一个不好的地方，就是你无法改变软件的安装目录等设置，一切都是以前设置好的，多少有一些不方便。