BitOSDT Features and Docs | Deployment Transparency

1) Prerequisites

Windows host with local administrator rights for the full GUI build, provisioning, and deployment surface.
Windows ADK + WinPE optional components installed (BitOSDT checks for required WinPE packages).
Experimental Linux-hosted media preparation is available for selected workflows when wimlib-imagex, xorriso, and a synced WinPE asset bundle are supplied.
Storage for downloaded OS media and workspace artifacts.
Network connectivity only if you choose cloud source, catalog sync, package managers, or remote runtime hosting.

2) Where BitOSDT Stores Files Locally

BitOSDT uses a user-profile app directory model for app state, plus deployment and runtime paths used during imaging, provisioning, and WinPE sessions.

Path	Purpose
`%USERPROFILE%\.bitosdt\config.json`	App settings and path preferences.
`%USERPROFILE%\.bitosdt\bitosdt.db`	Local metadata database (catalog and image records).
`%USERPROFILE%\.bitosdt\downloads\`	Download cache for source files/catalog content.
`%USERPROFILE%\.bitosdt\workspace\`	Workspace for mounted images, temporary build artifacts, and output preparation.
`C:\BitOSDT\Provisioning`	Provisioning package profiles, generated exports, and packaged support content.
`C:\BitOSDT\WDS`	Dedicated WDS/PXE export root containing `boot.wim`, payload manifests, and setup notes.
`C:\BitOSDT\Installers`	Runtime location for embedded Full ISO custom installer payloads.
`C:\BitOSDT\Apps`	Runtime app payload staging used by provisioning packages and generated deployment flows.
`C:\BitOSDT\Files`	Runtime file-copy payload staging for provisioning packages and deployed machines.
`C:\BitOSDT\Scripts`	Runtime script staging for provisioning package automation and first-logon execution.
`C:\BitOSDT\Tasks`	Task sequence scripts directory in generated task settings model.
`C:\BitOSDT\Logs`	Task/app/update logging destination inside deployed Windows.
`X:\BitOSDT\Scripts\|Config\|Logs\|State`	WinPE runtime scripts, deployment config, status, and logs.

3) Exactly What Runs During Deployment (Execution Order)

Phase	Execution Order
WinPE start (Full ISO)	`startnet.cmd` -> shell launcher -> `Deploy-FullIso.ps1` -> disk prep -> DISM apply -> BCDBoot -> reboot.
WDS/PXE export build	BitOSDT prepares a WDS-friendly export bundle under `C:\BitOSDT\WDS` with `boot.wim`, payload metadata, and operator notes. You must publish the final runtime payload yourself, and the export now records exactly one selected runtime source: SMB/UNC or HTTP.
First boot in Windows	`SetupComplete.cmd` runs and calls `task-runner.ps1`.
Provisioning package execution	Generated `.ppkg` assets can stage files, scripts, Winget, Chocolatey, and custom installers, then apply locale/timezone and first-logon actions based on the selected trigger.
Task execution	Enabled tasks execute in order (apps, updates, custom scripts) with per-task continue-on-error behavior.
Deferred actions	If applicable, deferred scripts register RunOnce entries and execute at first admin logon.

4) Optional / Conditional Actions Matrix

Action	Runs By Default?	Condition
Winget installs	No	Only when winget packages are selected.
Chocolatey installs	No	Only when chocolatey packages are selected.
Custom installers	No	Only when custom installers are selected (payload execution applies to Full ISO).
Deferred network installers	No	Only when network-directory installers are configured.
Provisioning package import/export tools	No	Available from Manage Provisioning Package when Advanced Mode is enabled.
WDS/PXE export	No	Only when the wizard output mode is set to `WDS / PXE` and exactly one final UNC or HTTP runtime path is supplied.
Provisioning BitLocker disable step	No	Only when a provisioning-package profile enables the dedicated BitLocker step before application installs.
RunOnce: `BitOSDTWingetInstallers`	No	Only when winget deferral is needed (e.g., LocalSystem context).
RunOnce: `BitOSDTNetworkInstallers`	No	Only when deferred network installers are configured.
Autopilot profile file	No	Only when Autopilot is enabled in wizard.
Windows Update task	Not always	Only when update categories are enabled.

5) Logs and Troubleshooting Paths

Path	What It Captures
`C:\BitOSDT\Logs\setup-complete.log`	SetupComplete execution log in deployed Windows.
`C:\BitOSDT\Logs\task-runner.log`	Main post-install task sequence log.
`C:\BitOSDT\Logs\app-install.log`	Primary application install task log.
`C:\BitOSDT\Logs\app-install-winget-deferred.log`	Deferred winget install log (RunOnce path).
`C:\BitOSDT\Logs\app-install-network.log`	Deferred network-directory installer log.
`C:\BitOSDT\Logs\windows-update.log`	Windows update task output.
`C:\BitOSDT\Logs\provisioning-ui.log`	Provisioning package UI runtime log for generated onboarding flows.
`C:\BitOSDT\Logs\provisioning-shell.log`	Provisioning package shell/orchestrator log.
`X:\BitOSDT\Logs\startnet.log`	WinPE startnet launcher trace.
`X:\BitOSDT\Logs\deploy.log`	WinPE deployment/bootstrap runtime log.
`X:\BitOSDT\State\deploy-status.json`	WinPE progress/state payload.

6) "No Bloatware" Transparency Statement

BitOSDT does not silently install random software by default. Package installs and custom installer actions are driven by explicit wizard selections.

No hidden app list is preloaded into deployment by default.
Optional actions are conditional and documented above.
Generated scripts and logs are available for inspection.

Implementation note: task settings model references C:\BitOSDT\Tasks, while SetupComplete currently executes generated scripts from Windows\Setup\Scripts in deployed images.

7) Provisioning Package Notes

The provisioning package workflow remains the main experimental surface in 2.0.4. Simple mode stays focused on profile authoring, while Advanced Mode exposes import/export, regeneration, and lifecycle tooling.

Capability	Behavior
Create Provisioning Package	Generates a profile with optional scripts, copied files, Winget packages, Chocolatey packages, custom installers, locale, and timezone settings.
Manage Provisioning Package	Lists saved profiles and supports edit, delete, folder-open, and conditional regeneration flows.
Advanced Mode	Adds ZIP import/export, duplicate, rename, and direct `.ppkg` export actions.
PPKG export	Export regenerates the provisioning sidecar payload from the saved profile, then writes the `.ppkg` beside sibling `Scripts`, `Apps`, and `Files` folders when those assets are required.
BitLocker step	Provisioning-package profiles can add a dedicated BitLocker disable step before application installs, with an optional reboot immediately after `manage-bde -off C:`.

8) Package Manager and Runtime Hosting Notes

Topic	Operator Guidance
Winget	Winget packages install only when selected. If BitOSDT is running in LocalSystem during deployment, it defers those installs to the first admin logon.
Chocolatey	Chocolatey packages install only when selected. BitOSDT can bootstrap Chocolatey if the provisioning or deployment flow is configured to allow it.
Custom installers	Custom installer payloads are explicit operator-selected actions. Review file paths and silent arguments before shipping images or provisioning packages.
Lightweight publish	Simple delivery uses the embedded lightweight host only when you explicitly start it. Advanced PXE/WDS scenarios still require you to host the final runtime payload.
WDS/PXE runtime source	WDS/PXE export requires one final runtime path only. Pick either a UNC path WinPE can reach directly or an HTTP/HTTPS URL BitOSDT can fetch at runtime, not both.
Experimental Linux-hosted prep	Selected build workflows can now prepare media from Linux when the required tools are installed and BitOSDT has access to the synced WinPE asset bundle.
Experimental builds	BitOSDT 2.0.4 experimental builds report their channel in-app and only surface update prompts when a newer downloadable build exists for the same channel.

Deployment Transparency Guide