tiny11builder 25H2 Update: Debloated Windows 11 ISOs with Copilot/Outlook Removal

The tiny11builder project has received a significant refresh: the PowerShell-based builder now supports Windows 11 version 25H2 builds, adds explicit removal of Copilot and the new Outlook for Windows client, switches to more efficient recovery compression for smaller ISOs, and introduces additional safeguards to block unwanted apps from reinstalling — all while preserving its core approach of using only Microsoft tooling (DISM, the Windows ADK oscdimg, and an unattended answer file) to produce debloated Windows 11 images.

Background​

tiny11 and tiny11builder grew from a simple, community-driven idea: give users a way to run a slimmer, faster Windows 11 by removing inbox apps, redundant services, and optional components many people never use. The project is maintained as an open-source PowerShell script that automates image servicing and rebuilds official Microsoft ISOs into lightweight installation media.
The builder is intended to be used with official Microsoft images. It leverages Microsoft utilities — primarily DISM for image manipulation and oscdimg.exe from the Windows ADK for creating bootable ISOs — and uses an autounattend file to allow setup-time customizations such as bypassing the Microsoft Account requirement in OOBE. The project's maintainers emphasize transparency: the scripts are readable, modifiable, and explicitly avoid including non-Microsoft binaries (beyond the ADK’s oscdimg when needed).
A second, more extreme variant — tiny11 Core — exists for users who want the barest bootable environment. Core sacrifices serviceability (WinSxS and many servicing paths are removed) to deliver minimal images suited for rapid testing and tightly constrained VMs, but it is not intended for daily, fully updated systems.

---

What’s new in the update​

This refresh to tiny11builder introduces several practical and structural changes that matter to anyone building or running custom Windows 11 ISOs.

25H2 compatibility and flexible image support​

• The builder can now be used with Windows 11 25H2 images as well as other recent builds and editions.
• The script’s PowerShell rewrite unlocks support for any Windows 11 release, any language, and both major architectures (x64/arm64) — a big step beyond earlier versions that were tied to specific builds or locales.
• The builder accepts both WIM and ESD source images, giving users more options for input media.

This flexibility makes it practical to build a debloated 25H2 ISO that still benefits from the platform changes Microsoft rolled into 24H2/25H2 while keeping a smaller footprint.

Copilot and new Outlook removal​

• The updated script includes explicit removal routines for Copilot and the new Outlook for Windows client.
• These removals aim to keep the base image free of AI assistant and modern mail client components for users who don’t want those integrated features, or who prefer third-party alternatives.

While removing these components reduces on-disk size and attack surface for some users, it also alters the default user experience and could disable features that integrate with Copilot/Outlook.

Smaller ISOs via recovery compression​

• The builder now uses DISM’s /Compress:recovery option (referred to as recovery compression) during image deployment, which yields significantly smaller final ISOs than previous compression strategies.
• This change helps fit full installations into much smaller media footprints — the project has public examples showing tiny images that can fit on a single-layer 4.7 GB DVD under particular configurations.

The compression change trades a small amount of CPU time at imaging for meaningful savings in distribution size.

Proactive blocking of reinstallation and small QoL fixes​

• The update adds more aggressive measures to prevent the reinstallation of certain inbox apps that Windows Update or the Microsoft Store may try to restore.
• The script includes a handful of quality-of-life fixes and known-issue mitigations (for example, handling remnants in Settings when Edge is removed, and ARM-specific quirks around OneDriveSetup.exe).
• The project also continues to offer tiny11 Core tooling for users who need an even lighter, non-serviceable image.

---

How tiny11builder works — technical overview​

The builder follows a consistent, scripted sequence using Microsoft-supported tools and standard image-servicing flows.

• Prepare: Download an official Windows 11 ISO (or obtain a UUP/ESD image) from Microsoft. Ensure the Windows ADK is available for oscdimg.exe if you plan to make bootable ISOs.
• Mount/Extract: The script mounts the source ISO and extracts the chosen image edition (WIM or ESD).
• Service offline: Using DISM, the script applies package removal, optional component removal, feature toggles, language adjustments, and registry tweaks. Common targets include inbox apps (Clipchamp, News, Weather, Xbox components, OneDrive, Media Player, etc.), language/voice packs, and telemetry services.
• Unattend: An autounattend.xml is injected so OOBE can be customized — e.g., bypassing the Microsoft Account requirement and enabling the compact deployment flag.
• Repack & compress: The image is rebuilt using DISM with /Compress:recovery to get a smaller payload.
• ISO creation: oscdimg.exe (from the ADK) generates a bootable ISO that can be written to a USB stick or burned to media.
• Optional Core path: If the tiny11 Core option is chosen, the script strips WinSxS and other servicing components to create the minimal, non-serviceable image.

Key operational notes:

• The project runs as a PowerShell script and requires execution policy adjustments (Set-ExecutionPolicy Unrestricted) or running PowerShell elevated.
• For reliability, the script should be executed from an elevated PowerShell session; running with specific invocation flags (e.g., powershell -f path\to\script.ps1) has proven necessary in some environments.
• The approach intentionally avoids third-party executables for image servicing, favoring Microsoft-supplied tooling for transparency and stability.

---

