Friday, 15 June 2018

TechSnips: Your Chance to Become a More Successful Tech Professional

We're geeks, right? We love tinkering with tech and figuring out better ways to solve problems. How cool would it be if lots of us could come together under one platform and share our hard-earned knowledge with everyone else via technical demo screencasts? I'm glad you asked!

I've recently launched an IT career development platform called TechSnips. First and foremost, TechSnips is not a Pluralsight, Udemy or LinkedIn Learning. We don't do courses; we do snips. Snips are short (1-10) minute screencasts with absolutely no slides of any kind. Its purpose is to deliver exactly what IT pros, system administrators and other technology professionals need right now. We skip over all of the fluff.

Because of this short format, it's a lot easier to get started contributing if you're new to putting yourself out there in a tech community. You will learn presentation skills through feedback from myself and your peers, you'll be a member of our growing community and get access to our Slack channel, you'll have some great content to put on your resume and you will get paid in monthly royalties!

Joining has a ton of upsides but you've got to be willing to put yourself out there.

I'm looking for contributors that can help myself and the dozens of other contributors build the TechSnips content library. As of now, we need to fill a lot of holes so the types of screencasts will most likely be up to you. As long the content fits in the snip format (which you'll get more info on the signup page), the world is your oyster. FYI: We needs lots of DevOps stuff!

If you're interested, please sign up! You'll be asked to do a quick audition and once approved, you'll be part of the TechSnips Contributor community! I look forward to seeing what new content you can come up with and how teaching others can help yours and others' IT careers flourish!

Thursday, 31 May 2018

Writing Resuable, Modular DSC Configurations

A few weeks go I posted about writing better DSC Configurations with Configuration Data. Really, this was just the start of the journey. Ideally, you want to want to pull your Configuration Data from your CMDB, but often tools or processes are missing to get your configuration management up to this level of integration. So let's go with something 90% of the way there. Now this in-between state is nothing to scoff at. You can run with this if you need to. Let's take a look.

When you are building your configuration, you have two essential parts. Your Configuration, the .ps1 file that is compiled to generate MOFs and the Configuration Data, the .psd1 file that is used to provide data to the configuration. You want to modify the Configuration file as infrequently as possible, modifying this file is bound to cause errors and issues (People make mistakes). Also, you want the Configuration Data to be modular, so multiple people can work on it at the same time without any chance of conflicts.

So, let's build a succinct and reusable configuration. Take a look at the below example:


The small block of code above installs all the features for any given node, based on its role. The node is defined like this:


As you can see, the Roles property is an array. This allows you to specify multiple roles for a given node, making it extremely powerful and allows your roles to be more modular.

Let's take a look at the role definition.

The role definition defines which features are associated with the role.

Now let's discuss how you can bring all this together. The Configuration Data is made of of two major parts. The AllNodes block and the other Configuration Data. This is sometimes called Non-node Data. Ignore that name, we going to use it to store all sorts of information. Take a look at the below code and file structure.

The script creates a hashtable for the configuration, then pulls in each of the Nodes that are represented in individual files. Then it pulls in all of the additional configuration data, such as domain and site information, finally the role information is imported, building a single configuration data file that can be used to compile your MOFs.

What are your thoughts on this type of modular DSC configuration?

Did you happen to notice the naming convention applied to resource names? That allows you to dynamically build DependsOn blocks.

Wednesday, 11 April 2018

Writing better DSC Configurations with Configuration Data

Configuration Data in Windows PowerShell Desired State Configuration (DSC) allows you to separate the what from the where. Configuration Data enables you to write better DSC configuration. Configuration Data is defined as a Hash table and is passed in when the configuration is compiled. If you're using Automation DSC on Azure, that looks like this:

As you can see on the last line, the configuration data is imported as part of the Automation DSC compilation job.

The basic layout of a Configuration Data file is:

Each Node entry must have a NodeName property as this property is used to generate a MOF file for each node in the AllNodes array.

When you import a Configuration Data file, new variables are available to you when defining your configuration. These variables allow you to define more sophisticated and succinct configurations. The variables are:

  • $AllNodes - Refers to the AllNodes array, use this variable with .Where() and .Foreach()
  • $Node - Refers to the current node within the AllNodes array once the array has been filtered
  • $ConfigurationData - This refers to the entire configuration data file hash table

You can use AllNodes.Where() to select specific nodes, for example, let's say we have a node that has a property of Role, and that role is defined as either DomainController or FileServer. Let's use the below configuration data as an example:

When you compile the above configuration, with the configuration data, you will get two MOF files, one for DC1 and one for FS1. The DC1 configuration file will only have settings for the DNS and NTDS services, the FS1 MOF file will only have settings for a File on D:\.

You can go one step further than this, by using the $ConfigurationData variable to access data outside of the $AllNodes block. Let's look at the below example:

In the above example, the configuration will loop through each of the services defined on a role and add them to the configuration.

Now let's assume that you have heaps of software, features, services and other settings you need to deploy to each of your nodes. You're going to start saving lines in your configuration, and eliminating code that would otherwise be repeated.