Iron Scripter prelude

Iron Scripter 2019 Prelude #4 Solution

Last week the Chairman offered up another prelude challenge to prepare you for the Iron Scripter Battle at the next month’s PowerShell + DevOps Summit. As promised, the Chairman has graciously provided a sample solution. For this challenge there were many possible routes you could have chosen so it is impossible to provide a comprehensive solution. Instead, this solution is for those of you who weren’t even sure where to begin. For others, the solution might offer some conceptual tips.

Create the Virtual Machine

The challenge didn’t really care what technology you use to spin up your machine. The sample solution actually goes a bit outside the box to use a Docker container image built on the microsoft/windowsservercore image. The Docker environment also has a separate network for the container.

The container will also include a volume.

With these items in place, creating the container is relatively straightforward. The command is saving the command’s output because it will be the container ID which will be needed later.

Finally, start the container.

Configure the Virtual Machine

To configure the server, you could have used Desired State Configuration or related tool. Or use an imperative script like the one in ConfigureServer.ps1

The script is designed with some flexibility in mind. The assumption with this solution is that it will run remotely ON the server either through PowerShell remoting or PowerShell Direct. The configuration script will need some parameter values.

The Password Challenge

The challenge also required creating a new local user account.  Whenever working with credentials you want to avoid plain text passwords wherever possible. However, the other part of the challenge was to make this a hands-free process. One way to securely store a password is with a protected CMS message. This requires the use of a document encryption certificate. This makes it easy to store the password in an encrypted file.

This is done ahead of time. The automated solution needs to decrypt the password and convert it to a secure string which can be used create a PSCredential object.

All of the settings are added to an array.

You’ll see why in a moment.

Running the Configuration

Even though the solution is using a container,  you can still use PowerShell remoting. Assuming the container was created in the first place and $ID has a value, create a PSSession to the container.

From here you can use PowerShell remoting commands as you normally would such as using Invoke-Command to run the configuration script in the container.

When using a technique like this, script parameters are all positional. And because some of the parameter values are themselves arrays, you can avoid problems by creating explicit arrays. This way the value of $Add, which is an array of feature names, will be passed as one value to the script’s AddFeatures parameter.

You can decide how you want to restart the server. In this solution, which is really a proof of concept, during testing the EnhancedStorage feature didn’t persist when restarting the container. Even though it was clearly installed. This is most likely due to the nature of the container that doesn’t really affect the challenge. The sample solution doesn’t restart the container.

Validation

The last step would be some sort of validation. How do you know that everything is configured as expected? That’s where a Pester test can come in handy. The scripted solution takes the liberty of installing the latest version of Pester.

Of course, you need a Pester test.

Because the tests really need to run on the server, the test is copied.

Finally it can be executed.

There are several ways you could consume the test output. The sample solution simply checks for any failures.

Clean Up

The challenge wasn’t specific, but you should also have included some code to spin down and remove the test machine. In the Docker situation this is as easy as this:

How did you do? Are you ready for another challenge? Keep an eye on the site.