This is the third post in my series on Practical PowerShell for the IT Pro. You can find the first post here.
(Note: any PowerShell cmdlets shown in a screenshot will be included in a block that can be copied and pasted later in the post.)
It has been a long time since my last post on Practical PowerShell for the IT pro. A lot of things have changed in the world. The last few weeks have been a bit of a whirlwind. I would apologize for not making this post sooner, but I think it’s good for us to acknowledge the need to unwind. Focusing on writing has been hard, but now that I have adjusted to this new normal, I am ready to get back into the groove. For many of us, our jobs are unlikely to return the the “old normal.” Covid-19 will prove to be a world changing event, and the impact will be felt for years. Many of us have had to shift our approach from incremental change to rapid workplace modernization, and we have been asked to do it virtually overnight.
As we modernize, we will find a greater need to rely on PowerShell for managing users, devices, and licenses in the cloud. While the Administrative consoles give us access to most functionality, some controls aren’t exposed in the UI and many batch jobs or repetitive tasks can be completed more efficiently through a script. I hope that this blog series acts as a jumping off point for administrators that want to get started with PowerShell for systems administration.
In the last Practical PowerShell post I walked you through how to find the cmdlets you need to return an Azure AD user object. To complete that task, we had to install the Azure AD module, connect to Azure AD, then run the Get-AzureADUser cmdlet to return the user object. We ran each of these cmdlets separately to accomplish our goal. We can now use those cmdlets to create a basic script.
In my most recent blog post I discussed how we, as IT pros in the modern workplace, can respond to empower our end users to be more effective while working remote. Most of us are facing the monumental task of identifying the best solutions for our workers and getting them implemented quickly and efficiently in the midst of this crisis.
I am going to use this post to keep track of resources I have found to be helpful. Feel free to share this post and send me any links that you have found to be useful. If you share a link with me, please include a link to your Twitter or website so I can give you credit for sharing content!
I haven’t been on my game this week. If we’re honest, I think a lot of us have been a little bit off. Covid-19 has been looming for months, yet somehow we failed to anticipate how the virus would impact our daily lives. In North America, we watched as the pandemic exploded first in Southeast Asia then quickly moved across Europe. Most of us expected we would see it here, but I think that in our hubris we never expected a major disruption to business and society. Our culture isn’t one to slow down. We tend to believe we are above the fray and can weather any storm.
It’s not a secret that I claim to be a technology disruptor. As IT pros working with Microsoft 365, we want to change the way that our organizations work. Our goal is to empower our end users. Change typically takes time and being a disruptor in technology is as much about being a salesman as it is about being a skilled technologist. We are used to pitching new solutions, talking about the benefits of new technology, and working to build allies in our organizations. Workplace disruption is typically a slow and methodical process. Even if we know the value these tools have it can take time to deploy them because of the impact they would have on end users, infrastructure requirements, and workplace culture that isn’t always ready for change.
Six months ago, we couldn’t have predicted the impact a global pandemic would have on the workplace. What was once unthinkable is now our reality. The disruptors have now joined the ranks of the disrupted. Pitching a modern workplace was always about creating a nirvana that would empower workers to work from any location, on any device with total security and unlimited freedom. It sounds great on paper, but a lot of organizations weren’t ready to adopt remote work models, so change was incremental. Many of the modern workplace tools were considered ‘nice-to-haves,’ but not essential for continuing day to day operations. Our roadmaps have been filled with bucket list items from the Microsoft 365 suite of tools, but for most of us those tools aren’t deployed yet. However, we can’t unmake decisions that were made six months ago. It would be easy to say, “If we had deployed Teams globally six months ago, we wouldn’t be in this situation,” or, “If we had only decided to set up a Cloud management gateway or co-manage our Windows 10 devices we could address this issue on PCs.”
Practical PowerShell Part 2: Perfection not needed - finding cmdlets, interpreting errors, and returning an object
This is the second part in my series on Practical Powershell for the IT Pro looking to get started with PowerShell. You can find the first post here.
Welcome back! You have found the second post in my series on Practical PowerShell, perhaps this series would be more aptly titled, “How to stop worrying and love the script.” This is a series that is dedicated to the IT pro that wants to learn PowerShell but doesn’t really know where to start. There are more comprehensive resources available, but this is meant to be a logical introduction on PowerShell. The first post was meant to be a basic introduction. The rest of the series will follow a common theme. Each post builds on the lessons taught in the one before it. We are going to start with a basic concept that can be accomplished in a few cmdlets, and eventually build a utility that started with these first few steps.
The most important lesson in learning PowerShell is simple: No one expects you to know everything.
Let that sink in. You don’t have to be perfect. In fact, most of us who use PowerShell regularly learned through trial and error (mostly error). The most important tool in a proficient PowerShell toolkit is a search engine. It helps you find cmdlets, troubleshoot errors, and find scripts other IT Pros have created that we can use as is or repurpose to fit our needs.
This series would be really short if I just presented a challenge and used Bing to find a pre-canned script that solved all of our problems. It may be the right answer for a lot of the issues we run into daily, but it doesn’t help us to build a bigger toolbox. My goal is to point you in the right direction to begin writing your own scripts, build basic utilities, and become more confident in your own abilities. This is a modern endpoint management blog, so I want to make sure we build skills that are relevant in a cloud-first endpoint management world. Through this blog series we will build a utility to help use manage users, devices, and licenses in Azure AD through PowerShell.
Welcome! This blog series will examine how traditional IT team dynamics fit in the Modern Workplace, and whether we are prepared to manage and deploy solutions effectively in a cloud-first world.
Sometimes it’s best to sit and listen.
In a recent meeting I sat back as the attendees “discussed” their vision for addressing a specific challenge. I was a late invitee, and it was clear to me that the brief overview of the agenda I was given didn’t match the meeting’s intent.
There was a business challenge that needed to be addressed, but the actual intent of the meeting was much broader. It turned into a round table discussion about many of the challenges that we face and how we can overcome them.
I’m not known for keeping quiet. Typically, I jump into a conversation early and make sure my opinions are known. In this meeting I chose to sit back and listen. The perspective I gained was invaluable. Once we had exchanged the typical pleasantries, one colleague led with a question. She had barely completed her question when another team member offered a solution. Unfortunately, the “solution” being offered was little more than a defense of the status quo.
The back and forth continued and I quickly realized that while everyone was in the same discussion, both sides were talking about something different. One team member was looking for a new, modern solution to a problem, while the other team member only saw challenges – the costs involved, man hours, lack of expertise, and a litany of other issues were brought up. No one bothered to ask if it was worth it – or even worse, if there was a workable solution available that we could easily leverage.
As technologists on the forefront of workplace modernization we are by nature disrupters. We want to empower our users to do more, but it can be difficult to share our vision and gain traction on deploying modern solutions. Our teams don’t always share a unified vision, and when we do, we frequently talk past each other.
This post is the first in a series on PowerShell scripting for the SysAdmin who doesn't know where to begin. This series is designed to move quickly from PowerShell basics to advanced scripting techniques. It is meant as a guide, not a standalone resource.
“So, where do I begin?”
You really thought I was going to start this post by shattering the third wall and asking a self-referential question? I wasn’t.
I was reading your mind.
There are two common refrains I have heard from people about PowerShell. The first is simple, “I want to learn PowerShell.” Support team members and young systems administrators know that the best way to learn a new role and grow their career is by learning a new skillset. PowerShell is becoming one of the most important and empowering skills that an aspiring administrator or engineer can learn.
The other statement is always tinged with a bit of regret, “I really wish I would have learned PowerShell sooner.” For any number of reasons many seasoned IT Pros have waited to learn PowerShell. It may not have been relevant to the systems they worked on, perhaps they had a preferred scripting language, or could complete most tasks through a GUI. In a cloud first world development cycles have been shortened and not every function finds its way into a GUI. Most systems administrators eventually find a need for PowerShell, and in the end, regret not using it sooner.
There’s one underlying principle in both cases – people don’t know where to begin with PowerShell. It’s a massive topic. There are countless resources available – from user groups, to video series, tutorials, and books. I will include a few links to some of those tools at the bottom, and if anyone has other links they would like to share I would be happy to add them. If you have the time to sit down and digest in-depth content on PowerShell I would highly recommend diving into some of the more advanced content written by experts in our field.
I wouldn’t consider myself an expert in PowerShell. I’m an IT Pro who had a need, and like many other IT Pros I didn’t know where to begin. I began my systems administration journey in a role that required me to learn WiseScript and AutoIT. I had a basic understanding of VBScript and .Net. PowerShell, while similar, is also a completely different tool. If you understand the basic concepts of scripting, PowerShell is easy to pick up, but the syntax is different and can be a tripping point for more experienced script writers.
My name is Sean Bulger. I am an IT Pro that has worked in the Modern Endpoint Management work space since 2015. I have worked in various environment, ranging from mature enterprise all the way down to a fledgling IT organization looking to find their way in a cloud first world. Before rejoining the technology field in 2014 I had a wide range of careers - from plumber to paramedic - that have helped to shape my perspective on the world.