Windows has multiple options for scripting languages, but some are better suited than others for widespread administration. This article looks to cover the most accessible options as well as their specific use cases and any caveats. I am focusing on what can be used in order to administer Windows machines, ideally remotely via an RMM tool or other remote access. This article will cover what languages are most widely available as well as the pros and cons of each.
Windows Batch
Windows Batch scripting is one of the most widely known ways to write scripts for Windows, but it is neither the best or the most efficient on any count. Batch scripting is based off of older DOS commands and logical structures. There are some benefits of scripting this way which make it relevant even today.
Windows Batch Use Case
Windows Batch scripting is still the best if you are on an environment with legacy devices which do not have something newer like Powershell, if you have policies which prohibit Powershell, or even if the systems are extremely inconsistent and you’re not sure what the lowest common denominator is (common when you inherit a site or environment to work on). Another use is accounting for sites where you have hugely different versions of Powershell and the lowest version being too low to work with sanely. Batch scripting still fills use cases for simple tasks which do not have Powershell, or sane Powershell alternatives.
Windows Batch Limitations
As batch scripting is based on older DOS commands, it is much more limited than any other option in this article. Batch logic is far more lacking than Powershell or Lua (or pretty much anything anyone would want to use in general) and certain things which are trivial with newer languages require far more work than one would expect or are just plain not sustainable to write. Another limitation is that you are typically limited to DOS commands or calling other commands in weird ways in order to collect data or information. Trying to share this kind of data between processes can and almost always will require extra temp files and steps.
Windows Batch Scalability
For widespread deployments, Windows batch scripting is relatively light for the overall deployment. If you are dropping a BAT file on thousands of agents, the impact for both the system distributing said file and the agent itself will be relatively minor (depending on what the BAT file is doing). For tasks where you do not need to keep track of the output or worry about too many variables, batch scripting is extremely agile and efficient. Batch is quick and consistent in terms of both writing and running.
Powershell
Powershell is Microsoft’s suggested way of scripting automation tasks for Windows machines. Powershell is a full-fledged, powerful language which is useful for Windows administration. The newer versions are so capable, that Microsoft even has a headless offering for servers which relies on Powershell for administration. Powershell is the evolution of batch programming.
Powershell Use Case
For newer Windows machine, Powershell will save a massive amount of time. Powershell is also backwards compatible, so if every agent has at least a minimum version of Powershell, a script will continue to work with minimal extra testing. For many low level Windows operations, Powershell is the best tool to use as well as long as you are on a Windows which includes Powershell. With proper policy tuning for a given site, Powershell can remain much more secure than batch programming as well.
Powershell is great when more program logic is needed than batch can provide. Programs can be run and data collected and processed to adjust control of the script to handle workflows where batch files break down without human interaction. Older DOS commands can still be used, so the baby doesn’t need to be thrown out with the bathwater when using Powershell.
Many newer Microsoft services also provide interfaces with Powershell which mean administration is much easier. AD, Exchange, etc. can all be automated in varying capacities with Powershell interfaces, even to the point that opening a traditional GUI console may not be necessary. Powershell is the ideal way to code for the vast majority of Windows scripting tasks provided a new enough version, or consistent enough version, is available at the site or sites.
Powershell Limitations
Older versions of Powershell were a complete joke. Until Powershell 3 or so, Powershell was more a toy than a tool. Powershell 3 added a lot, but was still limited in many respects. It had great promise, but very little it could do compared to the newer version and batch scripting tended to be more consistent for my use cases. Powershell 3 added many quality of life features as well as new features which fleshed the language out to where it was a viable option for many use cases.
Certain features with Powershell also require adding a module to the system, which may not be an option with some sites. Granted, this is far less of a limitation than batch scripting, it is still a known limitation to be aware of. Some really cool features require additional modules which may or may not be acceptable for use at some sites. Another limitation is that some newer encouraged security policies will disable or block foreign Powershell when not run from a known source or from a known folder.
Powershell Scalability
Powershell is about as scalable as batch programming. The files are slightly larger, but can get much larger when packaged with certain modules. With sane programming standards, Powershell is basically on point with batch programming for scalability as long as the environment does not have too many caveats. Powershell can have a heavier impact on a machine for similar processes as what you would run from command prompt like for a batch file, but this isn’t hugely noticeable except in extremely complicated scripts.
Lua
I’m a big proponent of Lua as you can see from my tutorial. Lua also makes a good Windows automation tool for certain types of processing where Powershell is not an option and batch scripting just won’t cut it. I use Lua for certain classes of problems on Windows machines, though I wouldn’t say it is as flexible as Powershell for Windows automation.
Lua Use Case
Lua is more useful when you need a more traditional programming language which is capable of higher level logic and more complicated processing of data. My primary use case is for something like when I need a consistent way to upload files to something like Dropbox on a Windows machine and can’t control for Powershell or install software on the machine itself. I have also used it for data processing on an endpoint where Powershell could theoretically work, but was not ideal for the type of data I was working with.
Lua is best when you specifically need something more like a traditional program but don’t have Powershell or Powershell doesn’t fit the case. Libraries and modules can be embedded in with the program for most cases working around some restrictions. Most Lua builds I’ve found or worked with are compatible all the way back with Windows 2000, which most RMM tools don’t even support at this point.
Lua Limitations
Lua is not a native part of Windows and as such is not going to be as efficient as a native tool. A lot of limitations can be worked around with some creativity and careful consideration to use case, but ultimately, Lua might just not be the best tool for the job for the majority of automation tasks on Windows. Another consideration is the fact that the Lua binaries must be either distributed or installed in order to run your scripts. The binaries are small, but several megabytes for a zipped version which can add up on large deployments. You also have to package modules and requisite libraries and understand how to do so which adds a layer of complexity to the whole process.
Lua Scalability
I only included Lua due to its scalability. Other scripting languages which are not Windows native may be “better” for many tasks, but ultimately are too heavy or too problematic to sanely deploy as a one off thing. Lua is small enough and efficient enough it easily skirts by. It’s many times more impactful than Powershell or batch scripting for size, but still light enough to not be insanity to deploy in bulk and the language itself is lightning fast. There are many classes of issues where Powershell was not an option and batch was too lacking to solve, but Lua was able to get it resolved for me with a smattering of creativity.
Conclusion
There are many other options and languages which can be used, but these three are my favorites by far, and arguably the best for most remote automation. Powershell is obviously king on Windows for most things, but both Lua and batch scripting still have a place for system automation. In a newer site with a controlled security policy, Powershell may be limited or unavailable, but in other sites, it may be the only avenue for automation. Batch scripting is a dying art, but still one with a niche for automation. Lua (and by extension other languages) also have a great use case for certain sites and certain niches.
Image by Gerd Altmann from Pixabay