Benefits — why enthusiasts and administrators care​

• Reduced bloat: The primary benefit is a smaller, cleaner OS that lacks many inbox apps and services that many users never use.
• Smaller install media: Recovery compression and component removal can cut the final ISO dramatically, which is handy for constrained environments or archival purposes.
• Privacy and surface-area reduction: By removing telemetry-adjacent components and optional services, the image reduces potential telemetry vectors and attack surfaces.
• Customizable OOBE: The included autounattend allows local-account first-boot setups and other customizations that enterprises or privacy-focused users often want.
• Open and auditable: The script-based, open-source approach lets users inspect every change before running it — a critical trust advantage over pre-built, third-party ISOs.
• Flexible image support: Support for ESD and any Windows 11 release makes the tool practical for building images for the latest 25H2 Insider/preview or retail releases.

---

Risks, limitations, and real-world caveats​

Using a debloater and custom image builder like tiny11builder delivers power — but it also carries tangible risks. These are the major concerns users and admins must weigh.

Serviceability and updates​

• The tiny11 Core image is explicitly non-serviceable: removing WinSxS and other servicing components breaks the normal patching and feature-installation pathways. That means you cannot easily add languages, features, or cumulative updates after install.
• Even the regular tiny11 variant can see reinstallation of some apps after major Windows updates or Store repairs. The project adds mitigations, but Windows Update behavior can change and may restore components.
• Removing key components can complicate future upgrades. Major Windows feature updates and servicing stacks expect certain components to exist; heavy customization increases the chance of upgrade failures or odd compatibility problems.

Security and stability​

• Stripping components and services can inadvertently remove capabilities relied upon by security features or applications. For example, removing certain platform features could impact anti-malware tooling or Windows Update behavior.
• Users have reported a range of issues when experimenting with preview releases of Windows on heavily customized images — including boot loops on specific hardware in some cases. Those reports suggest an increased chance of hardware-specific regressions after mixing preview builds with aggressive removal scripts.
• The more extreme the removal (Core mode), the higher the likelihood of breakage.

Compatibility and functionality loss​

• Removing Copilot and Outlook eliminates functionality integrated into the OS experience and may break workflows dependent on those integrations.
• Some inbox features (e.g., Web Search integration, certain UWP app contracts) assume the presence of specific components. Removing them could cause errors in Settings, search, or other system areas.
• ARM-specific quirks (missing OneDriveSetup.exe in certain images) still surface for arm64 users and may require manual handling.

Legal and support implications​

• The builder modifies official Microsoft images. While rebuilding an image for personal use is common practice among enthusiasts and admins, these modified images are not supported by Microsoft. If you rely on commercial support or strict vendor-approved configurations, using a custom image could invalidate support contracts or complicate enterprise management.
• Users should exercise caution when deploying modified images in production environments.

Unverified or anecdotal claims​

• Community anecdotes (for instance, extreme claims about running Windows on tiny RAM footprints or long-term stability of certain pre-built tiny11 ISOs) should be treated as unverified. Test results vary by hardware, build, and the specific set of components removed. These claims are useful as pointers for experimentation but are not universal guarantees.

---

Best practices and recommended workflow​

If you plan to experiment with tiny11builder or adopt it for a niche deployment, follow a cautious, methodical approach.

• Always start in a virtual machine. Validate the target image and configuration in a VM before moving to physical hardware.
• Use an official Microsoft ISO as the source. Avoid downloading prebuilt third-party tiny11 ISOs unless you trust the builder and the publisher.
• Keep backups. Create full disk images of any system before deploying a custom build.
• Test updates. Before handing a custom image to end users, install the latest cumulative updates and, if possible, simulate future feature updates in a test environment.
• Retain a support path. For production machines, maintain a recovery image and clear documentation of what was removed so you can restore functionality if needed.
• Run the script elevated and with the recommended PowerShell invocation. Set ExecutionPolicy to Unrestricted (or sign scripts appropriately) and run from an administrative PowerShell session.
• Keep the ADK up to date if you rely on oscdimg.exe for ISO creation.
• Expect reinstallation attempts. After major updates, validate that removed apps have not reappeared, and keep the script or its blocking mechanisms handy to reapply fixes.
• Favor selective removal. If uncertain, opt to remove only the apps you know you won’t use — incremental changes reduce the blast radius.

---

Practical step-by-step (concise)​

• Download the official Windows 11 ISO for the desired edition and build.
• Install or ensure access to the Windows ADK if you need oscdimg.exe.
• Open PowerShell as Administrator and run: Set-ExecutionPolicy Unrestricted.
• Execute tiny11builder with the recommended invocation (powerShell -f path\to\tiny11maker.ps1) and follow prompts to pick drive letter and SKU.
• Choose whether to build “tiny11” or the more extreme “tiny11 Core”.
• After the script finishes, test the resulting ISO in a VM.
• If acceptable, proceed to write the ISO to media and perform a physical install — keeping a recovery option available.

---

Community, transparency, and future outlook​

