Showing results for 
Search instead for 
Did you mean: 

Level up your automation skills

Level 13

If you’ve read any of my articles you’ll know I’m old school. Automation in my days was batch files, Kix32 scripts, then group policy and Microsoft Systems Management Server (before SMS was a popular messaging protocol). I’m fortunate to mingle with some very smart Enterprise tech people occasionally, and they are talking new automation languages. Infrastructure as Code. Chef. Puppet. Ansible. Wow. I’m going to pause for a minute in envy.

To start with, there’s the debate of “which one do you choose?” I’m going to leave that to anyone who has more knowledge of these products than me. Are you using one of those or an alternative product, to handle server and infrastructure configuration management?

Do we all need to be versioning our infrastructure or has this DevOps thing gone a little too far?

Or is there a tipping point – probably an organizational size – at which this makes way more sense than how we used to manage infrastructure? Does your organization slide under that, making you wonder what all the fuss is about and why you’d bother?

Meanwhile, back in my SMB world, PowerShell is nudging in more and more as “the way you do things." In fact, many Office 365 administration tasks can’t be performed in the web GUI and require a PowerShell command. Which also means you know how to install the required PowerShell components and issue the correct commands to connect to your Office 365 or Azure Active Directory tenant. If I ignored the operational efficiencies from going command line again (hello, Lotus Domino Server), I would still be dragged into the world of PowerShell when it’s the only way to do something.

If this is all new to you, or if you live and breathe this stuff, my next question is …. how do you start? Whether you’re resigned to needing this stuff on your CV now or whether you are genuinely excited about learning something new (or you might be somewhere in the middle), what are your go-to resources?

Product websites are always a good place to start. Many are offering videos and webinars as an alternative to drowning in text with screenshots.

Are you searching through Github for infrastructure as code samples and PowerShell scripts, or are you learning from peers on Reddit?

Maybe you’ve gone with a different learning resource altogether, like the courses at Pluralsight?

If automation is the new normal (or the old normal), how do we pick up new automation skills? Let me know what’s worked for you.

Disclaimer: I’m a Pluralsight author of one course that is nothing to do with the topics I’ve just written about. And there are no affiliate links here either.

Level 16

You start the same way you would start anything else in the tech world...

Step 1) Open browser
Step 2) Go to

Step 3) Open as many tabs as possible, and spend the next 3 weeks going through each tab, opening 5-10 more tabs from each page...

See, easy!!

I have found it far easier to build very specific projects, and keeping my attention span focused there. When I venture too far outside of the project parameters, I tend to wake up, 4 days later, wondering where I am.

Keeping it simple, with the understanding that I will eventually get there, in time, has worked for me.

Level 21

I don't think there is a right or wrong answer to which automation platform to use, just choose the one that works best for you or your environment.  If you aren't sure do some research and bring a few different ones in to "kick the tires".

I think you first need to have a successful Operations team before you can worry about a DevOps team.  Your DevOps team should be the other side of the coin to your Operations team supporting them by automating the redundant tasks.  In a perfect world any task that you do on a routine basis should be automated, or at the very least evaluated for potential automation and this is where your DevOps team comes in.  The DevOps success should be measured by how many tasks they can unload from your Operations team by automating them.

Level 10

Don't reinvent the wheel.

If you have access to working scripts, by all means look at them.

1. These scripts work in your environment, which removes a lot of questions.

