Posted in

WSL Containers Hit GA: Intune Now Gates the Images

by ailona•

WSL containers is generally available. Microsoft announced it on September 29, 2026, and the way to get it is the command your fleet already knows: run wsl --update, or download the latest release from GitHub. That matters more than it sounds, because the documented install path is user-reachable. The enterprise question is not whether your developers can run Linux containers on Windows. It is what happens when they do.

Most of the announcement is developer material. wslc.exe builds, runs and deploys Linux containers on Windows, with a container.exe alias for the familiar command names, plus an API for running containers programmatically from native Windows apps. Since the public preview Microsoft added wslc container restart, wslc container cp, wslc system info, wslc network connect and disconnect, arbitrary network driver options on wslc network create, wslc events for streaming container activity, container health checks, --stop-timeout (including -1), --mount on create and run, and a configurable storage path for the default wslc session. Compose support has no date: the post calls it the top feature request and says the aim is for wsl compose up to work with your existing compose.yaml files, unchanged.

Two Intune settings are the enterprise gate

The enterprise section is one paragraph and a short list, and it comes down to two settings. One sentence carries the weight: “Microsoft Intune has also added controls to enable or disable WSL container and restrict image pulls to approved registries.” Then the settings get names.

  • Allow WSL containers access: “Control access to the entire WSL containers feature.”
  • WSL containers registry allow list: “With container registry allow lists, administrators can define approved registries and help ensure developers only pull container images from that list, that meet organizational security and compliance requirements.”

So the control is a switch plus a list: one setting decides whether the feature exists on the device, the other decides which registries it will talk to. The announcement does not say what an empty allow list does, whether the list is enforced at the pull, at the client, or somewhere else, or whether it is deny-by-default. Test that on a pilot device before you write it into a policy description, because “administrators can define approved registries” is the only claim Microsoft makes.

Defender coverage arrived through the plugin that is already deployed rather than a new one: “MDE’s existing plugin for WSL has been augmented to also include support for containers.” MDE surfaces process, file and network activity from WSL containers and connects it back to the Windows host, so container activity lands in the investigation flow you already run. No version requirement is stated.

The page an admin would open has not been updated

Here is what you need to know before you go looking for those settings. The Learn page for WSL policy, “Intune settings for WSL”, was last updated on 2025-08-04. As of today it lists twelve settings and contains zero occurrences of the word “container”. Neither setting name above appears on it. The enterprise page the announcement links for setup guidance is older still, last updated 2024-08-16, and it also never mentions containers.

The two setting names in this post therefore come from the announcement, not from the documentation. The path Learn does document for WSL settings is Microsoft Intune admin center > Devices > Configuration Profiles > Create > New Policy > Windows 10 and later > Settings catalog, then search for “Windows Subsystem for Linux”. That is where the older WSL settings live today. Whether the two container settings are already exposed there is a one-minute check in a tenant and not something the docs currently answer.

Worth pairing the new switch with the one you probably already have. Learn describes Allow the Windows Subsystem For Linux as a policy that, when set to disabled, “disables access to the Windows Subsystem For Linux for all users on the machine”. That one governs WSL as a whole, while Allow WSL containers access is described as controlling “the entire WSL containers feature”. Separate scopes: turning WSL off is not the same decision as turning containers off.

What changed under the hood

Three sentences of architecture, because the obvious question is whether this is just WSL with a new command. It is not. Client processes still call into wslservice.exe, the privileged service that creates the virtual machine through HCS, but per the architecture post “wslservice.exe does not retain ownership of the virtual machine”. It spawns a child process, wslcsession.exe, which runs on behalf of the calling user and performs the session operations (creating containers, mounting directories, binding networking ports) in a less privileged process. Microsoft frames that split as a security improvement, not a new exposure: sessions are isolated from each other by process, and each one keeps its own storage VHD for images, containers, networks and volumes, stored under %AppData%\Local\wslc\sessions when you use wslc.exe.

What to decide this week

  • Decide whether the feature is on, off, or on with a registry allow list. Deciding nothing means no policy of yours states an answer and no image control is configured.
  • Test the allow list on a pilot device before you rely on it: does an empty list block pulls, and does a pull from an unlisted registry fail in a way your developers will understand?
  • Find out who already has it. wsl --update is the documented way to get GA, and nothing in either source says fleet servicing delivers it on its own, so ask rather than assume.
  • Re-check the Learn page before you publish internal guidance, since the settings you are documenting are the ones Microsoft has not documented yet.
  • If containers are staying off, make sure off is a setting a policy sets, not an assumption someone made about a default.

That is the whole decision surface: one switch, one allow list, and a documentation page that has not caught up. It is small, and it is a week of work at most. The feature shipped GA on September 29 and the install path is a command your developers already have.

Sources