Building workstations sure isn’t what it used to be.Now there are virtual machines that setup much faster than physical computers, even if the system is fast. Maybe that’s because I don’t need to leave my chair, maybe its not really different at all, who can tell.Case in point, installing Windows XP (I know, I know) in a virtual environment took somewhere around 15 minutes where on the hardware of its time, at least an hour was required.Even the installer says there are 39 minutes remaining for about 39 minutes… The issue I have is with the sysprep.exe tool that ships with Windows 10 Professional (I think Windows 8 and 8.1 had this issue as well).Once a system is updated, Sysprep is dead and unusable.

I understand that once a system is patched this may be more acceptable, though not much, but even the smallest little hint of an update – think a change in one of the tiles because the computer found new data for Candy Crush.This has caused system after system to render the ability to create an Out of Box Experience for a workstation impossible to do with Sysprep because the system has been updated. Have a peek at the logs specified when Sysprep fails… they will inform you of this situation.

Now that you cannot provide a New in box experience with this system and are relegated to the much lesser “like-new” what can be done?Well you can use tools of old to create new user accounts and spend time getting things rolling that way, but anything missed still hangs out on the computer. Which is generally no big deal, depending on how much the system’s user cares that other things exist or knows where to look.

PowerShell might be helpful… with some help

To make an attempt to get past this situation, I wanted to come up with a way to provide a New computer experience for incoming users that would also allow a set of default applications to be installed with only a minimal amount of Next buttons to click.

While working on a scripted way to put this together, I had planned to do things like install-package and get all the things from a repository. This was on the right path, but not quite. I needed to dig further into the concept of using a repository and investigate Chocolatey. To better facilitate the capabilities of the technology I included both the PowerShell/OneGet code to install these packages and the choco.exe code which I did initially just to see what it might look like. After a few comments back and forth with others about some issues I was having – bad syntax after a long coding session, it seemed better to use choco.exe rather than straight PowerShell to avoid anything that might appear as not quite ready for prime time. There isn’t too much of that, but there might be some.

Since choco.exe speaks PowerShell it was fairly straightforward to get things rolling that way and some of the complexities were purely added by me because some things are just nice… not absolutely necessary.One of the biggest of these for me is logging. I added full logging to the script so all of the things it is doing are captured just in case.

So what does this do?

I am able to pipe a list of applications stored in a text file to the script to have them installed. That is the goal of the whole thing. Since the system I’m running on won’t have Chocolatey configured since it is new, I handle that as well, then jump into the list of things to install writing some things to the screen, some things to -verbose, and all things to a log file. I have added a progress bar to provide the appearance of things happening because some of the packages are HUGE and take forever to complete. (I’m looking at you Visual Studio Pro 2015).The applications generally get installed with no issues, but there are still improvements to be made.

This is my first attempt at serious automation with PowerShell and I’m sure there are 100 ways to skin this cat, but so far this has been pretty solid in testing. I have opted for logging rather than general screen output to reduce junk being sent back to the console screen. In addition, if I need to see what is going on, I can use -verbose to see the details. Next up there may even be a GUI written to treat this like an application (for the non-commandline set).

An example execution, loading Sysinternals from the Chocolatey repo is shown below – one thing to also note – ELEVATE! first. I did include -verbose which may do a few other things to get going, but I’ve cleaned up the screenshot.

An example of both log files created is also shown here – the top one is for the script run and the bottom of the image shows the choco.exe output while installing the selected package. Maybe that is more detail than anyone wants, but its better to have it than not… right?

As I mentioned above, the script is probably one of one hundred ways to handle this type of thing, but it seems to work pretty well for me. Once there is a bit more polish on it, I will put it online somewhere so those who wish to can make it better. Also, if the pipeline is your thing…Instead of specifying a cmdlet, you can pipe a text file in, something like this:

That’s about all I’ve got for now… I think there are other script ideas floating around to get working on.