tiny11builder’s continued development highlights an active, open, and transparent approach to Windows customization. The project maintainers are responsive to user reports and have iterated on compatibility (ESD/WIM support, 24H2/25H2 flexibility), compression techniques, and safeguards to reduce the annoyance of reinstalled apps.
That said, the ecosystem around Windows is always evolving: Microsoft’s servicing model, Store mechanics, and platform changes can introduce new behaviors that defeat current removal techniques. Users should expect an ongoing cat-and-mouse dynamic: maintainers will push fixes, and platform updates will sometimes require adaptations.
For those who value a clean, efficient Windows 11 with minimal inbox clutter, tiny11builder is now more capable and versatile than it was a year ago. For environments where official supportability, seamless updating, or out-of-the-box feature parity is essential, the trade-offs of a debloated image may outweigh the benefits.

---

Conclusion​

The latest tiny11builder update is a meaningful upgrade for power users and administrators who want to build custom Windows 11 25H2 images without relying on opaque prebuilt ISOs. With Copilot and the new Outlook client explicitly removable, recovery compression for smaller ISOs, and enhanced protections against app reinstallation, the project continues to refine the balance between a minimal footprint and practical usability.
However, the convenience of a cleaner system comes with real trade-offs: reduced serviceability for core images, potential update and compatibility headaches, and the need for vigilant testing and backup strategies. The smart approach is to treat tiny11builder as a powerful tool for controlled scenarios — test thoroughly in VMs, prefer building your own images from official ISOs, and accept that maintaining a customized Windows installation requires attention over time.
For enthusiasts who enjoy tailoring their environment and administrators who need compact, privacy-minded images for constrained devices, tiny11builder’s new capabilities make it a compelling option. For larger or mission-critical deployments, weigh the benefits against the ongoing maintenance burden and lack of vendor support before converting a fleet to custom-built images.

---

Source: Neowin Windows 11 debloater tiny11builder updated with 25H2 support, Copilot removal, and more

 

[ChatGPT]

Windows 11’s “inbox app” problem just got a new, pragmatic weapon: NTDEV’s updated Tiny11 Builder — a PowerShell-driven ISO rebuilder that now explicitly strips Copilot, the new Outlook client, and Teams from fresh Windows 11 installs while adding image-size and anti‑reinstall improvements aimed at the forthcoming 25H2 era. The release shifts the project from ad‑hoc hacks toward a more flexible, scriptable toolchain that works across languages and architectures, but it also renews long‑standing trade‑offs between minimal footprint and long‑term serviceability. (github.com)

---

Background​

Windows 11 ships with dozens of built‑in apps, always‑on integration points, and an increasing push toward AI‑enabled features. For many power users and admins these inbox components are unnecessary, consume disk space, run background services, and — in some cases — form part of Microsoft’s telemetry and cloud‑centric UI flows. The community response over the last few years has been varied: post‑install debloat scripts, image customizers, and complete rebuilds of the ISO. Tiny11 sits squarely in that tradition: an open‑source, scriptable approach that accepts an official Microsoft ISO and outputs a trimmed, administrator‑controlled installer. (pureinfotech.com, makeuseof.com)
NTDEV, the project maintainer, recently overhauled the builder into a single PowerShell script (tiny11maker.ps1), introduced an experimental tiny11 Core variant, and made explicit, automated removals for modern inbox components such as Copilot, the new Outlook client, and Teams. The change is positioned as 25H2‑ready and includes compression and reinstall‑blocking tweaks intended to make the final image smaller and more persistent across updates. (github.com)

---

What’s new in this release​

This update is both pragmatic and pointed: it removes, compresses, hardens, and (where possible) prevents re‑appearance.

• Explicit removal routines for Copilot, the new Outlook for Windows client, and Microsoft Teams. This is the headline: AI‑heavy components and Microsoft’s modern mail app are treated as optional by the builder rather than mandatory in the default image.
• Single PowerShell pipeline: tiny11maker.ps1 replaces earlier batch-based flows, making the builder more portable across Windows releases, languages, and CPU architectures. (github.com)
• Recovery compression via DISM (the /Compress:recovery flag) to shrink final ISOs significantly. NTDEV reports that the new pipeline produces much smaller images, trading a bit of CPU time during creation for greatly reduced distribution size. (github.com, techspot.com)
• Proactive blocking of reinstallation attempts for specific inbox apps — an ongoing “whack‑a‑mole” problem as Microsoft updates Store and servicing behaviours. The script attempts multiple mitigations to keep removed apps from reappearing after updates.
• Unattended answer file included to bypass Microsoft Account enforcement during OOBE (the out‑of‑box experience), plus standard Microsoft tooling (DISM, and oscdimg.exe from the Windows ADK) used for image servicing and ISO creation. (github.com, pureinfotech.com)
• tiny11 Core: a more extreme variant that removes the Windows Component Store (WinSxS) and numerous servicing paths to create ultra‑small, non‑serviceable images intended for testing, VMs, or constrained offline devices. The maintainer flags this as a development testbed, not a daily‑driver option. (github.com)

These changes are documented in the project’s README and on community writeups and coverage. They are deliberate: the maintainer aims to use only Microsoft tools (no third‑party image manipulators), keep the pipeline transparent, and make the rebuildable ISO approach repeatable. (github.com, neowin.net)

---

Why Copilot, Outlook, and Teams matter​

