Skip to content
WindowsDeep Dive Published Updated 7 min readViews unavailable

Windows Features on Demand: Service Capabilities from Matching Sources

Inventory and service Windows capabilities with DISM, matching Features on Demand media to the image and tracing source policy before changing endpoints.

Windows Features on Demand (FoD) are optional capability packages that can be added to a running installation or an offline image when a workload needs them. Examples include language resources, accessibility components, OpenSSH, RSAT, and developer features. A capability is not simply a checkbox stored locally: Windows may need to acquire payload files from Windows Update, a configured policy source, or matching offline media.

Many “Add-WindowsCapability failed” incidents are source-selection or version-matching problems. A Windows client can be pointed at a WSUS policy that does not host the required optional content, a local FoD ISO can be from a different release, or a hand-copied CAB folder can lack metadata needed for satellite packages. Diagnose the image identity and source precedence before repeatedly retrying DISM or resetting update policy.

Inventory capability names and state

Capability names are versioned identities, not display labels. Query the target image to obtain the exact names and states before writing deployment automation. For a running system:

Get-WindowsCapability -Online |
    Where-Object Name -like 'OpenSSH.*' |
    Select-Object Name, State

For an offline image, use Get-WindowsCapability -Path <mount-path> or DISM’s /Image:<path> /Get-Capabilities. The installed/available list is image-specific; do not copy a capability identifier from a blog post or different OS release without checking the target. Capture the image version, architecture, language configuration, and servicing level with the capability inventory.

Windows has monolithic FoDs and FoDs with satellite packages. Satellite content can include language and architecture resources as separate packages; /Add-Capability resolves the set relevant to the image. Microsoft recommends using /Add-Capability rather than /Add-Package for FoDs so the complete dependency and satellite content is installed correctly. The Languages and Optional Features ISO for the matching Windows release can serve as an offline source. A custom repository for satellite FoDs must include DISM-generated metadata; copying CAB files into a folder does not create a valid repository.

Understand where DISM looks for payloads

For an online image, DISM checks explicitly supplied /Source locations first. If needed, it consults configured Group Policy source locations. If the payload is still unavailable and /LimitAccess is not specified, it may query Windows Update. LimitAccess prevents that Windows Update/WSUS lookup. This precedence explains why the same capability command may succeed on an unmanaged machine but fail on a corporate endpoint.

Inspect applicable “Specify settings for optional component installation and component repair” policy and Windows Update source policy before changing them. Microsoft documents version-specific limitations: starting with Windows 10 version 1709, WSUS cannot locally host FoD payloads. Current optional-content guidance also describes how source policy affects clients that use WSUS for feature or quality updates. Do not broadly bypass the organization’s update service to make one optional component install; use an approved alternate source or policy exception.

For a controlled online install using a local, matching source, the PowerShell form is:

$name = 'OpenSSH.Client~~~~0.0.1.0'
$source = 'E:\'
$result = Add-WindowsCapability -Online -Name $name -Source $source -LimitAccess
$result | Select-Object Online, RestartNeeded

The example is specifically for a tested source containing that capability; if the package is already installed, the command can report success without proving that the source was valid. Check the returned state using Get-WindowsCapability, inspect DISM logs, and verify the feature’s runtime function. For online Windows Update acquisition, omit -Source and -LimitAccess only when that network path is approved and available.

Service offline images predictably

For image engineering, identify the Windows release and mount the correct install image. Use a matching Languages and Optional Features ISO or a custom repository generated for the exact capability set. Example DISM operations against a mounted image are:

dism /Image:C:\mount\Windows /Get-Capabilities
dism /Image:C:\mount\Windows /Add-Capability /CapabilityName:OpenSSH.Client~~~~0.0.1.0 /Source:E:\ /LimitAccess
dism /Image:C:\mount\Windows /Get-CapabilityInfo /CapabilityName:OpenSSH.Client~~~~0.0.1.0

The source path must match the image and contain all required payloads. Keep servicing logs and record which ISO or repository revision was used. Use DISM /Export-Source when creating a custom FoD repository instead of manually copying selected package files. After servicing, commit and deploy the image through the normal servicing pipeline, then verify the capability on a clean test device.

For image pipelines, stage source media in a controlled repository with a manifest that records the Windows release, architecture, language pack set, media hash, and capability names exported into the repository. Restrict writes to the repository and publish a new immutable revision when media changes. This makes it possible to rebuild an image later and explain exactly which payload was added. Do not assume that a capability source for the base OS release remains valid after a feature update; maintain a tested source per supported image baseline.

When servicing a mounted image, ensure that the mount is writable, the scratch directory has local free space, and image cleanup/unmount is part of the pipeline’s failure handling. A failed command can leave the image mount in a servicing state. Capture the DISM log and return code before cleanup, then use the documented image servicing workflow to commit or discard the mount. Avoid deleting mount directories or source files while DISM still owns the image.

Do not remove a capability solely because it is absent from a baseline list. Other capabilities can depend on shared packages, and removing a dependency may be rejected or break a workload. Query dependency relationships and test removal in a clone of the image. Record the intended installed state in an image manifest or desired-state system so new releases do not silently drift.

Troubleshoot source and servicing failures

When installation fails, preserve the exact capability name, command line, exit/result code, DISM log, Windows Update client behavior, policy source, and image version. Look for whether DISM found a source, failed to download, rejected a package identity, or failed during package application. A generic “source files could not be found” message is a prompt to check source precedence and release alignment, not proof of component-store corruption.

Validate connectivity and authorization to the approved file source from the machine’s execution context. A mapped drive visible in an interactive session might not exist for a management service; use a path and identity supported by the deployment tool. If content originates from a remote share, confirm access and preserve the package provenance. Avoid mixing media across Windows releases or architectures.

For WSUS-managed endpoints, review the applicable policy and current Microsoft’s FoD/language-pack guidance for that Windows release. The effective path can vary based on whether updates are source-controlled by policy. If the policy requires an exception, use a documented, time-bounded change and restore the intended update source after installation. Do not reset all Windows Update components as a generic response to a capability-source issue.

Separate servicing availability from feature policy. An organization can intentionally keep a capability unavailable even when its payload can be downloaded, while another fleet may permit the component but lack a viable content source. Ask the image-management and update-policy owners which state is intended, then check whether the capability is blocked, absent, or simply unresolved. This prevents a remediation from installing developer tools, language resources, or remote-management components outside the approved device baseline.

Operational validation and cleanup

After adding a capability, query its state, check whether a restart is required, and exercise the actual feature. For OpenSSH Client, verify that the expected client component is available; for RSAT, confirm the relevant administrative tools load; for language resources, test the intended user experience and fallback language. A State: Installed result verifies servicing state, not every downstream dependency.

  1. Record the Windows edition/build, architecture, language, capability identity, and current state.
  2. Determine the effective source order and whether WSUS/Windows Update access is permitted.
  3. Use release-matched media or an approved online source; never hand-build a satellite repository.
  4. Apply the capability to a test device/image and retain DISM logs plus result codes.
  5. Verify installed state, restart requirements, and the end-user feature behavior.
  6. Reconcile source-policy exceptions and document image provenance before production rollout.

FoD servicing is predictable when the capability identity and payload source match the image. Keeping those facts explicit prevents repeated retries, accidental source bypass, and brittle image builds.

Related:

Sources:

Comments