Microsoft Endpoint Manager - Intune - Conditional Access

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

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. 

Are we even speaking the same language?

We spend a lot of time writing user-facing documentation, only to have users ask us questions that we already answered in our communications to them. It seems like no one is reading any of what we wrote. Users who need clear step-by-step instructions still contact the help desk, and the users who “get it” stop us in the hall and ask us questions we covered in the documentation.

We hear the term “digital native” being thrown around a lot lately. It was first coined in 2001 by Marc Prensky, in a paper titled, “Digital Natives, Digital Immigrants.”  Prensky was an educator. His paper focused on the different languages and learning styles of people raised in a world of technology, the digital natives, and people who grew up before technology became so ubiquitous, or “digital immigrants.” Prensky’s paper was targeted at educators, but for IT pros, his message carries several important lessons. He best sums up his own argument in one line: “Our students have changed radically. Today’s students are no longer the people our educational system was designed to teach.”

The biggest different between these two groups is how they engage with technology. Digital natives speak the language of a digital world. It has shaped how younger generations learn and engage with the world around them.
​
Traditional education was very methodical. Lessons were carefully planned and calculated to teach us important lessons through repetition and rote memorization. Lessons were singularly focused. Subjects were explored separately, and students were expected to give their undivided attention to the lessons of the day. It was far from perfect but designed to help the highest number of students succeed.

This is my latest post on the challenges faced by IT pros in the Modern Workplace, where I examine how changes in technology and business impact Modern Endpoint Managers and other technical professionals. The first post in the series can be found here.

​“Hello … IT. Have you tried turning it off and on again?” Roy and Maurice from the IT Crowd earned a special place in pop culture as the nerdy but lovable IT duo who personified a stereotype in the early 2000s.

It wasn’t that long ago that the information technology field, particularly systems engineering and administration, were dominated by the Roys and Maurices of the world. We never would have expected that Cosmo would run a column titled, “FYI, there are some pretty cool IT jobs out there.” Jobs that were once stereotyped as being the realm of unkempt, socially awkward guys working in dark, cluttered offices are now in-demand and sought after.

In the article, “How the IT Guy Became the ‘It Guy’: The Evolving Portrayal of Tech Professionals in Movies and Television,” Christina Wang discusses the changing image of IT pros in pop culture. She tracks the changing image from Dennis Nedry in Jurassic Park, to Roy and Maurice, and finally to Felicity Smoak in Arrow. In a lot of ways, this evolution mirrors reality. In the mid-90s the typical systems admin was expected to be a jack-of-all-trades with deep technical skills. IT teams were leaner, so deeply technical admins were regularly called upon for end user support – which led to confrontation and the stereotype of the IT guy as impatient and aloof, talking down to end users.

Roy and Maurice marked the first major evolution in the changing face of the IT pro. Throughout the series of the IT Crowd, we saw them being called to the president’s office and interacting with end users. They were looked at as advisors – not just technical assets. Roy was still a bit impatient with end users, but he worked to understand their needs and requirements. Maurice tried hard to fit in, even if he really didn’t understand the pop culture topics of the day. This first evolution tracked closely with the advent of Windows Server. Systems administration became more accessible to more people. While sysadmins were still expected to have deep technical skills, they could specialize more in different areas. End users became more knowledgeable, but many still had to call support frequently as the technology was not as stable nor easily accessible.

This is the second post in a series on the principles behind the Modern Workplace. 
​
​The first can be found here: It's not you, It's me
​

“Change for the sake of change is frivolous. It must be avoided. I know what users want because I’ve been doing this for so long, I know what works!” For a guy who has loudly told the world that he has never read Harry Potter, my (former) coworker sure did an amazing Dolores Umbridge impersonation.

We are caught in a cultural tug-of-war in our technology departments. On one side we have legacy SysAdmins who believe that IT knows what’s best for our users. The other end is anchored by the Modern Workplace evangelists who preach a gospel of agility, data-driven decision making, and user empowerment. End users are caught in the middle, often to the detriment of our organizations.

Brad Anderson touched on this in his blog post announcing Modern Endpoint Manager. He cites a study by Enterprise Strategy Group that shows certain trends amongst end users. The study demonstrates the importance of moving towards modern endpoint solutions.