The latest updates to WSL bring new enterprise security features, new improvements to WSL distros, and the announcement that RedHat is officially becoming a WSL distro!
Check out the table of contents in this post for a quick overview of all the announcements!
Red Hat is becoming an official WSL distro
Although you can run any Linux distro in WSL, being an official distro makes it easier for WSL users to install and discover it with actions like wsl --list --online
and wsl --install
. We’re excited to announce that Red Hat will soon be delivering a Red Hat Enterprise Linux WSL distro image in the coming months, and it will be shipped with the new tar based WSL distro architecture (which you can learn more about below). Thank you to the Red Hat team as their feedback has been invaluable as we built out this new architecture, and we’re looking forwards to the release!
“Developers have their preferred platforms for developing applications for multiple operating systems, and WSL is an important platform for many of them. Red Hat is committed to driving greater choice and flexibility for developers, which is why we’re working closely with the Microsoft team to bring Red Hat Enterprise Linux, the largest commercially available open source Linux distribution, to all WSL users.”
-Ron Pacheco, senior director, Red Hat Enterprise Linux Ecosystem, Red Hat
New tar based WSL distro architecture
We are releasing a new way to make WSL distros, with a new architecture that backs how WSL distros are packaged and installed. Up until now, you could make a WSL distro by either creating an appx package and distributing it via the Microsoft Store, or by importing a .tar file with wsl –import
. We wanted to improve this by making it possible to create a WSL distro without needing to write Windows code, and for users to more easily install their distros from a file or network share which is common in enterprise scenarios.
How will it work?
When using the prior appx based architecture, you would bring a .tar file and package that inside of a .appxbundle. You would write code on Windows to do user setup and creation, and then distribute via the Microsoft Store.
With the tar based architecture, you can start with the same .tar file (which can be an exported Linux container!) and just edit it to add details to make it a WSL distro. Specifically, you will need to add a /etc/wsl-distribution.conf
file and put in content like this:
[oobe]
defaultName = myDistro
command = /bin/my-distro -welcome
[shortcut]
Icon = /path/to/myicon.ico
These options will describe key distro attributes, like the name of the distro, its icon in Windows, and its out of box experience (OOBE) which is what happens when you run WSL for the first time. You’ll notice that the oobe_command
option points to a file which is a Linux executable, meaning you can set up your full experience just in Linux if you wish. As well since this is WSL, you could even run Windows executables for your out of box experiences! You could then rename this tar file to a .wsl
file or .tar.wsl
and then distribute it personally, or integrate it with wsl --install
.
You can learn more about the tar based architecture here at our docs.
What benefits will end users for WSL get?
This new architecture will add some new requested features for WSL users as well. Specifically, you’ll be able to:
- More easily automate WSL distro set up as an end user by being able to run commands before user creation and set up
- Get clearer error messages (this will be thanks to consolidations in the architecture for where errors get shown)
- Set the WSL distro name and install location with
wsl --install
options--name
and--location
(Now you can install straight to your other hard drives!) - More potential improvements in the future!
I have more questions!
And here is a quick Q&A for other questions around these changes:
- Will the appx based architecture still be supported?
- Yes, we have no immediate plans to deprecate this architecture and it is still supported!
- We will aim to make the default experience for existing and future distros to be on the new tar based architecture. So the goal is when a new user installs a WSL distro, they get the new tar based architecture.
- Do we plan to force migrate existing appx users to the new architecture?
- No, you can still use your existing distros and will not be forced to migrate.
- Will there be an upgrade path to the new distribution?
- Right now we aren’t planning to add that, as most of the improvements are focused on distribution and install. As a user if you wanted to upgrade you would do so by installing a new distribution.
New WSL zero trust feature updates: Intune integration and Entra ID integration
WSL has 2 new feature updates to enhance enterprise security with improved integrations in Intune and Entra ID!
The first feature is Intune device compliance integration with WSL is now generally available! This feature provides IT administrators the ability to enforce selective WSL distribution and version usage in their enterprise with conditional access. This enhances organizations’ security posture by enabling IT administrators to gain greater visibility into Linux distributions and versions running on managed Windows devices. WSL compliance status is now included when evaluating overall compliance of a Windows device that has both Windows and WSL compliance settings configured. In addition, users are presented with the familiar guided noncompliance remediation experience in Company Portal when noncompliant WSL instances are detected. You can learn more about how to get started with this feature at the Intune docs.
The second feature is that Microsoft Entra ID integration with WSL is now available for private preview! It provides a zero-trust experience while accessing protected enterprise resources from within a WSL distribution. It does this by adding better security around passing Entra tokens (so they don’t get passed via networking packets), and automatic connection for Linux processes to use the underlying Windows authentication. Please see this link to sign up for the private preview today and stay tuned for more updates on this feature!
WSL continues to be a highly integrated product with Windows, which works great with other Microsoft experiences. We recommend checking out the Microsoft Dev Box blog post as well to see their latest updates!
WSL has a new getting started experience
One piece of feedback that we’ve heard from new users who are using Linux for the first time in WSL is that they would want to know how to use it and what features are available. We’re aiming to address this concern with a new getting started experience in WSL. Now when a user installs and runs their first WSL distribution, they will see their distro install terminal window, as well as a window explaining what WSL is and its key features!
Each navigation item gives a short explanation of the feature, and deeper links to the docs for users to learn more. We’re hoping to hear your feedback on the content and this experience, and aim to keep improving it in the future! You can try this out by installing the latest WSL preview release 2.4.4 and then running the ‘WSL Settings’ app and clicking the ‘Getting Started’ experience.
Feedback and questions
As always we’re grateful for the awesome WSL community, and want to hear about your feedback and questions. Please check out the links below to connect with us, and happy coding!
- For any technical issues, file them at the microsoft/wsl GitHub repo
- See our docs at aka.ms/wsldocs to learn more about using WSL
- Ask questions on X / Twitter @craigaloewen
Happy coding!
Which minimal version of WSL is required for this features?
Which feature? They all have somewhat different requirements, I’d just recommend going onto the latest WSL release!
WSL(1) does not have fully compatible mmap. This breaks libdbm, broken libdbm breaks rpm packaging.
Therefore all RPM based distros(except Suse) dot not work on WSL1. This is a bummer in companies where HyperV is disabled on laptops.
PS: Suse has “patched” librpm and is not affected by this problem.