# How to Enable Hidden Windows 11 Features Early with ViVeTool > AI Release · @ai_release1 · https://ai-release.org/guides/poshagovoe-rukovodstvo-kak-vklyuchit-skrytye-funktsii-w_en.html ## TL;DR - Time: 20–30 minutes, including one reboot and a restore-point check. - Difficulty: Intermediate. - Requires: Windows 11, an administrator PowerShell window, a ViVeTool release for your CPU architecture, a feature ID from the release notes or a trusted tracker for your exact build, and a System Restore checkpoint. The `/enable` command is the easy part. The checks most guides omit are: whether your build already contains the feature code, whether the feature ID matches that build, and whether you can roll back cleanly. A feature flag is a hidden on/off switch in Windows code; ViVeTool changes the switch, but it cannot add code that is not already present. ## Requirements and setup ![Illustration: Requirements and setup](https://ai-release.org/guides/img/poshagovoe-rukovodstvo-kak-vklyuchit-skrytye-funktsii-w-en-1.jpg?v=1794473945) - Windows 11 with a known build number. Feature flags are build-specific; do not assume an ID from another build will work. - Administrator rights. ViVeTool changes system configuration and normally needs an elevated prompt. - ViVeTool extracted to a local folder, for example `C:\Users\\Downloads\ViVeTool\ViVeTool.exe`. - The target feature ID. The source material for this guide does not provide feature IDs, so use `` as a placeholder and replace it with an ID from the release notes or a trusted tracker for your exact build. - System Protection enabled, or permission to create a restore point. - Enough free space for the archive, extracted files, and a restore point. Check with `Get-PSDrive C`. Create a checkpoint before changing anything: ```powershell Enable-ComputerRestore -Drive "C:\" Checkpoint-Computer -Description "Before ViVeTool" -RestorePointType MODIFY_SETTINGS Get-ComputerRestorePoint | Select-Object -Last 1 ``` **Example:** the last command should return a recent entry with `Description : Before ViVeTool`. If System Protection is disabled by policy, the checkpoint command fails; stop and fix that first. If the feature depends on a Windows update that has not arrived, install the update first. The manual catalog procedure is covered in [Step-by-Step: How to Install a Windows 11 Security Update Manually via Microsoft Update Catalog](https://ai-release.org/guides/poshagovoe-rukovodstvo-kak-ustanovit-obnovlenie-bezopas.html?utm_source=tg&utm_medium=channel&utm_campaign=guide_inline&utm_content=guide_to_guide). ## Step 1. Record the build, architecture, and rollback baseline ![Illustration: Step 1. Record the build, architecture, and rollback baseline](https://ai-release.org/guides/img/poshagovoe-rukovodstvo-kak-vklyuchit-skrytye-funktsii-w-en-2.jpg?v=1794473951) **What to do:** open an administrator PowerShell window and save the OS build, architecture, and your feature-ID worksheet before running ViVeTool. **Why:** feature IDs are tied to specific Windows builds. If the ID does not exist in your build, `/enable` may report success while nothing changes. The baseline also tells you what to restore if the feature causes instability. **How to check:** confirm that the output contains `WindowsProductName`, `OsBuildNumber`, and `OsArchitecture`, and that the baseline file exists on your Desktop. ```powershell $baseline = "$env:USERPROFILE\Desktop\vive-baseline.txt" Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture | Tee-Object -FilePath $baseline [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture | Tee-Object -FilePath $baseline -Append ``` Expected output has this shape: ```text WindowsProductName : Windows 11 ... WindowsVersion : OsBuildNumber : OsArchitecture : ``` **Example:** if `OsArchitecture` returns `X64`, use the x64 ViVeTool build; if it returns `Arm64`, use the ARM64 build. Do not mix them. Record the experiment in a small worksheet: | Item | Example value | Why it matters | |---|---|---| | Feature ID | `` | Must match the build | | Build before | `` | Rollback reference | | ViVeTool SHA256 | `` | Integrity check | | Result after reboot | `Enabled` or `No change` | Keep-or-rollback decision | Checklist before continuing: - [ ] Build number saved to `vive-baseline.txt` - [ ] CPU architecture confirmed - [ ] Feature ID recorded with its source - [ ] Restore point visible in `Get-ComputerRestorePoint` - [ ] No other feature IDs are being changed in the same test ## Step 2. Stage ViVeTool and enable one feature flag **What to do:** extract ViVeTool, verify the executable hash, query the feature ID, and enable that single ID from an elevated PowerShell window. **Why:** one ID at a time keeps the result attributable. If you enable several IDs and the UI breaks, you cannot tell which flag caused it. Querying first also proves the ID exists in your build before you change state. **How to check:** `Get-FileHash` must match the hash published with your ViVeTool release, `\/query` must show the feature ID, and `\/enable` should print a success message such as `Successfully set feature configuration(s)`. ```powershell $work = "$env:USERPROFILE\Downloads\ViVeTool" New-Item -ItemType Directory -Path $work -Force Expand-Archive -LiteralPath "$env:USERPROFILE\Downloads\ViVeTool.zip" -DestinationPath $work -Force Set-Location $work Get-ChildItem Get-FileHash .\ViVeTool.exe -Algorithm SHA256 ``` **Example:** `Get-ChildItem` shows `ViVeTool.exe`; `Get-FileHash` returns a SHA256 value. Compare it with the value on the release page. If it differs, delete the folder and download again. Open an elevated window: ```powershell Start-Process powershell -Verb RunAs ``` In the elevated window, query before enabling: ```powershell Set-Location "$env:USERPROFILE\Downloads\ViVeTool" .\ViVeTool.exe /query /id: .\ViVeTool.exe /query > "$env:USERPROFILE\Desktop\vive-before.txt" .\ViVeTool.exe /enable /id: ``` **Example:** replace `` with a value such as the ID listed for your build in the release notes. Do not copy an ID from an unrelated build. If `/query /id:` returns no matching feature, stop; the ID is wrong for this build. Reboot so the flag is loaded at startup: ```powershell Restart-Computer ``` ## Step 3. Reboot, verify state, and check visible behavior ![Illustration: Step 3. Reboot, verify state, and check visible behavior](https://ai-release.org/guides/img/poshagovoe-rukovodstvo-kak-vklyuchit-skrytye-funktsii-w-en-3.jpg?v=1794473957) **What to do:** after reboot, query the same feature ID again and then check the Windows UI or app behavior that the flag is supposed to change. **Why:** ViVeTool state and visible behavior are two different checks. A flag can show `Enabled` while the UI remains unchanged because another dependency, a server-side experiment, or an app update is missing. That is the “where this does NOT work” case most guides skip. **How to check:** the query should show the feature ID with an enabled state; the target UI should show the new control or behavior after a short wait and, when relevant, a sign-out or second reboot. ```powershell Set-Location "$env:USERPROFILE\Downloads\ViVeTool" .\ViVeTool.exe /query /id: | Select-String -Pattern "Enabled|State|Feature" ``` **Example:** a successful query returns a line containing the feature ID and an enabled state. Then open the relevant Settings page or app. If the control is absent, do not enable more IDs blindly; use the decision table below. | Query result | Visible result | Action | |---|---|---| | State shows enabled | Feature appears | Keep it; record the build and ID | | State shows enabled | Feature absent | Check dependencies, app version, and server-side gating; then disable | | No matching feature | Not applicable | Wrong build or wrong ID; stop and re-check the source | If the feature does not appear and you do not need it, roll back immediately: ```powershell .\ViVeTool.exe /disable /id: Restart-Computer ``` **Example:** after `/disable`, the same `/query /id:` should show the feature as disabled or no longer active. If it does not, restore the checkpoint from Step 1. ## Troubleshooting **Problem. PowerShell cannot find ViVeTool** - Error: `The term 'ViVeTool.exe' is not recognized as the name of a cmdlet, function, script file, or operable program.` - Cause: PowerShell does not run executables from the current folder unless you prefix them with `.\`, or you are in the wrong directory. - Solution: change to the extracted folder and run the explicit path: ```powershell Set-Location "$env:USERPROFILE\Downloads\ViVeTool" .\ViVeTool.exe /query ``` **Problem. The enable command fails with access denied** - Error: `Access is denied` - Cause: the PowerShell window is not elevated, so ViVeTool cannot write the feature configuration. - Solution: open an administrator window and verify elevation before retrying: ```powershell ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) ``` The command must return `True`. If it returns `False`, close the window and start PowerShell with **Run as administrator**. **Problem. SmartScreen blocks the downloaded executable** - Error: `Windows protected your PC` and `Microsoft Defender SmartScreen prevented an unrecognized app from starting.` - Cause: the downloaded archive has Mark-of-the-Web, so Windows treats the extracted executable as untrusted. - Solution: verify the SHA256 hash first. If it matches the release page, unblock the file and retry; do not disable SmartScreen globally: ```powershell Unblock-File -Path .\ViVeTool.exe Get-FileHash .\ViVeTool.exe -Algorithm SHA256 ``` ## Summary and next steps Enable one feature ID at a time, record the build and hash, and keep the matching `/disable` command ready for rollback. If you are cleaning up a test machine after the experiment, apply the same staged approach to ads, telemetry, and AI features with [How to disable ads, telemetry and AI features in Windows 11](https://ai-release.org/guides/otklyuchit-telemetriyu-i-reklamu-windows-11.html?utm_source=tg&utm_medium=channel&utm_campaign=guide_inline&utm_content=guide_to_guide). ## FAQ **Does ViVeTool add features that are not installed?** No. It changes flags that already exist in the Windows build. If the code is absent, the flag cannot make the feature appear. **Can I use any feature ID I find online?** No. Feature IDs are build-specific and can change. Use only IDs tied to your exact build from release notes or a trusted tracker; this source does not provide feature IDs. **Why did `/enable` succeed but the UI is unchanged?** The flag may depend on another flag, an app update, specific hardware, or a server-side experiment controlled by Microsoft. Disable the ID and verify the dependency list before retrying. **How do I undo the change?** Run `.\ViVeTool.exe /disable /id:` and reboot. If the system is unstable, restore the checkpoint created in Step 1.