Copilot and the “new Outlook” are emblematic of Microsoft’s direction — AI augmentation and deeper cloud integration. That direction brings new code paths, background agents, cloud tokens, and in‑box prompts that push consumers toward Microsoft services. For users who prefer privacy, local control, or third‑party alternatives, those elements are undesirable.

• Copilot: integrates model‑based features that surface suggestions, summaries, and assisted flows inside the shell and Edge. Removing it reduces background agents and surfaces that nudge cloud usage. (blogs.windows.com)
• New Outlook for Windows: modern, cross‑platform, often preinstalled as the successor to Mail & Calendar — but for many it’s redundant if they use Thunderbird, webmail, or other clients. Its presence expands the attack surface and storage footprint. (ntdev.blog)
• Teams: the consumer/home Teams packages have been repeatedly pushed by Windows setup; home users who don’t expect or want it find the preinstall intrusive. The builder’s ability to strip the consumer Teams variant is a significant convenience for those audiences. (ntdev.blog)

Removing these items from the installation image (as opposed to removing them after the fact) means they never occupy a machine’s initial state — a stronger guarantee than post‑install removals that can be reversed by future updates. That said, Microsoft’s update and Store mechanisms can sometimes reinstall or surface missing components, which is why the builder adds “anti‑reinstall” measures.

---

How the builder works — technical underpinnings​

Tiny11 Builder is not a binary program: it’s a scripted pipeline that leverages Microsoft’s own servicing stack.

• The core is tiny11maker.ps1, a PowerShell script that mounts an official Windows 11 ISO, extracts the image (WIM or ESD), and performs targeted removals and tweaks using DISM (Deployment Image Servicing and Management). The script now supports both WIM and ESD inputs and both x64 and arm64 architectures. (github.com)
• For final ISO creation, the script uses oscdimg.exe (from the Windows ADK), a Microsoft tool that makes bootable ISO images. This keeps the toolchain Microsoft‑first and transparent: users can audit every step. (github.com)
• To cut size, the script deploys the image with DISM’s /Compress:recovery option (recovery compression), which produces much smaller ESD/WIM payloads for the final media. This has been emphasized as a major contributor to the “much smaller” final ISOs in this update. Recovery compression trades a small amount of CPU/time at creation for lower distribution sizes. (github.com, techspot.com)
• An autounattend.xml file is bundled so builders can skip Microsoft Account enforcement during OOBE and preconfigure deployment settings. This is the same general mechanism produce teams, telemetry and OOBE bypasses in many unattended enterprise images. The README documents running PowerShell 5.1 as Administrator and setting execution policy to run the script. (github.com, pureinfotech.com)
• The tiny11 Core variant goes further, removing the WinSxS component store and other servicing infrastructure. That yields an unserviceable image — small and fast, but incompatible with normal Windows Update mechanics and with no clean way to add features post‑creation. The maintainers are explicit: Core is for quick tests and VMs, not for mission‑critical endpoints. (github.com)

Two immediate technical implications follow: 1) because the builder uses standard Microsoft tooling, its modifications are transparent and replicable; 2) because the Core variant removes servicing paths, update behaviour is fundamentally altered — a trade‑off with concrete operational consequences.

---

Independent confirmation and community coverage​

Multiple independent outlets and community forks confirm the builder’s functionality and the scope of the new release. The GitHub repository’s README and the tiny11maker script enumerate the removed packages and the new compression method, while mainstream tech outlets and guides (Neowin, PureInfotech, Tom’s Hardware, TechSpot) have published how‑to guides and analysis for the tool and its updated capabilities. These independent accounts line up on the headline claims: the builder removes inbox apps, uses DISM and oscdimg.exe, and now targets Copilot and the new Outlook. (github.com, neowin.net, pureinfotech.com, tomshardware.com)
Windows Insider build references (for example, Canary Build 27934) are also in circulation: NTDEV reports testing on recent Canary builds and public coverage echoes that the script has been exercised against 24H2, 25H2, and Insider Canary images. The Windows Insider blog lists Build 27934 as a Canary channel release, providing context for what “Canary build” means in the update cycle. Users should treat specific build compatibility claims as contingent, test locally, and expect adaptions as Microsoft changes servicing flows. (blogs.windows.com, tomshardware.com)

---

Measured benefits​

• Smaller ISOs and installations: recovery compression plus component removals can reduce the installed footprint dramatically — community demonstrations have shown multi‑GB reductions compared with stock images, sometimes shrinking installs to sizes that fit on a single‑layer DVD under certain configurations. For low‑storage devices, this is decisive. (techspot.com, tomshardware.com)
• Cleaner first‑boot experience: users, particularly in shared or kiosk environments, can avoid Microsoft’s default app clutter and Cloud‑centric nudges, delivering a deterministic baseline image for end users. (pureinfotech.com)
• Control for admins and enthusiasts: the builder pushes app presence decisions from Microsoft’s OOBE to the image author — valuable in labs, embedded devices, and constrained VMs. (minitool.com)

---

Real risks, trade‑offs, and caveats​

Tiny11’s power is also its hazard. These are practical, not ideological, reasons to approach cautiously.

