How to Find and Use Windows Features with PowerShell on Windows 10 and 11

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Use PowerShell to discover the exact name of a Windows optional feature or capability, then run the matching servicing cmdlet against either the running system or a mounted offline image. Optional features use Get-WindowsOptionalFeature and Enable-WindowsOptionalFeature; capabilities use Get-WindowsCapability and Add-WindowsCapability. Run the session as administrator, verify the returned name, plan where package files will come from, and check the result for a restart requirement.

The phrase “only available through PowerShell” needs qualification. Windows 10 and Windows 11 expose some feature management in Settings, and Microsoft also documents corresponding DISM.exe operations. PowerShell is valuable when you need exact inventory, repeatable commands, offline-image servicing, parent-feature handling, or source-control options.

Know which Windows object you are managing

Windows uses two related but different servicing targets. Choosing the wrong cmdlet is the most common reason a command cannot find a name that appears to be valid.

Target	Discover it with	Change it with	Name to use
Optional feature	Get-WindowsOptionalFeature	Enable-WindowsOptionalFeature or Disable-WindowsOptionalFeature	The feature name returned by the discovery command
Windows capability	Get-WindowsCapability	Add-WindowsCapability	The full capability package name returned by discovery

An optional feature is normally a component represented in the operating-system feature inventory. A capability is a package that can be added to an image, such as a language-related or other on-demand component. Their names and installation commands are not interchangeable. Do not copy a capability name into Enable-WindowsOptionalFeature, or treat an optional-feature name as an argument to Add-WindowsCapability.

Both command families can target the running installation with -Online or a mounted offline image with -Path. The target switch is part of the operation, not a cosmetic option: it determines which operating-system image is inspected or changed.

This distinction also explains why a friendly label in Settings may not match the string required by a cmdlet. The inventory command exposes the servicing identity used by that particular image. Copy that identity exactly, including punctuation, separators, and any package or language details. A name copied from another Windows release can be absent or represent a different package.

Prepare a safe PowerShell session

Open an elevated shell

Start Windows PowerShell with Run as administrator. Microsoft’s module-compatibility guidance calls for an elevated session for these feature and capability commands. Without elevation, discovery may be incomplete and a state-changing command can fail before servicing starts.

Confirm the target and the intended change

• For the computer you are currently using, choose -Online.
• For a mounted Windows image, choose -Path <mounted-image-path> and verify that the path points to the intended image.
• Use the exact name returned by discovery instead of guessing punctuation, architecture suffixes, or package-language tags.
• Read the current state before enabling, disabling, or installing anything.
• Save work before a change that reports a possible restart requirement.

Available features and capabilities depend on the Windows edition, build, image contents, and servicing configuration. Microsoft’s cmdlet pages cover Windows client and several Windows Server releases, but no single inventory applies to every release or region. Query the actual target rather than relying on a list copied from another computer.

For a repeatable change, record the target switch, the exact returned name, the initial state, the command you intend to run, and the final state. This is especially useful when servicing a mounted image: a visually similar directory can contain a different image, and using -Online by mistake would alter the computer running the shell rather than the mounted image.

Find optional features on the running system

To list optional features in the currently running Windows installation, use:

Get-WindowsOptionalFeature -Online

The output is the authoritative starting point for that installation. It lets you see the feature names and their states before making a change.

Filter the list when you know part of the name

Use the -FeatureName parameter with a wildcard to inspect matching entries. Microsoft’s example pattern for Hyper-V is:

Get-WindowsOptionalFeature -Online -FeatureName *Hyper-V*

A wildcard search is safer than inventing a name, but it can return more than one entry. Read every matching result and select the feature whose complete name and current state match your objective. If the result is empty, do not substitute a similarly worded capability; first confirm the target edition and build, then query the complete inventory without a filter.

Inspect an offline image instead

If the image has been mounted, replace -Online with its mount path:

Get-WindowsOptionalFeature -Path <mounted-image-path>

You can apply the same name filter to an offline target:

Get-WindowsOptionalFeature -Path <mounted-image-path> -FeatureName *Hyper-V*

Keep the target switch consistent throughout a workflow. Discovering a feature in an offline image and then enabling it with -Online would modify the running computer instead of the image you inspected.

The offline query is useful before deployment because it shows what is already present in the image, not what happens to be installed on the technician’s computer. It also avoids using a name that exists on one image but is unavailable on another.

Enable an optional feature

After discovery, enable the feature on the running system with:

