OS Deployment Development Language Choices


Okay, so you’re working on an OS deployment tool, and you very quickly realise that if you want to create something more complex than your basic home lab, you are going to have to create some custom code to achieve what you need. This could be a simple as requiring registry changes, adding or deleting files, joining a domain, installing Windows Updates or setting up the Start Menu for default users. In fact, once real world requirements come into play, there are usually more and more things that require you to customise the deployment beyond what your deployment technology does out of the box. The question is, which language should you be developing in? Well, here are my suggestions along with some arguments for and against.

PowerShell

For: It’s the Microsoft preferred scripting language, and is definitely something you should be dabbling in to support all sorts of things. It’s hugely flexible and can hook into the full .NET Framework.

Against: It isn’t available by default on some older Operating Systems, which means that you have to trigger its installation earlier in the deployment sequence. That’s probably not much of a problem, but you need to take in into consideration. Another possible reason may be that you are using something like Microsoft Deployment Toolkit, which has favoured script template that uses VBScript that links to the built in support for the native MDT logging tools. The nature of your deployment technology is a big pointer here. Lastly, not all PowerShell versions are the same, so it’s probably worth scripting in PowerShell V2 format or installing a later version (v4 or v5) before you get to this point in the task sequence.

VBScript

For: It’s been natively installed in every version of Windows since Windows 2000 (Even Windows NT 4.0 could support it). There is a bucket load of support on the internet for it with mountains of scripting examples. Also, as mentioned above, VBScript is the format of the native scripting template for MDT, and almost all of the technology in MDT is built in VBScript. I would argue that everyone should have at least a basic understanding of VBScript as so much of the Windows world is based on it.

Against: It’s getting old now and hasn’t been functionally improved in many years. It’ll be available in Windows for years to come, but you’ll never see any new features in it.

.NET Executable (VB.NET / C#)

For: It’s a great platform to develop in, and you code gets hidden from prying eyes. It also runs fast and makes things like sorting collections as simple as one line, something that’ll be a lot harder in VBScript. It’s also type safe and easily object oriented.

Against: It’s not a scripting platform, what you get are compiled executables, so you can’t just make a change in a text file, you are going to have to recompile it in Visual Studio. Also, without the source code, no-one else is going to be able to amend what you’ve created.

 

So what’s the answer?

Hey, you knew all along that I was  going to come up with a wishy-washy answer about use what you feel is best and use the most appropriate technology for the situation, and I’m not going to disappoint you in that.

Personally I use a blend of all of these. I favour using VBScript as it’s my instinctive language for small scripts. It’s fast and easy to use as well as universal to all Windows platforms. Next on my preferred list is probably PowerShell, although it’s got some really crazy methodology that is different to all other languages and is therefore not as intuitive as it should be. At the end of the day, you can’t beat a VB.NET executable, but that is the developer in me speaking rather that someone responsible for deploying machines. Deployment systems are rarely used just used once and discarded, they are a living evolving platform to modify the build deployment process as changes are required, so supportability by others is a pre-requisite.

Anyway, I’m going to be extending this site with examples of all of the above. I hope you’ll enjoy them.

 

Leave a comment

Your email address will not be published. Required fields are marked *