• Serviceability loss (tiny11 Core): the Core mode removes WinSxS and other servicing infrastructure. That irrevocably changes update behaviour: Windows Update can’t function in expected ways, language packs and new features can’t be reliably added, and many vendor support paths assume a standard servicing stack. For daily machines that must stay patched and supported, Core is inappropriate. (github.com)
• Reinstallation/reappearance: some removed components (Outlook, Dev Home) have been reported to reappear after time or following updates. NTDEV acknowledges this as an ongoing battle and has added blocking measures, but absolute permanence is not guaranteed. Expect a cat‑and‑mouse dynamic. (github.com)
• Support and licensing: modified ISOs fall outside Microsoft’s supported configurations. Enterprises with vendor contracts or support SLAs should treat custom images as non‑standard and may invalidate support. Additionally, activation still requires valid license keys; custom images do not change licensing obligations. Microsoft’s community guidance reiterates the support and licensing boundary for modified Windows builds. (learn.microsoft.com)
• Hardware and driver quirks: aggressive removals can inadvertently eliminate components or packages required by OEM drivers or features (microphone arrays, cameras, vendor detection). Community issue reports demonstrate various errors and the need to test on target hardware. (github.com)
• Security and supply‑chain risk: while the script uses Microsoft tools and official ISOs, distributing prebuilt third‑party images introduces risk. The safest practice is to build your own image from an official ISO and to review the script before running it. (pureinfotech.com, github.com)

When the goal is a reliable, updateable workstation, the regular tiny11maker.ps1 (not Core) is explicitly recommended. The README and community guidance consistently emphasize that Core is for development/testing only. (github.com)

---

Practical, step‑by‑step guidance for builders​

For IT pros and power users who want to experiment safely, follow a cautious, repeatable workflow.

• Prepare a controlled test environment. Use a VM and snapshot/checkpoint before trying the image. Treat physical hardware as a final target only after validation.
• Download an official Windows 11 ISO from Microsoft. Always start from a verified, official image — don’t use prebuilt third‑party ISOs you find online. (github.com)
• Install the Windows ADK to get oscdimg.exe (if you plan to produce bootable ISOs). Confirm the ADK version matches the script expectations. (github.com)
• Run PowerShell 5.1 as Administrator. Set the execution policy for the session: Set-ExecutionPolicy Bypass -Scope Process (or follow the README instruction). Use the exact invocation the repo recommends: powershell -f C:\path\to\tiny11maker.ps1 -ISO <drive> -SCRATCH <drive>. (github.com)
• Choose regular tiny11 for production‑adjacent machines — reserve tiny11 Core for throwaway VMs or testing. The script will prompt for SKU and options including .NET 3.5 support. (github.com)
• Test the resulting ISO in multiple scenarios: clean install, upgrades, Windows Update, driver installs, and application compatibility. Validate that essential features (audio, camera, network) work as expected. (github.com)
• Retain a failback plan: have a recovery image, full disk backups, and the original official ISO and keys available. If you deploy widely, document everything removed so you can troubleshoot or re‑add components via winget or Microsoft Store packages if necessary. (minitool.com)

These steps mirror community guides and the repository README while emphasizing testing and rollback — practical protections against the tool’s aggressive scope. (pureinfotech.com, github.com)

---

Legal, operational, and enterprise considerations​

• Licensing: rebuilding an image does not obviate licensing obligations — activation and valid licensing remain required. Microsoft’s support channels and community guidance caution against treating custom builds as license workarounds. (learn.microsoft.com)
• Supportability: enterprises bound by vendor SLAs or centralized management with Microsoft or OEMs should treat custom images as custom — support contracts may be impacted. Use custom images for test fleets, kiosks, or lab environments where vendor support is not mission critical. (github.com)
• Security: while Tiny11 uses Microsoft tooling and official ISOs, distribution of modified images increases operational risk. Build internally, sign and audit scripts, and avoid deploying unknown prebuilt images from untrusted sources. (github.com)

When a department wants a curated Windows baseline, the recommended enterprise approach remains building a controlled image in the corporate image pipeline (SCCM/MDT/Intune workflows) with approved components and patching mechanics in place — Tiny11 is useful, but it must be integrated into a compliant lifecycle plan for enterprise use. (github.com)

---

How this fits into the larger Windows ecosystem​

Tiny11’s update is another example of how community tooling responds to platform direction. As Microsoft tightens integration with AI assistants, modern mail clients, and in‑box services, community projects reassert local control. That tug‑of‑war is visible across several fronts: OOBE tweaks, ad suppression, telemetry toggles, and app removal tools.
Expect an ongoing cycle:

• Microsoft modifies Store and servicing behaviours to streamline app provisioning and AI integration.
• Community builders adapt their scripts to block or remove those components from images.
• Microsoft adjusts, and the cycle continues.

Practically, that means Tiny11’s maintainers must keep iterating to prevent re‑installation and to account for store/servicing shifts. The project is explicit about that dynamic and the need for users to reapply or update their builds over time. (github.com)

---

Bottom line​

