How I Decided to Join TechSnips and Became a Contributor

 

 

After the birth of my first son, I was feeling like I was at a crossroads in my career. I have been working in IT on my own and for many others for a while now (I built my first computer somewhere around 1999-2000) and have been exposed to many different types of environments and tasks. Since his arrival into my life, I have had a growing sense of responsibility to move beyond just having mentors, to being the mentor and teaching; from being the apprentice to becoming the master.

The Journey

Back in May, I was following quite a few industry peers who were tech bloggers, presenters, and evangelists. One of those peers is Adam Bertram. I had seen a few tweets about an opportunity to get involved in a new venture that centered on the IT pro and career advancement. Having just finished reading the book “Be The Master” by Don Jones, I was inspired to take a leap and do more, I just wasn’t sure exactly how. I responded to one of Adam’s messages. Not long after, I had received a message from him. He explained that he was developing a new business in which IT pros could gain some valuable exposure to the IT community, teach others and further their careers. Everyone had something worth teaching.

I left that conversation having been inspired and was convinced that this was an opportunity worthy of investing time in. Therefore, I began to think of something that I knew that I could teach. Having some experience with Group Policy, and a passion for PowerShell, I did something…

I Just Hit Record…

It sounds easy, and for the most part that is true. For many people, including myself, not so much. IT pros tend to be a little shy, and afraid to put themselves out there. Aside from occasionally being very active on some forums, I had never recorded myself. I have taught some people one on one, but never a group of random strangers on the Internet.

This was an undiscovered country for me.

To Boldly Go…

After a period of reflection on what I could possibly contribute that was in my mind worthy of teaching. Side note, everything is worth teaching! Not everyone who is in IT is at the same point in his or her career as you. I remember having a hard time with some topics and not having someone there to teach me, but I digress.

I searched my geek stash for any supplies I could find to aid in making a recording. A spare monitor here, a junk microphone there. Some free screen-recording software. With zero initial budget, there were some struggles. Specifically audio battles. With the help of @MichaelBender, I obtained a much more high-quality microphone that eliminated most of the poor sound quality that was keeping my demo from passing acceptance to become a snip contributor. I am forever grateful for that random act of kindness.

With newfound confidence and better audio, I regrouped and submitted another demo, and it was accepted. The first hurdle passed, I learned a lot and was inspired to keep going. So I made a short snip on How to Create a Starter Group Policy Object with PowerShell on Windows Server 2016 which demonstrates how to quickly create an empty Starter GPO that can be configured with baseline settings, creating a template of sorts for future use. With some guidance from Adam, @_BryceMcDonald and the TechSnips editing team, the final snip was polished and published. It was a milestone for my career:

I was now a professionally published contributor.

Conclusion

The feeling of knowing that I have left something valuable for someone to learn from has not faded. It’s driven me to also submit writings about Pester to the TechSnips.io blog, and to publish two additional snips since then with more in the works as time allows. I take great pride in telling people about what TechSnips has done for me and why my fellow IT pros should consider joining. We all have something worthy of teaching the next generation of IT pro. We all need to “Be the Master.” Help someone else. Just hit record, and see where it takes you.

How to Use Tags in Pester for Targeted Testing

“There’s no sense in being precise when you don’t even know what you’re talking about. -John von Neumann”

 

http://developers-club.com/posts/264697/

I thought this was a good quote as the theme for this post. Re-read the quote, take it in, and then continue reading.

 

During the construction of a set of Pester tests, it can be increasingly difficult to follow the flow of each of the tests and the subjects against which these tests will be performed.

Since Pester tests PowerShell code, you are able to use a PowerShell method called Regions to separate section of code. These Regions will allow you to collapse large sections of similar code to create an overall more pleasant script reading experience. While that may assist to some extent, it does not help you find and run specific tests.

Here’s an example of what using a region would look like:

Example 1 - Regions
Region example

The problem is that this technique is only useful when reading code, but not necessarily nearly has helpful when executing code. A region doesn’t allow you to pick out precisely what test you want to run. That’s where using Tags comes into play.

Tagging is a Pester parameter that allows you to filter Describe blocks using a string or keyword value. When using Invoke-Pester with the -Tag & -Passthru parameters, only the Describe blocks that contain the -Tag value specified will execute.
Here is a simple example:

Example 2
Tag Example

This is useful because you do not have to have multiple test files with only one Describe block in each, you could instead create a single master file with multiple Describe blocks, each with their own tag. This is very useful to do when you have an application or infrastructure stack you want to test, and have the ability to add any new regression tests you may need in the future.

You can use multiple tags for a Describe block, but you cannot use multiple tags when running Invoke-Pester. This took me a little time to figure out but after thinking about it, it does make sense. You want to run a single or suite of tests that have the tag, not multiple tests with multiple tags because that is what Invoke-Pester will do by itself!

Since I first started learning about Pester, I have been building a few infrastructure tests for use in the environments I work in often. One particular task involves working with domain controllers and occasionally do some investigation into replication issues.

Taking what I know and turning it into some tests that run quickly and uniformly has improved my response time to domain controller issues. Tags have been extremely helpful during a couple of troubleshooting tasks now that I could target the specific failed component(s) in my test set based on results of the initial test.

There is no reason to keep running full tests for example if, for example, DNS is not working. I can then target DNS services and infrastructure without chasing other possibilities, thus wasting time. Another benefit was that I did not have to go find additional scripts because I already had the -tag parameter set for the Describe block in question.

How I Learned Pester by Building a Domain Controller Infrastructure Test

“What is simple, is understood. What is understood, is executed.” -Anonymous

Let me start by saying that Pester for the longest time was very intimidating to me early in my PowerShell journey. I’m still wondering what exactly it was that made me think that way. Was it being too busy just trying to learn what I needed for that moment, or was it that I didn’t see how I could implement it into my suite of scripts? I don’t have any good answers.

The Scenario

I’m a Sysadmin by trade and recently had experienced some system issues after performing some typical routine maintenance. Some of this work I had scripted by referencing the original checklists provided to me when I first started doing this work. This particular cycle, the checklist wasn’t enough.

Continue reading “How I Learned Pester by Building a Domain Controller Infrastructure Test”

Creating Starter Group Policy Objects for Quick Policy Baselines

If you are lucky to build a complete Active Directory infrastructure from scratch, then you know how much planning and consideration goes into the whole process. And it doesn’t just stop with delivering the environment. You have to also consider ongoing management of the environment.

That’s why you should consider using Starter Group Policy objects.

Starter Group Policy object is just a blank, or clean slate if you will, Group Policy Object. The purpose of these objects is to allow an administrator to create and have a pre-configured group of settings that represent a baseline for any future policy that is to be created. These settings can then be copied into a more formal Group Policy Object that is then applied to single or multiple organizational units (OU’s for short). Copying these starter objects preserves your baseline strategy and allows you to dynamically add or remove settings that shouldn’t be applied to future objects.

Continue reading “Creating Starter Group Policy Objects for Quick Policy Baselines”