2. Breaking down other peoples scripts is a great way to learn, as opposed to simply Googling and trying to figure out how to work with items in your environment. (Don't worry wluther, I use the technique you listed every day.

3. If you are lucky, the person who wrote the script may still be around, and you can ask why they did things a particular way.
Level 16

Nice write up

Level 21

There are even more options that can help develop or share more skills:

  • Follow the basic writer's guide of "PPP".
    • Start with a person.  (Or a process, or a goal)
    • Put them in a place.  (Define the environment in which your process occurs)
    • Present them a problem that must be overcome.  (Show how the specific skills save the day.)

And suddenly your writing has a personal touch that might just get your work more widely read and used.

  • Or define the problem with a single sentence, followed by "And then the scary things began to happen . . ." 
    • Remember to show how the skills took the scariness out!
Level 14

I've spent a good chunk of my career doing lots of things (and doing them well IMHO!) while maintaining the position that "I can't code".  For a while it was a bit of a badge of honour, as in "Look what I have accomplished and I can't code."  But lately it has been a black mark.  Here's the thing -- I can *read* most scripts.  Not read and understand every nuance and iteration but I know enough about enough things to look at a script and figure out what is trying to accomplish.  And when I'm done staring at something long enough (OK, it's 30 seconds later -- let's be completely honest!) then I can wield my Google-fu with the best of them.

But your question scuff​ wasn't about IF we should learn how to automate things it was HOW we learn to automate things.  A few of the MVPs and I were chatting the other day and I said that it was a combination of desperation and -- OK, it was all desperation -- that led me to the point of putting the effort in to try and learn PowerShell.  Here's the thing -- it is OK to fail.  I did it.  Heck, I still do it on a regular basis.  Sometimes I get distracted and end up going down long winding routes that are interesting (hello invoke-sqlcmd, I'm looking at you!!) but don't always have an immediate return on investment.

I think that is the lesson I've learned -- start learning now.  In fact, if you stopped learning at any point in your life then you did yourself a disservice but you can come back from that choice.  Decide to learn and pick a place to learn.  You don't need to learn what I learn.  Learn was is interesting to you.  I started learning Python (slowly, very slowly) last year because I like data science and it scratched an itch that I had.  I'm learning PowerShell because I'm tired of the Orion UI when I need to do ridiculously repetitive tasks on a ridiculously larger number of nodes.  Oh, and automation is the ONLY way to do compliance and auditing well.  And so I'm learning PowerShell to help make sure that the standards that I define, the processes I build, and the outcomes that I expect can be validated and reported on so that I can sleep at night.

How do you learn?  Start with a desire to learn.  Find a problem that is personal to you, something that will make your life easier if it were to be fixed, and then start figuring out how you can fix it.  You might never fix it.  That's OK!  What you learn while trying to fix it is valuable now and in the future.

Remember, wisdom is earned by exercising knowledge .  If you lack knowledge, you lack the required elements to earn wisdom.

Level 9

Automating ones processes is quite a nice idea but not at all times IMHO. You need to be very certain before you jump into it. A great deal of skill is required. Lovely write up scuff

Level 14

With some industries you could afford a gap-year or a sabbatical, but ours changes while we sleep. Even a holiday away from the job and the Internet takes time to catch from. It's been learn or die for years in IT. Whether your current role requires it or you have a requirement that must be delivered, you're just interested or you need something new, it's absolutely necessary to keep learning. I've started playing with PowerShell and it's a scary thing, but I feel that it has to be done.

Level 13

That's certainly a fun rabbit hole to go down!

I love your point about being specific. Instead of saying I'm going to learn PowerShell" you'll get better results from being specific and stating "I'm going to automate x, with PowerShell being the tool of choice" You still need to pick up the basics of things like command syntax, but by staying focussed on an outcome, you'll get a better sense of satisfaction, sooner. Great point!

Level 13

Absolutely agree that it's more about how well you are using a platform than which one you are actually using. For those who haven't decided, it's still interesting to hear what someone has chose and why.

That sounds like a perfect example of Dev & Ops working together. We often think of DevOps in relation to the continuous delivery of software development updates into production. Ask not what you can do for your developer, ask what your developer can do for you!

Level 13

Orin Thomas did a great session at Microsoft Ignite Australia on the 30 terrible habits of server and Cloud administrators. It was the top ranked session at the event. One of those habits? Trying stuff in production that we found from a google search on some random person's blog!

Link: 30 Terrible Habits of Server and Cloud Administrators. | Australia 2017 | Channel 9

Level 13

This is a great formula, thanks for sharing. Are you a writer? Where did you learn this?
Level 16

Most of them are gifted and for sure they would be able to come up with automation thoughts, probably they are just waiting for the right set of tools which help them in automation OR they wouldn't have explored much on what's currently available in the market, which could change their thoughts into reality.

Level 13

I think I'm just going to hand over my blog next time to you.

Couldn't agree more. In the business world, the cry right now is if you're not innovating, you are dying. For IT Pros, if you're not learning, you're dying. In a planning session for my own business a while ago I wrote "we're not failing fast enough". I have a good friend who wrote a book called "How to have the energy of a 4 year old every day". He talks about how as kids, we learn by failing our way to success and we are perfectly ok with that. We lose that boldness as adults because of our stigma around failing.

I can't code either and feel exactly the same way about scripts - I know enough to figure out a small percentage and I google the rest.

Level 13

Test environments help. Pick a small repetitive task and see if you can make it easier/faster/better. Do you have any examples where automation isn't a good idea?

Level 13

True, it's always been a changing industry but it feels like the rate of change is insane lately. One thing I mention to people looking to take parental leave is how to stay up to date while you're out of the office. Not everybody wants to, especially if you are an employee that wants to clock off completely for family time, and that's perfectly fine. Other people will play and tinker in their own time, just to keep their skills fresh & up to date. In my situation, I'm glad that working for myself meant I kept a hand in tech while raising two babies (at different times) so I didn't have a steep learning curve on my return.

Level 13

This is where you need a test environment and an explorer/adventurer spirit!

Level 17

Well said!

Level 14

Guest blogging for @scuff?  Sign me up!

Level 14

Automation has the potential to go bad.  You should approach automation with the same methodologies that you approach enterprise monitoring.  Test. Trap for errors.  Measure and report outcomes.  We wouldn't think of deploying a new application monitor that wasn't tested, or a set of alert logic that hadn't been tweaked, without first trying it out in a lab or a sub-set of the targets.  We wouldn't dream of letting our hard work go down the drain because we assumed it was always going to work and we should never deploy monitoring and alerting that we cannot measure and report on.

Automation is the same.  Know what your inputs are and where the come from.  Know what you want your outputs to be and where they go.  Measure and report on both.  Automation will make you happy when you can trust it.  It like that quote from the remake of the Italian Job, paraphrased of course -- "I trust all automation. Its the devil inside it that I don't trust."

Level 13

Great tips. I especially like the point about measuring the outputs.

Level 19

I've had automation go wrong before... for some of us the network is getting so big now that without NCM some things would be next to impossible to achieve though that's for sure!

Level 15

Automation - I got my start with Kixtart - one of the guys I worked with always said "If it can't be done from my desk, it doesn't need to be done."

Level 7

Very good tips. Automation as we know it is exploding. How and what we use to think of server environments is changing dramatically. There is a true separation in server/os/application. Which changes how we look and handle environments. Servers/OS are becoming nothing but disposable calculators. How we deploy maintain automate these environments today is vastly different.

As we look at changing how these environments operate, and the roles within those environments. Our direction on tooling changes

In older hybrid environments powershell is great but you need to fall back to some old school methodologies on validating the condition of the environment, and the rights of the user before running scripts and cmdlets. For myself I have a nice script I have created which validates the above, and then calls various other scripts to facilitate specific functions. IE can't use secedit to export a local security policy? That's okay lets run a batch file and read the specific registry keys. Messy, but then it dumps to another script that brings it back to a human readable format.

Be flexible, and never trust your input always double check.

Level 14

I like it!  I think sqlrockstar​ recently posted an article about data being a commodity. I love that "never trust your input".  How many times we do we see exploits that happen because someone didn't validate the values that we expected on an input?  Now imagine running a script with thousands, maybe 10s of thouands, of records to scrape through and possible perform actions against.  Failure to validate both the input and output of automation exposes us all to substantial risk.

I recently had an experience where a team made a bulk change and didn't validate the output.  The result?  Hundreds of CMDB records with incorrect IP addresses.  No big deal, right?  It's just a configuration management record.  Except that IP addresses provided a key for a lookup for tonnes of other systems that pulled data from that CMDB and generated other automation.  In the end there impact was minimal but by not measuring, by not knowing who was consuming your data through automation, it could have been much worse.

Great tips ceward​!

Level 13


Level 13

Servers as disposable calculators? Harsh but true! Some server admins loathe the concepts of serverless or containers or PaaS, but that's the brave new world we live in now. Server admins must adapt or perish!

Thanks for adding your thoughts.

Level 13

Love it!

Level 21

I'm only a reader, sadly.  But occasionally a muse sits upon my shoulder and carries my attention in ways that seem to translate nicely to the written word.

I'd enjoy receiving a living wage for writing, but many people know ways to write effectively; competing with them is not my goal.

The advice I offered above is shared often to writers of every level, by those who study effective communication.

The last bit is certainly tongue-in-cheek, and was a grin-worthy story on N.P.R. this winter.  I substituted "scary things" for a word I expected would possibly be filtered by Thwack's auto-sensor.

Level 13

Boy get it right or your in trouble.

Level 11

There are tons of free learning resources on youtube if you want to go that route.

Pluralsight and cbtnuggets are good paid resources for the bang vs buck.

Start will something small then go from there.

Versioning you can do it if you want to me its not that big of a deal cause if your doing devops you will probably catch it since it doesn't work.

Key concepts.

Test and retest in dev, validate data. This will be key in making decisions.

Before you make the change export the current data before you make the change. Example say your deleting a massive of ad account. Well the restore gets super easy if you can restore if you know the data that you deleted first.

Have at least a representative sample of prod in dev.

Separate out code from the solution, allows you to migrate between automation solutions. For example we us sam as our automation engine for certains based on alerts where we run our powershell or bash scripts. If SAM were to go away as long as the next solution support powershell or bash we are good to go.