Skip Ribbon Commands
Skip to main content

 Follow Me


 SharePoint Blog List

Todd Klindt's home page > Todd Klindt's Office 365 Admin Blog
What's going on with TK.
July 09
How to Register the PnP.PowerShell App Registration if You’re not a Tenant Admin

I’ve done a few articles about the new PnP.PowerShell module. One of the biggest changes from its ancestor, SharePointPnPPowerShellOnline, is that it requires the registration of an Azure Application before you can connect with it. In this blog post I’m going to explain how to get that Azure App registered if you’re not a Tenant Admin in your tenant.

You don’t need to be a Tenant Admin to use the PnP.PowerShell cmdlets. You don’t even need to be a SharePoint Admin or a site collection admin. There are plenty of cmdlets you can run, like Add-PnPFile if you’re only a Member of the site. However, before you can run the most import PnP cmdlet of all, Connect-PnPOnline, the PnP Azure Application has to be registered in your tenant by a tenant admin. If it’s not, you’ll get a sad message that looks like this:


Here’s the text:

Connect-PnPOnline: AADSTS65001: The user or administrator has not consented to use the application with ID '31359c7f-bd7e-475c-86db-fdb8c937548e' named 'PnP Management Shell'. Send an interactive authorization request for this user and resource.

In most cases the person introducing the PnP.PowerShell module is a tenant admin, so it’s not an issue. They run Register-PnPManagementShellAccess and Bob’s your uncle. But it’s not uncommon for an organization to be large enough that the SharePoint or Microsoft 365 Admin team is not a tenant admin. In that case the Tenant Admin, who likely doesn’t know what a PnP.PowerShell is, has to register the Azure App before the SharePoint Admin can enjoy the bliss that is PnP.PowerShell. Fortunately, there’s an easy enough solution, the Consent URL.

The Consent URL is the URL to a web page your Tenant Admin can go to to consent the PnP.PowerShell Azure App without needing to install anything, or really know anything about the PnP.PowerShell. There are a few ways to get the Consent URL. It doesn’t matter how you do it, they all get you to the same place.

The easiest way to remember is to run Register-PnPManagementShellAccess –ShowConsentUrl after installing the PnP.PowerShell. You’ll be asked to log in, but you don’t need to be an sort of admin. It’s only logging in so it knows when tenant you’re in. Then it will give you the Consent URL. It looks like this:


The part in the red box is your tenant’s ID.You had to log so the cmdlet could get that number. The Client_id refers to the PnP.PowerShell, so it’s the same everywhere. 

You can also specify your tenant’s name instead of its ID. This works as well:

Whether you get the URL from running Register-PnPManagementShellAccess –ShowConsentUrl or by copying it out of this blog post and putting your tenant’s information, send that URL to your Tenant Admin. When they browse to the page it will look like this:


All they need to do is click Accept and you’re ready to go.

That’s a pretty long, scary list of permissions, and it might spook some admins. Accepting this does not give everyone in your tenant all of those permissions. The PnP.PowerShell Azure App uses Delegation, which means any user using it to access objects in Microsoft 365 has to have permission to access it. The PnP.PowerShell does not allow anyone access to anything they don’t otherwise have access to. If they don’t believe you, have them try. Have someone that cannot open up a SharePoint site in the browser try to connect to it with Connect-PnPOnline. They won’t be able to.

If they want to check out what the Azure App has permission to, or heaven forbid, remove it, you can browse to the Azure AD Portal and find it in the Enterprise Applications.


The Permissions blade will show you all delegated permissions the app has. Feel free to poke around, but resist the urge to change any, even if you’re positive you’ll never use them. I promise it’ll only hurt you in the future.

After your tenant admin has done all of that you should be able to get back to all that PowerShell and PnP goodness.



June 25
Create Lots of Test SharePoint Sites (or Teams or Groups) with PowerShell

Throughout my IT career I have had to create tens (or hundreds, or thousands) of objects to test something. It could be a bunch of Windows Users, a bunch of folders, files, etc. It seems like every time that happens I end up starting from scratch on the process. To stop that silly cycle I decided to make the process official by blogging it. Let’s stop this madness!

This time it started with my friend Michal Pisarek posting this tweet:


Orchestry needs to test their lifecycle features and he wanted to stress test it real good!

As is often the case, I see a tweet like that and my first thought is “Challenge Accepted!” The mechanics of how to create Teams with PowerShell is pretty simple but where this really gets tricky, at least for me, is the names. Especially if you’re looking at creating 20,000 like Michal is. In the past the way I’ve handled that is the old tried and true “Adjective Noun Number” formula. To get near 20,000 I wanted a long list of nouns and adjectives to pull from. I scoured the Internet and pulled together two files, nouns.txt and adjectives.txt. You can find them in this GitHub repo. Then I tack a random two digit number at the end to reduce the chance of collision. I put those files in the same directory as this PowerShell script and let ‘er rip!

Connect-PnPOnline -Url -Interactive

