Microsoft Endpoint Manager - Intune - Conditional Access

"I'm good enough, I'm smart enough, and dog gone it, people like me." -- Stuart Smalley
​
Yes, I know Stuart Smalley wasn’t a licensed therapist, but he did have a mirror and a way of reflecting on himself (even if he was just a character in an SNL skit). While I have never been on SNL, only occasionally get called a character, and am certainly not a licensed therapist – I am an impostor.

For those of you who are new to my blog, you may have missed my previous series on impostor syndrome. If this is your first time here, or if you are just starting to explore and understand impostor syndrome, let me introduce myself. My name is Sean Bulger. I am an IT Pro that works with Microsoft Endpoint Manager. We have all taken different paths to get where we are in life – and my path can definitely be described as different. Stops on my career have included being a paramedic, working as a plumber, a brief period in sales, and a few different stints working in information technology. While this range of careers has provided me a well-rounded skillset, it also leaves me questioning how I got here. Oftentimes I worry about what other people think about me and whether I am qualified to be where I am in my career.

That is the crux of Impostor Syndrome. If we boil it down to its most basic elements, we find that living with impostor syndrome means that we spend a lot of time feeling insecure about things we shouldn’t feel insecure about. When I say that, “I am an impostor,” it is not saying that I am pretending to be something I’m not. Saying those words is an open admission that I frequently feel like I don’t deserve to be at the level I am in my career. Those feelings often lead to a fear of being exposed and a belief that other people can see through me.

In my earlier series, I explored the phenomenon of impostor syndrome in depth. In that five-part series I covered everything from who experiences it, to how we can deal with it, and what it means for our careers. Perhaps the most important thing that I found, both through my research and from talking with others, was that none of us are alone in feeling like we may not be good enough. Blogging and engaging with the community were important in helping me to address my own fears. My journey should serve as proof that sharing your story with others, engaging with a community of like-minded individuals, and finding an outlet for personal development can help to overcome feelings of inadequacy.

My goals at the start of 2020 were high. Running towards those goals meant that I did not have time to worry about what other people thought of me. The positive side effects were obvious. Feelings of inadequacy and self-doubt were replaced by confidence and determination.
​
I failed to consider what would happen if the world changed in the blink of an eye. If we are being honest, most of us struggled through the first weeks of the pandemic. There will be countless biopics exploring the effects of 2020 on society, but I want to explore one simple question: What does a remote world mean for those of us who feel like impostors?

Welcome back!
 
I know that it has been a while since I last posted a blog entry. The break wasn’t because I didn’t have ideas, nor because I didn’t want to blog. When I started the Managed Modern Endpoint blog at the end of 2019, I had grand plans for what I wanted to accomplish. I thought writing two new posts a week would be easy and hoped that I would be able to leverage that content to find speaking opportunities. My plan was to supercharge my personal development and engage with the Endpoint Manager community.

Early on, the returns were obvious. I was gaining Twitter followers and my blog saw a modest, but steady, audience. Two blog posts a week proved to be a greater challenge than I expected, but everything else fell into place. By the end of March, I had my first open invitation to speak at a user group and my content was improving. ​

There are a dozen cliches I could insert here about 2020, and no matter which one I choose, the message is the same. Plans changed. Working remotely posed a new set of challenges. Our house didn’t have a dedicated workspace. The end of the workday wasn’t well defined. Suddenly working on a personal blog felt too much like the work I was doing for eight or more hours a day. Eventually, I moved my rudimentary workspace down to our unfinished basement – and that quickly led to a new project.

This post is part 4 in an open ended series on PowerShell for IT Pros. It is intended to be a framework to learn from, not an exhaustive study guide. Consider it a survey in what's possible, not a master's class in all things PowerShell. You can find the first post in the series here.

It’s taking everything in me right now to not break into School House Rock’s “Conjunction Junction,” but unfortunately this post is about functions, not conjunctions.

A function in PowerShell is a block of code that you can call from within a script. Parameters can be passed into a function, and it can be called any number of times. I typically write functions for one of two different purposes: either I need to run the same block of code multiple times in the same script, or I plan on reusing the code block in multiple scripts.

Functions are essentially scripts that are included as part of a larger script. You will often hear experienced scripters talking about building a toolbox. For many of us, that is a collection of scripts and functions that we reuse regularly. For example, I have several different functions that I use as source material for other scripting project. I have a logging function, a function that writes an exit code to the registry, and functions to build PowerShell objects. Some of these, like the logging and exit code functions, can be plugged into a script with almost no changes. The PS Object function usually needs to be customized based on the script I am work on. Whether a function needs to be edited or can be plugged directly into another script – they all save time and assist with common tasks.

A function can be as simple as a single cmdlet, or as complex as many scripts. Generally, I like to keep my functions simple. If it needs dozens of lines, it may be best broken out into small functions. Conversely, if a task can be handled in one or two cmdlets, it may be harder to justify handling it in a function. In this post we are going to explore a relatively simple function, building off the Connect-AzureAD cmdlet from my previous post.
​

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.” 
​

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. 

​“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.