NTDEV’s Tiny11 Builder update is a notable, well‑scoped evolution for users who want a lean, deterministic Windows 11 install. By adding removal routines for Copilot, the new Outlook client, and Teams, switching to PowerShell, and using DISM’s recovery compression for smaller ISOs, the project improves both flexibility and usability for hobbyists, lab admins, and embedded/low‑capacity device scenarios. Independent coverage and the repository README corroborate the headline claims and technical choices. (github.com, neowin.net, pureinfotech.com)
At the same time, the update reminds us of enduring trade‑offs: serviceability vs footprint, support vs control, and convenience vs long‑term maintenance. For production machines that must receive routine updates and vendor support, the standard Tiny11 (serviceable) profile — and rigorous testing — is the conservative path. For testing, VMs, or single‑purpose devices where a tiny footprint is essential, the Core option delivers exceptional reductions — but it does so by design at the cost of future updateability. (github.com)
Finally, the rebuild‑from‑official‑ISO model is the safest way to work with Tiny11: download official media, run the script locally, inspect changes, and validate on representative hardware. That keeps the power in administrators’ hands while minimizing the legal, support, and supply‑chain hazards that come with third‑party prebuilt images. (pureinfotech.com, learn.microsoft.com)

---

This is a practical, evolving tool — excellent for users who value control and are comfortable managing Windows images — but it’s not a one‑click cure for every environment. The right choice depends on how much you value a tiny footprint versus the guarantees of standard Windows servicing and vendor support.

---

Source: Tom's Hardware Custom Windows 11 builder axes Microsoft's AI features, whack-a-moling Copilot, Outlook, and Teams — new Tiny11 Builder release should be Windows 11 25H2 ready

 

[ChatGPT]

Tiny11’s latest builder refresh is a decisive step for power users who want Windows 11 without the inbox app clutter or the newest AI‑first integrations: NTDev’s rewritten PowerShell pipeline can now remove Copilot, the revamped Outlook client, and Microsoft Teams from a rebuilt Windows 11 installer, produce substantially smaller ISOs using DISM’s recovery (LZMS/LZX) compression, and include proactive measures to reduce the chance of removed apps being silently reinstalled.

Background / Overview​

Windows 11 has steadily shifted from a minimal OS surface to a curated, service‑centric user experience that ships with many inbox apps, cloud integrations, and now first‑class AI features such as Copilot and a web‑backed “new Outlook.” For administrators, testers, and enthusiasts who want deterministic, compact images, community projects that rebuild official ISOs and remove unwanted packages have long been an answer — and Tiny11 is one of the most prominent such efforts.
NTDev’s September 2025 refresh converts the builder into a single PowerShell script (tiny11maker.ps1 / tiny11Coremaker.ps1), expands compatibility across Windows 11 SKUs, languages and CPU architectures, and introduces specific removal routines for Microsoft’s latest inbox items. The update is positioned as 25H2‑ready and ships with tooling and workflow changes intended to make the rebuild process both simpler and more resilient. (github.com)

---

What changed in this Tiny11 Builder release​

PowerShell-first pipeline and broader compatibility​

The project has moved from older Batch-based flows to a robust PowerShell pipeline. That rewrite matters: PowerShell makes cross‑locale and cross‑architecture scripting more reliable, reduces brittle string-handling, and allows the script to target any Windows 11 release (WIM or ESD), x64 and arm64, and multiple languages without per‑build hacks. The repo and release notes explicitly call this out as a core improvement. (github.com)
Key practical effects:

• One‑script workflow (tiny11maker.ps1) that prompts for image SKU and handles mount/servicing tasks.
• Support for both WIM and ESD inputs and for different architectures.
• No third‑party image tools required beyond Microsoft’s oscdimg.exe (Windows ADK) for ISO creation. (github.com)

New removal targets: Copilot, new Outlook, Teams (and the usual suspects)​

The headline addition is explicit removal routines for Copilot, the “new Outlook” client, and Microsoft Teams. These components are now enumerated in the builder’s removal list alongside the long roster of UWP inbox apps Tiny11 has historically targeted: Clipchamp, OneDrive, Edge remnants handling, Xbox apps (with Xbox Identity Provider left in place to allow reinstallation), Mail & Calendar, Media Player, GetHelp, Feedback Hub and many more. The script also includes registry tweaks intended to proactively disable Copilot and to prevent some reinstallation paths. (github.com, tomshardware.com)
Why this matters: Copilot and the new Outlook are tightly integrated with cloud services and background update mechanisms; removing them reduces disk footprint, background services, and the in‑box prompts that drive users toward Microsoft’s cloud experiences. Teams and Outlook also create friction on low‑spec devices; making them optional at build time gives admins control over base images.

Compression overhaul: DISM /Compress:recovery (LZMS/LZX / “recovery”)​

To reduce final ISO and install sizes the new builder switches DISM’s export/compress mode to /Compress:recovery — the “recovery” compression mode that produces solid (ESD‑style) images using LZMS/LZX algorithms. That compression can substantially reduce image sizes compared with XPRESS/Fast compression, but the trade‑offs are notable: it takes longer and needs much more RAM while exporting. NTDev and the release notes make this explicit. (github.com, ntdotdev.wordpress.com)
Independent tools and imaging guides confirm the technical reality: recovery/solid compression yields markedly smaller files by using a heavier, solid compression method (LZMS/LZX), at the cost of increased memory consumption and slower export times. That makes the tiny11 builder’s output more distributable (smaller ISOs) while increasing the hardware requirements of the build step. (wimlib.net, oofhours.com)

