Hey sysadmins! Do you want to automate more, but get bogged down in the time and complexity of bulletproof PowerShell scripting? After a period of skepticism and reading a lot of negative opinions on Copilot, I finally decided to try it out for myself. I discovered that you can’t simply allow it to go off on its own. However, the positives greatly outweigh the negatives. Even though my title seems “click-baity”, I genuinely believe that you can supercharge Powershell with Github Copilot. I will demonstrate my experience in this article.
The screenshots in this article come from a Visual Studio Code environment with the GitHub Copilot extension. Both of these are free. However, GitHub Copilot itself is not. The webpage for Copilot claims that it boost development by 55%. For folks that primarily write code for a living, I have no reason to doubt that claim. However, for the typical sysadmin who scripts sometimes, I predict a much higher improvement. You won’t spend as much time researching things, for one. For another, Copilot will make suggestions that spark insights. Even when it does neither of those things, it frequently suggests code more or less as you would have written it anyway. Give the trial a spin, and I doubt you’ll have difficulty getting your employer to provide the $20 for a monthly subscription.
Example: PowerShell Scripting with Github Copilot
I was working on a script that needed to know when Windows Update was scheduled to run so that I could avoid colliding with another automation routine. I did the normal things that I do when I script things like this: I researched what I needed to know and built up a general plan of how to get it.
Warning: The script as shown was early, raw, and required multiple adjustments to put into production. For one thing, it does not account for the difference in day numbering between System.DateTime and the Windows Update registry keys. It attempts to do illegal things like set read-only fields. Read this article for the Copilot parts. Do not use this code in production. It will fail.
Let’s start with a screenshot:
At this point, everything outside the screenshot was basic boilerplate. I set up the environment and opened the process{} block. I had not written any comments or other variables. I knew that I wanted to offset from the Windows Update schedule, and you know that because I told you in the opening paragraph, but I had not suggested anything to Copilot. It guessed where I was headed, and it happened to guess correctly.
What it could not know, and what I did not tell you, is that I planned to have the other automation tool run at precisely the same time as the Windows Update schedule. That process takes a couple of seconds and immediately reboots. Windows Update has a random offset from its scheduled time and will recover from a missed timeslot. This allowed me to take advantage of a single, pre-ordained downtime window to handle both reboots. Note: these systems all have Windows Update set to run in whatever week the WSUS server approves their patches, so they have weekly downtime windows with a general expectation of monthly reboots. That’s why this plan works.
So, where Copilot suggested waiting one day (which would have fit the predictable criteria), I needed it to go out to the next week. I changed that. After some thought, I realized that if the automated process encountered a system that had a pending reboot, it would fail. So, I added in some other code to figure that out. I wanted it to use that to wait another week before running the automated process:
Even before I confirmed the variable that I was querying, Copilot figured out where I was headed. Again, it got the number of days wrong. But, it had the right idea.
A Note on My Github Copilot Experience
The above interaction occurred after I’d had a few weeks to get acquainted with Copilot. That wasn’t even close to the most impressive thing that Copilot did. It was just when I first decided to share. I generally don’t like plugging things that cost money (especially when I don’t get a cut), but I genuinely believe this tool will help a lot of sysadmins in their day-to-day duties.
Do Not Allow Github Copilot to Work Unsupervised
Sometimes, you will think that Copilot is clairvoyant. Other times, you will think that it’s just throwing out random characters to look busy. Learn quickly that you must always review everything that Copilot does. Even code that looks good at a glance might turn out nonsensical. Sometimes, it’s things that it could not have known, like the number of days that I wanted added above (although you’d think that “SkipWeek” was a clue, but AI is still progressing).
Copilot will not even try to stop you from writing bad code. It didn’t even pause when I tried to assign values to read-only fields.
Sometimes, it makes really obviously bad decisions:
Honestly, the worst are the ones that look right. Be on guard for those.
Don’t Neglect Copilot Chat!
I have had ample opportunities to use Copilot Chat, but I always forget. However, a colleague has used AI chat to great effect in scripting. Look at the position of the mouse in the following screenshot for where to access Github Copilot Chat in Visual Studio Code:
Most importantly: remember that the word Chat is not just a marketing or branding thing. I have watched a lot of seasoned admins use Copilot in Bing and then complain that it’s not better than regular search. However, they use it the way we have always used search: they type something, get results they don’t want, then refine the same query, and repeat until they get what they want or give up in frustration. Do not do that in any chat-based AI, including Github Copilot Chat. Use it as a chat. It “remembers” what you have already talked about. If it misses on the first try, don’t type the same thing differently. Tell it where it went wrong.
Assuming that I ever remember to do that myself (it would have saved me a lot of headaches on the displayed script), I will screenshot it and update this post.
Try Out Github Copilot
In the meantime, sign up for the trial and see if you get the same kind of results from Github Copilot that I did. I hope it boosts your scripting and automation tasks!
Software licensing is a special form of awful that nearly rises to the frustration level of dealing with printers. Windows Server licensing pushes it even further. Virtual machine licensing in Windows Server takes it to an extreme. This topic has a lot to unpack, but I want to scope specifically down to the subtopic of the two virtual machine licenses with Windows Server Standard. That confuses more people than any other part.
For the legalese, Microsoft has that. Remember that if you end up in court defending yourself against a software piracy charge or the like, Microsoft attorneys will reference the documents on that site and any particular agreements made by you or your organization only. They will not accept anything posted on any blog or forum, not even if the post came from a Microsoft employee. Confirm anything that you see here, or anywhere else, with a trained licensing expert. Your retailer almost certainly employs one. If you purchase open licenses or something similar from Microsoft, they may assist you. If you decide to go it alone, make a mistake, and get audited, then you can face six figure fines per incident. I cannot tell you precisely what “per incident” means, but you should expect to take a hit on every single improperly licensed installation of an operating system. Licensing mishaps have sunk businesses, and you should never believe that you are too large or too small to escape notice.
Which Hypervisor?
As one of the few times in the technology world, the question of “which hypervisor does this apply to?” has a single, unambiguous answer: all of them. You mostly hear about it in terms of Hyper-V, but this licensing specifically covers virtualized instances of Windows Server. It applies under ESXi, XenServer, KMS, VirtualBox, whatever, just as much as it applies under Hyper-V.
Customer may assign additional Standard edition Licenses to the Licensed Server equal to the number specified in 2 above and use the server software in two additional OSEs on the Licensed Server.
Let’s focus on “Standard edition permits use of the server software in two OSEs on the Licensed Server.” I have real problems with the use of the word “server” in “Licensed Server”. “Server” refers to a function, not an object, and most properly means a piece of software. In this case, it means a physical host. I understand that in the common techie vernacular, “server” often means a piece of hardware, but it shouldn’t. “Server-class hardware” would fit better. A hunk of computer with no operating system won’t serve anything; the software makes it a server. Anyway, that’s a rant for another day. Just understand that “Licensed Server” here means the physical system. The linked glossary item doesn’t even make that perfectly clear, but this part helps: “For purposes of this definition, a hardware partition or blade is considered to be a separate Server.”
The next bullet expands on that first one a bit. You can run a total of three instances of Windows Server when one of the three is installed to the physical hardware and doesn’t do anything except host and maintain virtual machines. So, you can install Windows Server to the hardware, then install the Hyper-V role, then create two virtual machines with Windows Server Standard Edition and run them all under the same license. You can also install backup software and monitoring agents in the physical instance. You cannot start installing other roles, like IIS, in the physical instance. You also cannot use the always-available components of Windows Server for purposes other than hosting and maintaining its contained virtual machines. A big example of this is the file and print sharing components. This gets sticky for a lot of organizations on the grounds of “what if I want to have a file share on the host that only its virtual machines use?” If you think that you can make that argument to a judge, and you’re willing to pay whatever fines if they disagree, then I guess you find the risk more acceptable than I do. I would use file sharing in one of the two guests and bypass the problem entirely.
How Does it Work if I Don’t Use Hyper-V?
When you use a different hypervisor, then that second bullet simply does not apply to you. Your “licensed server” can run two virtual machines with Windows Server Standard Edition.
What if I Need Three, or Four, or XX Virtual Machines?
Previous versions of the license agreement did not clearly spell this out, but notice the third bullet point in the referenced version: “Customer may assign additional Standard edition Licenses…” Once you hit your legal limit of instances per license, you buy enough licenses to cover the physical host again. That gives you two more licensed instances of Windows Server Standard Edition. You can keep “stacking” until you hit what you need. However, at some point, the unlimited instance allowance of Windows Server Datacenter Edition becomes more economical, even if you won’t use its advanced storage features. That line usually falls somewhere around the 10-12 instance range. Check with your reseller on pricing.
What About LiveMigration, vMotion, etc.?
The virtual machines can migrate; the license cannot. There are some terms in some licenses that talk about portability, but those are intended for disaster recovery and business continuity. Under those conditions, you can move an instance to another physical machine once, but not again for 90 days, among other restrictions. For typical LiveMigration and vMotion and comparable operations, you must license each physical host individually for the number of virtual machines it can expect to operate.
What about Linux Virtual Machines?
Remember that all this licensing talk applies to instances. You do not pay Microsoft per virtual machine. If you run a non-Microsoft operating system instance, then you must follow the licensing rules of that vendor. In most cases, when you’re talking about Linux, that effectively means “don’t worry about it.” However, all mainstream operating systems have some sort of license, so make sure you understand the ones that apply to you. For instance, even though Apple’s operating system is essentially a customized remix of BSD UNIX (which runs just fine on Hyper-V), Apple will not license it to run on any non-Apple hardware. You can technically run OSX under Hyper-V, but not legally.
What About Windows Desktop Virtual Machines?
This question pops up a lot: can I run Windows 10/11 on Hyper-V using the virtual instance OSE terms? Again, a non-ambiguous answer: NO. You must license the hardware for the number of Windows 10/11 instances that it runs. Also, if you intend to allow people to connect remotely (like in a VDI/RDS situation), then that requires even more licenses. Absolutely talk to your software license provider in those cases.
If you meant running Windows 10/11 inside a Client Hyper-V instance on Windows 10/11, then the same rule applies. You need one license per instance. Of course, some people just use evaluation licenses in those guests. Is that annoying? Yes. Does it work? Also yes. As long as you are not using the installed instance in a way that violates the evaluation license terms, then go for it. As stated previously, beware the courts and judges and fees any time you push the boundaries.
What About License Keys?
Keys are quite a bit different from licenses. For open licenses, you can use the MAK or KMS. For retail, you can use the same key in all two/three of your licensed instances, although you might have to contact the licensing center. I can’t answer every possible question on this. Yes, people have run into trouble with their keys. You have a legal right, but you might run into technical trouble.
Gatekeeping is one of the worst ills of the technology world. Someone with no authority finds an arbitrary reason to tell you that you’re not a “real” something, or they use it to try to shame you. For reasons that I certainly can’t explain, many people in tech love jumping on the bandwagon and gatekeeping whenever possible. The latest “big thing” is dark mode. Not only is it the foundation for enormous amounts of shaming and gatekeeping, it’s also been a great excuse for software houses to avoid real problems. Software buggy? Divert resources to building dark mode! Customers unhappy with software behavior? Divert resources to building dark mode! And so on. Well, if you don’t like dark mode, that’s OK. If they don’t like that you don’t like dark mode, that’s OK too. If you think that developers should spend time on actual problems instead of focusing on dark mode, that’s definitely OK.
(Somewhat) jokingly, I have long said that a certain company famous for virtualization has set a goal of bankrupting all its customers as its victory condition. That company was recently purchased (again), and the new owners promptly set about trying to prove me correct with massive price increases. As part of their campaign to do anything except set reasonable pricing, they have begun telling customers that Hyper-V is dead. At best, they’re wrong. At worst, they’re lying. Hyper-V is not dead. Hyper-V is not dying. Hyper-V is an integral part of Microsoft’s product lineup.
As with many of my articles, this one serves as a public “note to self” for a problem that I run into often enough to need to skip a lot of searching but not often enough to remember how to fix. I have set up a new Ubuntu server system and I want to manipulate files from my desktop using WinSCP. This works almost automatically if you enter your password each time or you don’t work with files that require sudo permissions. Of course, I want both. I guess you came here for the same reason. Follow the steps in this article to configure Ubuntu for public key WinSCP access. Because WinSCP uses PuTTY-formatted key files, I added a section on configuring PuTTY for public key access as well.
Scenario: You connect your Windows or Hyper-V system to a FiberChannel or iSCSI target device that supports multi-path I/O (MPIO). When you view Disk Management, it shows up twice (or more). You can bring one online, but any others show “Offline (The disk is offline because it has a redundant path with another device)”.
The basic issue is that multipath I/O needs to be configured at the Windows level. If you have specialized software from your hardware vendor, use that first. They will often enable and configure the necessary Windows components for you.
Windows Subsystem for Linux (WSL) brings the convenience of native Linux functionality to Windows Server. You have access to a fully functional Linux kernel in the distribution of your choice embedded right where you have instant access without needing to rely on a heavy virtualization layer or a thick emulator. This article focuses on WSL in Windows Server 2022 as the current version, but includes notes for WSL on Windows Server 2019.
Overall, Microsoft maintains decent documentation on WSL, which you can always access at aka.ms/wsl. However, their directions for installing distributions from APPX on Windows Server have some clarity problems and may not work for you. If you want, you can try them. The steps shown in this article have all been verified functional as of the date of publication/most recent update.
Install WSL Using DISM
You can install WSL on Windows Server using the command-line DISM utility in two ways. The first uses an elevated command line and the dism.exe program. Remember that feature names in DISM are case sensitive. If you are on Windows Server 2019 or you do not wish to use WSLv2 on Windows Server 2022, you can omit the references to VirtualMachinePlatform. Note that because Windows Server 2022 always defaults to version 2 for WSL, attempting to install a distribution without this component will usually result in error code 0x8004032d. The sections in this article on installing distributions show how to set the default version to 1.
You can use Install-WindowsFeature or its alias of Add-WindowsFeature, however, it only works for the base WSL package. If you have Windows Server 2022 and want to use WSLv2, then you will still need to add the “VirtualMachinePlatform” package as shown above.
If the method you use does not prompt for reboot, you can initiate one with Restart-Computer. in PowerShell or shutdown /r /t 0 at any prompt. Afterward, you have the WSL infrastructure but no distributions. Skip the next installation section for instructions.
Not Recommended: Install WSL Using Pre-placed Stub
With some caveats, you can sometimes install Windows Subsystem for Linux on Windows Server 2022 the same way that you can on Windows 10 or Windows 11. Just open an elevated command-line and run:
wsl --install --no-distribution
This may not notify you afterward, but it requires a reboot. You can initiate from the command line with shutdown /r /t 0.
When it works, it does so because Windows Server 2022, like the desktop editions of Windows with more recent updates, includes just enough of the Windows Subsystem for Linux to operate the installer. Once this completes, you might have the framework necessary to run Linux distributions. However, it may set the system to default to version 2 but miss a vital component that allows for anything beyond version 1, and it does not include any distributions. Instructions for adding distributions appear after the remaining installation sections. Sometimes, it doesn’t even actually enable the feature! To save time troubleshooting any of these problems, use the DISM steps in the next section.
Not Recommended: Install WSL Using Server Manager
You can also use Server Manager to install the base component of WSL. This will not install the “VirtualMachinePlatform” component, so you can’t use WSLv2. That component does not appear anywhere in the Server Manager UI, so you’ll need to follow the DISM steps. This does not apply on Windows Server 2022 or when you don’t want to use WSLv2 on Windows Server 2022.
From Server Manager’s start page, use the Add Roles and Features link. Step through the wizard to the Features page and check the option for Windows Subsystem for Linux.
Continue through the wizard. If you check the box for automatic restart, then Windows Server will take care of it. Otherwise, you can restart manually at your convenience.
After the restart, proceed to the next section to learn how to add a Linux distribution.
Acquiring Packaged Linux Distributions for WSL
Microsoft provides multiple distributions ready for use with WSL. On a typical desktop installation of Windows, you would install them directly from the Windows Store. Windows Server does not provide access to the Windows Store. Therefore, you’ll need to download distributions and install them manually.
Before downloading anything, decide where you want to house your Linux distributions. You can use something simple, like C:\WSL. Create the directory with default options. You can do this in Windows Explorer or at a command line:
mkdir C:\WSL
You can download from Microsoft’s site. You should not use a production server for general Internet access. Ideally, a server won’t even have an installed Internet browser. Instead, access the site from a desktop installation of Windows and use a secured channel to transfer it to your server environment. Rather than repeat everything from the Microsoft site here, you can just follow this link: https://learn.microsoft.com/en-us/windows/wsl/install-manual#downloading-distributions.
A couple of notes on what you’ll find:
Notice that each of the links includes an aka.ms shortcut URL, such as https://aka.ms/wslubuntu for the current Ubuntu distribution.
Below the links, you can find examples for using PowerShell and the command-line utility cURL to download.
The site delivers distributions as appx (package application) files, but as mentioned during the intro of this article, those directions may not work. The next section shows how to extract them for use.
Quick, Foolproof WSL Distribution Setup Directions
This section contains the shortest possible directions. If you have already tried to follow the Microsoft instructions and a bunch of Internet solutions and learned a lot but still failed, then you will probably only need this section. It makes a lot of assumptions about your knowledge. If you find these instructions too simplistic, skip past and use the longer versions afterward.
Download the major .appx file for the distribution
If you used a browser, remember to unblock the file (Unblock-File)
Rename the .appx to .zip. If it’s an .appxbundle file, then you’ll still rename to .zip.
Extract the files from that zip
If the extracted files have more appx files for the distribution, the source was probably an appxbundle. Determine which of the contained appx files you want to use for your distribution, rename that to zip, and extract its files.
Optional: Register that appx with Add-AppxPackage (this will not work on any core mode installation and does not work and is not necessary on any edition of Windows Server 2019)
Rename the appx that you just registered to .zip
Extract the files from that zip. You specifically need the distribution executable (e.g., ubuntu.exe) and the install.tar.gz
On Windows Server 2022, you may have instances where you can’t or don’t want to use WSLv2, but WSL wants to run v2 by default. Switch to version 1 with wsl --set-default-version 1. If you expected WSLv2 to work, make sure that you installed the “VirtualMachinePlatform” optional feature (discussed in the DISM section near the beginning of the article).
Run the distro’s executable
Delete the extracted files except for the distro executable, the rootfs folder (if present), and the temp folder (if present)
Going forward, you can just run that same executable to start this distribution. You can add its location to the path to initiate it from anywhere. After it has executed once, it will also appear as one of the options in wsl --list (Windows Server 2022+) or wslconfig /l (Windows Server 2019).
Quick Walkthrough: Linux Distro Installation for WSL on Windows Server 2019
These steps show the exact process to start an installation of the current Ubuntu distribution in WSL on Windows Server 2019 fresh install, Standard edition, core mode, updated via online Windows Update to available patches on November 24, 2023. They will also work on WS2019 with the desktop experience.
If not already in PowerShell, start PowerShell from an elevated command prompt (powershell.exe)
This will start an install process, then ask you to set up the credentials to use in this distribution.
Because Windows Server 2019 cannot use WSL2, only a subset of the instructions that you find for wsl.exe will work. Use wsl --help to show what you can use. For the other functions, such as removing a distribution, use wslconfig. wslconfig --help will show its options. For example, to remove the distribution that you just set up, run wslconfig /u Ubuntu. If you do that, you can immediately run the ubuntu.exe again to reinstall it, provided that you left the install files intact.
If you want to clean up your directory tree after installation, the C:\WSL\Ubuntu location mentioned in the walkthrough only needs the ubuntu.exe file, the rootfs folder, and the temp folder. If you delete the temp folder, your next run of the distribution will recreate it. Do not try to remove the rootfs folder as it contains your distribution and has file names that the NTFS tools can’t handle. If you try to remove the folder, it will partially work and complain about something, usually an undeletable aux file. Use wslconfig /u instead. If you’ve already wrecked it and you can’t remove the folder, try going to an elevated command prompt (not PowerShell) and run the following: rd \\.\C:\WSL\Ubuntu\rootfs /s /q.
Quick Walkthrough: Linux Distro Installation for WSL on Windows Server 2022
These steps show the exact process to start an installation of the current Ubuntu distribution in WSL on a Windows Server 2022 fresh install, Standard edition, core mode, updated via online Windows Update to available patches on November 24, 2023. This follows the pattern of the previous section in which you manually retrieve the appx package from the Microsoft site even though you now have the online option to perform this automatically. We chose this technique because, except for the download part, it will work for servers that do not have an Internet connection.
These steps will also work on WS2022 with the desktop experience.
Start an elevated PowerShell session (powershell.exe)
If you prefer to use WSL v1 or must because of a hardware limitation, run the following: wsl --set-default-version 1
.\ubuntu.exe
This will start an install process, then ask you to set up the credentials to use in this distribution.
If you want to clean up your directory tree after installation, the C:\WSL\Ubuntu location mentioned in the walkthrough only needs the ubuntu.exe file, the rootfs folder, the fsserver file, and the temp folder. If you delete the temp folder, your next run of the distribution will recreate it. Do not try to manually remove the rootfs folder as it contains your distribution and has file names that the NTFS tools can’t handle. If you try to remove the folder, it will partially work and basically just wreck the whole thing. Use wsl --unregister instead. If you’ve already wrecked it, try going to an elevated command prompt (not PowerShell) and run the following: rd \\.\C:\WSL\Ubuntu\rootfs /s /q.
Notes for WSL On Windows Server 2022
The above directions used a core mode installation, which varies from the desktop experience in two major ways.
First, the steps will work just fine on the desktop experience, but the core mode lacks several capabilities: No use of wsl --install, wsl --update, or any --online functionality. All these result in a vague Class not registered message. You also can’t install the most recent WSL recent from the Github page, apparently because of the same anonymous missing component.
Second, on desktop experience, you can use Add-AppxPackage on the internal APPX component before renaming it to ZIP at step 11. Example: Add-AppxPackage .\Ubuntu_2204.1.7.0_x64.appx. If you do this and then follow the rest of the directions, the system creates a folder for the APPX package under your user profile (ex: C:\Users\Administrator\AppData\Local\Packages). The rootfs and temp folders for the distribution will appear there. You can then delete everything in the place where you extracted the files (ex: C:\WSL\Ubuntu in the directions above) except for the distribution’s executable (ubuntu.exe in the directions). You can even move the executable anywhere you like.
Installing an APPX WSL Distribution on Windows Server
Here begin the longer instructions for installing a Linux distribution from APPX on Windows Server. This will show the process more in-depth than the quick directions in the preceding two sections and will use Windows Server 2022 with the desktop experience instead of core.
From this point onward, the directions assume that you have installed WSL, created a location to store your distributions, and have acquired at least one APPX-packaged distribution. These steps will use C:\WSL as the root for WSL distributions, so modify them to match what you decided to use.
Preparing Windows Server 2022 to run Linux Distributions
Before you start, consider two things.
First, WSL on Windows Server 2022 always wants to run version 2 distributions. If you didn’t enable the “VirtualMachinePlatform” or your hardware just doesn’t support it, WSL will refuse to install distributions. You can follow the instructions in DISM section at the beginning of the article to enable the missing component.
Alternatively, you can tell WSL to use version 1. At an elevated command prompt, run:
wsl --set-default-version 1
From this point forward, all Linux distributions will install as version 1. It will not impact existing distributions. You can change the default version and the version of an installed distribution at any time.
Second, update WSL. Unfortunately, this does not work on core installations of Windows Server 2022 or any installation of Windows Server 2019. For offline servers, you can get the bits from Github. For online servers, you can update right from the command prompt.
At an elevated command prompt, run:
wsl --update
This will retrieve and install the most current WSL bits. If it fails because the server can’t access the Internet, WSL will still operate your distribution.
Extracting and Installing the Linux APPX
This example shows an openSUSE distribution instead of Ubuntu to shake things up a bit. It downloads as an APPX file, which the article has talked about all along. The Ubuntu distribution in the preceding sections uses a nested delivery technique. If you download that one using a web browser, you’ll get an “appxbundle” file. You rename an APPXBUNDLE to ZIP just like the APPX example shown here, then open that archive to find nested APPX files. Select the one you want (usually by architecture, ex: x64 or ARM), extract it, and use that APPX as the following example shows.
To start, rename the downloaded file so that it has a .ZIP extension instead of .APPX (or .APPXBUNDLE).
Explorer will warn about changing the extension. Click Yes if you get that. You can then double-click the newly renamed ZIP. Inside, you’ll find multiple files, but you only need the application (EXE) and the install.tar.gz files.
If you configured Explorer to show extensions, then can quickly spot the executable by the exe extension. Otherwise, it should distinguish itself by using the name of the Linux distribution. Extract these two files to your desired operating location (ex: C:\WSL).
Now, you can double-click the extracted executable or run it from an elevated command prompt. Be warned that SmartScreen might not like it!
You can click More Info and Run anyway to get past this warning.
The distribution will then perform its installation routine.
When you exit from the session, you will notice that the installer created some supporting files, either in the same location or under your user’s profile.
If using WSLv2, you will have a VHDX file instead of the rootfs folder. The temp folder will automatically recreate when necessary on each run of the distribution. Distributions may create their own files, such as the fsserver item that openSUSE created here. Leave those items and the executable that runs the distribution. You can delete the install.tar.gz file and any other support files that came from the APPX.
Going forward, you can run this executable or use the wsl command to start the distribution.
Adding the Distribution to the Path
The wsl.exe file lives in C:\Windows\System32, so you can invoke it from anywhere. With nothing else specified, doing so will start the default distribution. You can also pass the name of an installed distribution using -d and it will start that one. This is how you would run a command inside your distribution without loading the entire thing (ex wsl -d Ubuntu --ls /). Such usage exceeds the intent of this article, so check the documentation link at the top for more information.
If you’d rather start your distribution by its executable, (ex ubuntu.exe), then you can add its location to your path. Microsoft’s document lists a convoluted way via PowerShell that did not work for me. Instead, use the age old technique at an elevated command prompt (not PowerShell):
PATH = %PATH%;C:\WSL\Ubuntu
Now you can just run ubuntu from any command prompt and it will start up your distro.
Want another cool trick? You can rename the exe and it will continue to work just fine.
ren C:\WSL\Ubuntu\ubuntu.exe my-cool-ubuntu.exe
This does not change the behavior of wsl.exe in any way. You would still invoke this distribution with wsl -d Ubuntu.
Go Forth and Linux on Windows Server
Future articles here on Project Runspace will use WSL for activities such as certificate services. Whatever your purpose, you now have the tools you need to run Windows Subsystem for Linux on your Windows Servers.
The growth of digital threats has made our need for security more pervasive. Where possible, we try to use active schemes. However, private key infrastructure and certificates serve a powerful purpose and will continue to do so for the foreseeable future. As threats grow, we as systems administrators need to improve the way that we protect against them. This article starts a series on PKI and related certificates with a call to action: stop using self-signed certificates.
While not terribly common, sometimes you need to know the “bitness” of an executable (32-bit or 64-bit). The sudden growth of architectures besides traditional x86 and x64 (ARM, etc.) has introduced a related need to know the processor that an executable targets. Every EXE file has this information embedded in a common, easily read location. Oddly, Windows has no built-in tools to view it easily. Reviewing the available options, it seems like someone thinks that only a software developer or security researcher would ever want to know if a particular program can run on a given CPU. I built a PowerShell script that will read the necessary information from a Windows EXE (or DLL) to determine its bitness and the target CPU.
The C++20 standard introduced modules. This feature enhances the language by reducing reliance on header files. Visual Studio 2022’s Visual C++ projects have built-in support for modules. However, they don’t automatically provide access to modularized versions of the standard library headers. This article shows a quick way to configure Visual Studio 2022 to use C++ standard library modules.