# import the files with nouns and adjectives
$Nouns = Get-Content .\nouns.txt
$Adjectives = Get-Content .\adjectives.txt

# Number of Teams to create
$NumberOfTeams = 3
$Index = 1

while ($Index -le $NumberOfTeams) {
    # Generate Random stuff
    $TeamNoun = $Nouns | Get-Random
    $TeamAdjective = $Adjectives | Get-Random
    $TeamNumber = Get-Random -Maximum 100
    $TeamDisplayName = "$TeamAdjective $TeamNoun $TeamNumber"
    Write-Host "$Index - $TeamDisplayName"
    New-PnPTeamsTeam -DisplayName $TeamDisplayName -MailNickName $($TeamDisplayName.Replace(" ","")) -Description $TeamDisplayName -Visibility Public -AllowGiphy $true

You can find the file CreateLotsofTeams.ps1 in that same GitHub repo.

You can alter the nouns and adjectives files as you see fit. Set the the $NumberofTeams variable to how many Teams you want and you’re set. This script uses the venerable PnP.PowerShell module. You’ll need that installed and its Azure Application registered before you can run this. Be sure to change the Connect-PnPOnline line to reflect your tenant’s name, unless you actually work for Contoso.

Because of some weird timing, the current version of the PnP.PowerShell, 1.6.0, won’t work with this script as there is a bug in New-PnPTeamsTeam that prevents it from actually creating a Team. Ironic, I know. I put notes in the CreateLotsofTeams.ps1 file on how to handle that. But if you’re running it and it looks successful but no Teams are being created, look there first.

Also, for whatever reason, when you look at the Groups Sites in SharePoint they don’t show up as being Teams enabled, but they really are.


You can see in this crudely mocked up screenshot that the Teams are in the Teams client even though SharePoint Admin Center swears they don’t exist.

And while this script’s purpose in life is to create lots and lots of Teams, it could be easily modified to create lots and lots of anything. If you just need Groups, swap out New-PnPTeamsTeam with New-PnPMicrosoft365Group. If you just need SharePoint sites, use New-PnPTenantSite. Folders? Add-PnPFolder. I think you see where I’m going with this. Smile 

If you’re like Michal and you’re going to create 20,000 Teams, or anything, I hope you have a comfortable chair. It’s going to take a while. Michal is seeing about 1 Team a minute. It’s going to take him a couple of weeks at that pace. Almost certainly PowerShell is the bottleneck in this situation. If you’re looking at a similar situation, my advice is to open up another PowerShell window and run another instance of CreateLotsofTeams.ps1 there. And maybe run a few instances on another machine entirely. In the past that has helped me speed this things up considerably.




February 09
What is a “Dev Tenant” and why would you want one?

My fellow Sympraxian Julie Turner recently published an outstanding blog post on what a Microsoft 365 Dev Tenant is and why you should get one. I’ve been a long time user of Dev or Demo tenants and I find them to be an invaluable resource both for people trying to gain skills in Microsoft 365, but also grizzled old veterans like myself. Like the old saying goes, “The question isn’t whether you have a Test Site, it’s whether you have a Production Site.” If you don’t have a Dev or Demo Tenant to test things in then you’ve just demoted your Production Tenant to a Test Tenant. Don’t be that person. Smile I did a session on the PnP PowerShell today for One of the people there was hesitant to try out PowerShell on their tenant. I recommended they get one of these Dev tenants and hone their skills there.

Be one of the cool kids. Read Julie’s blog post and grab a Dev Tenant.



January 19
The new PnP.PowerShell Module is live!

As of January 19th, 2021 the new and improved PnP.PowerShell module is no longer prerelease and is ready for the masses. You can also find it in a GitHub repo. It replaces the venerable SharePointPnPPowerShellOnline module we all know and love. The new module has a lot changes, but here are a few of the highlights:

  • PnP.PowerShell only works with online products like SharePoint Online and Microsoft 365. It does not work with SharePoint Server platforms like SharePoint 2013, 2016, or 2019.
  • It is built on .NET core 3.1 so it runs on non Windows platforms like Linux, Mac, and Azure Functions. SharePointPnPPowerShellOnline is built on .NET 4.6.1 and only runs on Windows.
  • PnP.PowerShell is focused on all of Microsoft 365, not just SharePoint. SharePointPnPPowerShellOnline started out focused on SharePoint and other things have snuck in over the years, but were never supported as well as we would have liked.
  • Authentication relies on App Registrations. To facilitate the cross application support the module relies on Graph API permissions as opposed to straight up usernames and passwords. SharePointPnPPowerShellOnline uses App Registrations as well, but it’s not built on that premise like PnP.PowerShell is.

If you can, you should uninstall the SharePointPnPPowerShellOnline module and install PnP.PowerShell everywhere. You should also stop using Windows PowerShell 5.1 and move over to PowerShell 7.x. There are a couple of legit reasons why you can’t though. I have a whole blog post, “Using both PnP PowerShell Modules with PowerShell 5 and PowerShell 7” that covers how to have both modules and both shells available to you. For those of you with short attention spaces I’ll give you the tl;dr:

Open PowerShell 7.x in Administrator mode and uninstall all the modules:

Uninstall-Module SharePointPnPPowerShellOnline -Force –AllVersions
Uninstall-Module PnP.PowerShell -Force –AllVersions

That should clear all the appropriate modules out of PowerShell 7.x. You’re good there.

Now open Windows PowerShell 5.1 in Administrator mode. Here you’ll uninstall all the modules and reinstall them:

Uninstall-Module SharePointPnPPowerShellOnline -Force –AllVersions
Uninstall-Module PnP.PowerShell -Force –AllVersions

For good measure I close down the Windows PowerShell 5.1 host and open a new one before I install the new version. That might not be necessary, but it feels like cheap insurance. Either way, in a Windows PowerShell 5.1 Administrator shell install both modules:

Install-Module -Name SharePointPnPPowerShellOnline -Scope Allusers
Install-Module -Name PnP.PowerShell -Scope Allusers –AllowClobber

I added a little chocolate to the install commands to make them go down easier. First, I added -Scope Allusers to make sure Windows PowerShell 5.1 installs the module in a place that PowerShell 7.x can find it. I think any modules installed in an Admin window are installed there by default, but I’m not sure. Again, cheap insurance. Second, to the second (and any subsequent) module I added –AllowClobber. This tells PowerShell that it’s okay to install a module that has cmdlets that collide with cmdlets already on the system. This is okay because of the difference between installing a module and importing a module. You can read more about that in my previous post.

If you need one of the on-prem SharePoint Server modules use a line like this:

Install-Module -Name SharePointPnPPowerShell2019 -Scope Allusers –AllowClobber

You can have as many of these modules installed as long as you install the later ones with –AllowClobber.

Once you’ve got the modules installed you need to tell PowerShell which one to load. That’s done with the Import-Module cmdlet. When you open a new PowerShell window, or at the top of any PowerShell scripts, you can specify which PnP Module you want PowerShell to use. For instance:

Import-Module PnP.PowerShell


Import-Module SharePointPnPPowerShellOnline


Import-Module SharePointPnPPowerShell2019

Then you know you’ll get the version of Connect-PnPOnline (or whatever) your code is running.  In theory you could swap them in and out by using Remove-Module, but in reality there are some fiddley PowerShell things in the background (the AppDomain) that keeps this from being successful. My previous blog post does show you how to have multiple versions of the PnP module imported in the same window or script at the same time.

But really, stick to PnP.PowerShell and PowerShell 7 if humanly possible. Smile

I hope you find that all helpful. I don’t know about you, but I’m really excited about this new module.



January 13
Using both PnP PowerShell Modules with PowerShell 5 and PowerShell 7.

Since the PnP team announced that the venerable SharePointPnPPowerShellOnline module was going to be replaced by the shiny, new PnP.PowerShell module there has been some confusion on which module to use and which PowerShell to use. I have good news, the answer is “D. All of the above.” In this blog post I’ll show you how you can have both modules installed and use them interchangeably as well as use either of them on whatever version of PowerShell tickles your fancy.

A Few Words about Modules

Before we can get into how to do this I want to spend some pixels on why we have to do it the way we do. I intended to publish this blog post a couple of weeks (okay, months) ago but as I was doing my research I kept learning more. Most of the learning was around the “Module” cmdlets and what each of them does. In order to get the two modules to cooperate we need to use the right Module cmdlets at the right time. Here are the Cliff’s Notes:

The System

Several Module cmdlets deal with what PowerShell Modules are installed on your system with PowerShellGet. There are a lot of ways to install Modules into PowerShell and PowerShellGet is one of the most popular and it’s built into PowerShell. Here are the pertinent cmdlets and what they do:

  • Install-Module – Downloads a module from a repository (the PowerShell Gallery by default) and installs it on the system.
  • Get-InstalledModule – Lists the modules that were installed on the computer with PowerShellGet
  • Uninstall-Module – Uninstalls a packages from that computer that was installed with PowerShellGet

The key here is that the scope of those commands, and the other PowerShellGet cmdlets, is the whole computer

The Host

“Host” is a fancy word for PowerShell window or console. There are a few common Module cmdlets that deal only with the host they’re run in. Here are some of my favorites:

  • Import-Module – Imports a module that was already installed on the computer into the host
  • Get-Module – Lists the modules currently imported into the host. The –ListAvailable parameter shows modules installed on the computer that can be imported into the host
  • Remove-Module – Unloads (unimports? exports?) a module from the host

These cmdlets are all part of Microsoft.PowerShell.Core as opposed to PowerShellGet.

The Import Business

Now we know how to get a module installed onto our computer, and how to manually coax it into our host. But most of us have never done all this Import-Module business but everything seems to work. How’s that? PowerShell has the ability to automatically load modules when they’re needed. The entire, exciting, story of how PowerShell imports modules is chronicled here, but I’ll give you the highlights. If you try to use (or reference it with something like Get-Command) a cmdlet that isn’t in a module already loaded PowerShell will walk through the PSModulePath locations looking into each module for the cmdlet you’re trying to run. If it finds it, it implicitly imports that module and Bob’s your uncle. You can use $env:PSModulePath to see where PowerShell will look. It’s important to note that Windows PowerShell 5 and PowerShell 7 have similar, but different PSModulePaths. Here’s what it looks like in both. I added -split ";" to put each path on its own line, and I piped it through Sort-Object to make them easy to keep track of.



$env:PSModulePath -split ";" | Sort-Object

To make either Module, SharePointPnPPowerShellOnline or PnP.PowerShell, available to both Windows PowerShell 5 and PowerShell 7 it has to be installed in one of the paths that both versions of PowerShell will look in. For backwards compatibility PowerShell 7 looks in the PowerShell 5 paths, so I do the Install-Module bit in PowerShell 5 and PowerShell 7 gets it for free. You could install it in both, that works. But this way keeps you from having to update it both places every time a new version comes out. The PnP.PowerShell module is aimed for PowerShell 7, but also works fine in PowerShell 5. Erwin​ told me they may remove that support in future, but for now it’s safe.

You can see from the screenshots that I have my Known Folders redirected to OneDrive. When installing these modules PowerShell was installing them to my personal folders and it was causing problems. A couple of the Module cmdlets don’t handle that well. To get around some of that chicanery I had to install the modules in a different path. The easiest way I found to do that was the specify the scope Allusers, like this:

Install-Module PnP.PowerShell -Scope AllUsers

In PowerShell 5 that installed into C:\Program Files\WindowsPowerShell\Modules\PnP.PowerShell, which PowerShell 7 can see so it can be imported into a host of either version and it’s not in OneDrive.

Using Both Modules in Both PowerShells

We know both PowerShells can run both modules if we install it right. To get everything playing nicely I uninstalled both modules from both versions of PowerShell using Uninstall-Module -Force –AllVersions. In one case Uninstall couldn’t clean it all up so I had to go into the file system and delete the folder manually. I also had to close the host various times as it had imported the module I was trying to uninstall and I couldn’t get it unloaded in that host.

After all the uninstalling was done I closed all of the PowerShell windows I had open and I opened a PowerShell 5 window in Admin mode. I installed the old module with this:

Install-Module -Name SharePointPnPPowerShellOnline -Scope Allusers

That made it so it could be imported into both PowerShell 5 and PowerShell 7. Next I installed the PnP.PowerShell module. This one took a bit of extra coaxing.  It’s currently in prerelease so Install-Module requires the –AllowPrerelease parameter. The version of PowerShellGet in PowerShell 5 does have that. I had to upgrade PowerShellGet first with this line:

Update-Module -Name PowerShellGet

I close the window and opened a new one for good measure. This put me at version 2.2.5 of PowerShellGet. One problem solved. The second problem is that PnP.PowerShell and SharePointPnPPowerShellOnline share most of their cmdlet names, so a regular Install-Module is going to fail. To fix that we need to use the –AllowClobber parameter. The whole thing looks like this:

Install-Module -Name PnP.PowerShell -AllowPrerelease –AllowClobber

At first this sounds scary, but remember, Install is just dropping the bits onto your computer. You can still control which module gets loaded in a script or host. To do that using Import-Module. The key is to use Import-Module before you do anything that will trigger PowerShell implicitly loading the module for you. If you want to force your script to use a specific module include one of these lines at the top:

Import-Module PnP.PowerShell


Import-Module SharePointPnPPowerShellOnline

You would do the same thing in a PowerShell window when you open it to run some cmdlets. I’ve been doing this for a few weeks and it works well.

Using Both Modules in the Same Host

Now I’m just going to show off a bit. Smile We know we can load either module into a host, but what if we need both modules into the same host or script at the same time? It came be done! It sounds like magic, but it works. The key is using the –Prefix parameter of Import-Module. If you want both modules loaded and available in the same window you need to import one with a prefix. It looks like this:

Import-Module SharePointPnPPowerShellOnline -Prefix Old


You can see from the screenshot that both sets of cmdlets are available, with the SharePointPnPPowerShellOnline versions having the additional prefix of “Old.” I wouldn’t recommend doing this as a normal course of action, but it’s good to know it’s there. PowerShell 7 is a little fussy when doing this. I had issues importing the old version if I had already imported the PnP.PowerShell module explicitly or implicitly, which is why I didn’t in this screenshot. Get-Command implicitly loaded it for me, so that wasn’t an issue. PowerShell 5 handles it more gracefully.

The End

There it is, the culmination of weeks (maybe months) of me fiddling around to understand the inner workings of PowerShell module installing and importing. Thanks to Jeff Hicks​ for holding my hand and answering all my dumb questions. Hopefully my pain will make your transitions from PowerShell 5 to PowerShell 7 and from SharePointPnPPowerShellOnline to PnP.PowerShell easier.



December 28
Making the move from SharePointPnPPowerShellOnline to PnP.PowerShell

As the new year approaches I find myself making changes. Like everyone on the planet I plan to eat less and exercise more. I also plan on making another change, I’ll be moving away from my friend the venerable old SharePointPnPPowerShellOnline module to the new, sexier PnP.PowerShell. I thought I’d blog the experience so you all can follow along.

Why the Move?

The SharePointPnPPowerShellOnline module has been good to me over the last few years. It has helped me do amazing things both in PowerShell and in SharePoint. Why would I ever give that all up? Because the times, they are a-changing. The SharePointPnPPowerShellOnline module is being retired and all of that effort is being channeled to the PnP.PowerShell module. The SharePointPnPPowerShellOnline module will continue to be around for the on-prem versions of SharePoint Server (though not updated), but for SharePoint Online/Office 365/Microsoft 365 you’ll need to use the PnP.PowerShell module.

Why did the PnP team decide this? You can get the whole story at the official PnP PowerShell page, but there are two main reasons. The first is wider platform support. SharePointPnPPowerShellOnline had .NET dependencies that meant it would only run on Windows PowerShell. Emphasis on Windows. When that module was first created 6 years ago that made perfect sense, but since then PowerShell has gone open source and now runs on a variety of platforms like Mac, Linux, a variety toasters, etc. Since SharePointPnPPowerShellOnline required Windows it couldn’t follow PowerShell onto those other platforms. The PnP.PowerShell module was written without those Windows dependencies so it can run anywhere PowerShell can run. You may not use a Mac, but this also means that you can use PnP.PowerShell more easily in cloud environments like Azure Functions.

The second reason was to give wider application support. The SharePointPnPPowerShellOnline mostly supported SharePoint, as the name would suggest. These days you can’t manage SharePoint Online without also needing to touch Microsoft Groups, Teams, etc. The PnP added more and more cmdlets to handle that, but there were some big authentication changes that needed to be made to fully support all of the other applications. They started adding some of that to SharePointPnPPowerShellOnline, but it was cobbled together a bit. While they were refactoring the module for .NET Standard they went ahead and made some sweeping authentication changes that mean we’ll be able to use it more easily for SharePoint and all of the other applications we know and love.

First Step PowerShell 7

The first step to moving to the PnP.PowerShell module is to install PowerShell 7, also called PowerShell Core. I’m on Windows, so that’s the process I’m going to walk through. Windows comes with PowerShell, Windows PowerShell 5.1. To use PowerShell 7 we’ll have to install it. Windows PowerShell 5.1 and PowerShell Core 7 can happily coexist on your machine, so you don’t have to worry about breaking any of your other existing PowerShell scripts or tools.


You can see from this screenshot I have both versions of PowerShell installed and running on this machine. You can use the system variable $PSVersionTable to see which version of PowerShell your host is currently using. It’s also pretty easy to pick the version of PowerShell you want when firing it up.


While PowerShell 7.x can coexist with Windows PowerShell 5.x, it will replace PowerShell 6.x if you have that installed.

I installed PowerShell 7 by downloading the installation MSI from the GitHub page. For me that was the Windows x64 platform and I grabbed the stable build. That file was PowerShell-7.1.0-win-x64.msi, but obviously that filename will change as PowerShell 7 advances. Then I popped open a Windows PowerShell 5 (oh, the irony) prompt in Admin mode and ran the MSI.


The friendly wizard walked me through the process. There are few installation choices to make, but I’ve found the defaults are usually fine.

After the installation is finished you’ll have both Windows PowerShell 5.x and PowerShell Core 7.x. Time to install some modules.

The Module

Installing the PnP.PowerShell module is pretty easy, but if you have the older SharePointPnPPowerShellOnline module installed you’ll need to uninstall it first. The cmdlet names in both modules are the same, So PnP.PowerShell won’t install all of its cmdlets while there are collisions with the old version. To uninstall the SharePointPnPPowerShellOnline module open up a Windows PowerShell 5 host in Admin mode and enter this:

Uninstall-Module SharePointPnPPowerShellOnline –AllVersions

and wave a fond farewell to our old friend. After that’s finished, and you’re done sobbing, open up a shiny new PowerShell Core 7 host in Admin mode. While you’re in there opening up in Admin mode, go ahead and add PowerShell 7 to your Start Menu and your Taskbar. You’ll thank me later.


Then issue this command:

Install-Module PnP.PowerShell –AllowPrerelease


You’re all done. Since PnP.PowerShell is not an official release yet you’ll need the scary sounding –AllowPrerelease parameter. After January of 2021 you won’t need that anymore.

Finally, Authentication

I mentioned earlier that one of the reasons for changing modules was a change in authentication. I don’t want to get too deep into it in this blog post but I do want to mention that you should run Register-PnPManagementShellAccess to set up a an Azure Application Registration. This is the magic that allows the new PnP PowerShell access to all of the applications in Office 365. You may have seen this referred to as Graph API. I’ll dig into it later, but for now all you need to know is that a tenant admin needs to run the PnP.PowerShell version of Register-PnPManagementShellAccess once in your tenant. After that is in place you should be able to use Connect-PnPOnline and get connected.



November 25
Tips for using the Microsoft Authenticator app for MFA

Earlier this month, Alex Weinert, the Director of Identity Security at a little company called Microsoft, published a blog post begging us to stop using SMS as the second factor for MFA. I’m an MFA kind of guy, I live the MFA life style, and I’m on board with that. As the majority of the accounts I use can use the Microsoft Authenticator app, that’s what I use the most. Other companies, like Google, also have authenticator apps. I’m sure they’re fine and well loved by their friends and families. Smile

Over the last few months I’ve moved most, if not all, of the apps and sites I can to MFA using the Microsoft Authenticator app and I’ve picked up a few tricks along the way. I thought I’d blog a few of them in case they help anyone else. Keep in mind this blog post was written in November of 2020 and the version of the app I’m using is 6.2010.7266 on Android.

Use Microsoft Your Phone

My first tip for using Microsoft Authenticator is not about using Microsoft Authenticator at all. It’s about using a Windows 10 feature called “Your Phone.” This feature, along with an app running on your phone, allow you to interact with your Android phone on your Windows 10 machine, or machines. I initially started using it to send text messages but it can do so much more. For instance, you can run phone apps on your PC, via screen sharing. One of those apps can be your friend and mine, Microsoft Authenticator. Since web sites (like Microsoft 365) and other services like VPN use codes generated from Microsoft Authenticator it is handy to have quick access to it on your PC. Here’s what it looks like:


That saves you fumbling with the UI on your phone, but you’d still need to look at your phone to get the code.

For this to really be helpful you also need to change a setting in the app to allow its screen to be captured. Go into Settings and enable Screen Capture:


If you don’t, you’ll see this on your PC when you open Microsoft Authenticator:


When I need to log into my GitHub account I fire up Your Phone on my computer, switch to the Microsoft Authenticator app and type the secret 6 characters in. Now I’m logged into GitHub and ready to cause some trouble.

Show the Codes

By default, when you open Microsoft Authenticator you’re greeted with a list of all of the accounts you’ve registered and you select the one you want to log in to. Authenticator takes you to a screen with the one-time passcode for that account. But all that clicking is sooo much work. I take advantage of the “Show Codes” option, like below.


That shows me all the codes for the accounts that support it. You can see how it looks in the first screenshot. Combining these two techniques my MFA process went from:

  1. Hunting around for my phone
  2. Unlocking it (unsuccessfully the first couple of times)
  3. Finding the Microsoft Authenticator app
  4. Finding the account I want to log in to
  5. Clicking it (so much work)
  6. Typing all six digits into the MFA prompt on my computer
  7. Collapsing from exhaustion

To this:

  1. Clicking the Microsoft Authenticator app on my Windows 10 Taskbar
  2. Copying the one-time passcode for the account
  3. Pasting into the MFA prompt
  4. There’s no step 4!

Wait, copy and paste the passcode? How’s that again?

Copy and Paste the Passcode

Once you have that set up you can actually copy the passcode from your phone in Windows and paste it into whatever web page or app is asking for it. To take advantage of this magic you need to enable copy and paste in the Your Phone app on Windows 10.


You might have to close the Authenticator app both on your phone and your PC for that to take effect. When you have it working, it’s a thing of beauty. Just copy the passcode with your mouse like you would any other application. There’s no visual indication that it’s copying, but trust me, it is. Go ahead, paste it into Notepad and see for yourself. Cool, huh?

Backup Your Settings

I recently heard a sad tale of woe from a friend of mine that uses Microsoft Authenticator for all of his MFA needs. Something went wonky on his phone and he lost a bunch of the account settings. He had to go through a lot of work to get it all set back up. That’s when he and I both noticed the handy Backup functionality. Like all the other fun we’ve looked at it’s in the Settings page of the app. You can read all about it on this Docs Page. But the basic idea is, turn it on. Future you will appreciate your consideration and foresight.

There are a few other fun Authenticator tricks, but these are my favorites. Are you using Authenticator and have tips to share? Put them in the comments below.



September 14
Free SharePoint Migration Webinar with me!

My friends at SysKit have been kind enough to do all the work for me to put on a free webinar on SharePoint migration. Those folks are the best! They do all the work, and you and I get to chat about one of our favorite topics! The big day is Wednesday September 16th. It’s 10:00 am CDT

The registration is free, and you can find out more details and sign up here.

I’ll give some good advice, and tell some stories, and generally have fun. Join me, I’d love to see you there.



August 18
Create "All Users" Groups and Distribution Lists in Office 365 and Azure AD

Some blog posts just beg to be written, and this is one of them. I swear I’ve had this conversation half a dozen times in last month after having never had it at all before. It just keeps coming up, I’m guessing because the adoption of Office 365 has really taken off in the last 5 months. What’s the topic? It boils down to, “How do I create a Team/Distribution List/SharePoint site that is always available everyone in the company?” The first couple of times the topic came up I tried to talk the customer out of it. I’m usually not a fan of big blast communication like that, and in the case of products that are built on top of Microsoft 365 Groups, there are published limitations to this. It just seemed like a bad idea. But every time a customer asks me about it I understand it a little better, so I threw this blog post together to point people at if they want to do it. This post is meant to be  technical, not prescriptive. I won’t cover why you should employ any of these techniques, but how you can do them if you have already decided they are a good idea. I’ll leave the why up to people that are smarter than me.

The Options

There are several “All User” communication methods that have come up in my discussions with customers. I’ll cover how to enable them. They all leverage the functionality of updating dynamically as people join your company. Your company could already handle adding people to Distribution Lists (DLs) as part of your onboarding process. All of my examples will show how to keep the All User list populated automatically. All of these examples also assume the groups are cloud only, not synced from on-prem Windows Active Directory.

Distribution Lists (DLs)

The first option I’ll cover is the old tried and true email Distribution List. These things have been around since shortly after prehistoric fish came on land from the primordial soup and they’ve been going strong ever since. DLs are email only  and they’re a good way to send out company wide things like “There are donuts in the breakroom. Get here quick before Gary eats them all” or “The CEO is feeling generous and she’s giving everyone (except Gary) Friday off!”

To do this, create a new DL and make it a dynamic DL. This one is a little tricky. When you create a dynamic anything you have to provide a rule so that Azure AD (AAD) knows whether someone should be in the thing or not. In the case of a dynamic DL the way to get everyone is to create no rule. If there’s no rule, emails sent to that DL end up in every mailbox in your tenant. If you currently have any static DLs they cannot be changed to dynamic DLs, but they can be upgraded to Office 365 Groups. Dynamic DLs cannot be upgraded to Office 365 Groups. I’ve also had customers set one of these up and send News Digests from SharePoint Online to it. The owner of the dynamic DL does not need to be IT or have any elevated roles in the tenant.

How do I Create one?

There are a couple of different ways to create a dynamic DL. You can do it in the Exchange admin center in Office 365. Then navigate to the Groups tab. Next to New Microsoft 365 Group click the dropdown and select Dynamic distribution list.


The configuration will look something like this. Do not add a rule.


Once your dynamic DL is created there are some fun settings you can play with. For instance, you can moderate messages and have approved senders.

If you’re super cool, you can create dynamic DLs with PowerShell. First connect to Exchange Online PowerShell, then run New-DynamicDistributionGroup:

New-DynamicDistributionGroup -IncludedRecipients MailboxUsers -Name "Blog Lovers"

Doesn’t that feel better than using the UI? I thought so.

Security Groups and Microsoft 365 Groups

Both AAD Security Groups and Microsoft 365 Groups support dynamic membership, so they can be used the same way. A dynamic, all company, Microsoft 365 Group can be used for a site that you want everyone to have access to, and they’ll all get emails sent to that Group’s DL. Depending on how the Group is configured or how the users configure their mail client the Group’s emails may or may not show up in their Inbox. There will also be a Team for that Group that everyone will be in. Lots of ways to annoy everyone with one of these. I honestly can’t think of a way to leverage a Security Group in the context of Office 365, but I added since it’s the same process as the Office 365 Group, and it makes this blog post look that much longer.

How do I Create Them?

As we are all painfully aware, there are just shy of 117 different ways to create an Microsoft 365 Group. I think two more have been added since I started writing this blog post. There might be more than one way to create a dynamic Microsoft 365 Group, but I’m only going to cover how to do it in the Azure AD Portal and with Azure PowerShell. Navigate to the Groups blade and click "New group.” Under Membership type choose “Dynamic User”


If Membership type is greyed out that’s because the user creating the group does not have an Azure AD Premium license.

To set the rule, click “Edit dynamic query” button to get to the rules page. The rule we want is “user.objectId -ne null”. You can build that in the wizard at the top. Don’t worry about a user’s ID actually being “Null.” The rule knows the difference between null and “Null.” Ned Ull will not be the only member of the Group.


Once you tab out of the Value box the Save button will light up and you’ll be able to save the query and go back to creating your group. The process is the same for Security Groups.

But what about PowerShell?? I’m so glad you asked. Make sure you have the AzureAD module loaded and you’re connected as an account that can create Groups. Then run this little gem to create a Dynamic Microsoft 365 Group:

New-AzureADMSGroup -DisplayName "Dynamic M365 Group From PowerShell!" -Description "Dynamic group created with PowerShell!" -MailEnabled $true -MailNickName "Dynamic-M365-Group-From-PowerShell" -SecurityEnabled $True -GroupTypes "Unified","DynamicMembership" -MembershipRule "(user.objectId -ne null)" -MembershipRuleProcessingState "On"

If you only want a Security Group (I’m not sure why) change the –MailEnabled parameter to $false, and the –GroupTypes to only DynamicMembership, like this:

New-AzureADMSGroup -DisplayName "Dynamic Security Group From PowerShell!" -Description "Dynamic security group created with PowerShell!" -MailEnabled $false -MailNickName "Dynamic-Security365-Group-From-PowerShell" -SecurityEnabled $True -GroupTypes "DynamicMembership" -MembershipRule "(user.objectId -ne null)" -MembershipRuleProcessingState "On"

It is also possible to switch an existing static Security Group or Microsoft 365 Group to dynamic. It’s a long process, and this article does a good job explaining how. I don’t think there’s a way to convert a Security Group to a Microsoft 365 Group.

Happy Dynamic Group Creating!

Question #1: "Can you use Dynamic Groups with Audience targeting?"
Answer #1: Despite this Microsoft Support document saying otherwise, I was able to target links in both Global (top) Nav and Quick (left) Nav by audience with a Dynamic Microsoft 365 Group. 

Question #2: "Does the 'user.objectId -ne null' approach include Guests?"
Answer #2: I'm not sure, I'll look into that and update this blog post. 



Edit: 8/24/20 to add questions

July 29
Use PowerShell to Work with SharePoint 2010 Workflow Scan

Workflow Retirement Series TOC

Part 1 - SharePoint 2010 and 2013 Workflows Kaput in Office 365
Part 2 - Finding All the SharePoint 2010 Workflows in SharePoint Online
Part 3 - Find Only the Active SharePoint 2010 Workflows in SharePoint Online 
Part 4 - Use PowerShell to Work with SharePoint 2010 Workflow Scan

In Part 2 of my much beloved “Workflow Retirement Series” I covered how to scan your SharePoint Online environment for those pesky SharePoint 2010 workflows with the free SharePoint Modernization Scanner. I figured that was that. I was preparing to do my victory lap when I started getting some feedback. It seems some folks have a a lot of workflows in their environment, and a CSV file with a few hundred, or a few thousand rows isn’t terribly helpful. Now, once you get that CSV file into Excel you have one of the best data slicing and dicing tools invented by man at your disposal. You can slap a couple of filters on there, sort a few columns, hide a few others, and you can probably get whatever information you need. But I’m a PowerShell guy. I like to do things the hard way, with maximum typing. Let’s walk through what I did.

One of the reports the SharePoint Modernization Scanner makes is

ModernizationWorkflowScanResults.csv  and that’s the one I’m going to use. Since it’s a pretty well formed CSV file we can import it into an object without much fuss:

$results = Import-Csv .\ModernizationWorkflowScanResults.csv

As a gut check we can see how many rows we brought in:


You can also type $results[0] to see the first row, since it’s just an object. And since it’s an object, it has Members that we can exploit. What are those Members? I’m glad you asked:

$results | Get-Member


My eagle-eyed readers will notice that the NoteProperties are the column headers in the CSV file. To get my feet below me I did a simple Select to get a few properties:

$results | select "Definition Name",Version

You can add any of the columns you want. Remember to put quotes around the columns with spaces in the name.

$results | select "Definition Name","Subscription Name","List Title",Version,enabled

Depending on how your PowerShell host is configured that might be wide enough that might switch from table to list. To get it back to table pipe it through Format-Table:

$results | Select-Object "Definition Name","Subscription Name","List Title",Version,enabled,"Flow upgradability" | Format-Table –AutoSize


This report has both SharePoint 2010 and SharePoint 2013 workflows in it. The current fire is around SharePoint 2010 workflows, so let’s just look at those:

$results | Where-Object -Property version -EQ -Value "2010" | Select-Object "Definition Name","Subscription Name","List Title",Version,enabled,"Flow upgradability" | Format-Table -AutoSize

That should give you a better picture of the Herculean task in front of you. There’s one final piece I want to show you, and that’s how to see which sites have the most workflows:

$results | Where-Object -Property version -EQ -Value "2010" | Select-Object "Definition Name","List Title",enabled,"Site Url" | Group-Object -Property "Site Url" | Format-Table –AutoSize


This will help you figure out where to focus your efforts between now and November 1st.

Like I said at the beginning of this post, all of this and more is available in Excel and most of it has been done for you already in the Office 365 Classic workflow inventory.xlsx report that the SharePoint Modernization Scanner creates. But it’s a fun PowerShell exercise just the same.



1 - 10Next

 Subscribe to my Netcast


You can watch Shane and I's Cloudy Podcast live every Wednesday Morning at 10:00 am Central US time at

You can subscribe to the Podcast in the following ways:

MP3 Audio

Windows WMV video

YouTube Channel




 Todd's Upcoming Events

There are no items to show in this view of the "Events" list.