Enable-WindowsOptionalFeature -Online -FeatureName <feature-name>

Replace <feature-name> with the exact value returned by Get-WindowsOptionalFeature. The command supports online and mounted-image targets, so the offline form is:

Enable-WindowsOptionalFeature -Path <mounted-image-path> -FeatureName <feature-name>

Include required parent features

Add -All when you want Windows to enable parent features required by the selected feature:

Enable-WindowsOptionalFeature -Online -FeatureName <feature-name> -All

For an offline image, combine the same option with -Path:

Enable-WindowsOptionalFeature -Path <mounted-image-path> -FeatureName <feature-name> -All

-All changes the scope of the operation by including parent features. Use it only when that dependency behavior is intended; otherwise, enable the named feature without it. If a parent is already enabled, the command can leave it in that state while enabling the requested child; the important point is that the dependency is included rather than ignored.

Account for payload sources

Enabling a feature can require component files that are not currently available to the target. The cmdlet supports source controls for restore scenarios. If the command reports that source files are needed, provide a source that contains the required Windows payload and verify that the source matches the target image. Do not assume a source from a different build or edition is interchangeable.

A source problem is separate from a naming problem. First confirm that the feature exists and that the command is aimed at the correct image. Then address where the payload can be obtained. Using a mismatched source can leave the operation incomplete even though the feature name was correct.

Verify the result and restart guidance

Run the corresponding discovery command again after the operation:

Get-WindowsOptionalFeature -Online -FeatureName <feature-name>

Review the returned state and the indication of whether a restart may be required. Microsoft’s feature-management guidance specifically calls out this restart information. Restart only after saving work and after confirming that the changed feature is the one you intended to modify.

For an offline image, repeat the query with the same -Path value. The verification step is not optional: a command can finish while the image still needs a restart, a source file, or a subsequent servicing action before the feature is usable.

Disable a feature, or remove its files

To disable an optional feature while leaving its files in the image, run:

Disable-WindowsOptionalFeature -Online -FeatureName <feature-name>

The offline equivalent is:

Disable-WindowsOptionalFeature -Path <mounted-image-path> -FeatureName <feature-name>

Disabling and removing are different decisions. Disabling changes the feature’s active state. It does not, by itself, remove the feature payload.

Use -Remove only when you intend to remove the payload

Add -Remove to remove the feature files while preserving the feature manifest:

Disable-WindowsOptionalFeature -Online -FeatureName <feature-name> -Remove

For an offline image:

Disable-WindowsOptionalFeature -Path <mounted-image-path> -FeatureName <feature-name> -Remove

Because the manifest remains, the feature can later be restored from a remote source. Removing files therefore saves local payload space but creates a future source requirement. If you merely need the feature inactive and expect to re-enable it without arranging a source, omit -Remove.

Think of -Remove as a servicing and recovery decision, not simply a stronger form of disablement. A disabled feature retains its local payload; a removed feature retains the manifest but needs an appropriate source when its files are restored. Document that choice so a later administrator does not mistake a removed payload for a permanently unavailable feature.

Check the post-change state

Query the feature again with the same target switch and inspect its state and any restart indication. Keep the output with your change record when servicing a managed image, so you can distinguish a disabled feature from one whose files were removed.

Find Windows capabilities

Capabilities have their own inventory and naming scheme. List installed and available capabilities on the running system with:

Get-WindowsCapability -Online

For a mounted image, use:

Get-WindowsCapability -Path <mounted-image-path>

Read the complete Name value from the output. Capability names commonly include package details, so using only a shortened description can select nothing or the wrong package. Discovery first also tells you whether the capability is already installed or available to add.

Filter capability output

The capability cmdlet can be combined with PowerShell filtering when the complete inventory is large. For example, inspect the returned objects and select a known text fragment before copying the full name into the installation command:

Get-WindowsCapability -Online | Where-Object Name -like '*Language*'

The filter is only a way to narrow what you read; it does not change the package name that must be supplied later. The important rule is that the value supplied to -Name must be the full capability name from the target image, not a friendly label remembered from another release. If several matches appear, compare their complete names and states rather than choosing the first result.

Use the same approach for an offline image by replacing -Online with -Path <mounted-image-path>. The returned list belongs to that image, so it is the appropriate authority for an image that will be deployed elsewhere.

Install a capability with the correct source behavior

Install a discovered capability on the running system with:

Add-WindowsCapability -Online -Name <full-capability-name>

For an offline image:

