Posey's Tips & Tricks
Planning for PowerShell Script Usage in a Multiplatform Environment
Let's examine the challenges of running Windows-dependent PowerShell scripts from Linux and compares three practical approaches -- dual booting, WinBoat and Windows Server RemoteApp -- to maintaining compatibility in a multiplatform environment.
Over the years, I have created numerous PowerShell scripts that I use to manage both my internal network and my business. Many of these scripts are tools that I use every day and that I would consider to be mission critical. The problem, however, is that because of some changes that I have been making to my IT infrastructure, I found myself needing to run some of these tools from a Linux workstation.
At first, the idea of needing to run PowerShell scripts from a Linux instance probably seems like a total non-issue. After all, you can run PowerShell natively on Linux. So problem solved, right? Not quite.
The problem is that there are numerous Windows PowerShell cmdlets that simply are not supported in PowerShell for Linux. As an example, many of the cmdlets related to managing Windows systems don't exist in Linux PowerShell. Similarly, scripts that rely heavily on the .NET framework tend not to work on Linux. As an example, many of my scripts rely on a Windows Forms-based GUI and Windows Forms does not work on Linux machines. Based on the research that I have done, you cannot even use something like WINE to make these scripts work on a Linux machine.
That being the case, I had to carefully evaluate my options. After looking at a lot of different possibilities, there were only three options that proved to be realistic.
Dual Booting
The first option that I considered was dual booting a system between Linux and Windows 11. From the standpoint of being able to run Windows applications, there was a lot to like about this idea. Since the PowerShell scripts would run from a true Windows instance, there would be native performance (thanks to the absence of an abstraction layer) and guaranteed compatibility. Unfortunately, there were also some very real down sides to using this method.
The most obvious disadvantage was the need for rebooting every single time I needed to access one of my PowerShell scripts. I also had to consider the complexities involved in managing a dual boot partition. I have heard unconfirmed stories about Windows updates breaking dual boot environments. Of course another disadvantage is the labor involved in keeping two separate operating systems patched and up to date.
WinBoat
My second option was to run WinBoat. For those who might not be familiar with WinBoat, it is a Linux application that runs Windows 10 or Windows 11 in a container and makes Windows applications available for use in Linux. You can even use the clipboard to move data between Windows and Linux applications.
I have spent some time working with WinBoat and it seems to work really well, although there are plenty of stories in online forums of people having serious problems with WinBoat.
Given my experience working with WinBoat, I almost settled on it as my preferred solution for running Windows applications in Linux. The one thing that held me back was performance. I found that WinBoat slowed down both my Windows applications and my Linux applications. I was also somewhat hesitant to adopt WinBoat because it hasn't been around for all that long and might not have fully matured. Given WinBoat's relative newness, I also had to question how much help I would be able to find online if I were to experience a problem.
Windows Server RemoteApp
The solution that I ultimately decided to adopt was to host my Windows applications on Windows Server RemoteApp. RemoteApp hosts the applications on a Windows Server and makes those applications available through an RDP session. The experience is very similar to what it would be if the application were running locally.
One of the things that I liked about this approach was that applications run directly on a Windows Server, meaning that the applications are hosted in a native Windows environment, not an emulated environment. Windows Server also does a good job of keeping the applications securely isolated from one another and also allows for centralized application management.
There were however, a couple of big disadvantages to using this method. One such disadvantage is that most Linux distributions do not come with an RDP client. As such, I had to download an RDP client before I could use my published applications. It's also worth noting that Windows RDP files do not work with Linux RDP clients. I had to do some manual configuration work before I was able to access my hosted apps from Linux.
The other disadvantage, and this is the big one, was the cost. Besides needing a Windows Server license and the required client access licenses, you also need Windows RDS licenses.
Besides the cost, it may also be worth considering how long the RemoteApp feature will be around. As far as I can tell, Microsoft has not updated this feature in years and it's possible that they might eventually deprecate it.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.