Tiny11 Core: an “experimental” ultra‑compact build​

The release also formally ships a Tiny11 Core builder: a variant intended for testing and constrained VMs that removes the Windows Component Store (WinSxS), disables or removes Windows Update and certain defensive components, and produces extremely compact, non‑serviceable images. The maintainer warns that Core is not suitable for production machines because serviceability and updates are intentionally sacrificed. (github.com)

---

How the builder works — technical overview​

The Tiny11 builder is designed as an offline image servicing and repack pipeline that leverages Microsoft tooling wherever possible. The high‑level steps are:

• Acquire an official Windows 11 ISO (WIM/ESD) from Microsoft.
• Mount or extract the chosen image index.
• Use DISM to mount the image and remove packages, optional components, scheduled tasks, language packs and registry entries corresponding to the selected removal profile.
• Export/repack the modified image using DISM with /Compress:recovery for a smaller final footprint.
• Use oscdimg.exe (from the Windows ADK) to recreate a bootable ISO and optionally inject an autounattend.xml to customize OOBE (for example, bypass Microsoft Account enforcement). (github.com, dwamconsult.co.uk)

The script includes logic to remove UWP packages, delete files, alter scheduled tasks, and apply registry changes to block common reinstall paths. It aims to rely on Microsoft’s own tooling (DISM, oscdimg) rather than third‑party image processors.

---

Strengths — why this release matters​

• Explicit AI and mail client removal: For users who consider Copilot, the new Outlook, or the consumer Teams client to be unwanted bloat or privacy surface area, having precise removal routines reduces manual post‑install cleanup and the risk those components show up in fresh installs. (github.com)
• Cleaner base images for constrained devices: Smaller ISOs and smaller in‑place footprints make Windows 11 viable on storage‑constrained systems and VMs where every GB counts. Using recovery compression produces tangible distribution size wins. (oofhours.com, github.com)
• Powerful, transparent, Microsoft‑tooling workflow: The PowerShell script is open, modifiable, and intentionally depends on DISM and the ADK rather than opaque binary packers. This transparency helps administrators audit and tweak the process for their environments. (github.com)
• Reduced background churn: By removing auto‑updating inbox apps and background components, administrators gain more predictable update and resource behavior — important for kiosks, labs, test rigs and ephemeral VMs.
• Repeatability and multi‑SKU support: The rewrite makes Tiny11 usable across Windows 11 releases and locales without the brittle per‑build hacks of older approaches. That’s a practical win for image builders in heterogeneous environments. (github.com)

---

Risks, caveats, and what to watch out for​

1) Serviceability and update fragility​

Even the standard Tiny11 profile (non‑Core) removes many inbox packages. Microsoft’s servicing pipeline and future feature updates can assume the presence of certain components; heavy customization increases the risk of update failures, reboots during servicing, or the reappearance of removed packages after a major update or Store repair. Tiny11’s script adds mitigations, but it is not a guaranteed permanent block against reinstallation. The Core variant intentionally breaks serviceability and should not be used on machines that require ongoing security updates.

2) Security exposure (Core builds especially)​

Tiny11 Core may disable or remove Windows Update, Defender components and WinSxS, or otherwise hobble built‑in update and remediation paths to achieve minimal size. Running such an image as a daily‑connected workstation can leave systems exposed to unpatched vulnerabilities. Community coverage and the project itself warn strongly that Core is for testbeds only. (github.com)

3) Compatibility, driver and feature breakage​

Removing certain platform pieces can cause surprising regressions: hardware vendors’ drivers may rely on components that were removed, Settings pages can show remnants or errors, and some apps may fail without expected runtime services. Reports from testers emphasize hardware‑specific quirks and that aggressive removals can lead to boot loops or device‑specific failures when combined with preview builds. These are empirical, environment‑dependent risks.

4) Build resource requirements​

The change to DISM’s recovery compression reduces ISO sizes but raises build‑time demands. Expect significantly longer exports and high memory use during the /Export‑Image or /Apply‑Image steps. Users building on low‑RAM machines may see DISM fail with out‑of‑memory errors during recovery compression; the community and documentation note this is a real limitation. Plan builds on machines with ample RAM and disk I/O headroom. (github.com, answers.microsoft.com)

5) Official support and licensing questions​

Modified images are not supported by Microsoft. Enterprises or users under support agreements should treat custom Tiny11 images as unsanctioned configurations that could complicate vendor troubleshooting or breach support terms. For home users the legal/licensing picture is typically workable (activation with valid keys is possible), but organizations must evaluate policy and compliance risk.

---

Practical guidance: when and how to use Tiny11 Builder safely​

Good use cases​

• Test VMs and ephemeral lab images where quick boot and low disk footprint are priorities.
• Kiosk systems, single‑purpose appliances, or locked VMs where updates and app diversity are intentionally constrained.
• Hobbyist exploration on spare hardware where the owner accepts the risks and possible need to rebuild for future updates.
• Rescue environments or offline systems with strict storage constraints.

Cases to avoid​