Add-WindowsCapability -Path <mounted-image-path> -Name <full-capability-name>

When Windows Update or WSUS supplies the package

If you do not specify -Source, Microsoft’s example states that the Windows Update client obtains the required package. The target therefore needs an active Internet connection or an active connection to the local WSUS server, subject to the organization’s servicing policy.

An installation can fail even when the capability name is valid if the target cannot reach its approved servicing source. Treat connectivity and policy as part of the command design. A machine intentionally restricted from Windows Update should not be expected to obtain an on-demand package merely because the capability appears in the inventory.

When you have package files locally

Use -Source <source-path> to point the cmdlet at package files:

Add-WindowsCapability -Online -Name <full-capability-name> -Source <source-path>

To prevent the cmdlet from querying Windows Update for source packages, add -LimitAccess:

Add-WindowsCapability -Online -Name <full-capability-name> -Source <source-path> -LimitAccess

The same source options can be used with an offline image by replacing -Online with -Path <mounted-image-path>. A source path does not make an incompatible package usable; it must contain files appropriate to the target image.

Use -LimitAccess deliberately. It changes the fallback behavior by preventing a Windows Update source query; it is useful when policy requires local servicing, but it also means the command cannot recover by consulting Windows Update if the specified source is incomplete.

Verify installation

Query the capability again:

Get-WindowsCapability -Online -Name <full-capability-name>

For an offline target, use the image path instead. Confirm that the state changed as intended before moving on to dependent configuration or deployment steps. If the state did not change, preserve the command output and revisit the target, name, source, and elevation rather than repeatedly submitting the same installation.

Choose the workflow that matches your situation

Decision	Use this approach	Why it matters
Running Windows or image servicing	-Online for the running OS; -Path for a mounted image	Prevents you from inspecting one target and changing another
Optional feature or capability	Optional-feature cmdlets for features; capability cmdlets for packages	The inventories, names, and change operations differ
Feature dependency	Add -All when parent features should also be enabled	Required parents are included instead of being left inactive
Capability package source	Omit -Source for Windows Update/WSUS behavior, or specify a source; add -LimitAccess to block Windows Update queries	Controls where servicing looks for package files
Freeing component files	Disable normally, or use -Remove when payload deletion is intentional	Removing files creates a later source requirement

These are servicing choices, not product comparisons. Settings may be more convenient for a one-off client change, while PowerShell gives you explicit names, repeatable commands, offline-image support, and source parameters. DISM.exe also provides corresponding servicing operations; Microsoft maps its commands to the PowerShell cmdlets.

Use Settings when you want a guided client interface and the feature is exposed there. Use PowerShell when the exact inventory matters, when the feature is not surfaced in that interface, when you are preparing an image, or when source and dependency behavior must be explicit. Neither choice changes the need to verify the target and the resulting state.

PowerShell, Settings, and DISM.exe: what “only” really means

Microsoft’s client-management guidance says optional features may not be included by default, that Settings can add or remove features, and that PowerShell can enable or disable specific features. The practical conclusion is that PowerShell is not the universal exclusive doorway to every Windows feature. Its advantage is control and repeatability.

Microsoft also maps DISM.exe commands to DISM PowerShell cmdlets and states that the cmdlets perform the same functions. If an existing deployment process uses DISM.exe, you are not dealing with a completely different servicing model; the PowerShell form exposes the same broad operations through cmdlets and object output. Choose one workflow and keep its target, name, source, and verification steps consistent.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Troubleshoot the common failure points

The command cannot find the feature or capability

Run the matching discovery cmdlet against the same target you plan to change. Copy the exact returned name, including punctuation and package details. If the name appears in one image but not another, treat that as an image or build difference rather than substituting a similar name.

The operation fails immediately with an access error

Close the shell, reopen Windows PowerShell with Run as administrator, and repeat discovery before repeating the change. An elevated session is a prerequisite for the documented management workflow.

A capability installation cannot obtain source files

Decide whether the target should use Windows Update or WSUS. If that path is unavailable, provide an explicit package source. If you used -LimitAccess, remember that it deliberately prevents a Windows Update source query; remove that switch only when organizational policy permits Windows Update access.

The command reports that a restart may be needed

Do not treat the command’s completion as proof that every dependent component is active immediately. Save work, complete any required maintenance window, restart when appropriate, and query the feature again afterward.

You disabled a feature but expected disk space to return

Disabling changes availability but leaves files in place. Use -Remove only if deleting the payload is the intended trade-off, and retain a suitable remote source for a future restore.

The feature works on one release but not another

Availability is tied to the target image’s edition, build, contents, and servicing configuration. Re-run discovery on the affected system or image and use only the name returned there. Do not infer a universal inventory from a command copied from a different Windows 10, Windows 11, or Windows Server release.

A repeatable checklist

1. Open an elevated Windows PowerShell session.
2. Decide whether the target is the running OS (-Online) or a mounted image (-Path).
3. Decide whether the target is an optional feature or a capability.
4. Run the corresponding Get- cmdlet and record the exact returned name and current state.
5. Choose the matching change cmdlet: enable or disable an optional feature, or add a capability.
6. For optional features, decide whether parent features should be included with -All.
7. For capabilities, decide whether Windows Update/WSUS, an explicit -Source, or -Source plus -LimitAccess fits the servicing policy.
8. If disabling, decide separately whether -Remove should delete payload files.
9. Run the change against the same target you queried.
10. Run the Get- command again, inspect the state and restart indication, and restart if required.

Command reference

Purpose	Running OS	Mounted image
List optional features	Get-WindowsOptionalFeature -Online	Get-WindowsOptionalFeature -Path <mounted-image-path>
Find matching optional features	Get-WindowsOptionalFeature -Online -FeatureName *Hyper-V*	Get-WindowsOptionalFeature -Path <mounted-image-path> -FeatureName *Hyper-V*
Enable an optional feature and parents	Enable-WindowsOptionalFeature -Online -FeatureName <feature-name> -All	Enable-WindowsOptionalFeature -Path <mounted-image-path> -FeatureName <feature-name> -All
Disable an optional feature	Disable-WindowsOptionalFeature -Online -FeatureName <feature-name>	Disable-WindowsOptionalFeature -Path <mounted-image-path> -FeatureName <feature-name>
Disable and remove feature files	Disable-WindowsOptionalFeature -Online -FeatureName <feature-name> -Remove	Disable-WindowsOptionalFeature -Path <mounted-image-path> -FeatureName <feature-name> -Remove
List capabilities	Get-WindowsCapability -Online	Get-WindowsCapability -Path <mounted-image-path>
Add a capability	Add-WindowsCapability -Online -Name <full-capability-name>	Add-WindowsCapability -Path <mounted-image-path> -Name <full-capability-name>

Frequently Asked Questions

How do I find the exact PowerShell name for a Windows optional feature?

Run Get-WindowsOptionalFeature -Online for the running system, or use -Path <mounted-image-path> for an offline image. You can narrow the output with a wildcard such as -FeatureName *Hyper-V*, then copy the complete returned feature name.

What is the difference between an optional feature and a capability?

They are separate servicing targets with different inventories and cmdlets. Use Get-WindowsOptionalFeature and Enable-WindowsOptionalFeature or Disable-WindowsOptionalFeature for optional features. Use Get-WindowsCapability and Add-WindowsCapability for capabilities.

Should I use -Online or -Path?

Use -Online when inspecting or changing the Windows installation that is currently running. Use -Path when the target is a mounted offline image. Keep the same target form for discovery, change, and verification.

Why does a capability install need Windows Update or WSUS?

When -Source is omitted, the Windows Update client obtains the required package. The target therefore needs an active Internet connection or an active connection to the local WSUS server, subject to policy. An explicit source can be supplied instead.

What does -LimitAccess do?

With a specified source, -LimitAccess prevents Add-WindowsCapability from querying Windows Update for source packages. Use it when local-source servicing is required, and make sure the source contains files compatible with the target image.

Does disabling a feature remove its files?

No. Disable-WindowsOptionalFeature changes the active state while leaving the payload in the image. Add -Remove only when you intentionally want to remove the files; the manifest remains, but restoring the feature later requires an appropriate remote source.

How can I tell whether I need to restart?

Run the matching discovery cmdlet after the change and inspect the returned state and restart indication. Save work and restart during an appropriate maintenance window when the result says a restart may be required, then query the target again.

The Bottom Line

Start elevated, identify whether you are managing an optional feature or a capability, and query the exact target before changing it. Use -Online for the running OS and -Path for a mounted image; use -All, -Source, -LimitAccess, and -Remove only when their specific effects match your plan. Verify the post-change state and restart guidance every time. PowerShell is not the only Windows servicing interface, but it is the clearest way to make names, dependencies, targets, and package sources explicit.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.