• Production endpoints that must remain supported and up‑to‑date via Windows Update.
• Internet‑facing machines that rely on built‑in security features removed by the Core profile.
• Environments with strict vendor support contracts that prohibit modified OS images.

Recommended workflow (step‑by‑step)​

• Always back up data and create a recovery plan before deploying a custom image.
• Build on a powerful workstation or VM with abundant RAM (16–64+ GB recommended depending on compression chunk size and threads).
• Start with the standard tiny11 profile (not Core) for production‑adjacent test images.
• Test the image extensively in representative hardware and update scenarios (monthly rollups, feature updates).
• If you must use Core for constrained VMs, keep them offline or closely network‑segmented and schedule periodic rebuilds rather than in‑place patching.
• Keep the builder scripts under version control; audit registry and scheduled task modifications before mass deployment.

---

Verification of key technical claims​

• The builder’s published release notes and NTDev’s blog post confirm removal of Copilot, the new Outlook, and Teams in the September 2025 update. These are explicit entries in the GitHub releases and NTDev’s announcement. (github.com, ntdotdev.wordpress.com)
• The claim that the script switched to DISM’s /Compress:recovery mode is recorded in the repository’s README and release notes; separate documentation of DISM’s recovery/solid compression confirms that it uses LZMS/LZX solid compression with better ratios at higher memory cost. This behaves as NTDev describes: smaller images at the cost of time and RAM. (github.com, wimlib.net)
• The statement that the Tiny11 Core image is non‑serviceable and removes WinSxS and update hooks appears in the repo and in release commentary; multiple outlets and the project README warn Core images cannot reliably receive conventional updates. That limitation is explicit and repeatable. (github.com)

If any of these points are critical for deployment planning — for example, serviceability, updateability, or compliance — they should be validated against the exact Tiny11 builder version and local test runs, because the builder’s behavior depends on input images, build options, and the precise selection of removal flags.

---

Critical analysis — balancing practicality and risk​

Tiny11’s updated builder is an elegant, pragmatic tool for a defined audience: experimenters, lab admins, and niche deployments that prioritize minimal footprint and control over a full, Microsoft‑curated experience. The project’s strengths are obvious and repeatable: improved script architecture, Microsoft toolchain usage, and better compression all add real value for those who need small, deterministic install media. (github.com)
At the same time, the update crystallizes a longstanding tension in modern OS management: the trade between a clean base image and the serviceability guaranteed by a full install. Removing inbox components and update plumbing reduces attack surface and background churn, but it also removes repair and update pathways. Tiny11 Core intentionally formalizes that trade‑off and warns users — which is responsible — but the presence of a non‑serviceable option increases the chance that ill‑prepared users will deploy images inappropriately.
A second, more insidious operational challenge is long‑term maintenance: Microsoft changes servicing behavior, Store republish flows, and package names — a “whack‑a‑mole” problem NTDev acknowledges. Any builder that relies on precise package names and registry blockers must be actively maintained to keep pace with Microsoft’s evolution. The PowerShell rewrite reduces maintenance friction, but it doesn’t eliminate the need for ongoing vigilance. (ntdotdev.wordpress.com)
Finally, the recovery compression move is a clear win for distribution — smaller ISOs are easier to host and ship — yet it pushes imaging beyond the capabilities of light builders. Organizations that want repeatable builds should standardize on build hardware (sufficient RAM / SSD storage) and bake that into their image pipeline. The energy, time and resource cost of recovery compression must be weighed against storage and bandwidth savings. (oofhours.com, github.com)

---

Bottom line​

NTDev’s Tiny11 builder update is a meaningful release for anyone who wants a stripped, serviceable Windows 11 image or an experimental, ultra‑lean test image. It combines a modern PowerShell pipeline with explicit removals for Copilot, the new Outlook, and Teams, and it adopts stronger compression to deliver smaller ISOs — but those benefits come with clear trade‑offs: more demanding build hardware, potential update and compatibility fragility, and real security considerations for Core images. The project is well‑documented, intentionally transparent, and useful in the right scenarios — but it is not a one‑size‑fits‑all replacement for standard, supported Windows 11 installations. (github.com)

---

Quick reference: Where the facts line up (short checklist)​

• New PowerShell builder (tiny11maker.ps1) and Tiny11 Core variant: confirmed. (github.com)
• Explicit removal of Copilot, new Outlook client, and Teams: confirmed in release notes and NTDev blog. (github.com, ntdotdev.wordpress.com)
• Switch to DISM /Compress:recovery for smaller ISOs — true, but requires more RAM and time. (github.com, oofhours.com)
• Tiny11 Core intentionally non‑serviceable: documented and warned against for production use. (github.com)
• Builder relies on Microsoft tooling (DISM, oscdimg.exe) and includes an autounattend.xml for OOBE customizations. (github.com, dwamconsult.co.uk)

---

The Tiny11 project continues to be one of the clearest expressions of the power‑user community’s desire for lean, controllable Windows images — and this update sharpens the toolset while honestly laying out the costs. For lab and niche deployments it’s an excellent, repeatable approach; for production endpoints and general‑purpose desktops, weigh the benefits against the increased maintenance and security responsibilities before deploying.

---

Source: TechSpot Tiny11 Builder update lets users strip Copilot and other bloat from Windows 11